CRA nie używa pojęcia „Secure SDLC” i nie narzuca żadnej metodyki. Wymaga jednak, żeby produkt został zaprojektowany, opracowany i wyprodukowany zgodnie z zasadniczymi wymaganiami cyberbezpieczeństwa, a ocena ryzyka była uwzględniana na każdym etapie: od planowania po utrzymanie. Uporządkowany proces bezpiecznego wytwarzania jest praktycznym sposobem, żeby te obowiązki spełnić i udokumentować.
- Podstawa: art. 13 ust. 1–3 i załącznik I. Bezpieczeństwo ma być uwzględnione w planowaniu, projektowaniu, opracowywaniu, produkcji, dostarczaniu i utrzymaniu.
- Rozporządzenie nie wymienia z nazwy żadnej metodyki ani normy procesu wytwarzania.
- Proces trzeba opisać w dokumentacji technicznej (załącznik VII pkt 2): projektowanie, opracowywanie, produkcja, obsługa podatności.
- CRA wymaga skutecznych i regularnych testów oraz przeglądów bezpieczeństwa produktu.
- Przy module H jednostka notyfikowana ocenia system jakości obejmujący projektowanie, rozwój, testy i obsługę podatności.
Czy CRA wymaga Secure SDLC?
CRA nie wymaga Secure SDLC z nazwy. Wymaga, żeby producent zapewnił, że produkt zaprojektowano, opracowano i wyprodukowano zgodnie z zasadniczymi wymaganiami z załącznika I część I (art. 13 ust. 1), oraz żeby uwzględniał ocenę ryzyka na etapach planowania, projektowania, opracowywania, produkcji, dostarczania i utrzymania (art. 13 ust. 2). Jak to zorganizować, decyduje producent.
Secure SDLC, czyli proces bezpiecznego tworzenia oprogramowania, to praktyka, która rozkłada te obowiązki na etapy pracy zespołu. W tym artykule oddzielamy to, co wynika z przepisu, od tego, co jest dobrą praktyką.
Co wynika wprost z przepisów?
Z przepisów wynika pięć rzeczy: ocena ryzyka prowadzona i aktualizowana przez cały cykl życia, projektowanie zgodne z wymaganiami załącznika I, należyta staranność wobec komponentów stron trzecich, skuteczne i regularne testy oraz przeglądy bezpieczeństwa, a także udokumentowanie procesu projektowania, opracowywania, produkcji i obsługi podatności w dokumentacji technicznej.
| Obowiązek | Przepis |
|---|---|
| Produkt zaprojektowany, opracowany i wyprodukowany zgodnie z załącznikiem I część I | Art. 13 ust. 1 |
| Ocena ryzyka uwzględniana od planowania po utrzymanie, dokumentowana i aktualizowana | Art. 13 ust. 2–3 |
| Ograniczenie powierzchni ataku, bezpieczna konfiguracja domyślna, ograniczanie skutków incydentu | Zał. I cz. I pkt 2 lit. b, j, k |
| Należyta staranność przy integrowaniu komponentów stron trzecich | Art. 13 ust. 5 |
| Systematyczne dokumentowanie istotnych aspektów cyberbezpieczeństwa produktu | Art. 13 ust. 7 |
| Skuteczne i regularne testy i przeglądy bezpieczeństwa | Zał. I cz. II pkt 3 |
| Procedury utrzymania zgodności w produkcji seryjnej, z uwzględnieniem zmian w procesie rozwoju i produkcji | Art. 13 ust. 14 |
| Opis projektowania, opracowywania, produkcji i walidacji procesów w dokumentacji technicznej | Zał. VII pkt 2 |
Jak przełożyć te obowiązki na etapy pracy zespołu?
Najprościej przypisać każdemu etapowi cyklu wytwarzania jedno lub dwa działania, które zostawiają dowód. Poniższy podział jest propozycją opartą na praktyce inżynierskiej, a nie listą wymaganą przez CRA. Prawa kolumna pokazuje, co z danego etapu trafia do dokumentacji technicznej.
| Etap | Działanie | Dowód do dokumentacji |
|---|---|---|
| Planowanie | Ocena ryzyka produktu, wymagania bezpieczeństwa, decyzja o okresie wsparcia | Ocena ryzyka, uzasadnienie okresu wsparcia |
| Projektowanie | Analiza zagrożeń dla architektury, decyzje o interfejsach, uwierzytelnianiu, aktualizacjach | Opis architektury, zapis decyzji projektowych |
| Dobór komponentów | Sprawdzenie wsparcia i znanych podatności bibliotek, SDK i modułów | SBOM, kryteria doboru komponentów |
| Implementacja | Zasady kodowania, przegląd kodu, analiza statyczna, zarządzanie sekretami | Opis procesu, wyniki przeglądów |
| Budowanie | Powtarzalny proces budowania, podpisywanie firmware, generowanie SBOM | Opis procesu budowania, SBOM dla wersji |
| Testy | Testy funkcji bezpieczeństwa, skan podatności, testy interfejsów, w razie potrzeby testy penetracyjne | Sprawozdania z testów |
| Wydanie | Sprawdzenie braku znanych podatności możliwych do wykorzystania, bezpieczna konfiguracja domyślna | Lista kontrolna wydania |
| Produkcja | Bezpieczne wgrywanie firmware i kluczy, unikalne dane dostępowe urządzeń | Opis procesów produkcji i ich walidacji |
| Utrzymanie | Śledzenie podatności, aktualizacje zabezpieczeń, aktualizacja oceny ryzyka | Rejestr podatności, historia aktualizacji |
Od czego zacząć, jeśli zespół nie ma formalnego procesu?
Od spisania tego, jak zespół pracuje dzisiaj, i wskazania trzech największych braków wobec tabeli powyżej. W większości zespołów firmware część praktyk już działa: kontrola wersji, przegląd kodu, testy. Brakuje zwykle oceny ryzyka, listy komponentów, zasad dla sekretów i kluczy oraz śladu po decyzjach projektowych.
Pięcioosobowy zespół rozwija firmware sterownika. Ma repozytorium, przegląd kodu i testy funkcjonalne na stanowisku. Nie ma oceny ryzyka, firmware buduje jeden inżynier na własnym komputerze, a hasło serwisowe jest wspólne dla wszystkich urządzeń.
Pierwszy plan obejmuje cztery zmiany: warsztat oceny ryzyka z zapisem decyzji, przeniesienie budowania na serwer z generowaniem SBOM i podpisywaniem firmware, zastąpienie wspólnego hasła danymi unikalnymi dla urządzenia oraz listę kontrolną wydania. Każda z nich usuwa realną lukę i jednocześnie tworzy dowód do dokumentacji technicznej.
Jak Secure SDLC łączy się z oceną zgodności?
W każdej ścieżce oceny zgodności producent musi wykazać, że jego procesy projektowania, opracowywania i produkcji zapewniają zgodność produktu. W module A deklaruje to sam. W module H jednostka notyfikowana ocenia i nadzoruje system jakości producenta obejmujący projektowanie, rozwój, kontrolę i testy produktu końcowego oraz obsługę podatności.
Ścieżki oceny opisuje artykuł CRA a oznakowanie CE: ocena zgodności produktów cyfrowych.
Czego Secure SDLC nie załatwia?
Proces wytwarzania nie zastępuje obowiązków po wprowadzeniu produktu do obrotu. Obsługa zgłoszeń podatności, aktualizacje zabezpieczeń przez okres wsparcia i zgłaszanie do CSIRT w terminach 24 i 72 godzin to osobne procesy z własnymi rolami. Nie zastępuje też dokumentacji technicznej: dostarcza do niej dowodów, ale ktoś musi je zebrać.
Co powinien zrobić producent?
Producent powinien opisać obecny proces wytwarzania, uzupełnić go o brakujące działania z oceny ryzyka, komponentów, budowania i testów, a następnie zadbać o to, żeby każdy etap zostawiał zapis. Proces ma być dopasowany do wielkości zespołu. Krótki, stosowany dokument jest wart więcej niż rozbudowana procedura, której nikt nie przestrzega.
- Spisz obecny proces na jednej stronie: etapy, narzędzia, kto co zatwierdza.
- Przeprowadź ocenę ryzyka produktu i przekuj jej wyniki w wymagania dla projektu.
- Uporządkuj komponenty: kryteria doboru, SBOM, śledzenie podatności.
- Zabezpiecz budowanie i wydawanie: powtarzalny proces, podpis firmware, ochrona kluczy.
- Wprowadź regularne testy i przeglądy bezpieczeństwa i zapisuj ich wyniki.
- Dodaj listę kontrolną wydania, w tym sprawdzenie znanych podatności i konfiguracji domyślnej.
- Przypisz właściciela procesu i przeglądaj go po każdej większej zmianie produktu.
Listę komponentów opisuje artykuł SBOM w Cyber Resilience Act, a wymagania wobec samego urządzenia artykuł CRA dla producentów IoT i elektroniki.