Od produktu i SBOM do decyzji oraz evidence
Źródło podatności wskazuje obserwację. Dopiero ocena człowieka w kontekście konkretnego wydania prowadzi do VEX, remediation lub przeglądu Article 14.
Operacyjny łańcuch: SBOM → źródło podatności → human triage
SBOM powinien być snapshotem konkretnego wydania, a nie jedną stale nadpisywaną listą. Dane z CVE, OSV lub importowanego skanera są obserwacjami źródłowymi. Dopiero analiza w kontekście produktu pozwala ustalić, czy dana wersja jest dotknięta, wymaga dalszego badania albo zawiera poprawkę.
- Product Inventory wskazuje produkt i właściciela
- Product Release ustala dokładną wersję
- SBOM opisuje komponenty tego wydania
- CVE, OSV lub skaner dostarcza obserwację
- human triage ocenia rzeczywisty wpływ
- VEX utrwala stanowisko i uzasadnienie
- Article 14 Review odrębnie ocenia trigger raportowy
- Evidence Vault zachowuje źródła, decyzje i historię
Integruj wyniki skanerów, nie buduj drugiego skanera
SCA i skanery takie jak Trivy, Snyk lub Dependency-Track nadal odpowiadają za wykrywanie i własne reguły. Warstwa CRA powinna importować ich wyniki, zachować typ źródła i czas obserwacji, a następnie powiązać rekord z właściwym komponentem oraz release'em. Brak dopasowania albo konflikt między źródłami powinien pozostać jawny.
- nie uruchamiaj kodu ani zależności podczas importu SBOM
- nie traktuj nazwy pakietu bez wersji jako pewnego dopasowania
- zachowuj wcześniejsze import runs i snapshoty
- oddzielaj source disposition od decyzji human triage
Cztery stany human triage
| Stan | Co oznacza | Minimalny dowód |
|---|---|---|
| UNDER_INVESTIGATION | Wpływ nie został jeszcze rozstrzygnięty | właściciel, zakres analizy i kolejny krok |
| AFFECTED | Analiza wskazuje wpływ na konkretne wydanie | uzasadnienie produktowe i plan działania |
| NOT_AFFECTED | Komponent występuje, ale analiza nie potwierdza wpływu | jawne uzasadnienie, np. nieużywana funkcja lub brak reachability |
| FIXED | Wpływ usunięto w określonym wydaniu | powiązany fixed release, testy i historia zmiany |
AFFECTED nie znaczy automatycznie „raportuj”
Article 14 dotyczy m.in. aktywnie wykorzystywanej podatności, o której producent uzyskał wiedzę. Sam rekord CVE, wynik OSV albo status AFFECTED nie dowodzi aktywnego wykorzystania i nie powinien automatycznie tworzyć zgłoszenia ani terminu. Potrzebny jest jawny Reportability Review oparty na faktach, roli podmiotu, zakresie CRA i czasie uzyskania wiedzy.
- ustal, czy produkt podlega CRA
- potwierdź rolę producenta
- oddziel exploitability od wiarygodnego dowodu aktywnego wykorzystania
- zapisz źródła i moment awareness
- dopiero potem przejdź do właściwego workflow raportowego
Minimalne kontrole operacyjne
- four-eyes dla finalnych decyzji AFFECTED, NOT_AFFECTED i FIXED
- wersjonowanie assessmentów i VEX bez nadpisywania historii
- tenant isolation dla źródeł, rationale i eksportów
- retencja powiązana z produktem i support period
- fail-closed przy częściowym imporcie lub niedostępności źródła
- audit trail dla każdej zmiany stanu i aprobaty
CRA vulnerability management – FAQ
Czy wykrycie CVE oznacza, że produkt jest podatny?
Nie. CVE lub rekord OSV jest sygnałem źródłowym dotyczącym komponentu albo wersji. Rzeczywisty wpływ na produkt wymaga human triage w kontekście konkretnego release'u, użytej funkcji, konfiguracji i zabezpieczeń.
Czy status AFFECTED automatycznie uruchamia Article 14?
Nie. AFFECTED opisuje ocenę wpływu na produkt. Article 14 wymaga odrębnej analizy ustawowych przesłanek, w tym aktywnego wykorzystania, zakresu CRA, roli producenta oraz momentu uzyskania wiedzy.
Czy CRA Workspace zastępuje skaner podatności?
Nie. Workspace importuje i porządkuje wyniki zewnętrznych źródeł lub skanerów. Nie skanuje repozytorium i nie zastępuje Snyk, Trivy ani Dependency-Track.
Oficjalne źródła
Podstawa materiału została sprawdzona 1 września 2026.