Od human triage do dowodu wdrożenia poprawki
Workspace łączy ocenę AFFECTED z planem naprawy, konkretnym fixed release'em, ręcznie udokumentowanym rolloutem i evidence zamknięcia. Article 14 pozostaje odrębnym przeglądem przesłanek.
Dlaczego samo FIXED nie wystarcza?
Status FIXED przy komponencie lub CVE nie pokazuje jeszcze, czy poprawka znalazła się w konkretnym Product Release ani czy została udostępniona użytkownikom wspieranych wersji. Operacyjny ślad powinien rozdzielać decyzję o wpływie, wykonanie poprawki, publikację wydania, dystrybucję aktualizacji i zamknięcie oparte na evidence.
- zachowaj dokładną wersję human assessment w stanie AFFECTED
- przypisz właściciela, strategię i termin remediation
- wskaż target release oraz rzeczywisty fixed release
- zapisz kanał rollout i źródło danych o postępie
- dołącz dowody testów, publikacji i dystrybucji
- zamknięcie pozostaw jawnej decyzji człowieka
Workflow: od findingu do closure evidence
| Etap | Co zapisać | Granica |
|---|---|---|
| CVE / finding | źródło, komponent, affected Product Release i czas obserwacji | sygnał nie jest automatyczną decyzją o wpływie |
| Human Triage | wersjonowany assessment AFFECTED z rationale i evidence | AFFECTED nie uruchamia automatycznie Article 14 |
| Remediation Case | owner, deadline, strategia, plan i target release | plan nie potwierdza jeszcze usunięcia podatności |
| Fixed Release | konkretne wydanie z poprawką, testy i evidence | wydanie poprawki nie dowodzi jej wdrożenia u odbiorców |
| Update Rollout | kanał, rozpoczęcie, populacja docelowa i zaktualizowana | wartości są źródłowymi twierdzeniami, nie telemetryką Workspace |
| Evidence / Closure | raport OTA, deployment log, plik, wersja decyzji i niezależny review | zamknięcie operacyjne nie jest conformity assessment |
| Article 14 | jawne source facts przekazane do odrębnego Reportability Review | brak automatycznego deadline'u, zgłoszenia lub final report |
Co powinien zawierać Remediation Case?
Case powinien wiązać się z dokładną, sfinalizowaną wersją assessmentu AFFECTED. Kolejne zmiany planu lub rollout tworzą historię wersji zamiast nadpisywać wcześniejsze decyzje.
- vulnerability assessment i affected product/release
- owner oraz deadline
- remediation strategy i uzasadnienie
- target Product Release
- fixed Product Release po publikacji poprawki
- rollout channel, start i completion
- wersjonowane odwołania do Evidence Vault
- status: PLANNED, IN_PROGRESS, FIX_RELEASED, ROLLING_OUT, COMPLETED albo ACCEPTED_RISK
Jak dokumentować update rollout bez telemetryki urządzeń?
Na początek wystarczy kontrolowany zapis wartości pochodzących z istniejących systemów wdrożeniowych. Dla przykładu: target population 15 000, updated 12 840 i wynik 85,6%. Każda liczba powinna mieć nazwane źródło, czas obserwacji i evidence, takie jak raport OTA, deployment log, PDF, CSV albo screenshot.
CRA nie ustanawia jednego obowiązkowego wskaźnika rollout percentage dla wszystkich produktów. Taki pomiar jest praktyką operacyjną pomagającą udokumentować dystrybucję aktualizacji i ocenić jej skuteczność; jego znaczenie zależy od produktu, kanału i dostępnych danych.
Remediation i rollout w CRA Workspace
Workspace pozwala udokumentować proces remediation i dystrybucji aktualizacji oraz zachować evidence działań podejmowanych w cyklu vulnerability handling. Korzysta z istniejących Product Releases, vulnerability assessments, VEX, Evidence Vault, RBAC, audit trail i Article 14 Review — nie tworzy drugiego systemu vulnerability management.
- Remediation Case wyłącznie dla sfinalizowanego assessmentu AFFECTED
- target i fixed release z istniejącego Product Inventory
- manualny rollout progress z jawnym provenance
- closure evidence przechowywane w Evidence Vault
- four-eyes dla terminalnego COMPLETED lub ACCEPTED_RISK
- source facts dla Article 14 bez automatycznej konkluzji
Remediation i update rollout — FAQ
Znaleźliśmy i naprawiliśmy podatność — jak udokumentować, że poprawka została rzeczywiście wdrożona?
Powiąż assessment AFFECTED z Remediation Case, wskaż target i fixed Product Release, zapisz kanał oraz zakres rollout, a następnie dołącz wersjonowane evidence publikacji i dystrybucji. Decyzja o zamknięciu powinna wskazywać źródła, autora i niezależnego reviewera.
Czy trzeba śledzić rollout percentage?
CRA nie wskazuje jednego obowiązkowego procentowego wskaźnika rollout dla wszystkich produktów. Producent powinien jednak skutecznie obsługiwać podatności i bezpiecznie dystrybuować aktualizacje. Pomiar postępu może być użytecznym dowodem operacyjnym, jeżeli jego źródło i zakres są jawne.
Czy fixed release oznacza, że remediation jest zakończone?
Nie zawsze. Fixed release potwierdza wskazane wydanie zawierające poprawkę, ale nie pokazuje automatycznie, czy aktualizacja została udostępniona lub wdrożona w docelowej populacji. Dlatego publikację, rollout i closure evidence warto prowadzić jako osobne etapy.
Czy status AFFECTED automatycznie uruchamia zgłoszenie Article 14?
Nie. AFFECTED jest oceną wpływu podatności na konkretne wydanie. Article 14 wymaga osobnego Reportability Review ustawowych przesłanek, w tym dostępnych faktów dotyczących aktywnego wykorzystania lub incydentu i momentu uzyskania wiedzy.
Jakie dowody można dołączyć do update rollout?
Przykładami są raport OTA, log wdrożenia, potwierdzenie publikacji w repozytorium lub sklepie, CSV z systemu dystrybucji, raport serwisowy albo screenshot. Każdy materiał powinien mieć zachowaną wersję, źródło, datę i zakres.
Czy COMPLETED oznacza zgodność produktu z CRA?
Nie. COMPLETED jest stanem operacyjnym konkretnego Remediation Case. Nie stanowi opinii prawnej, conformity assessment, certyfikacji ani deklaracji zgodności produktu z CRA.
Oficjalne źródła
Podstawa materiału została sprawdzona 2 września 2026.