CRA Ocena ryzyka cyberbezpieczeństwa: przewodnik i szablon

Każdy producent produktu z elementami cyfrowymi objętego zakresem CRA musi przeprowadzić ocenę ryzyka cyberbezpieczeństwa i prowadzić ją w formie pisemnej. To dokument, który rozstrzyga, które wymagania bezpieczeństwa CRA wiążą dany produkt i w jaki sposób są spełniane. Organy nadzoru rynku mogą go zażądać. Bez niego dokumentacja techniczna jest niekompletna, a deklaracja zgodności nie ma podstawy.

Ten przewodnik wyjaśnia, jak przeprowadzić ocenę, jak ją udokumentować i jak utrzymać jej aktualność. Zawiera pełne mapowanie wymagań bezpieczeństwa, przykład z życia oraz gotowy do skopiowania szkielet dokumentu.

Czym jest ocena ryzyka cyberbezpieczeństwa CRA?

Ocena ryzyka cyberbezpieczeństwa to udokumentowana analiza ryzyk, na jakie narażony jest produkt, oparta na jego przeznaczeniu i sposobach użycia, jakich można się racjonalnie spodziewać. Obejmuje warunki użytkowania, takie jak środowisko eksploatacji i aktywa, które produkt musi chronić, oraz uwzględnia oczekiwany czas użytkowania produktu.

Ocena ma jeden wynik, od którego zależy wszystko inne. Dla każdego wymagania bezpieczeństwa produktu w CRA stwierdza, czy dane wymaganie ma zastosowanie, a jeśli tak, jak realizuje je projekt i procesy producenta. Zapisuje też, w jaki sposób spełniony jest podstawowy poziom secure-by-design i jak procesy obsługi podatności obejmują produkt.

Trzy cechy odróżniają ją od ogólnego, firmowego rejestru ryzyk:

• Jest specyficzna dla produktu. Opiera się na architekturze, interfejsach i użytkownikach danego produktu. Ogólnofirmowy rejestr ryzyk SZBI jej nie zastępuje. Nasze porównanie z ISO 27001 opisuje tę lukę szczegółowo.
• Jest dokumentem cyklu życia. Wykorzystywana jest podczas planowania i projektowania, nie tylko przy wydaniu. Aktualizowana jest przez cały okres wsparcia.
• Jest dowodem. Udokumentowana ocena trafia do dokumentacji technicznej, skąd mogą zażądać jej organy.

Kto jej potrzebuje i kiedy

Każdy producent wprowadzający produkt z elementami cyfrowymi na rynek UE jej potrzebuje, chyba że produkt w ogóle nie mieści się w zakresie CRA. W zakresie: sprzęt z firmware'em, samodzielne oprogramowanie oraz produkty, których część oferty stanowi zdalne przetwarzanie danych. Dotyczy jednoosobowej firmy programistycznej tak samo jak korporacji międzynarodowej. Produkty wyłączone przez CRA, takie jak objęte odrębną regulacją wyroby medyczne, niektóre pojazdy i certyfikowany sprzęt lotniczy, podlegają zamiast tego własnym przepisom sektorowym. W razie wątpliwości, czy CRA w ogóle obejmuje dany produkt, zacznij od przewodnika po zakresie.

Harmonogram ma większe znaczenie, niż zakłada większość zespołów:

• Zacznij w fazie planowania. Ocena ma kierować decyzjami projektowymi. Przeprowadź pierwszy przebieg, gdy zmiana architektury jest jeszcze tania.
• Zakończ i udokumentuj ją przed wprowadzeniem do obrotu. Pisemna ocena musi znajdować się w dokumentacji technicznej w chwili wysyłki produktu.
• Utrzymuj ją przez cały okres wsparcia. Ocena nigdy nie jest ostateczna. Towarzyszy produktowi tak długo, jak długo trwa obowiązek dostarczania aktualizacji bezpieczeństwa.

Istnieje jedno wąskie uproszczenie. Obejmuje wyłącznie produkty, które CRA traktuje jako systemy AI wysokiego ryzyka i które jednocześnie podlegają innym przepisom UE wymagającym oceny ryzyka. Dla nich ocena cyberbezpieczeństwa może stać się częścią tamtej innej oceny ryzyka, zamiast osobnym dokumentem. Obowiązki co do treści pozostają takie same. Zobacz przewodnik o nakładaniu się CRA i aktu w sprawie AI, aby zobaczyć, jak to działa w praktyce.

Co musi zawierać ocena

CRA ustala minimalny zakres treści. Ocena musi obejmować trzy elementy:

• Produkt w kontekście. Do czego służy produkt, jakiego użycia można się racjonalnie spodziewać, w jakim środowisku działa, jakie aktywa musi chronić i jak długo ma pozostawać w użyciu.
• Decyzje o stosowalności. Dla każdego z 13 wymagań bezpieczeństwa produktu: czy ma zastosowanie do tego produktu i jak jest wdrożone. Tam, gdzie nie ma zastosowania, jasne pisemne uzasadnienie.
• Pokrycie procesów. Jak spełniony jest podstawowy poziom secure-by-design i jak procesy obsługi podatności obejmują produkt.

Obowiązek uzasadnienia jest kluczowy. „Nie dotyczy” bez podania powodu to błąd. Nazwij fakty dotyczące produktu, które wyłączają dane wymaganie, i zapisz je. Pisemne uzasadnienie trafia do dokumentacji technicznej razem z resztą oceny.

Poza tym prawnym minimum warto dodać elementy, które czynią dokument obronnym: decyzje o postępowaniu z ryzykiem wraz z ryzykiem rezydualnym, kryteria akceptacji, nazwane zatwierdzenie z datą oraz historię wersji. CRA nie narzuca żadnego z nich. To one pokazują, że ocena pozostaje aktualna i że ktoś odpowiedzialny zaakceptował pozostałe ryzyko.

Wybór metody

CRA nie narzuca metodyki oceny, skali punktowej ani szablonu. Wymaga udokumentowanego wyniku, który wspiera decyzje o stosowalności. Wybierz metodę, którą zespół może powtarzać, i opisz ją w ocenie, aby recenzent mógł prześledzić tok rozumowania.

Niezależnie od wyboru obowiązuje jedna zasada. Każde ryzyko trzeba wyrazić jako połączenie jego prawdopodobieństwa i skali skutku, czyli straty lub zakłócenia, jakie mogłoby spowodować. CRA ujmuje ryzyko cyberbezpieczeństwa dokładnie w tych dwóch wymiarach, więc lista zagrożeń, która nie ocenia żadnego z nich, nie jest jeszcze oceną.

Sprawdzone opcje:

Metoda	Co daje	Najlepiej pasuje
Macierz prawdopodobieństwo x skutek	Proste liczbowe oceny ryzyka i uszeregowany rejestr	Małe zespoły, pierwsze oceny
Modelowanie zagrożeń w stylu STRIDE	Systematyczna identyfikacja zagrożeń dla każdego komponentu i przepływu danych	Produkty z dużą ilością oprogramowania i jasnymi diagramami architektury
Proces w stylu ISO/IEC 27005	Pełny cykl zarządzania ryzykiem: kontekst, analiza, postępowanie	Organizacje, które już prowadzą SZBI
Podejście zagrożenie-ryzyko IEC 62443	Analiza stref i kanałów dla kontekstów przemysłowych	Produkty przemysłowe i OT, zobacz przewodnik po automatyce przemysłowej

Nadchodzące normy zharmonizowane nie zmienią swobodnego wyboru metody. Projekt europejskiej normy ramowej dla zarządzania ryzykiem CRA jest sam w sobie neutralny wobec metody: opiera się na procesie ryzyka ISO 31000, nie narzucając modelu punktacji. Nasz tracker norm zharmonizowanych śledzi jego postęp. Normy nigdy też nie zastępują oceny: nawet produkt, który w pełni stosuje normy zharmonizowane, potrzebuje własnej udokumentowanej oceny, a trzeba sprawdzić, czy normy obejmują ryzyka, które faktycznie zidentyfikowano.

Niezależnie od wyboru, trzymaj się dwóch zasad:

1. Metoda musi dawać odpowiedzi o stosowalności. Stos ocenionych ryzyk to za mało. Wynik musi mapować się na 13 wymagań bezpieczeństwa poniżej.
2. Opisz metodę. Definicje skali, formuła, progi akceptacji. Ocena „12 (Wysokie)” nic nie znaczy, jeśli skala nie jest udokumentowana. Zapis powinien pozwolić organowi nadzoru rynku zweryfikować, jak każde ryzyko zidentyfikowano, oceniono i potraktowano.

Ocena krok po kroku

Sprawdzony proces w siedmiu krokach. Dostosuj głębokość analizy do złożoności i ryzyka produktu.

Krok 1: Zakres i kontekst

Zapisz nazwę i wersję produktu, jego przeznaczenie, środowiska, w których będzie działać, oraz jego użytkowników. Określ, co wchodzi w zakres, w tym aplikacje towarzyszące, backendy chmurowe będące częścią oferty i dołączone komponenty. Określ, co jest poza zakresem i dlaczego.

Krok 2: Aktywa

Wypisz, co produkt musi chronić. Typowe aktywa to dane użytkownika, dane uwierzytelniające i klucze, integralność firmware'u i konfiguracji, dostępność funkcji produktu oraz otaczająca sieć. Zanotuj, gdzie znajduje się każde aktywo i jak się przemieszcza.

Krok 3: Zagrożenia

Przejdź przez architekturę powierzchnia po powierzchni. Najpierw interfejsy zewnętrzne, bo od nich zaczynają atakujący. Dla każdego interfejsu i przepływu danych zadaj pytanie, co mógłby zrobić atakujący: przechwycić, podszyć się, zmanipulować, zalać ruchem, wydobyć dane. Uwzględnij przewidywalne niewłaściwe użycie produktu, nie tylko celowy atak. Zapisz każde wiarygodne zagrożenie wraz z podatnością, którą by wykorzystało.

Krok 4: Ocena ryzyk

Oceń prawdopodobieństwo i skutek dla każdego zagrożenia, korzystając z udokumentowanej skali. Tam, gdzie incydent mógłby spowodować szkodę fizyczną, uwzględnij w ocenie skutku wpływ na zdrowie i bezpieczeństwo użytkowników. Uszereguj wyniki. Sens oceny to priorytetyzacja, nie precyzja. Obronny ranking, który wpływa na decyzje projektowe, jest wart więcej niż pozornie precyzyjna tabela, z której nikt nie korzysta.

Krok 5: Stosowalność wymagań bezpieczeństwa

Przejdź kolejno przez 13 wymagań bezpieczeństwa produktu. Dla każdego określ, czy ma zastosowanie do tego produktu, które ze zidentyfikowanych ryzyk obejmuje i jak jest wdrożone. Tam, gdzie faktycznie nie ma zastosowania, zapisz uzasadnienie. Pełna tabela mapowania poniżej służy jako arkusz roboczy.

Krok 6: Postępowanie z ryzykiem i ryzyko rezydualne

Dla każdego istotnego ryzyka zapisz wybrane zabezpieczenie, miejsce jego wdrożenia oraz ryzyko rezydualne po zastosowaniu zabezpieczenia. Zdefiniuj kryteria akceptacji i zapisz, kto zaakceptował pozostałe ryzyko. Ryzyka bez zabezpieczenia wymagają jawnej, przypisanej do konkretnej osoby decyzji o akceptacji.

Krok 7: Zatwierdzenie i wyzwalacze aktualizacji

Wyznacz właściciela, który zatwierdzi ocenę, z datą. Następnie zdefiniuj zdarzenia, które ją ponownie otwierają: nowe informacje o podatnościach, nowe funkcje, zmiany komponentów lub dostawców, ustalenia z incydentów. Dodaj tabelę historii wersji, aby organy widziały, że dokument żyje.

Mapowanie 13 wymagań bezpieczeństwa

To centrum oceny. CRA wymienia 13 wymagań bezpieczeństwa produktu, a dokument musi odpowiedzieć na dwa pytania dla każdego z nich: czy ma zastosowanie i jak jest wdrożone. Poniższa tabela przekłada każde wymaganie na pytania kontrolne i typowe dowody.

Kolumna z wymaganiem pozostaje blisko brzmienia przepisu. Kolumna z zabezpieczeniami nie jest częścią prawa: wymienia środki i dowody, których zespoły zwykle używają, by wykazać spełnienie wymagania.

Dwie praktyczne uwagi do tabeli:

• „Tam, gdzie ma zastosowanie” to decyzja podejmowana dla konkretnego produktu, którą trzeba umieć obronić. Wymagania mają zastosowanie na podstawie oceny ryzyka. Samodzielne narzędzie programowe, które nie przechowuje żadnych danych ani ustawień, może uzasadnić wyłączenie wymagania dotyczącego usuwania danych. Żaden produkt nie może wyłączyć zdolności do aktualizacji tylko dlatego, że aktualizacje są niewygodne.
• Mapowanie pełni jednocześnie rolę indeksu dowodów zgodności. Kolumna zabezpieczeń w każdym wierszu wskazuje, co powinno trafić do dokumentacji technicznej, i to właśnie ten materiał bada ocena zgodności.

Pokrycie procesów obsługi podatności

Ocena musi też stwierdzać, jak bieżące procesy obejmują produkt. Wymagania procesowe CRA to operacyjna strona tego samego zagadnienia. Ocena powinna krótko potwierdzać, z odniesieniami do dokumentów źródłowych, że dla tego produktu:

• identyfikowane i dokumentowane są podatności i komponenty, w tym SBOM obejmujący co najmniej zależności najwyższego poziomu
• podatności są usuwane bez zbędnej zwłoki, a aktualizacje bezpieczeństwa dostarczane są osobno od aktualizacji funkcji, tam gdzie jest to technicznie wykonalne
• stosowane są skuteczne i regularne testy oraz przeglądy bezpieczeństwa produktu
• po wydaniu aktualizacji publicznie ujawniana jest usunięta podatność wraz z opisem, dotkniętymi produktami, skutkami, poziomem powagi i pomocą w usunięciu. Uzasadnione opóźnienie jest dopuszczalne, gdy ryzyko bezpieczeństwa związane z publikacją przewyższa korzyści, i tylko do momentu, gdy użytkownicy mieli możliwość zastosowania łatki
• prowadzona jest polityka skoordynowanego ujawniania podatności
• udostępniony jest adres kontaktowy do zgłoszeń podatności, a informacje o potencjalnych podatnościach mogą swobodnie płynąć, także dla komponentów stron trzecich
• aktualizacje dystrybuowane są przez bezpieczne mechanizmy, tak aby poprawki docierały terminowo, automatycznie tam, gdzie dotyczy to aktualizacji bezpieczeństwa
• aktualizacje bezpieczeństwa rozpowszechniane są bez zbędnej zwłoki i bezpłatnie, wraz z komunikatami doradczymi informującymi użytkowników, co robić. Dla produktu szytego na miarę klient biznesowy może ustalić inaczej wyłącznie w kwestii bezpłatności

Te punkty to robocze podsumowania, nie pełne brzmienie przepisu. Tę sekcję oceny warto utrzymać krótką, z odesłaniem do dokumentów źródłowych procesów, a pełne wymagania sprawdzić w przewodniku po obsłudze podatności.

Przykład z życia

Poniższe fragmenty pokazują poziom szczegółowości, który sprawdza się w praktyce. Produktem jest fikcyjny podłączony czujnik środowiskowy z aplikacją towarzyszącą i pulpitem w chmurze.

Fragment rejestru ryzyk

OCENA RYZYKA CYBERBEZPIECZEŃSTWA

Produkt: SmartSense Pro (SSP-3000)
Wersja: 2.4.1
Data oceny: styczeń 2027
Właściciel: [Imię i nazwisko, Zespół Bezpieczeństwa]

METODA:
Prawdopodobieństwo x skutek, skale zdefiniowane w sekcji 1.
Ryzyko = Prawdopodobieństwo (1-5) x Skutek (1-5)
Pasma: Niskie (1-4), Średnie (5-9), Wysokie (10-16), Krytyczne (17-25)

-------------------------------------------------------------
ID RYZYKA: R-001
ZAGROŻENIE: Nieautoryzowana modyfikacja firmware'u
PODATNOŚĆ: Możliwość zainstalowania niepodpisanego firmware'u
SKUTEK: 5 - Kompromitacja urządzenia, wyciek danych
PRAWDOPODOBIEŃSTWO: 3 - Wymaga dostępu fizycznego lub do sieci lokalnej
RYZYKO PIERWOTNE: 15 (Wysokie)

ZABEZPIECZENIE: Weryfikacja podpisu firmware'u
WDROŻENIE: Podpis ECDSA P-256 sprawdzany przed instalacją
RYZYKO REZYDUALNE: 3 (Niskie) - Atak kryptograficzny mało prawdopodobny
STATUS: Zminimalizowane
-------------------------------------------------------------
ID RYZYKA: R-002
ZAGROŻENIE: Przechwycenie komunikacji z chmurą
PODATNOŚĆ: Ruch sieciowy czytelny w trakcie transmisji
SKUTEK: 4 - Ujawnienie danych, wstrzyknięcie poleceń
PRAWDOPODOBIEŃSTWO: 3 - Oczekiwane sieci współdzielone i publiczne
RYZYKO PIERWOTNE: 12 (Wysokie)

ZABEZPIECZENIE: TLS 1.3 z przypinaniem certyfikatu
WDROŻENIE: Przypięty certyfikat CA, brak mechanizmu zapasowego
RYZYKO REZYDUALNE: 2 (Niskie) - Kompromitacja certyfikatu mało prawdopodobna
STATUS: Zminimalizowane
-------------------------------------------------------------
[Kontynuacja dla wszystkich zidentyfikowanych ryzyk...]

PODSUMOWANIE RYZYK:
Liczba zidentyfikowanych ryzyk: 23
Krytyczne: 0
Wysokie: 3 (wszystkie zminimalizowane do Niskiego lub Średniego)
Średnie: 8 (wszystkie zminimalizowane do Niskiego)
Niskie: 12 (zaakceptowane lub zminimalizowane)

AKCEPTACJA RYZYKA REZYDUALNEGO:
Wszystkie ryzyka rezydualne mieszczą się w tolerancji zdefiniowanej w sekcji 1.
Zaakceptowane przez: [Kierownik ds. Bezpieczeństwa], [Data]

Fragment zapisu stosowalności

STOSOWALNOŚĆ WYMAGAŃ BEZPIECZEŃSTWA

WYM. 3 - AKTUALIZACJE BEZPIECZEŃSTWA
Dotyczy: TAK
Ryzyka objęte: R-004, R-011
Wdrożenie: Podpisane aktualizacje OTA. Automatyczne aktualizacje
bezpieczeństwa włączone domyślnie, opcja rezygnacji i odroczenia
w ustawieniach aplikacji. Użytkownicy powiadamiani w aplikacji i e-mailem.
Dowód: Projekt mechanizmu aktualizacji UMD-002

WYM. 12 - REJESTROWANIE ZDARZEŃ I MONITOROWANIE
Dotyczy: TAK
Ryzyka objęte: R-009
Wdrożenie: Zdarzenia bezpieczeństwa (nieudane logowania, zmiany
konfiguracji, zdarzenia aktualizacji) rejestrowane na urządzeniu
i przekazywane do chmury. Opcja rezygnacji z rejestrowania dostępna
w ustawieniach prywatności.
Dowód: Projekt rejestrowania LD-001, katalog zdarzeń

WYM. 13 - BEZPIECZNE USUWANIE DANYCH
Dotyczy: TAK
Ryzyka objęte: R-015
Wdrożenie: Przywrócenie ustawień fabrycznych trwale usuwa wszystkie
przechowywane dane i ustawienia, w tym dane uwierzytelniające sieci.
Urządzenie nie przechowuje danych użytkownika możliwych do przeniesienia,
więc ścieżka transferu nie istnieje.
Dowód: Projekt resetu i czyszczenia RD-001

[Kontynuacja dla wszystkich 13 wymagań...]

Zwróć uwagę na wpis dotyczący usuwania danych: wymaganie obejmuje wszystkie dane i ustawienia, a przechowywane dane uwierzytelniające sieci też się liczą. Tam, gdzie wymaganie faktycznie nie ma zastosowania, wpis zachowuje ten sam kształt, ale nazywa fakty dotyczące produktu, które je wyłączają. Samodzielne narzędzie programowe bez przechowywanych danych i ustawień mogłoby zapisać: „Nie dotyczy. Produkt nie przechowuje danych ani ustawień. Nie ma nic do usunięcia.” To właśnie to zdanie oparte na faktach organ może ocenić.

Szkielet dokumentu

Struktura do skopiowania na potrzeby pisemnej oceny:

OCENA RYZYKA CYBERBEZPIECZEŃSTWA - [Produkt, wersja]

1. METODA
   Skale, formuła, pasma ryzyka, progi akceptacji

2. KONTEKST PRODUKTU
   Przeznaczenie / Przewidywalne użycie i niewłaściwe użycie
   Środowisko eksploatacji / Użytkownicy
   Aktywa do ochrony
   Oczekiwany czas użytkowania
   Zakres: uwzględnione komponenty, wyłączenia z uzasadnieniem

3. ARCHITEKTURA I POWIERZCHNIA ATAKU
   Interfejsy, przepływy danych, granice zaufania
   (odniesienie do diagramu)

4. REJESTR RYZYK
   Jeden wpis na wiarygodne zagrożenie, oceniony, z zabezpieczeniem,
   ryzykiem rezydualnym i statusem

5. STOSOWALNOŚĆ WYMAGAŃ BEZPIECZEŃSTWA
   Jeden wpis na wymaganie (wszystkich 13), dotyczy tak/nie,
   wdrożenie, odniesienie do dowodu, uzasadnienie tam, gdzie
   wymaganie nie ma zastosowania

6. PODSTAWOWY POZIOM SECURE-BY-DESIGN I POKRYCIE PROCESÓW
   Jak ogólny poziom bezpieczeństwa produktu odpowiada jego
   ryzykom, odniesienia do procesów obsługi podatności

7. RYZYKO REZYDUALNE I AKCEPTACJA
   Podsumowanie, kryteria akceptacji, nazwana akceptacja

8. ZATWIERDZENIE I UTRZYMANIE
   Właściciel, data zatwierdzenia
   Wyzwalacze aktualizacji
   Tabela historii wersji

Aktualność oceny w czasie

Ocena jest żywym dokumentem przez cały okres wsparcia. Otwórz ją ponownie, gdy:

• pojawiają się nowe informacje o podatnościach dotyczących produktu lub jego komponentów, z własnego monitoringu, raportów badaczy lub biuletynów dostawców
• produkt się zmienia, a zawsze wtedy, gdy zmiana jest na tyle istotna, że wymaga nowej oceny zgodności
• zmieniają się komponenty, w tym nowi dostawcy i wersje komponentów stron trzecich lub otwartoźródłowych
• incydent uczy czegoś, czego oceny nie przewidziały

Zapisuj każdą wersję w tabeli historii, wraz z tym, co się zmieniło i dlaczego. Ocena z jedną datą sprzed trzech lat mówi urzędnikowi nadzoru rynku, że dokument jest dekoracyjny.

Łatwo przeoczyć jeden obowiązek spójności. Ocena uwzględnia oczekiwany czas użytkowania produktu. Zadeklarowany okres wsparcia musi odzwierciedlać ten oczekiwany czas użytkowania, zestawiony z własnymi ustawowymi przesłankami. Oba zapisy muszą się więc zgadzać. Jeśli ocena zakłada osiem lat eksploatacji w terenie, a zadeklarowany okres wsparcia wynosi pięć lat, ustalenie trzeba ponownie zweryfikować względem tych przesłanek. Zwykłym skutkiem jest dłuższy okres wsparcia, nie przypis tłumaczący rozbieżność.

Kto odpowiada za ocenę i gdzie mieści się w procesie

CRA nakłada odpowiedzialność na producenta. Nie przypisuje ról wewnętrznych ani nie narzuca metodyki oceny ryzyka czy procesu zespołowego. Ocena, za którą nikt nie odpowiada, jednak traci aktualność, więc w praktyce zespoły dzielą ją mniej więcej tak:

• Product owner. Odpowiada za kontekst: przeznaczenie, przewidywalne użycie, oczekiwany czas użytkowania. Decyduje, co produkt obiecuje, więc zatwierdza zmiany, gdy ta obietnica się zmienia.
• Deweloperzy i architekci. Odpowiadają za obraz zagrożeń: interfejsy, przepływy danych, zabezpieczenia obsługujące każde ryzyko oraz dowody, że te zabezpieczenia istnieją.
• Kierownik ds. bezpieczeństwa albo osoba pełniąca tę rolę. Odpowiada za metodę, rejestr, zapis stosowalności i zatwierdzenie. W małym zespole to jedna osoba w trzech rolach naraz, i to działa.

Wyzwalacze aktualizacji warto potem wpiąć w momenty, w których praca już się dzieje, tak aby ocena nigdy nie zależała od tego, czy ktoś o niej pamięta:

Dowody z potoku pochodzą z narzędzi już używanych: generowanie SBOM w CI/CD zasila zapis komponentów, a proces obsługi podatności ponownie otwiera wpisy w kroku 4. CRA narzuca wynik, czyli udokumentowaną i aktualną ocenę, nie samą pętlę. To pętla sprawia, że ten obowiązek daje się utrzymać obok realnej presji dostarczania.

Komponenty stron trzecich

Ryzyko produktu obejmuje komponenty w jego wnętrzu. Przy integracji komponentów stron trzecich, w tym otwartoźródłowych, konieczna jest należyta staranność, aby nie naruszały bezpieczeństwa produktu. W ocenie oznacza to, że:

• ryzyka komponentów pojawiają się w rejestrze tam, gdzie są istotne, a SBOM stanowi szkielet inwentarza
• opisane jest podejście do wyboru i monitorowania komponentów, z odniesieniami do dowodów od dostawców
• ścieżki aktualizacji komponentów stanowią część analizy zdolności do aktualizacji

Praktyczna mechanika, w tym kwestionariusz dla dostawcy, znajduje się w przewodniku po należytej staranności wobec dostawców.

Gdzie przechowywana jest ocena

Pisemna ocena jest częścią dokumentacji technicznej, obok dokumentacji projektowej, dowodów z testów i zapisu decyzji o okresie wsparcia. Zatwierdzona wersja, jej historia wersji oraz dowody, do których odsyła, muszą pozostać dostępne przez cały okres, w którym dokumentacja musi być przechowywana. Przewodnik po dokumentacji technicznej pokazuje strukturę dokumentacji i miejsce każdego artefaktu.

Najczęstsze błędy

• Napisana po fakcie. Ocena powstała w tygodniu przed wysyłką nie mogła wpłynąć na projekt. Recenzenci to zauważają.
• Brak decyzji o stosowalności. Sam rejestr ryzyk nie odpowiada na pytanie, jakie zadaje CRA. Każde z 13 wymagań potrzebuje jednoznacznej odpowiedzi.
• „Nie dotyczy” bez uzasadnienia. Każde wyłączenie wymaga pisemnego uzasadnienia w dokumentacji.
• Nieudokumentowana metoda. Oceny bez skal, formuły bez definicji.
• Poziom organizacji zamiast produktu. Rejestr ryzyk SZBI obejmuje organizację. CRA wymaga oceny dla tego konkretnego produktu.
• Zamrożona przy wydaniu. Brak historii wersji, brak wyzwalaczy aktualizacji, brak powiązania z monitorowaniem podatności.
• Niespójna z okresem wsparcia. Założenia dotyczące oczekiwanego użycia sprzeczne z zadeklarowanym oknem wsparcia.
• Brak wyznaczonego właściciela. Nikt jej nie zatwierdził, nikt nie akceptuje ryzyka rezydualnego, nikt nie odpowiada za aktualizacje.