Akt o cyberodporności: włącz obowiązki do rozwoju produktu

Akt o cyberodporności (Cyber Resilience Act, CRA) wprowadza obowiązki w zakresie cyberbezpieczeństwa do cyklu życia objętych nim produktów z elementami cyfrowymi. Dla CTO praktycznym zadaniem jest powiązanie tego, co zespół inżynierski buduje, dostarcza i utrzymuje, z dowodami potrzebnymi do wykazania spełnienia tych obowiązków.

To powiązanie musi działać na poziomie produktu i wersji. Polityka bezpieczeństwa obowiązująca w całej firmie nie wyjaśnia, czy konkretne wydanie ma bezpieczne ustawienia domyślne, jakie zawiera zależności ani jak klienci otrzymają aktualizację bezpieczeństwa. Zgłoszenie podatności oznaczone jako „naprawione” nie określa, które wspierane wersje nadal pozostają narażone.

Użytecznym punktem wyjścia jest więc model cyklu życia produktu: zakres, wymagania bezpieczeństwa, dowody dotyczące wydań, obsługa podatności, zobowiązania dotyczące wsparcia i decyzje z przypisaną odpowiedzialnością. Wbuduj ten model w proces rozwoju, zamiast składać go osobno przed oceną.

Określ granice produktu przed przypisaniem zabezpieczeń

CRA dotyczy produktów z elementami cyfrowymi objętych jego zakresem, w tym objętego nim sprzętu i oprogramowania. Nie jest uniwersalną regułą dla każdej usługi SaaS. Usługa hostowana i oprogramowanie dystrybuowane do klientów mogą wymagać różnych analiz; zbadać trzeba też zdalne przetwarzanie danych stanowiące integralną część produktu.

Jako punkt odniesienia wykorzystaj wytyczne Komisji Europejskiej dotyczące CRA, a następnie rozstrzygnij pytania prawne specyficzne dla produktu. Zapisz wniosek, zamiast polegać na nieformalnym założeniu zespołu.

Dla każdego produktu, który może podlegać przepisom, ustal:

• Co otrzymują klienci: sprzęt, zainstalowane oprogramowanie, komponenty do pobrania czy ich kombinację.
• Które funkcje zdalnego przetwarzania danych są niezbędne, aby produkt mógł wykonywać swoje funkcje.
• Jak produkt jest dostarczany na rynek UE i który podmiot go dostarcza.
• Swoją rolę jako podmiotu gospodarczego: producent, importer, dystrybutor lub inna odpowiednia rola.
• Mające zastosowanie wyłączenia, przepisy dotyczące konkretnych produktów i kwestie związane z open source.
• Kategorię produktu i wynikające z niej wymagania dotyczące oceny zgodności.

Open source wymaga szczególnej uwagi. Sposób traktowania oprogramowania dostarczanego poza działalnością handlową nie oznacza, że producent komercyjny może ignorować komponenty open source osadzone w jego produkcie. Odróżniaj sytuację autora projektu upstream od swojej odpowiedzialności za produkt, który dostarczasz.

Rezultatem prac inżynierskich powinien być krótki zapis zakresu z diagramem architektury, identyfikatorami produktu, odpowiednimi podmiotami handlowymi, założeniami i zatwierdzonym wnioskiem. Wskaż osobę odpowiedzialną za ponowne otwarcie tego wniosku, gdy zmieni się funkcjonalność lub sposób dystrybucji.

Na przykład aplikacja do zarządzania pobierana przez klientów i powiązana z nią hostowana usługa analityczna nie powinny automatycznie otrzymać jednej, niezróżnicowanej decyzji o zakresie. Ustal, które funkcje działają lokalnie, które zależą od usługi i czy to zdalne przetwarzanie mieści się w granicach produktu. To rozróżnienie wpływa na ocenę ryzyka, zapisy dotyczące zależności i odpowiedzialność za incydenty.

Pracuj według aktualnych terminów wdrożenia

Komisja wskazuje 11 września 2026 r. jako datę rozpoczęcia stosowania obowiązków zgłoszeniowych i 11 grudnia 2027 r. jako datę stosowania głównych wymogów CRA. Według stanu na 7 października 2026 r. termin dotyczący zgłaszania już minął. Traktuj gotowość do zgłaszania jako bieżący wymóg operacyjny, a nie zadanie odłożone do czasu przygotowań do oceny zgodności.

Utrzymuj widoczność dwóch strumieni prac:

Produkty wprowadzone do obrotu przed główną datą stosowania wymagają uwagi w kontekście przepisów przejściowych i istotnych modyfikacji. Nie zakładaj, że starszy produkt nie ma znaczenia dla zgłaszania tylko dlatego, że jego pierwotne wydanie nastąpiło przed grudniem 2027 r.

Prowadź datowany rejestr wymagań prawnych. W kwestii progów zdarzeń, etapowych terminów zgłoszeń, adresatów i procedur przekazywania sprawdzaj aktualny tekst prawny i oficjalne wytyczne wdrożeniowe. Nie zastępuj procesu specyficznego dla CRA ogólnym szablonem reagowania na incydenty.

Przekształć wymagania bezpieczeństwa w kryteria projektowe i kryteria wydania

Zasadnicze wymagania CRA obejmują właściwości bezpieczeństwa produktu i obsługę podatności. Ich wdrożenie powinno wynikać z oceny ryzyka cyberbezpieczeństwa produktu, a nie z uniwersalnej listy kontrolnej stosowanej bez kontekstu architektonicznego.

Zacznij od tego, w jaki sposób produkt może wyrządzić szkodę. Opisz użytkowników, środowiska wdrożenia, udostępnione interfejsy, operacje uprzywilejowane, dane wrażliwe i dające się przewidzieć niewłaściwe użycie. Uwzględnij założenia operacyjne klienta: urządzenie wdrożone w sieci przemysłowej ma inną ekspozycję i inne ograniczenia w zakresie odtwarzania niż narzędzie na komputer stacjonarny.

Praktyczne ćwiczenie z modelowania zagrożeń może wspierać tę pracę; wytyczne OWASP dotyczące modelowania zagrożeń przedstawiają sprawdzone podejście. Rezultat powinien łączyć zagrożenia z konkretnymi wymaganiami, decyzjami wdrożeniowymi i testami.

Zobacz, jak znane wymagania stają się testowalne:

To praktyczne przykłady wdrożeniowe, a nie zamiennik mających zastosowanie wymogów. Ich adekwatność i wystarczalność określ na podstawie oceny ryzyka.

Dodaj kryteria akceptacji bezpieczeństwa do prac nad funkcjami. Nowe administracyjne API powinno pojawiać się wraz z decyzjami dotyczącymi uwierzytelniania, autoryzacji, obsługi danych wejściowych i logowania – a nie z obietnicą, że zespół bezpieczeństwa sprawdzi je później. Wracaj do modelu zagrożeń przy dodawaniu zdalnego interfejsu, komponentu uprzywilejowanego lub nowej granicy zaufania.

Zatwierdzenie wydania powinno wskazywać nierozwiązane podatności, możliwość ich wykorzystania, konfiguracje, których dotyczą, i sposób postępowania z nimi. Stosuj wymóg CRA, zgodnie z którym produkty udostępnia się na rynku bez znanych podatności możliwych do wykorzystania, z uwzględnieniem oceny ryzyka i mających zastosowanie zasadniczych wymagań; samo zarejestrowanie lub zaakceptowanie ryzyka nie spełnia tego wymogu. Sam wynik skanera nie może przesądzić o tej decyzji: znaczenie mają osiągalność podatnego kodu, warunki wstępne i zachowanie produktu. Z drugiej strony niska ocena liczbowa wagi nie jest wystarczającym powodem, by pominąć podatność, która w Twoim modelu wdrożenia ma poważne skutki.

Zapis wydania powinien łączyć zatwierdzoną rewizję kodu źródłowego, artefakt kompilacji, inwentarz zależności, wyniki testów i decyzję dotyczącą bezpieczeństwa. Dzięki temu ocenę można odtworzyć, gdy klient lub organ zapyta później o konkretną wersję.

Uczyń należytą staranność wobec komponentów częścią procesu kompilacji

Komponenty stron trzecich tworzą obowiązki, których nie da się wypełnić przez przekazanie dalej komunikatu bezpieczeństwa od dostawcy upstream. Musisz rozumieć, co dostarczyłeś, czy problem Cię dotyczy i jak możesz go usunąć.

CRA obejmuje wymóg dotyczący wykazu komponentów oprogramowania (SBOM) w ramach wymagań dotyczących obsługi podatności: w powszechnie stosowanym formacie nadającym się do odczytu maszynowego, obejmującym co najmniej zależności najwyższego poziomu. W ramach praktycznej rekomendacji rejestruj głębsze informacje o zależnościach wszędzie tam, gdzie Twoje narzędzia kompilacji mogą dostarczyć wiarygodnych wyników. To zależności przechodnie często decydują o ekspozycji.

SBOM jest użyteczny tylko wtedy, gdy odpowiada rzeczywistemu artefaktowi produktu. Powiąż go z identyfikatorem wydania i kompilacją oraz odróżniaj komponenty dostarczane od narzędzi używanych wyłącznie w procesie wytwórczym. W stosownych przypadkach uwzględnij firmware, pakiety systemu operacyjnego, dołączone biblioteki i komponenty komercyjne; eksport z menedżera pakietów może pominąć kilka z nich.

Buduj przegląd komponentów wokół pytań, które zmieniają decyzje inżynierskie:

• Czy komponent jest utrzymywany i czy okres jego wsparcia jest zgodny z naszym?
• Czy możemy szybko uzyskiwać informacje o podatnościach i aktualizacje bezpieczeństwa?
• Czy mamy dostęp do kodu źródłowego, ścieżkę poprawek od dostawcy lub strategię zastąpienia?
• Czy komponent wprowadza wykonywanie z podwyższonymi uprawnieniami lub nowe połączenie zewnętrzne?
• Czy produkt nadal będzie można utrzymywać, jeśli dostawca zaprzestanie wsparcia komponentu?

W przypadku komponentów komercyjnych proces zakupowy powinien ustalić kontakty ds. bezpieczeństwa, zasady powiadamiania i dostęp do poprawek. Terminy dostawcy muszą pozostawiać czas na Twoją własną ocenę i obowiązki zgłoszeniowe. Producent produktu nadal potrzebuje wewnętrznej ścieżki eskalacji na wypadek niekompletnej odpowiedzi dostawcy.

W przypadku zależności open source zachowuj informacje o pochodzeniu i realistyczny plan utrzymania. Publiczna dostępność repozytorium nie dowodzi, że ktoś przygotuje kompatybilną poprawkę w okresie Twojego wsparcia.

Projektuj okres wsparcia i mechanizm aktualizacji razem

Wsparcie to zobowiązanie inżynierskie o konsekwencjach handlowych. CRA co do zasady wymaga okresu wsparcia wynoszącego co najmniej pięć lat, chyba że przewidywany okres użytkowania produktu jest krótszy. Określ właściwy okres na podstawie kryteriów rozporządzenia, zamiast wybierać arbitralną datę dopasowaną do roadmapy.

Zapisz uzasadnienie, przekaż klientom wymagane informacje o wsparciu i powiąż je z utrzymywanymi wersjami produktu. Zobowiązanie dotyczące wsparcia musi uwzględniać zdolność do dostarczania aktualizacji bezpieczeństwa, a nie tylko utrzymywanie adresu helpdesku.

Zanim zatwierdzisz plan wsparcia produktu, zapytaj, czy jesteś w stanie:

• Przebudować starsze wspierane gałęzie przy użyciu utrzymywanych narzędzi.
• Bezpiecznie przygotowywać, uwierzytelniać i dystrybuować aktualizacje bezpieczeństwa.
• Testować poprawki na wszystkich wspieranych konfiguracjach sprzętowych i wdrożeniowych.
• Utrzymywać klucze podpisujące i bezpiecznie odtworzyć działanie po ich naruszeniu.
• Zapewniać dostępność informacji o aktualizacjach i bezpieczeństwie przeznaczonych dla klientów.
• Obsługiwać zależności, których wsparcie upstream kończy się przed Twoim.

Aktualizacje bezpieczeństwa należy co do zasady udostępniać nieodpłatnie w okresie wsparcia, z zastrzeżeniem przepisów rozporządzenia. Każda aktualizacja bezpieczeństwa wydana w tym okresie musi pozostać dostępna przez co najmniej dziesięć lat od jej wydania lub przez pozostałą część okresu wsparcia, w zależności od tego, który okres jest dłuższy. Planuj poprawki bezpieczeństwa oddzielnie od rozwoju funkcji, aby klienci nie byli niepotrzebnie zmuszani do przyjmowania niezwiązanych zmian funkcjonalnych.

Testuj więcej niż ścieżkę optymistyczną. Przerwana instalacja, brak miejsca na dysku, wygasłe poświadczenia i nieudana weryfikacja mogą zamienić poprawną łatkę w problem z dostępnością. Zdecyduj, jakie mechanizmy odtwarzania są potrzebne dla profilu ryzyka produktu.

Po zakończeniu wsparcia komunikacja z klientami i zapisy wewnętrzne powinny być spójne. Nie zostawiaj strony pobierania sugerującej dalsze utrzymanie bezpieczeństwa, gdy rejestr produktów wskazuje, że zobowiązanie wygasło.

Zbuduj runbook zgłaszania odporny na niepewność

Zwykłe wykrycie podatności, aktywnie wykorzystywana podatność i poważny incydent bezpieczeństwa to nie to samo. Proces zgłaszania w ramach CRA wymaga udokumentowanej oceny odpowiedniego zdarzenia uruchamiającego – ani automatycznego zgłaszania każdego alertu skanera, ani automatycznego odrzucania czegokolwiek bez zakończonej analizy kryminalistycznej.

Runbook powinien zaczynać się od przyjmowania zgłoszeń. Badacze, zespół obsługi klienta, dostawcy i zespoły inżynierskie potrzebują znanej ścieżki do funkcji odpowiedzialnej za bezpieczeństwo produktu. Zachowaj oryginalne zgłoszenie i zapisz, kiedy istotne informacje stały się znane; nie resetuj znaczników czasu powzięcia wiadomości, gdy ticket przechodzi do innego zespołu.

W przypadku zdarzeń potencjalnie podlegających zgłoszeniu zbierz:

• Identyfikatory produktu i wspierane wersje, których dotyczy zdarzenie.
• Dowody wykorzystania podatności lub skutków incydentu wraz z poziomem pewności i niewiadomymi.
• Znane warunki ataku, funkcje, których dotyczy zdarzenie, i założenia dotyczące wdrożenia.
• Dostępne środki łagodzące i status działań naprawczych.
• Ocenę zdarzenia uruchamiającego, właściciela zgłoszenia i obliczenia mających zastosowanie terminów.
• Złożone zgłoszenia, potwierdzenia odbioru, kolejne aktualizacje i komunikację z klientami.

Sprawdzaj etapowe terminy powiadomień, wymogi dotyczące sprawozdania końcowego, adresatów i aktualną procedurę zgłaszania w oficjalnych źródłach. Aktywnie wykorzystywane podatności i poważne incydenty mają odrębne szczegóły zgłaszania; jedno skopiowane pole z terminem nie wystarczy.

Wyznacz głównego właściciela zgłoszeń i zastępcę z uprawnieniami do koordynowania pracy inżynierskiej, prawnej i komunikacji z klientami. Zapewnij z wyprzedzeniem dostęp do właściwego mechanizmu zgłaszania. Przegląd prawny powinien być dostępny w oknie zgłoszeniowym, a nie zamieniać się w kolejkę zatwierdzeń bez określonego końca.

Ćwicz proces przy niepełnych informacjach. Użyteczna próba zaczyna się od wiarygodnego zgłoszenia wykorzystania podatności, niepewnej listy wersji, których dotyczy problem, i niedostępnego dostawcy komponentu. Zespół powinien być w stanie podjąć terminową, udokumentowaną decyzję o zgłoszeniu, podczas gdy analiza wciąż trwa.

Zgłaszanie w ramach CRA nie zastępuje innych mających zastosowanie obowiązków. Zdarzenie dotyczące produktu może również wymagać oceny na gruncie przepisów o ochronie danych lub umowy z klientem. Koordynuj te oceny, ale zachowaj ich odrębne zdarzenia uruchamiające, adresatów i zapisy decyzji.

Potwierdź klasyfikację przed wyborem planu oceny

Klasyfikacja produktu wpływa na dostępną procedurę oceny zgodności. Nie zakładaj, że każdy podłączony do sieci produkt wymaga tej samej zewnętrznej oceny ani że każdy producent może polegać na ocenie wewnętrznej.

Określ właściwą kategorię na podstawie funkcji produktu oraz definicji i załączników rozporządzenia. Następnie potwierdź dozwoloną procedurę, w tym wszelkie warunki dotyczące norm zharmonizowanych, uznanych specyfikacji, programów certyfikacji lub oceny przez stronę trzecią.

Planowanie w zakresie norm wymaga jawnego rejestru zależności: które odniesienia mają zastosowanie, jaki jest ich aktualny status i co się zmieni, jeśli oczekiwana procedura okaże się niedostępna. Unikaj uzależniania planu wydań od niepotwierdzonego założenia dotyczącego norm lub dostępności jednostek oceniających.

Wracaj do klasyfikacji, gdy zmienia się funkcjonalność. Dodanie funkcji zarządzania bezpieczeństwem lub kontroli sieci może wpłynąć na analizę, ale sama nazwa funkcji nie przesądza o kategorii. Oceń faktyczną funkcję i udokumentuj wniosek.

Utrzymuj powiązanie klasyfikacji, wybranej procedury i rezultatów oceny zgodności z dokumentacją techniczną. Oznakowanie CE i deklaracja zgodności muszą wynikać z właściwego procesu; nie zastępują wdrożenia wymogów, na których się opierają.

Utrzymuj pakiet dowodów, który potrafi wyjaśnić wydanie

Dokumentacja techniczna powinna opisywać zarówno produkt, jak i uzasadnienie decyzji dotyczących jego bezpieczeństwa. Zachowuj oceny ryzyka i dokumentację w miarę zmian produktu i stosuj do odpowiednich zapisów ustawowe wymogi dotyczące przechowywania.

Użyteczny pakiet dowodów dotyczących produktu obejmuje decyzję o zakresie, architekturę, ocenę ryzyka, wymagania bezpieczeństwa, informacje o komponentach, wyniki weryfikacji, procedury obsługi podatności, uzasadnienie okresu wsparcia i zapisy dotyczące zgodności. Każdy element potrzebuje właściciela i identyfikowalnej wersji.

Używaj stabilnych identyfikatorów do łączenia tych zapisów. Zapis podatności powinien wyjaśniać, których wersji dotyczy, jaka jest ekspozycja, sposób postępowania, wydanie i wymagana komunikacja. Status „naprawione” bez kontekstu wersji pozostawia dowody dotyczące produktu niekompletnymi.

Istniejące procesy SZBI mogą dostarczyć użytecznych dowodów dotyczących ładu organizacyjnego, dostawców i bezpiecznego wytwarzania oprogramowania. ISO 27001 dotyczy jednak systemu zarządzania bezpieczeństwem informacji o określonym zakresie; certyfikacja nie potwierdza zgodności konkretnego produktu z CRA. Wykorzystuj odpowiednie dowody ponownie, nie traktując mapowań między frameworkami jako równoważności prawnej.

Przykład: błąd w zależności we wspieranym urządzeniu

Rozważmy przykładowego producenta dostarczającego w UE urządzenie podłączone do sieci. Przyjmijmy, że jego zakres i klasyfikacja zostały przeanalizowane, dwie gałęzie wydań są nadal wspierane, a dołączona biblioteka została zgłoszona jako aktywnie wykorzystywana w innych miejscach.

Pierwszym zadaniem nie jest zamknięcie komunikatu bezpieczeństwa od dostawcy upstream. Zespół inżynierski ustala, które kompilacje urządzenia zawierają podatną bibliotekę i czy funkcja, której dotyczy problem, jest osiągalna. SBOM wskazuje, że obie gałęzie ją zawierają, ale analiza konfiguracji pokazuje różną ekspozycję. To rozróżnienie zostaje zapisane wraz z dowodami.

Następnie właściciel bezpieczeństwa produktu ocenia, czy dostępne fakty spełniają odpowiednie kryterium zgłoszenia w ramach CRA. Niepewność dotycząca jednej konfiguracji wdrożenia zostaje zapisana; nie uzasadnia ona pozostawienia osoby decyzyjnej niewskazanej. Runbook zgłaszania określa aktualne etapy powiadamiania i procedurę.

Zespół inżynierski przygotowuje tymczasowy środek łagodzący i poprawioną kompilację dla każdej gałęzi, której dotyczy problem. Testy obejmują podatną ścieżkę, normalne działanie i uwierzytelnioną instalację aktualizacji. Jeśli w jednej gałęzi nie można użyć poprawki upstream, zespół zapisuje alternatywny sposób postępowania i ryzyko rezydualne, zamiast oznaczać cały produkt jako naprawiony.

Komunikacja z klientami wskazuje wersje, których dotyczy problem, natychmiastowe działania ochronne i sposób uzyskania aktualizacji. Termin ujawnienia jest koordynowany z mającymi zastosowanie wymogami dotyczącymi obsługi podatności i wszelkimi uzasadnionymi względami bezpieczeństwa.

Kompletny zapis łączy komunikat bezpieczeństwa, analizę kompilacji, których dotyczy problem, decyzję o zgłoszeniu, złożone zgłoszenia (jeśli były wymagane), commity z poprawką, wyniki testów, artefakty wydania i komunikację. Recenzent może teraz odtworzyć zarówno reakcję inżynierską, jak i decyzję dotyczącą zgodności.

Zacznij od jednego produktu i jednego kompletnego łańcucha dowodów

Wybierz reprezentatywny wspierany produkt i prześledź jedno niedawne wydanie oraz jedną podatność w całym cyklu życia. Brakujące powiązania z wersjami, niejasne zobowiązania dotyczące wsparcia i niedostępne procedury zgłaszania szybko staną się widoczne. Zamień każdą lukę w zadanie z przypisanym właścicielem, a następnie rozszerz model na całe portfolio.

Secani może wspierać ten workflow dowodowy, łącząc wymagania, dowody, właścicieli, zadania i decyzje z przeglądów. Narzędzia inżynierskie pozostają operacyjnymi źródłami informacji o kompilacjach, wydaniach i podatnościach; przestrzeń robocza compliance odnosi te zapisy do mających zastosowanie obowiązków. Utrzymuj jednoznaczne zatwierdzanie mapowań i wniosków przez ludzi i zachowuj identyfikowalność źródeł przy korzystaniu z projektów przygotowanych z pomocą AI.

Najpilniejszym kolejnym krokiem jest przetestowanie runbooka zgłaszania. Równolegle wymagaj, aby kolejne wydanie produktu zawierało powiązaną decyzję o zakresie, aktualną ocenę ryzyka, inwentarz komponentów i zatwierdzenie bezpieczeństwa. Tworzy to powtarzalną praktykę inżynierską, podczas gdy przygotowania do oceny zgodności postępują.