Czym jest CRA evidence mapping?
To robocze powiązanie: wymaganie z Annex I → proces lub działanie → przykładowy dowód → produkt i release → wynik przeglądu. Oddzielnie zapisuje się dokument normalizacyjny, jego wersję i status. Wypełniony wiersz nie jest automatycznym potwierdzeniem spełnienia wymagania.
Poniższy szablon jest autorskim przykładem operacyjnym do ręcznego użycia. Nie odtwarza treści norm, nie mapuje ich konkretnych punktów i nie jest oficjalną macierzą CEN-CENELEC. Nie ogłaszamy tutaj wdrożonego modułu Standards Evidence Mapping v1 ani automatycznej oceny w checkerach.
Dlaczego punktem wyjścia jest Annex I, a nie etykieta normy?
CRA rozdziela wymagania dotyczące właściwości produktu w części I załącznika I i obsługi podatności w części II. Nazwa dokumentu normalizacyjnego nie zastępuje analizy, które wymagania odnoszą się do konkretnego produktu.
Publiczne materiały CEN-CENELEC pokazują kierunek: część 1-2 dla ram ryzyka i cyklu życia, 1-3 dla obsługi podatności, 1-4 dla wymagań i zabezpieczeń. Na tej podstawie można grupować pracę, ale przypisanie do punktu normy wymaga analizy właściwej wersji jej tekstu przez kompetentną osobę. Slajd webinaru nie jest treścią normatywną.
Przykładowa mapa: CRA Annex I → proces → evidence
To wybór obszarów, a nie pełna lista kontrolna CRA. Artefakty w ostatniej kolumnie są przykładami; ich wystarczalność zależy od zakresu produktu, ryzyka i wyników przeglądu. Odniesienia do EN 40000 wskazują obszar tematyczny, nie dowiedzioną zgodność z konkretną klauzulą.
| Obszar CRA | Działanie zespołu | Kierunek EN 40000 | Przykładowe dowody |
|---|---|---|---|
| Annex I, część I, pkt 1 — bezpieczeństwo oparte na ryzyku | Ocena scenariusza ryzyka i wybór zabezpieczenia | 1-2: ryzyko i cykl życia | Wersjonowana ocena, decyzja właściciela, wynik testu zabezpieczenia |
| Część I, pkt 2(b) — bezpieczna konfiguracja domyślna | Przegląd konfiguracji konkretnego wydania | 1-2: działania lifecycle; projekt 1-4: zabezpieczenia | Baseline ustawień, test instalacji, opis uzasadnionego wyjątku |
| Część I, pkt 2(d) — ochrona przed nieautoryzowanym dostępem | Weryfikacja kontroli dostępu | Projekt 1-4: obszar zabezpieczeń | Model uprawnień, test negatywny, log i review wyniku |
| Część II, pkt 1 — komponenty, podatności i SBOM | Ustalenie składu konkretnego release'u | Projekt 1-3: obszar obsługi podatności | SBOM, pochodzenie artefaktu, zapis ograniczeń kompletności |
| Część II, pkt 2 — obsługa i usuwanie podatności | Triage oraz decyzja o poprawce | Projekt 1-3: obszar obsługi podatności | Uzasadnienie affectedness, remediation, fixed release i test |
| Część II, pkt 3 — regularne testy i przeglądy | Przegląd bezpieczeństwa produktu | 1-2: cykl życia; projekt 1-3: obsługa podatności | Plan i wynik testu z wersją środowiska oraz listą braków |
| Część II, pkt 5 — coordinated vulnerability disclosure | Obsługa zgłoszenia badacza | Projekt 1-3: obszar obsługi podatności | Polityka CVD, historia kontaktu i decyzje triage |
| Część II, pkt 7–8 — dystrybucja aktualizacji | Weryfikacja kanału i udostępnienia poprawki | 1-2: release; projekt 1-3: obsługa podatności | Test aktualizacji, komunikat użytkownika, dowód udostępnienia |
Co zapisać przy każdym powiązaniu wymagania i dowodu?
Zapis musi pozwalać odtworzyć decyzję. Link do żywego dokumentu może później prowadzić do innej treści, dlatego warto zachować identyfikator wersji albo kontrolowany snapshot. Gdy brakuje danych, wpisz brak i następny krok zamiast statusu „spełnione”.
- Dokładne wymaganie CRA oraz uzasadnienie, czy dotyczy produktu.
- Produkt, wariant klientowski, release i zakres konfiguracji.
- Działanie oraz oczekiwany wynik — przed sprawdzeniem dowodu.
- Dowód, źródło, data, wersja i ograniczenia jego zastosowania.
- Właściciel zadania, termin i osoba wykonująca przegląd.
- Oddzielne statusy: brak dowodu, częściowy, wymaga przeglądu, przegląd wykonany albo nie dotyczy z uzasadnieniem.
- Dokument EN, jego wydanie, etap prac i osobno informacja o ewentualnym cytowaniu w OJEU.
Dwa wdrożenia klientowskie nie zawsze mają te same dowody
Przykład: klient A korzysta z release'u 5.1, a klient B z 5.3 z dodatkowym API. Test kontroli dostępu dla 5.1 może nie obejmować nowego endpointu klienta B. W mapie należy pozostawić to jako lukę do przeglądu, nawet jeżeli oba wdrożenia należą do tego samego produktu.
Podobnie poprawka biblioteki zastosowana jako backport wymaga dowodu dla właściwego artefaktu. Wspólna nazwa produktu, zamknięty ticket lub numer CVE nie pozwalają przenieść wyniku weryfikacji na wszystkie forki. Zapisz, gdzie dowód ma zastosowanie i gdzie potrzebny jest nowy test.
Przegląd dowodu nie oznacza harmonised-standard conformity
Status dowodu opisuje pracę zespołu. Status normy opisuje etap dokumentu. Ocena zgodności produktu jest odrębnym procesem. Nie łącz tych trzech rzeczy w jeden zielony wskaźnik.
W szczególności samo mapowanie do części 1-2 nie daje domniemania zgodności. Także późniejsza ratyfikacja nie zastąpi sprawdzenia cytowania oraz zakresu normy. Wiersz „przegląd wykonany” powinien zachować wynik, zastrzeżenia i autora, a nie deklarować spełnienie całego CRA.
Raportowanie z art. 14 ma własne przesłanki i terminy. Brak gotowej mapy norm nie uzasadnia odłożenia wymaganego zgłoszenia. Proces raportowy i przygotowanie dokumentacji produktowej prowadź jako powiązane, lecz odrębne ścieżki.
Od ręcznej mapy do uporządkowanych rekordów Workspace
W modelu CRA Workspace Requirement Board, Product Releases, Product Cyber Risk i Evidence Vault pomagają połączyć wymagania, decyzje oraz dowody z produktem. Można zacząć od jednego release'u i kilku najważniejszych obszarów, zamiast importować zbiór dokumentów bez określenia ich zakresu.
Odniesienia do EN 40000 w tym artykule są propozycją ręcznej struktury analizy. Nie stanowią automatycznego mapowania norm w Workspace ani nowego wyniku checkera. Dostępność istniejących modułów zależy od planu; Workspace nie zastępuje osoby oceniającej dowody ani właściwej procedury oceny zgodności.
Mapowanie dowodów CRA — FAQ
Czy mapa Annex I to ocena zgodności CRA?
Nie. Mapa porządkuje wymagania i dowody. Nie zastępuje przeglądu ich wystarczalności ani właściwej procedury oceny zgodności.
Czy tabela jest oficjalnym mapowaniem EN 40000?
Nie. To autorski przykład operacyjny oparty na wymaganiach CRA i publicznym opisie kierunku prac. Nie zawiera mapowania do konkretnych klauzul norm.
Czy SBOM wystarczy jako dowód dla całego Annex I?
Nie. SBOM opisuje komponenty w określonym zakresie. Nie zastępuje oceny ryzyka, testów zabezpieczeń, decyzji o podatności ani dowodów udostępnienia poprawki.
Jak oznaczyć brakujące albo nieaktualne evidence?
Zachowaj brak lub potrzebę przeglądu, wyznacz właściciela i następny krok. Nie zmieniaj braku danych w potwierdzenie, że wymaganie zostało spełnione.
Czy CRA Workspace automatycznie mapuje evidence do EN 40000?
Ten artykuł nie ogłasza takiej funkcji. Opisuje ręczny sposób uporządkowania analizy; istniejące moduły Workspace należy sprawdzić na stronie produktu i w zakresie swojego planu.
Oficjalne źródła
Podstawa materiału została sprawdzona 7 października 2026.