Dokumentacja bezpieczeństwa produktu na potrzeby CRA 2026 z wykorzystaniem ISO 27001

Producent urządzeń połączonych zaprasza swoją CISO Marię na piątkowe popołudniowe spotkanie. Dział sprzedaży właśnie podpisał europejską umowę dystrybucyjną. Dział prawny pyta, czy spółka jest w stanie wykazać zgodność z Cyber Resilience Act. Zespół inżynierski twierdzi, że bezpieczny rozwój oprogramowania jest „w większości pokryty”, ponieważ działają przeglądy kodu, SAST i wdrażanie poprawek. Dział zakupów informuje, że dostawcy są „objęci NDA”. Zespoły produktowe utrzymują zależności firmware w jednym narzędziu, inwentarze interfejsów API usług chmurowych w innym, a zgłoszenia podatności w Jira. Funkcja zgodności posiada dowody certyfikacji ISO/IEC 27001:2022, ale są one uporządkowane wokół korporacyjnego SZBI, a nie wokół każdego produktu wprowadzanego na rynek UE.

Wtedy pada niewygodne pytanie: „Jeżeli organ UE, klient, jednostka notyfikowana albo kluczowy dystrybutor poprosi w 2026 r. o dokumentację bezpieczeństwa produktu, czy jesteśmy w stanie przygotować ją w tydzień?”

Dla wielu dostawców oprogramowania, producentów inteligentnych urządzeń i dostawców usług połączonych uczciwa odpowiedź brzmi: nie. Nie dlatego, że brakuje im środków bezpieczeństwa, lecz dlatego, że dowody bezpieczeństwa produktu są rozproszone. Zapisy bezpiecznego rozwoju oprogramowania znajdują się w zespole inżynierskim. SBOM-y są generowane dla poszczególnych kompilacji, ale nie podlegają nadzorowi. Skoordynowane ujawnianie podatności istnieje jako strona internetowa, lecz nie zawsze jest powiązane z kwalifikacją zgłoszeń, poprawkami, komunikatami bezpieczeństwa i monitorowaniem po wprowadzeniu produktu do obrotu. Bezpieczeństwo dostawców jest ukryte w dokumentacji zakupowej i umowach. Zgłaszanie incydentów należy do operacji bezpieczeństwa, a dokumentacja zgodności do zespołu zgodności produktowej.

Cyber Resilience Act UE zmienia model operacyjny. Cyberbezpieczeństwo produktu nie jest już wyłącznie dobrą praktyką ani deklaracją umowną. Staje się obowiązkiem dowodowym obejmującym cały cykl życia. Organizacje muszą umieć wykazać, w jaki sposób wymagania cyberbezpieczeństwa są wbudowane w projektowanie, rozwój, wydanie, obsługę podatności, aktualizacje i monitorowanie po wprowadzeniu produktu do obrotu.

W tym miejscu ISO/IEC 27001:2022 staje się bardzo użyteczna, o ile jest stosowana prawidłowo. Sama w sobie nie jest schematem certyfikacji produktu, ale jej SZBI oraz zabezpieczenia dotyczące ryzyka, aktywów, dostawców, bezpiecznego rozwoju oprogramowania, podatności i incydentów mogą stanowić szkielet dokumentacji bezpieczeństwa produktu na potrzeby CRA. Celem nie jest utworzenie kolejnego silosu zgodności. Celem jest przekształcenie istniejącego SZBI w system dowodowy na poziomie produktu.

Jak ujmuje to Clarysec Zenith Blueprint: 30-etapowa mapa drogowa audytora w fazie 2, kroku 8, Architektura dowodów:

„Dowodów nie należy zbierać dopiero na końcu cyklu audytu. Powinny być zaprojektowane jako element zabezpieczenia, przypisane do właściciela, opatrzone znacznikiem czasu przez proces i możliwe do ponownego wykorzystania dla każdego obowiązku, który zadaje to samo pytanie innym językiem.”

To zdanie oddaje istotę gotowości na CRA. Pytanie nie brzmi tylko: „Czy mamy bezpieczny rozwój oprogramowania?” Pytanie brzmi: „Czy potrafimy udowodnić bezpieczny rozwój oprogramowania, świadomość komponentów, obsługę podatności i monitorowanie po wprowadzeniu do obrotu dla tego produktu, tej wersji, tego wydania i tego rynku?”

Dokumentacja bezpieczeństwa produktu na potrzeby CRA jest żywym systemem dowodowym

Dokumentacji bezpieczeństwa produktu na potrzeby CRA nie należy traktować jako statycznego pliku PDF, wytworzonego raz przed wydaniem i zapomnianego. Powinna być uporządkowanym dossier, które opisuje historię bezpieczeństwa produktu od koncepcji do zakończenia wsparcia.

Użyteczna dokumentacja wyjaśnia:

1. Czym jest produkt i do jakiego użycia jest przeznaczony.
2. Jakie oprogramowanie, firmware, usługi chmurowe i zależności stron trzecich obejmuje.
3. Jakie ryzyka cyberbezpieczeństwa zostały ocenione.
4. Jakie wymagania bezpieczeństwa zastosowano.
5. Jak przeprowadzono bezpieczny rozwój oprogramowania.
6. Jak podatności są przyjmowane, kwalifikowane, usuwane i ujawniane.
7. Jak dostarczane są bezpieczne aktualizacje.
8. Jak nadzorowani są dostawcy i komponenty open source.
9. Jak eskalowane są incydenty i aktywnie wykorzystywane podatności.
10. Jak produkt jest monitorowany po wprowadzeniu do obrotu.

Dla CISO jest to wyzwanie dowodowe SZBI. Dla menedżera zgodności produktowej jest to dokumentacja techniczna. Dla inżynierii jest to DevSecOps i nadzór nad wydaniami. Dla najwyższego kierownictwa jest to dostęp do rynku i kontrola odpowiedzialności.

Błędem jest traktowanie tych elementów jako odrębnych strumieni prac. Lepszym modelem jest zbudowanie pliku dowodowego na poziomie produktu, który mapuje się na zabezpieczenia ISO/IEC 27001:2022 i ISO/IEC 27002:2022, a następnie mapuje te same dowody na NIS2, DORA, GDPR, NIST i COBIT 2019 tam, gdzie ma to zastosowanie.

Clarysec Zenith Controls: przewodnik po zgodności krzyżowej opisuje to jako łańcuch: zabezpieczenie – dowód – audytor:

„Plik dowodowy zgodności krzyżowej powinien mapować każdy obowiązek na działające zabezpieczenie, powtarzalny obiekt dowodowy, odpowiedzialnego właściciela oraz perspektywę audytu, z której będzie on kwestionowany.”

Takiej dyscypliny wymaga przygotowanie do CRA. Dokumentacja bezpieczeństwa produktu nie jest zwykłym folderem. Jest warstwą translacyjną między inżynierią produktu, ładem bezpieczeństwa, oceną zgodności i zapewnieniem dla klientów.

Najpierw zbuduj szkielet dowodowy produktu

Dokumentacja potrzebuje spójnej struktury, zanim zespoły zaczną dodawać zapisy. Bez jasnego szkieletu dowody stają się zbiorem zrzutów ekranu, eksportów i plików PDF z politykami, którego żaden audytor nie jest w stanie prześledzić.

W warsztatach gotowości na CRA Clarysec zwykle rekomenduje poniższą strukturę dokumentacji bezpieczeństwa produktu organizacjom, które już utrzymują SZBI zgodny z ISO/IEC 27001:2022.

Ta tabela nie zastępuje prawnych obowiązków dotyczących dokumentacji technicznej. Daje organizacji model operacyjny pozwalający je udowodnić.

W Zenith Blueprint faza 1, krok 3 koncentruje się na zdefiniowaniu zakresu i granic. Dla CRA ten krok staje się specyficzny dla produktu. Zdefiniuj rodzinę produktów, wersje oprogramowania, założenia wdrożeniowe, role użytkowników, usługi połączone, kanały aktualizacji i okres wsparcia. Jeżeli zakres SZBI brzmi „korporacyjna platforma SaaS i zarządzania urządzeniami”, plik CRA nadal musi odpowiedzieć na węższe pytanie: „Który produkt z elementami cyfrowymi jest wprowadzany na rynek UE i co wchodzi w jego skład?”

Mapuj bezpieczny rozwój oprogramowania na zapisy na poziomie produktu

Sercem dokumentacji bezpieczeństwa produktu są dowody bezpieczeństwa na etapie projektowania. ISO/IEC 27001:2022 zapewnia system ładu. ISO/IEC 27002:2022 dostarcza wskazówek wdrożeniowych poprzez zabezpieczenia takie jak A.8.25 Cykl życia bezpiecznego rozwoju oprogramowania, A.8.27 Bezpieczna architektura systemów i zasady inżynierii, A.8.28 Bezpieczne kodowanie oraz A.8.29 Testowanie bezpieczeństwa w rozwoju i akceptacji.

Kluczowa zmiana polega na przejściu od ogólnych deklaracji o bezpiecznym rozwoju oprogramowania do zapisów specyficznych dla wydania. „Wykonujemy przegląd kodu” nie wystarcza. Dokumentacja powinna pokazywać, które wydanie zostało przejrzane, jakie ryzyka uwzględniono, które testy bezpieczeństwa zakończyły się powodzeniem, które podatności zaakceptowano albo usunięto oraz kto zatwierdził wydanie.

Enterprise Clarysec Polityka bezpiecznego rozwoju oprogramowania została zaprojektowana tak, aby wymuszać taką ścieżkę dowodową. W klauzuli 6.1, Wymagania cyklu życia bezpiecznego rozwoju oprogramowania, wskazuje:

„Każde wydanie produktu lub usługi musi utrzymywać udokumentowane dowody wymagań bezpieczeństwa, przeglądu projektu, działań w zakresie bezpiecznego kodowania, testowania bezpieczeństwa, decyzji dotyczących usuwania podatności oraz zatwierdzenia wydania przed wdrożeniem produkcyjnym.”

Ta klauzula jest użyteczna dla CRA, ponieważ przekształca bezpieczny rozwój oprogramowania w powtarzalny wzorzec dowodowy. Audytor nie musi wnioskować, że bezpieczny rozwój oprogramowania miał miejsce. Może sprawdzić zapis wydania.

Dla inteligentnego termostatu, medycznego urządzenia IoT, czujnika przemysłowego albo produktu połączonego z SaaS dowody bezpiecznego rozwoju oprogramowania powinny obejmować:

• Wymagania bezpieczeństwa produktu zmapowane na zidentyfikowane ryzyka.
• Model zagrożeń albo analizę przypadków nadużyć dla produktu i usług połączonych.
• Przegląd architektury, w tym granice zaufania i interfejsy zewnętrzne.
• Standard bezpiecznego kodowania oraz dowód potwierdzenia zapoznania się przez programistów albo odbycia szkolenia.
• SAST, DAST, analizę składu oprogramowania, skanowanie sekretów i analizę firmware, gdy ma to zastosowanie.
• Zgłoszenia działań naprawczych dla ustaleń wysokiego ryzyka.
• Zapisy akceptacji ryzyka z zatwierdzeniem biznesowym i bezpieczeństwa.
• Listę kontrolną bramki wydania potwierdzającą spełnienie kryteriów bezpieczeństwa.
• Dowody podpisu kryptograficznego i integralności aktualizacji.
• Założenia dotyczące okresu wsparcia i zakończenia cyklu życia.

Inne normy pomagają wzmocnić metodę. ISO/IEC 27005 wspiera podejście oparte na ryzyku stojące za tymi zapisami. ISO/IEC 27017 jest użyteczna, gdy usługi chmurowe stanowią część ekosystemu produktu. ISO/IEC 27035 wspiera obsługę incydentów. ISO/IEC 29147 i ISO/IEC 30111 są szczególnie istotne dla ujawniania i obsługi podatności. ISO/IEC 27036 wspiera bezpieczeństwo dostawców, co ma znaczenie, gdy produkt obejmuje oprogramowanie realizowane w outsourcingu, moduły wbudowane, zarządzane usługi chmurowe albo biblioteki stron trzecich.

W Zenith Controls dowody bezpiecznego rozwoju oprogramowania dla CRA są zwykle mapowane wokół motywów zabezpieczeń ISO/IEC 27002:2022, takich jak bezpieczeństwo informacji w zarządzaniu projektami, cykl życia bezpiecznego rozwoju oprogramowania, bezpieczne kodowanie, testowanie bezpieczeństwa, zarządzanie zmianami i zarządzanie podatnościami technicznymi. Przewodnik wiąże je również z inwentarzem aktywów i zabezpieczeniami dotyczącymi dostawców, ponieważ żaden proces bezpiecznego rozwoju oprogramowania nie jest kompletny, jeżeli organizacja nie potrafi zidentyfikować komponentów, które dostarcza.

Traktuj SBOM jako regulowany dowód produktowy

Software Bill of Materials jest często traktowany jako artefakt techniczny. W kontekście gotowości na CRA należy traktować go jako dowód produktowy.

Użyteczny SBOM wskazuje, jakie komponenty znajdują się w produkcie, jakie wersje są używane, skąd pochodzą, jakie licencje mają zastosowanie, jakie podatności ich dotyczą oraz które wydania je zawierają. W przypadku firmware i produktów wbudowanych może to obejmować pakiety systemu operacyjnego, bootloadery, biblioteki, sterowniki, kontenery, moduły stron trzecich i zależności po stronie chmury wymagane do działania produktu.

Problem polega na tym, że wiele organizacji generuje SBOM-y, ale nie obejmuje ich nadzorem. Potok budowania może wytwarzać plik SPDX albo CycloneDX, ale nikt nie waliduje kompletności. Narzędzia bezpieczeństwa mogą oznaczać podatności, ale wyniki nie są powiązane z wersjami produktu. Zakupy mogą zatwierdzić dostawcę, ale lista komponentów tego dostawcy nie jest uzgadniana z wydanym produktem.

Enterprise Clarysec Polityka zarządzania aktywami adresuje tę lukę nadzorczą w klauzuli 5.2, Inwentarz informacji i powiązanych aktywów:

„Aktywa informacyjne i powiązane komponenty technologiczne muszą być identyfikowane, przypisane właścicielowi, klasyfikowane tam, gdzie ma to zastosowanie, oraz utrzymywane w inwentarzu wspierającym ocenę ryzyka, zarządzanie podatnościami, kontrolę zmian i dowody z audytu.”

Dla CRA ta klauzula staje się specyficzna dla produktu. SBOM jest częścią inwentarza powiązanych komponentów technologicznych. Potrzebuje właściciela, reguły okresu przechowywania, procesu walidacji i powiązania z zarządzaniem podatnościami.

Praktyczna reguła dowodowa dla SBOM jest prosta: każda wydana wersja produktu musi mieć zatwierdzony inwentarz komponentów, który można dopasować do artefaktu wydania. Jeżeli organizacja nie potrafi powiązać SBOM z dokładnym obrazem firmware, pakietem aplikacji, skrótem kontenera albo wydaniem SaaS, SBOM stanowi słaby dowód.

Jeżeli niespełnione są więcej niż dwa wiersze, problem zwykle nie leży w narzędziu SBOM. Jest nim nadzór. Dokumentacja bezpieczeństwa produktu powinna odnotować działanie korygujące w SZBI, ponieważ słabość dowodów CRA jest również problemem skuteczności zabezpieczeń ISO/IEC 27001:2022.

Połącz CVD z obsługą podatności i nadzorem nad wydaniami

Skoordynowane ujawnianie podatności jest jednym z najbardziej widocznych obszarów gotowości na CRA, ponieważ zewnętrzni badacze, klienci i organy mogą je bezpośrednio przetestować. Opublikowanie strony ujawniania podatności albo pliku security.txt jest użyteczne, ale stanowi jedynie drzwi wejściowe. Dokumentacja bezpieczeństwa produktu musi udowodnić, że działa zaplecze operacyjne.

Możliwy do obrony zestaw dowodów CVD i obsługi podatności powinien obejmować:

• Publiczny kanał ujawniania i instrukcje składania zgłoszeń.
• Proces potwierdzania zgłoszeń od badaczy.
• Kryteria kwalifikacji, w tym ocenę wagi i możliwości wykorzystania.
• Analizę wpływu na produkt.
• Właścicielstwo działań naprawczych i docelowe terminy.
• Szablony komunikatów dla klientów i informacji o aktualizacjach.
• Dowody bezpiecznego opracowania i testowania poprawek.
• Zapisy skoordynowanej publikacji, gdy ma to zastosowanie.
• Wnioski z doświadczeń oraz analizę powtarzających się trendów podatności.

Enterprise Clarysec Polityka zarządzania podatnościami, klauzula 6.3, Przyjmowanie, kwalifikacja i usuwanie podatności, stanowi:

„Zgłoszone podatności muszą być rejestrowane, oceniane pod kątem dotkniętych aktywów i produktów, priorytetyzowane według ryzyka i możliwości wykorzystania, przypisane odpowiedzialnemu właścicielowi oraz śledzone przez działania naprawcze, weryfikację, komunikację i zamknięcie.”

Ta klauzula łączy CVD z SBOM, inwentarzem aktywów, zgłoszeniami inżynierskimi, zarządzaniem wydaniami i monitorowaniem po wprowadzeniu produktu do obrotu. Jest to również klauzula, którą audytorzy naturalnie przetestują: pokaż zapis przyjęcia, pokaż dotknięte produkty, pokaż kwalifikację, pokaż poprawkę, pokaż komunikację z klientami, pokaż zamknięcie.

Istniejąca Polityka zarządzania incydentami bezpieczeństwa informacji powinna zostać rozszerzona tak, aby obejmowała podatności produktowe, które stają się incydentami albo wymagają powiadomienia zewnętrznego. ISO/IEC 27002:2022 A.5.24 obejmuje planowanie i przygotowanie zarządzania incydentami, A.5.25 obejmuje ocenę i decyzję dotyczącą zdarzeń bezpieczeństwa informacji, A.5.26 obejmuje reagowanie na incydenty bezpieczeństwa informacji, a A.5.27 obejmuje uczenie się na podstawie incydentów.

W Zenith Controls zarządzanie podatnościami jest traktowane zarówno jako działanie zapobiegawcze, jak i korygujące. Strona zapobiegawcza obejmuje inwentarz, bezpieczny rozwój oprogramowania, monitorowanie dostawców i bezpieczną konfigurację. Strona korygująca obejmuje wykrywanie, kwalifikację, wdrażanie poprawek, komunikację i eskalację incydentów. To rozróżnienie ma znaczenie, ponieważ obsługa podatności po wprowadzeniu produktu do obrotu jest częścią obowiązku obejmującego cykl życia produktu, a nie działaniem następczym.

Dowody od dostawców są ukrytą słabością

Dokumentacja bezpieczeństwa produktu będzie często najtrudniej kwestionowana tam, gdzie producent polega na innych podmiotach. Obejmuje to moduły wbudowane, rozwój firmware realizowany w outsourcingu, komponenty white-label, hosting w chmurze, mobilne SDK, usługi płatnicze, biblioteki kryptograficzne i dostawców usług zarządzanego wsparcia.

Typowy wzorzec niepowodzenia to abstrakcja umowna. Producent mówi: „Za to odpowiada nasz dostawca”. Przy kontroli bezpieczeństwa produktu to nie wystarcza. Organizacja musi wykazać, że ryzyko dostawcy jest zidentyfikowane, wymagania bezpieczeństwa są zakomunikowane, dowody są zbierane, podatności są koordynowane, a zmiany kontrolowane.

Enterprise Clarysec Polityka bezpieczeństwa dostawców i stron trzecich, klauzula 7.1, Wymagania bezpieczeństwa dostawców, stanowi:

„Dostawcy, którzy rozwijają, obsługują, przetwarzają, wspierają lub istotnie wpływają na systemy informatyczne, produkty albo usługi, muszą być oceniani według ryzyka i podlegać wymaganiom bezpieczeństwa obejmującym dostęp, zarządzanie podatnościami, powiadamianie o incydentach, podwykonawstwo, ciągłość działania oraz dostarczanie dowodów.”

Dla CRA fraza „istotnie wpływają na produkty” jest kluczowa. Jeżeli komponent dostawcy może wprowadzić podatność, zakłócić aktualizacje, ujawnić dane klientów albo naruszyć integralność urządzenia, należy go uwzględnić w dokumentacji bezpieczeństwa produktu.

Ta sama polityka może również wspierać wymagania umowne dotyczące SBOM. Klauzula 7.3 stanowi:

„Dla wszystkich komponentów oprogramowania stron trzecich, bibliotek albo systemów operacyjnych integrowanych z firmowymi „produktami z elementami cyfrowymi” dostawca musi, na żądanie, dostarczyć czytelny maszynowo Software Bill of Materials (SBOM) w standardowym formacie, takim jak SPDX albo CycloneDX. Wymóg ten musi być włączony do wszystkich umów zakupowych i umów z dostawcami.”

Silny pakiet dowodów od dostawców powinien obejmować klasyfikację dostawców według wpływu na produkt, wymagania bezpieczeństwa w umowach, dowody bezpiecznego rozwoju oprogramowania dostawcy dla komponentów krytycznych, zobowiązania dostawcy dotyczące ujawniania podatności, SBOM albo deklaracje komponentów tam, gdzie jest to wykonalne, wsparcie poprawek i terminy zakończenia cyklu życia, zapisy okresowych przeglądów oraz ścieżki eskalacji dla podatności pochodzących od dostawcy.

ISO/IEC 27002:2022 A.5.19, A.5.20 i A.5.21 zapewniają kluczowe motywy zabezpieczeń dotyczących dostawców. ISO/IEC 27036 dodaje pogłębienie w zakresie bezpieczeństwa relacji z dostawcami. W ujęciu zgodności krzyżowej NIS2 podkreśla łańcuch dostaw i obsługę podatności. DORA podkreśla ryzyko stron trzecich ICT dla podmiotów finansowych. GDPR staje się istotne, gdy produkt lub jego usługi chmurowe przetwarzają dane osobowe. COBIT 2019 ujmuje nadzór nad dostawcami jako zagadnienie ładu technologii przedsiębiorstwa, a nie tylko problem operacji bezpieczeństwa.

Monitorowanie po wprowadzeniu produktu do obrotu zmienia dowody w operacje

Najbardziej dojrzałe organizacje bezpieczeństwa produktu myślą poza wydaniem. Pytają: „Skąd będziemy wiedzieć, że ten produkt stał się ryzykowny już po wdrożeniu u klientów?”

Monitorowanie po wprowadzeniu produktu do obrotu powinno obejmować sygnały ze strumieni informacji o podatnościach, informacji o exploitach, obsługi klienta, telemetrii, bug bounty lub zgłoszeń badaczy, powiadomień dostawców, logów chmurowych, zapisów incydentów i danych o działaniu produktu w terenie. Powinno również obejmować okresowy przegląd ryzyka produktu, gdy zmieniają się warunki zagrożeń.

Enterprise Clarysec Polityka logowania i monitorowania, klauzula 5.4, Monitorowanie i przegląd bezpieczeństwa, stanowi:

„Zdarzenia istotne dla bezpieczeństwa muszą być zbierane, przeglądane, eskalowane i przechowywane w sposób wspierający terminowe wykrywanie, dochodzenie, reagowanie na incydenty, raportowanie zgodności i ciągłe doskonalenie.”

W przypadku produktów połączonych należy interpretować to ostrożnie. Monitorowanie musi respektować prywatność, minimalizację danych i ograniczenia prawne, zwłaszcza gdy telemetria obejmuje dane osobowe albo dane operacyjne klientów. Mapowanie do GDPR jest istotne. Zespoły bezpieczeństwa produktu powinny współpracować z zespołami prywatności, aby określić, jaka telemetria jest niezbędna dla bezpieczeństwa, jak jest minimalizowana, jak długo jest przechowywana i jak informowani są klienci.

Dowody monitorowania po wprowadzeniu produktu do obrotu powinny obejmować plan monitorowania bezpieczeństwa produktu, źródła informacji o podatnościach, kanały przyjmowania zgłoszeń od klientów, kanały powiadomień dostawców, zakres przeglądu telemetrii lub logów, protokoły okresowych przeglądów ryzyka produktu, śledzenie wdrożenia poprawek, analizę trendów incydentów i wkłady do przeglądu zarządzania.

W Zenith Blueprint faza 5, krok 30 koncentruje się na ciągłym doskonaleniu i gotowości do nadzoru. Dla CRA jest to miejsce, w którym dokumentacja bezpieczeństwa produktu staje się żywym plikiem. Każde wydanie produktu, podatność, zmiana dostawcy i sygnał z terenu powinny aktualizować zapis dowodowy.

Jeden plik dowodowy, wiele pytań o zgodność

Dobrze zaprojektowana dokumentacja bezpieczeństwa produktu na potrzeby CRA ogranicza powielanie, ponieważ te same dowody odpowiadają na wiele pytań o zgodność. Język się zmienia, ale rzeczywistość kontrolna często jest podobna.

Zenith Controls jest zaprojektowany do takiego ponownego użycia. Mapuje motywy zabezpieczeń ISO/IEC 27002:2022 na atrybuty takie jak zapobiegawczy, detekcyjny i korygujący cel zabezpieczenia, koncepcje cyberbezpieczeństwa, zdolności operacyjne i właściwości bezpieczeństwa. Dla CRA pomaga to CISO wyjaśnić, dlaczego pojedynczy obiekt dowodowy, taki jak przegląd bezpieczeństwa wydania, wspiera bezpieczny rozwój oprogramowania, postępowanie z ryzykiem, kontrolę zmian, zarządzanie podatnościami i gotowość do audytu.

Przygotuj się na różne perspektywy audytorów

Dokumentacja bezpieczeństwa produktu na potrzeby CRA może być kwestionowana przez audytora ISO, zespół audytu wewnętrznego, zespół zapewnienia dla klientów, recenzenta zgodności produktu, regulatora, asesora opartego na NIST albo audytora COBIT przeszkolonego przez ISACA. Każdy z nich zada podobne pytania z innej perspektywy.

Ten sam słaby punkt zostanie ujawniony inaczej. Jeżeli SBOM-y są generowane, ale nie są przechowywane, audytor ISO widzi problem kontroli zapisów i kontroli operacyjnej. Asesor NIST widzi słabość zarządzania aktywami i podatnościami. Audytor COBIT widzi słaby ład nad aktywami informacyjnymi. Recenzent produktu widzi niewystarczającą dokumentację techniczną.

30-etapowa mapa drogowa dostosowana do gotowości na CRA

Zenith Blueprint zapobiega temu, aby zespoły zgodności od razu przeszły do zbierania dokumentów. Dla CRA 30-etapowa mapa drogowa staje się programem dowodów bezpieczeństwa produktu.

Faza 1 zaczyna się od mapowania obowiązków i zakresu. Zidentyfikuj produkty, wersje, komponenty, usługi chmurowe i procesy wsparcia objęte zakresem. Potwierdź zamierzone użycie, kategorie użytkowników, rynki i okres wsparcia bezpieczeństwa.

Faza 2 buduje architekturę dowodów. Zdefiniuj indeks dokumentacji bezpieczeństwa produktu, właścicieli dowodów, wymagania dotyczące okresu przechowywania, strukturę repozytorium i ścieżkę akceptacji. Dostosuj się do systemów inżynierskich zamiast wymuszać ręczne przesyłanie plików.

Faza 3 wdraża zabezpieczenia operacyjne. Bezpieczny rozwój oprogramowania, generowanie SBOM, obsługa podatności, dowody od dostawców, bramki wydań, bezpieczne aktualizacje i eskalacja incydentów muszą działać jako rzeczywiste procesy.

Faza 4 testuje gotowość do audytu. Wybierz wydanie produktu i przeprowadź próbny audyt. Czy zespół może pobrać SBOM? Czy może udowodnić testowanie bezpieczeństwa? Czy może pokazać, jak podatność została zakwalifikowana? Czy może powiązać dowody od dostawców z komponentami produktu?

Faza 5 osadza nadzór i doskonalenie. Monitorowanie po wprowadzeniu produktu do obrotu, analiza trendów podatności, przeglądy dostawców i wkłady do przeglądu zarządzania utrzymują aktualność dokumentacji.

Taki sprint zwykle szybko ujawnia prawdę. Organizacje rzadko zawodzą dlatego, że nie mają żadnych zabezpieczeń. Zawodzą dlatego, że zabezpieczenia nie są połączone na poziomie produktu.

Typowe luki gotowości na CRA przed 2026 r.

Wśród dostawców oprogramowania, producentów urządzeń i dostawców usług połączonych powtarzające się luki są spójne.

Po pierwsze, zakres SZBI jest zbyt korporacyjny. Obejmuje organizację, ale nie zapewnia wystarczającego poziomu szczegółowości cyklu życia produktu. Rozwiązaniem jest utworzenie załączników i plików dowodowych na poziomie produktu.

Po drugie, SBOM-y istnieją, ale nie są wiarygodne. Są generowane przez narzędzia, ale nie są przeglądane, zatwierdzane, przechowywane ani powiązane z decyzjami dotyczącymi podatności. Rozwiązaniem jest nadzór nad SBOM, a nie tylko generowanie SBOM.

Po trzecie, CVD jest widoczne publicznie, ale niedojrzałe operacyjnie. Zgłoszenia napływają, lecz kryteria kwalifikacji, docelowe czasy reakcji, zatwierdzenia komunikatów bezpieczeństwa i dowody zamknięcia są niespójne. Rozwiązaniem jest zintegrowanie CVD z zarządzaniem podatnościami, zarządzaniem incydentami i zarządzaniem wydaniami.

Po czwarte, dowody od dostawców są zbyt powierzchowne. Dostawcy krytyczni są zatwierdzani komercyjnie, ale nie są oceniani pod kątem wpływu na bezpieczeństwo produktu. Rozwiązaniem jest klasyfikacja dostawców według ryzyka produktowego i obowiązkowe dowody dla komponentów krytycznych.

Po piąte, monitorowanie po wprowadzeniu produktu do obrotu jest reaktywne. Zespoły reagują na pilne podatności, ale nie prowadzą okresowych przeglądów ryzyka produktu. Rozwiązaniem jest zaplanowany przegląd bezpieczeństwa po wprowadzeniu produktu do obrotu, powiązany z raportowaniem zarządczym.

Po szóste, dowody audytowe są zbyt ręczne. Zespoły zgodności gonią za zrzutami ekranu. Rozwiązaniem jest dowód wbudowany w proces, wykorzystujący systemy inżynierskie, przepływy zgłoszeniowe i repozytoria jako źródła autorytatywne.

Zbuduj plik dowodowy, zanim termin zrobi to za Ciebie

Cyber Resilience Act premiuje organizacje, które potrafią udowodnić bezpieczeństwo produktu jako dyscyplinę operacyjną. Tworzy ryzyko dla organizacji, które traktują dowody jako ćwiczenie zgodności realizowane w ostatniej chwili.

Zacznij od jednego produktu. Zbuduj jedną dokumentację bezpieczeństwa produktu. Zmapuj ją na ISO/IEC 27001:2022 i ISO/IEC 27002:2022. Dołącz dowody bezpiecznego rozwoju oprogramowania, SBOM, zapisy CVD, zapewnienie ze strony dostawców i monitorowanie po wprowadzeniu produktu do obrotu. Przeprowadź symulację audytu, zanim zrobi to ktoś z zewnątrz.

Clarysec może pomóc przyspieszyć tę drogę dzięki Zenith Blueprint, Zenith Controls, Enterprise Polityce bezpiecznego rozwoju oprogramowania, Polityce zarządzania podatnościami, Polityce zarządzania aktywami, Polityce bezpieczeństwa dostawców i stron trzecich, Polityce logowania i monitorowania oraz Polityce zarządzania incydentami bezpieczeństwa informacji.

Najważniejsze pytanie dotyczące CRA 2026 nie brzmi: „Czy mamy środki bezpieczeństwa?”

Brzmi ono: „Czy potrafimy udowodnić bezpieczeństwo produktu – wydanie po wydaniu, komponent po komponencie, podatność po podatności – gdy produkt jest już na rynku?”

Zbuduj plik dowodowy teraz, połącz go ze swoim SZBI i spraw, aby każde przyszłe wydanie produktu było gotowe do audytu z założenia.