Praktyczne przewodniki dla software house'ów, firm SaaS, zespołów produktowych, producentów hardware i liderów engineeringu, którzy muszą tworzyć bezpieczne produkty cyfrowe oraz spełniać wymagania cyberbezpieczeństwa, w tym Cyber Resilience Act. Omawiamy secure SDLC, product security, threat modeling, zarządzanie podatnościami, SBOM, bezpieczne aktualizacje, DevSecOps, testy bezpieczeństwa, responsible disclosure i podejście secure-by-design.
Modelowanie zagrożeń w systemach wbudowanych: 5 kroków
Jak przeprowadzić modelowanie zagrożeń dla urządzenia, które łączy elektronikę, firmware i komunikację sieciową? Pokazujemy pięć etapów analizy, zastosowanie STRIDE oraz sposób zamiany zagrożeń w wymagania i testy. Przykład rejestratora temperatury obejmuje dostęp serwisowy, ochronę kluczy i aktualizacje oprogramowania. Wyjaśniamy również, dlaczego podpisany firmware nie rozwiązuje wszystkich problemów, CVSS nie zastępuje oceny ryzyka, a model zagrożeń trzeba aktualizować razem z produktem.
Opracowanie: Zespół redakcyjny CCyber
Modelowanie zagrożeń w systemach wbudowanych polega na analizie urządzenia i jego otoczenia z perspektywy możliwego nadużycia. Zespół ustala, co chroni, którędy można wpłynąć na działanie produktu, jakie skutki są istotne i które zabezpieczenia należy zaprojektować lub sprawdzić.
Nie wystarczy przeanalizować aplikacji komunikującej się z urządzeniem. W przykładzie embedded trzeba uwzględnić również firmware, pamięć, interfejsy serwisowe, aktualizacje i dostęp fizyczny. Wynikiem powinny być scenariusze zagrożeń, decyzje o ryzyku, wymagania oraz testy powiązane z konkretną wersją produktu.
19 września 2026 r.
Punktem wyjścia jest artykuł Sii o modelowaniu zagrożeń w systemach wbudowanych. Pięcioetapowy układ nawiązuje do tego materiału. Rozwinięcia techniczne oparto na wskazanych źródłach, a przykład urządzenia, pytania warsztatowe i karta zagrożenia są propozycją CCyber, nie opisem rzeczywistego klienta ani wykrytej podatności.
Dla producentów urządzeń, zespołów firmware i elektroniki, architektów, testerów oraz osób odpowiedzialnych za bezpieczeństwo produktu. Także dla integratorów i właścicieli rozwiązań przemysłowych, którzy chcą wiedzieć, o jakie założenia bezpieczeństwa zapytać dostawcę.
Artykuł koncentruje się na urządzeniu i jego cyklu życia. Ogólny poradnik „Threat modeling: praktyczny przewodnik dla zespołów produktowych” znajdziesz w kategorii Bezpieczne tworzenie oprogramowania i produktów cyfrowych.
Threat modeling to uporządkowana analiza tego, jak można naruszyć bezpieczeństwo systemu. Nie jest wyłącznie listą znanych błędów z baz podatności. Może dotyczyć projektu, który jeszcze nie został zaimplementowany.
OWASP opisuje modelowanie jako proces powtarzalny, obejmujący zrozumienie systemu, identyfikację zagrożeń, wybór reakcji i sprawdzenie wyników. Istotne są przepływy danych oraz granice zaufania, czyli miejsca, w których zmieniają się uprawnienia, kontrola lub założenia dotyczące źródła informacji.
Praktyczne rozróżnienie: zagrożeniem może być nieuprawniona zmiana konfiguracji urządzenia. Brak sprawdzenia uprawnień byłby możliwą słabością umożliwiającą taki scenariusz. To, czy słabość faktycznie występuje, wymaga sprawdzenia projektu lub implementacji.
W tym artykule systemem wbudowanym nazywamy elektronikę i oprogramowanie realizujące określoną funkcję urządzenia. Nie utożsamiamy automatycznie każdego takiego systemu z urządzeniem IoT albo elementem infrastruktury krytycznej.
W analizie urządzenia warto rozdzielić interfejsy sieciowe, lokalne i fizyczne. OWASP IoT Security Testing Guide uwzględnia osobno między innymi pamięć, firmware, mechanizm aktualizacji i różne rodzaje interfejsów. Sam przegląd panelu internetowego nie obejmuje całego tego zakresu.
Pytanie projektowe: czy zabezpieczenie nadal działa, gdy urządzenie trafia do serwisu, zostaje zresetowane albo pracuje bez połączenia z chmurą? Odpowiedź może wymagać zmian w sprzęcie, procedurze produkcji lub obsłudze, nie tylko poprawki w aplikacji.
Rekomendujemy wskazanie wersji sprzętu i firmware, funkcji urządzenia, sposobu użytkowania oraz analizowanego fragmentu. Przygotuj opis interfejsów, przechowywanych danych, aktualizacji i trybów serwisowych. Zapisz również rzeczywiste ograniczenia pamięci, zasilania i czasu reakcji.
Do pracy zaproś osoby znające elektronikę, oprogramowanie, testy i użytkowanie produktu. Właściciel produktu powinien uczestniczyć w ustalaniu priorytetów. Jeżeli urządzenie wpływa na bezpieczeństwo ludzi lub procesów, potrzebny jest również udział osoby odpowiedzialnej za ten obszar.
Takie podejście zespołowe i sprawdzanie założeń projektowych wspiera Microsoft w praktykach Secure by Design. Specjalista security może prowadzić analizę, ale nie zastąpi wiedzy konstruktorów o urządzeniu.
Przykładem będzie modelowy rejestrator temperatury, który zapisuje pomiary lokalnie, wysyła je do chmury i umożliwia aktualizację firmware. Ma również lokalny interfejs serwisowy. Zakładamy, że nie steruje maszyną i nie pełni funkcji zabezpieczenia bezpieczeństwa funkcjonalnego.
Wskaż funkcje, dane i właściwości produktu wymagające ochrony. W naszym przykładzie są to wiarygodność pomiarów, konfiguracja progów alarmowych, tożsamość urządzenia i możliwość bezpiecznego wznowienia pracy.
Uwzględnij otoczenie: operatora, serwisanta, usługę chmurową oraz system przygotowania i dostarczania aktualizacji. Nie każdy z tych elementów musi być szczegółowo analizowany podczas jednej sesji, ale zależności nie powinny znikać z modelu.
Rezultat etapu: uzgodniony zakres, lista chronionych elementów, wersje produktu i jawne wyłączenia. Zapis „analiza tylko komunikacji sieciowej” nie może później zostać przedstawiony jako pełny przegląd sprzętu.
Dla rejestratora opisz osobno przepływ pomiarów, zmian konfiguracji i aktualizacji. Wskaż procesy, pamięć trwałą, komponent startowy uruchamiający firmware oraz interfejs serwisowy.
Przykładowy przepływ danych: czujnik przekazuje pomiar do programu urządzenia, który zapisuje wynik i wysyła go do usługi chmurowej.
Przykładowy przepływ aktualizacji: pakiet z systemu dystrybucji trafia do urządzenia, przechodzi weryfikację i dopiero potem może zostać uruchomiony.
Przy każdym przejściu zapytaj, komu ufamy i co to zaufanie potwierdza. Fizyczne umieszczenie złącza wewnątrz obudowy nie jest samo w sobie mechanizmem sprawdzania uprawnień. Diagram powinien pokazywać także dostęp lokalny, a nie tylko połączenie z internetem.
Rezultat etapu: model przepływów z granicami zaufania i listą punktów wymagających sprawdzenia.
Rozdziel możliwości różnych osób: zdalnego użytkownika bez konta, serwisanta z ograniczonym dostępem i osoby mającej fizyczny dostęp do urządzenia. Nie zakładaj, że każdy atakujący od początku ma pełne uprawnienia.
W przykładzie można rozważyć podszycie się pod urządzenie, nieuprawnioną zmianę progów alarmowych albo instalację starszego firmware. Dla każdego scenariusza zapisz warunki, potrzebny dostęp i możliwy skutek.
Przykład zapisu: osoba mogąca rozpocząć aktualizację próbuje zainstalować wcześniej podpisaną wersję, która nie powinna być już dopuszczona do użycia. To hipoteza do sprawdzenia, nie stwierdzenie, że konkretny produkt jest podatny.
Rezultat etapu: scenariusze odnoszące się do modelu, a nie ogólna lista haseł takich jak „ransomware” lub „atak na sieć”.
Sprawdź wymagany dostęp, trudność wykonania, możliwość wykrycia oraz skutki dla pojedynczego urządzenia i całej grupy produktów. Zaznacz, które informacje są potwierdzone, a które pozostają założeniem.
W materiale Sii pojawia się CVSS. Doprecyzowanie z dokumentacji FIRST: wynik CVSS Base mierzy istotność podatności i nie powinien samodzielnie służyć do oceny ryzyka. Kontekst wdrożenia i zagrożeń wymaga dodatkowej analizy. Wyjaśnia to przewodnik CVSS v4.0.
W naszym przykładzie brak wpływu na sterowanie maszyną nie oznacza braku konsekwencji biznesowych. Nieprawidłowe pomiary mogą uniemożliwić wiarygodną ocenę warunków przechowywania. Tę konsekwencję należy ocenić w rzeczywistym zastosowaniu produktu.
Rezultat etapu: uzasadnione priorytety i wskazanie brakujących danych. Nie nadawaj pozornie precyzyjnej punktacji scenariuszowi, którego warunków nie rozumiesz.
Dla wybranych zagrożeń określ decyzję: zmiana projektu, ograniczenie funkcji, dodatkowe zabezpieczenie albo świadomie udokumentowane pozostawienie ryzyka przez uprawnionego właściciela. Każdej zmianie przypisz wykonawcę i kryterium odbioru.
W rejestratorze może to oznaczać ograniczenie interfejsu serwisowego, ochronę poświadczeń albo kontrolę wersji firmware. Dobór powinien wynikać ze scenariusza i możliwości platformy, nie z listy modnych technologii.
Przy firmware warto myśleć o ochronie przed nieuprawnioną zmianą, jej wykrywaniu oraz bezpiecznym odzyskiwaniu. Te trzy kierunki opisuje NIST SP 800-193.
Rezultat etapu: wymagania i testy powiązane z zagrożeniami. Sam wpis „zastosowano kryptografię” nie określa, co zostało zabezpieczone.
Sii wymienia STRIDE, DREAD, PASTA, TRIKE, VAST i OCTAVE. W naszym przykładzie wykorzystujemy STRIDE do porządkowania scenariuszy. Nie jest to wybór obowiązkowy dla każdego projektu.
Nazwy kategorii pochodzą z dokumentacji Microsoft. Poniższe pytania odnoszące je do rejestratora są propozycją CCyber.
Czy usługa chmurowa odróżni właściwy rejestrator od innego urządzenia przedstawiającego ten sam identyfikator? Jak potwierdzana jest tożsamość serwisanta i źródła aktualizacji?
Czy można zmienić zapisane pomiary, progi alarmowe lub pakiet firmware bez wykrycia? W którym miejscu kontrola integralności faktycznie wpływa na decyzję o przyjęciu danych?
Czy po zmianie konfiguracji można ustalić, kto ją wykonał i jaki był wynik? Co dzieje się z zapisem podczas pracy offline, resetu lub zapełnienia pamięci? Sam fakt istnienia logu nie rozstrzyga jego wiarygodności.
Czy diagnostyka albo odczyt pamięci ujawnia poświadczenia? Czy sekret uzyskany z jednego egzemplarza mógłby zostać wykorzystany wobec innych urządzeń?
Czy obsługa komunikacji może wyczerpać zasoby potrzebne do zbierania pomiarów? Jakie zachowanie ma być oczekiwane przy przeciążeniu lub utracie połączenia z chmurą?
Czy użytkownik uprawniony tylko do odczytu może zmieniać konfigurację albo instalować firmware? Czy tryb serwisowy pozwala ominąć ograniczenia stosowane podczas zwykłej pracy?
STRIDE nie daje gwarancji kompletności. Microsoft podkreśla potrzebę podważania założeń projektowych także poza samymi kategoriami. Dlatego pytanie „co się stanie, jeśli ta kontrola zawiedzie?” pozostaje częścią analizy.
Sprawdź, skąd pochodzą poświadczenia, kto nadaje je podczas produkcji i jak są zmieniane lub unieważniane. OWASP wskazuje ryzyka wynikające z sekretów zaszytych w firmware, w tym możliwość objęcia problemem wielu egzemplarzy i utrudnioną zmianę po ujawnieniu. Zobacz sekcję OWASP dotyczącą firmware.
W naszym przeglądzie warto dodać pytanie: co stanie się po wymianie urządzenia lub zmianie jego właściciela? Nie zakładaj, że reset zawsze usuwa wszystkie dane i uprawnienia.
Podpis pakietu, sprawdzenie podpisu i polityka dopuszczonych wersji rozwiązują różne problemy. Poprawnie podpisana starsza wersja nadal może być niepożądana. OWASP opisuje osobno weryfikację podpisu, autoryzację aktualizacji i ochronę przed cofnięciem wersji w katalogu testów mechanizmu aktualizacji.
W proponowanym projekcie trzeba też uzgodnić odzyskiwanie po przerwaniu aktualizacji. Ochrona przed powrotem do niebezpiecznej wersji nie powinna być projektowana bez analizy dostępnej, zaufanej ścieżki naprawy.
Przejrzyj osobno tryb produkcyjny, serwisowy i awaryjny. Dla każdego ustal dostępne funkcje, uprawnienia i możliwość zauważenia niepożądanej zmiany.
Katalog zdolności bezpieczeństwa urządzeń NIST rozdziela między innymi identyfikację, konfigurację, ochronę danych, kontrolę interfejsów i aktualizacje. To pomoc w doborze wymagań do urządzeń IoT, nie lista identycznych zabezpieczeń dla każdego produktu.
Przykład modelowy CCyber. Przyjmujemy, że zespół testuje rejestrator, a wcześniejsza wersja testowa zawiera znany błąd, którego nie wolno ponownie wprowadzić do urządzenia. Nie opisujemy rzeczywistej podatności konkretnego producenta.
Identyfikator i zakres: TM-UPDATE-01, wskazana rewizja sprzętu, wersja komponentu startowego i mechanizmu aktualizacji.
Chroniony element: integralność działającego oprogramowania oraz wiarygodność pomiarów.
Warunki scenariusza: osoba ma dostęp do funkcji aktualizacji oraz wcześniej podpisanego pakietu. Nie zakładamy przejęcia klucza podpisującego.
Niepożądany rezultat: uruchomienie wersji poniżej zatwierdzonego minimum bezpieczeństwa.
Proponowane wymaganie: standardowy mechanizm aktualizacji odrzuca taki pakiet także wtedy, gdy jego podpis jest poprawny. Zasady odzyskiwania awaryjnego są określone osobno i nie mogą stanowić niekontrolowanego obejścia.
Test: na egzemplarzu laboratoryjnym sprawdzić odrzucenie wycofanej wersji oraz poprawne przyjęcie wersji dopuszczonej. Zarejestrować wersję faktycznie uruchomioną po restarcie.
Dowód i odpowiedzialność: raport z identyfikatorem sprzętu i kompilacji, wynik testu, właściciel poprawki oraz osoba oceniająca pozostałe ryzyko.
To wzór do dopasowania. Testy naruszające normalne działanie wykonuj na uzgodnionym stanowisku, nie na urządzeniu obsługującym produkcję lub proces krytyczny.
Powiąż model z wersją architektury, sprzętu i oprogramowania. Przy zmianie sprawdź, czy powstał nowy interfejs, inny sposób uwierzytelniania, dodatkowy tryb serwisowy lub nowa zależność od dostawcy. Aktualizacji może wymagać również model po incydencie lub ujawnieniu istotnej podatności. Takie utrzymywanie analizy wraz z systemem opisuje OWASP.
Rekomendujemy rozdzielanie statusów: zidentyfikowane, zaplanowano zabezpieczenie, wdrożono oraz zweryfikowano. Dodatkowo oznaczaj scenariusze wymagające informacji i ryzyka formalnie pozostawione przez właściciela.
Przed wydaniem produktu sprawdź, czy istotne scenariusze mają decyzję i czy wymagane testy wykonano na właściwej konfiguracji. Nie uznawaj liczby zamkniętych wpisów za dowód pełnego bezpieczeństwa.
Do diagramów i rejestru można wykorzystać OWASP Threat Dragon. Narzędzie wspiera zapis modelu i zagrożeń, ale nie sprawdzi za zespół rzeczywistego działania interfejsu ani odporności elektroniki.
Weryfikację zakresu norm warto prowadzić oddzielnie od wyboru metody takiej jak STRIDE. Poniższe rozróżnienie opiera się na oficjalnych opisach, nie na analizie wszystkich wymagań norm.
IEC 62443-4-1 opisuje bezpieczny cykl rozwoju produktów dla automatyki i sterowania przemysłowego, w tym sprzętu, oprogramowania i firmware. Ta część dotyczy twórcy i podmiotu utrzymującego produkt. Nie należy automatycznie przenosić jej wszystkich wymagań na użytkownika urządzenia. Zakres podaje IEC.
ISO/SAE 21434 dotyczy inżynierii cyberbezpieczeństwa systemów elektrycznych i elektronicznych pojazdów drogowych. Nie jest uniwersalnym standardem dla każdego urządzenia embedded. Zakres wyjaśnia ISO.
CLC/TS 50701 odnosi się do cyberbezpieczeństwa zastosowań kolejowych i ich cyklu życia. Opis dostępny w BSI wskazuje również, że nie zastępuje wymagań bezpieczeństwa funkcjonalnego.
Sam diagram zagrożeń nie potwierdza zgodności z normą. Trzeba ustalić właściwy zakres, wymagane działania i dowody.
Model produktu warto połączyć z analizą środowiska, w którym urządzenie będzie pracować. Segmentację, zdalny serwis i zależności zakładu rozwijamy w kategorii Bezpieczeństwo OT, przemysłu i infrastruktury krytycznej.
Nie należy jednak traktować zabezpieczeń sieci klienta jako automatycznego zastępstwa dla ochrony samego urządzenia. Założenia dotyczące wdrożenia powinny być jawne i możliwe do sprawdzenia.
W ramach projektów i wdrożeń cyberbezpieczeństwa CCyber wspiera analizę ryzyka, bezpieczeństwo aplikacji, procesy bezpiecznego wytwarzania oraz środowiska OT.
Zacznij od jednej istotnej funkcji urządzenia. Do ustalenia zakresu wsparcia przygotuj opis produktu, interfejsów i zmian planowanych w najbliższym wydaniu. Pozwoli to określić potrzebny udział konstruktorów, zakres analizy i ewentualnych testów laboratoryjnych.
Brak internetu nie usuwa dostępu lokalnego, aktualizacji z nośnika ani interfejsów serwisowych. Zakres analizy może być inny, ale powinien wynikać z rzeczywistych możliwości oddziaływania na urządzenie.
Nie. Analiza pomaga zaplanować wymagania i scenariusze testowe. Nie dowodzi jednak, że implementacja działa zgodnie z projektem. Testy mogą ujawnić błędy lub założenia wymagające aktualizacji modelu.
Nie. STRIDE porządkuje rodzaje zagrożeń. Nadal trzeba ocenić warunki scenariusza, skutki i adekwatność zabezpieczeń. Liczba znalezionych kategorii nie jest miarą ryzyka.
Podpis pomaga sprawdzić pochodzenie i integralność pakietu, jeżeli jest poprawnie weryfikowany względem zaufanego klucza. Nie potwierdza braku błędów w kodzie ani dopuszczalności każdej starszej wersji.
Nie ma jednego czasu właściwego dla wszystkich urządzeń. Zależy on od zakresu, dokumentacji i złożoności. Zacznij od ograniczonej funkcji, a brakujące informacje potraktuj jako zadania. Jedno spotkanie nie musi zamknąć analizy całego produktu.
Modelowanie zagrożeń dla systemu wbudowanego powinno łączyć elektronikę, firmware, komunikację i sposób obsługi urządzenia. Pięć etapów prowadzi od zakresu i przepływów do scenariuszy, priorytetów oraz zabezpieczeń.
Najważniejszym wynikiem jest sprawdzalna decyzja projektowa. Zespół powinien wiedzieć, przed czym chroni produkt, jakie założenia przyjął i jak potwierdzi działanie zabezpieczeń. Taki model pozostaje użyteczny również przy kolejnej wersji urządzenia.
Jak przygotować produkt cyfrowy do testów bezpieczeństwa i certyfikacji?
Przygotowanie produktu cyfrowego do testów bezpieczeństwa i certyfikacji wymaga więcej niż udostępnienia aplikacji testerowi. Firma powinna uporządkować zakres produktu, architekturę, środowisko testowe, dokumentację techniczną, SBOM, model zagrożeń, proces podatności, dowody Secure SDLC i wymagania regulacyjne, szczególnie pod Cyber Resilience Act.
Opracowanie: Zespół redakcyjny CCyber
Produkt cyfrowy warto przygotować do testów bezpieczeństwa i certyfikacji przez uporządkowanie zakresu, architektury, środowiska testowego, dokumentacji, dostępu dla testerów, danych testowych, listy komponentów, SBOM, modelu zagrożeń, wymagań bezpieczeństwa i procesu obsługi podatności. Test bezpieczeństwa sprawdza odporność techniczną produktu. Certyfikacja lub ocena zgodności wymaga dodatkowo dowodów procesu: ryzyka produktu, Secure SDLC, aktualizacji, dokumentacji technicznej, wyników testów, decyzji o ryzyku i obsługi podatności po wydaniu.
Lipiec 2026
Przygotowanie produktu do testów bezpieczeństwa oznacza uporządkowanie wszystkiego, czego testerzy potrzebują, aby wykonać rzetelny test i nie tracić czasu na zgadywanie, jak działa produkt.
W praktyce chodzi o:
Dobrze przygotowany test daje lepszy wynik, ponieważ testerzy mogą skupić się na ryzykach produktu, a nie na szukaniu dostępu, dokumentacji i podstawowych informacji.
Przygotowanie do certyfikacji lub formalnej oceny zgodności oznacza przygotowanie produktu, procesu i dowodów do sprawdzenia względem określonych wymagań. W zależności od celu może chodzić o ocenę zgodności pod CRA, certyfikację cyberbezpieczeństwa, wymagania klienta, audyt dostawcy albo standard branżowy.
Certyfikacja zwykle wymaga więcej niż test penetracyjny. Może wymagać pokazania:
Najprościej: test bezpieczeństwa sprawdza produkt w praktyce, a certyfikacja lub ocena zgodności sprawdza także, czy firma ma proces, dowody i odpowiedzialność za produkt.
Test bezpieczeństwa to techniczna weryfikacja produktu, aplikacji, API, infrastruktury lub komponentu. Jego celem jest znalezienie podatności, błędów konfiguracji, słabości logicznych i ryzyk, które mogą zostać wykorzystane przez atakującego.
Typowy wynik testu:
Certyfikacja lub ocena zgodności sprawdza produkt względem wymagań określonego schematu, regulacji, standardu albo profilu bezpieczeństwa. Może obejmować testy techniczne, ale zwykle obejmuje też dokumentację, proces, role, dowody i formalne decyzje.
Typowy wynik:
Pod CRA producent produktu z elementami cyfrowymi musi wykazać spełnienie wymagań cyberbezpieczeństwa. Dla wielu produktów możliwa będzie samoocena producenta. Dla części produktów ważnych lub krytycznych może być wymagany udział jednostki notyfikowanej albo bardziej rygorystyczna procedura.
Dlatego firma nie powinna zakładać, że „certyfikacja” zawsze oznacza to samo. Najpierw trzeba ustalić, jaki produkt, jaka regulacja, jaki schemat, jaka kategoria i jaki poziom wymagań mają zastosowanie.
Najpierw trzeba odpowiedzieć, po co produkt ma być testowany lub certyfikowany. Inaczej wygląda przygotowanie do testu penetracyjnego API, inaczej do oceny zgodności pod CRA, inaczej do certyfikacji EUCC, a inaczej do ankiety bezpieczeństwa dużego klienta.
Przykładowe cele:
Dowód do przygotowania: krótki opis celu, oczekiwanego wyniku i odbiorcy raportu lub certyfikacji.
Zakres jest jednym z najważniejszych elementów przygotowania. Nieprecyzyjny zakres prowadzi do słabego testu, nieporozumień i problemów z interpretacją wyników.
Zakres powinien obejmować:
Dowód do przygotowania: dokument zakresu testu lub oceny zgodności z listą systemów, wersji i wyłączeń.
Testerzy i audytorzy muszą zrozumieć, jak działa produkt. Bez architektury test będzie bardziej powierzchowny, a certyfikacja może utknąć na brakach w dokumentacji.
Przygotuj:
Dowód do przygotowania: aktualny diagram architektury i przepływów danych.
Środowisko testowe powinno być możliwie podobne do produkcji, ale bez ryzyka dla prawdziwych klientów, danych i procesów biznesowych.
Środowisko powinno mieć:
Nie należy udostępniać testerom środowiska produkcyjnego bez bardzo jasnych zasad, zgód, ograniczeń i oceny ryzyka.
Dowód do przygotowania: opis środowiska testowego, dane dostępowe, zasady testowania i plan przywrócenia stanu.
Dane testowe powinny pozwolić na realistyczny test, ale nie powinny ujawniać prawdziwych danych klientów lub pracowników.
Przygotuj:
Dowód do przygotowania: zestaw danych testowych i potwierdzenie, że nie zawiera danych produkcyjnych ani poufnych.
Testerzy powinni mieć dostęp do ról, które odzwierciedlają realne użycie produktu. Jeśli test obejmuje autoryzację, potrzebne są konta o różnych poziomach uprawnień.
Przygotuj:
Dowód do przygotowania: lista kont testowych, zakres uprawnień i data wygaśnięcia dostępu.
Model zagrożeń pomaga ukierunkować testy na najważniejsze ryzyka. Nie musi być idealny, ale powinien pokazywać, co zespół uważa za najważniejsze zagrożenia produktu.
Model powinien obejmować:
Dowód do przygotowania: model zagrożeń lub lista najważniejszych scenariuszy ryzyka.
Jeśli produkt ma być oceniany pod CRA albo wymagania klientów B2B, lista komponentów jest bardzo ważna. SBOM pomaga sprawdzić zależności, podatności, licencje i wpływ nowych podatności na produkt.
Przygotuj:
Dowód do przygotowania: SBOM powiązany z konkretną wersją produktu.
Przed zewnętrznym testem warto usunąć oczywiste problemy. Dzięki temu budżet testu nie zostanie zużyty na błędy, które firma mogła wykryć sama.
Wewnętrzny przegląd powinien obejmować:
Dowód do przygotowania: lista problemów usuniętych przed testem i status otwartych ryzyk.
Test bezpieczeństwa musi mieć jasne zasady. Testerzy powinni wiedzieć, co wolno, czego nie wolno, kiedy testować, z kim się kontaktować i jak zgłaszać krytyczne podatności.
Zasady powinny określać:
Dowód do przygotowania: zasady testowania zatwierdzone przez właściciela produktu i bezpieczeństwa.
Test nie kończy się na raporcie. Najważniejsze jest to, co firma zrobi z wynikami: jak oceni podatności, kto je naprawi, kiedy nastąpi ponowna weryfikacja i jakie dowody zostaną zachowane.
Proces powinien obejmować:
Dowód do przygotowania: procedura obsługi wyników testu i rejestr napraw.
Jeżeli celem jest certyfikacja, ocena zgodności lub przygotowanie do CRA, firma powinna przygotować pakiet dowodów szerszy niż raport z testu.
Pakiet może obejmować:
Dowód do przygotowania: uporządkowany folder dowodów produktu gotowy do klienta, audytu, jednostki oceniającej lub organu nadzoru.
Sprawdza aplikację webową z perspektywy użytkownika, atakującego i logiki biznesowej. Obejmuje między innymi uwierzytelnianie, autoryzację, sesje, formularze, pliki, błędy, konfigurację i dostęp do danych.
Jest szczególnie ważny dla produktów SaaS, aplikacji mobilnych i integracji B2B. Powinien sprawdzać autoryzację obiektów, role, tokeny, limity zapytań, walidację danych i nadużycia przepływów biznesowych.
Powinien obejmować aplikację, komunikację z API, przechowywanie danych na urządzeniu, ochronę tokenów, konfigurację, reverse engineering i specyficzne ryzyka platform mobilnych.
Sprawdza konfigurację środowiska, sieć, dostęp, konta uprzywilejowane, logowanie, składowanie danych, konfigurację usług chmurowych i bezpieczeństwo wdrożenia.
Sprawdza repozytoria, pipeline, sekrety, artefakty, zależności, podpisywanie, uprawnienia i możliwość podstawienia złośliwego kodu lub komponentu.
Powinien obejmować firmware, aktualizacje, komunikację, interfejsy sprzętowe, konfigurację domyślną, klucze, protokoły, aplikację mobilną i backend.
Może mieć charakter wstępnej oceny gotowości. Celem nie jest tylko znalezienie podatności, ale sprawdzenie, czy produkt i dokumentacja są gotowe do formalnego procesu.
Nie każda certyfikacja pasuje do każdego produktu. Produkt SaaS, aplikacja mobilna, router, firewall, moduł kryptograficzny, urządzenie IoT i komponent sprzętowy mogą wymagać zupełnie innych podejść.
Przed rozpoczęciem sprawdź:
EUCC to unijny schemat certyfikacji oparty na Common Criteria. Może dotyczyć produktów ICT, takich jak komponenty technologiczne, sprzęt i oprogramowanie. Jest to podejście bardziej formalne niż zwykły test penetracyjny i wymaga przygotowania wymagań bezpieczeństwa, dokumentacji oraz oceny przez właściwe podmioty.
Nie każdy software house będzie od razu potrzebował EUCC. Warto jednak rozumieć ten kierunek, jeśli produkt ma funkcje bezpieczeństwa, jest używany w sektorach regulowanych, będzie sprzedawany dużym klientom albo może należeć do kategorii wymagającej wyższego poziomu zapewnienia.
Wiele firm powinno zacząć nie od samej certyfikacji, ale od oceny gotowości. Taka ocena pokazuje, czy produkt ma wystarczającą dokumentację, testy, procesy, dowody i kontrolę wersji.
Ocena gotowości pozwala uniknąć sytuacji, w której formalny proces zaczyna się zbyt wcześnie i ujawnia braki, które można było przygotować wcześniej.
Niejasny zakres prowadzi do sporów, luk w testach i raportu, którego trudno użyć. Zakres musi wskazywać produkt, wersję, moduły, konta, API, integracje i wyłączenia.
Jeśli środowisko testowe znacząco różni się od produkcji, wyniki testu mogą być mniej wartościowe. Różnice powinny być opisane i świadomie zaakceptowane.
Bez realistycznych kont, ról i danych testerzy nie sprawdzą poprawnie autoryzacji, separacji danych, przepływów biznesowych i wielodostępności w SaaS.
Raport z testu nie jest automatycznie certyfikatem. Może być dowodem technicznym, ale certyfikacja lub ocena zgodności zwykle wymaga szerszej dokumentacji i procesu.
Jeśli po teście nie ma triage, właścicieli, terminów napraw i ponownej weryfikacji, raport nie przekłada się na realną poprawę bezpieczeństwa.
Dla oceny zgodności i certyfikacji brak dokumentacji jest jednym z największych problemów. Produkt może być technicznie dobry, ale trudny do formalnego potwierdzenia.
CRA wymaga procesu, dokumentacji i dowodów. Tego nie da się przygotować w ostatnim tygodniu przed oceną. Najlepiej zacząć od oceny gotowości i planu działań.
Firma SaaS przygotowuje platformę B2B do testu bezpieczeństwa wymaganego przez dużego klienta. Zespół chce od razu zamówić test penetracyjny, ale szybko okazuje się, że nie ma aktualnego diagramu architektury, środowisko testowe różni się od produkcji, brakuje kont dla różnych ról, a API nie jest dobrze opisane.
Firma najpierw wykonuje przygotowanie do testu. Ustala zakres, tworzy konta testowe, przygotowuje dane dla dwóch klientów testowych, opisuje API, zbiera dokumentację i uruchamia wewnętrzne skanowanie zależności oraz sekretów.
Dzięki temu zewnętrzny test jest bardziej wartościowy. Testerzy nie tracą czasu na organizację dostępu, tylko sprawdzają realne ryzyka: autoryzację, separację danych klientów, API, panel administratora, eksport danych i integracje.
Po teście firma robi triage, naprawia podatności i wykonuje ponowną weryfikację. Następnie wykorzystuje raport jako część większego pakietu dowodów: SBOM, model zagrożeń, rejestr podatności, proces aktualizacji i dokumentację techniczną pod CRA.
ccyber.io pomaga firmom przygotować produkty cyfrowe do testów bezpieczeństwa, certyfikacji, oceny zgodności i wymagań klientów B2B. Nie zaczynamy od samego testu. Najpierw sprawdzamy, czy produkt, środowisko, dokumentacja i procesy są gotowe.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest krótka ocena gotowości produktu. Pokazuje, czy produkt jest przygotowany do testu, czego brakuje przed oceną zgodności i które działania warto wykonać przed zaangażowaniem zewnętrznych testerów albo jednostki oceniającej.
Nie. Test bezpieczeństwa wykrywa podatności i ryzyka techniczne. Certyfikacja lub ocena zgodności sprawdza produkt względem określonych wymagań i zwykle wymaga szerszej dokumentacji, procesu oraz dowodów.
Nie. Raport z testu może być ważnym dowodem, ale CRA wymaga szerszego podejścia: oceny ryzyka, dokumentacji technicznej, obsługi podatności, aktualizacji, SBOM, okresu wsparcia i informacji dla użytkownika.
Nie. Dla wielu produktów możliwa będzie samoocena producenta. Niektóre produkty ważne lub krytyczne mogą jednak wymagać bardziej rygorystycznej procedury albo udziału jednostki notyfikowanej.
Zakres testu, środowisko testowe, konta użytkowników, dane testowe, opis ról, opis API, architekturę, zasady testowania, osoby kontaktowe i proces obsługi wyników.
Dokumentację API, konta i tokeny o różnych rolach, przykładowe zapytania, dane testowe, limity, opis autoryzacji, scenariusze biznesowe i środowisko testowe.
W wielu przypadkach tak. SBOM jest bardzo ważny przy CRA, zarządzaniu podatnościami, ocenie komponentów, odpowiedziach dla klientów i dokumentacji technicznej produktu.
To stan, w którym produkt ma nie tylko wyniki testów, ale także zakres, dokumentację, procesy, dowody, właścicieli i kontrolę wersji potrzebne do formalnej oceny.
Najlepiej zacząć od oceny gotowości: zakres, architektura, środowisko testowe, konta, dane, API, podstawowe skanowanie, model zagrożeń i plan obsługi wyników testu.
Przygotowanie produktu cyfrowego do testów bezpieczeństwa i certyfikacji wymaga uporządkowania produktu, procesu i dowodów. Samo udostępnienie aplikacji testerowi nie wystarczy, jeśli brakuje zakresu, środowiska, danych, dokumentacji i procesu obsługi wyników.
Dla firm przygotowujących się do CRA lub wymagań dużych klientów kluczowe jest szersze podejście: ocena ryzyka, dokumentacja techniczna, SBOM, proces podatności, aktualizacje bezpieczeństwa, model zagrożeń i dowody Secure SDLC.
Najlepsza kolejność to: najpierw gotowość, potem test, następnie naprawy i ponowna weryfikacja, a dopiero później formalna certyfikacja lub ocena zgodności, jeśli jest wymagana.
Bezpieczne aktualizacje: jak przygotować proces aktualizacji produktu pod wymagania CRA?
Bezpieczne aktualizacje produktu cyfrowego to nie tylko wydanie poprawki. Pod Cyber Resilience Act producent powinien mieć proces wykrywania podatności, przygotowania poprawki, testowania, podpisywania, bezpiecznej dystrybucji, komunikacji z użytkownikami, monitorowania wdrożenia i dokumentowania dowodów przez cały okres wsparcia produktu.
Opracowanie: Zespół redakcyjny CCyber
Bezpieczny proces aktualizacji pod CRA powinien obejmować cały cykl życia poprawki: wykrycie podatności, ocenę ryzyka, przygotowanie zmiany, testy, zatwierdzenie, podpisanie artefaktu, bezpieczną dystrybucję, komunikat dla użytkowników, monitorowanie wdrożenia i dokumentowanie dowodów. Producent produktu z elementami cyfrowymi powinien też określić okres wsparcia, zapewnić aktualizacje bezpieczeństwa bez zbędnej zwłoki, przygotować możliwość automatycznych aktualizacji tam, gdzie ma to zastosowanie, oraz oddzielać aktualizacje bezpieczeństwa od funkcjonalnych, jeśli jest to technicznie możliwe.
Lipiec 2026
Bezpieczne aktualizacje to proces przygotowywania, sprawdzania i dostarczania poprawek produktu w taki sposób, aby zmniejszać ryzyko podatności, nie wprowadzać nowych błędów i nie umożliwiać atakującym podstawienia złośliwej wersji produktu.
W praktyce bezpieczny proces aktualizacji odpowiada na pytania:
Bezpieczna aktualizacja nie dotyczy wyłącznie kodu. Dotyczy również procesu budowania, kontroli zmian, podpisów, kanałów dystrybucji, dokumentacji, wsparcia użytkownika i reakcji na podatności.
Cyber Resilience Act wprowadza wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi. Jednym z kluczowych obszarów jest obsługa podatności przez cały okres wsparcia produktu.
Dla producentów oznacza to, że produkt powinien być projektowany i utrzymywany tak, aby możliwe było:
CRA zmienia więc aktualizacje z tematu technicznego w temat produktowy, regulacyjny i biznesowy. Zespół musi wiedzieć nie tylko, jak wydać poprawkę, ale też jak wykazać, że proces działa.
Producent powinien mieć proces, który pozwala reagować na podatności i usuwać je przez aktualizacje bezpieczeństwa. To wymaga połączenia zarządzania podatnościami, procesu wydawniczego, testów, komunikacji i dokumentacji.
Jeżeli firma wie o istotnej podatności, nie powinna odkładać poprawki bez uzasadnienia. Priorytet powinien zależeć od ryzyka, ekspozycji produktu, aktywnego wykorzystania podatności, wpływu na klientów i dostępności obejścia.
Użytkownik nie powinien być zmuszany do instalowania dużej aktualizacji funkcjonalnej tylko po to, aby otrzymać poprawkę bezpieczeństwa, jeśli technicznie można te aktualizacje rozdzielić.
CRA wskazuje na automatyczne aktualizacje bezpieczeństwa w określonych przypadkach, w szczególności dla produktów konsumenckich. Jednocześnie użytkownik powinien mieć jasny i prosty mechanizm wyłączenia automatycznych aktualizacji oraz możliwość czasowego odroczenia instalacji.
Aktualizacja bezpieczeństwa powinna być połączona z informacją, co naprawia, jakie działania użytkownik powinien wykonać i czy istnieje ryzyko wymagające dodatkowych kroków.
Użytkownik powinien wiedzieć, do kiedy może oczekiwać obsługi podatności i aktualizacji bezpieczeństwa. Końcowa data okresu wsparcia powinna być wskazana jasno, z miesiącem i rokiem.
Nie da się dobrze zarządzać aktualizacjami, jeśli firma nie wie, które produkty i wersje są nadal wspierane. Pierwszy krok to rejestr produktów i wersji.
Rejestr powinien obejmować:
Dowód do przygotowania: rejestr produktów, wersji i okresów wsparcia.
Polityka aktualizacji powinna określać, kiedy firma wydaje poprawkę bezpieczeństwa, kto podejmuje decyzję, jak wygląda testowanie i jak użytkownicy są informowani.
Polityka powinna zawierać:
Dowód do przygotowania: polityka aktualizacji bezpieczeństwa zatwierdzona przez właściciela produktu i bezpieczeństwa.
Aktualizacja bezpieczeństwa zwykle wynika z podatności. Dlatego proces aktualizacji powinien być połączony z rejestrem podatności, SBOM i procesem oceny ryzyka.
Dla każdej ważnej podatności ustal:
Dowód do przygotowania: powiązanie podatności z wydaniem poprawki i decyzją komunikacyjną.
Atakujący może próbować podmienić poprawkę, przejąć proces budowania, ukraść klucz podpisu albo wstrzyknąć złośliwy kod do procesu wydania. Dlatego bezpieczeństwo aktualizacji zależy także od bezpieczeństwa procesu wytwarzania.
Sprawdź:
Dowód do przygotowania: opis procesu budowania i wydania, logi zatwierdzeń oraz lista osób z uprawnieniami.
Użytkownik lub system powinien mieć możliwość sprawdzenia, że aktualizacja pochodzi od właściwego producenta i nie została zmieniona po drodze.
W praktyce oznacza to:
Dowód do przygotowania: procedura podpisywania aktualizacji, rejestr kluczy i dowody weryfikacji podpisu.
Kanał dystrybucji aktualizacji może być celem ataku. Jeżeli atakujący przejmie serwer aktualizacji, repozytorium, konto administracyjne albo system dystrybucji, może próbować dostarczyć złośliwą wersję produktu.
Kontrole bezpieczeństwa powinny obejmować:
Dowód do przygotowania: diagram kanału aktualizacji, kontrola dostępu, logi i plan awaryjny.
Poprawka bezpieczeństwa nie może naprawiać jednej podatności i jednocześnie powodować nowego incydentu. Testy powinny obejmować zarówno bezpieczeństwo, jak i stabilność produktu.
Testy powinny obejmować:
Dowód do przygotowania: raport testów aktualizacji, decyzja o dopuszczeniu wydania i lista znanych ograniczeń.
Dla części produktów automatyczne aktualizacje bezpieczeństwa będą najlepszym sposobem ograniczenia ryzyka. Nie zawsze jednak można instalować poprawki automatycznie bez wpływu na użytkownika, produkcję lub integracje.
Proces powinien określać:
Dowód do przygotowania: opis mechanizmu automatycznych aktualizacji, instrukcja dla użytkownika i rejestr decyzji produktowych.
Aktualizacja bezpieczeństwa powinna być zrozumiała dla użytkownika. Komunikat nie musi ujawniać wszystkich szczegółów technicznych przed naprawą, ale powinien jasno wskazywać, co użytkownik ma zrobić.
Komunikat może zawierać:
Dowód do przygotowania: zatwierdzony komunikat bezpieczeństwa i lista kanałów komunikacji.
Wydanie poprawki nie oznacza, że ryzyko zniknęło. Firma powinna wiedzieć, ilu użytkowników zainstalowało aktualizację, które wersje są nadal podatne i czy pojawiły się problemy po wdrożeniu.
Monitoruj:
Dowód do przygotowania: raport adopcji aktualizacji i lista problemów po wydaniu.
CRA wymaga, aby aktualizacje bezpieczeństwa udostępnione użytkownikom w okresie wsparcia pozostawały dostępne po wydaniu przez co najmniej 10 lat albo przez pozostałą część okresu wsparcia, w zależności od tego, który okres jest dłuższy.
To oznacza, że producent powinien zaplanować:
Dowód do przygotowania: polityka przechowywania aktualizacji i rejestr dostępnych wersji.
Pod CRA aktualizacje bezpieczeństwa są częścią dowodów, że producent obsługuje podatności i utrzymuje produkt w sposób bezpieczny. Dowody powinny być dostępne w dokumentacji technicznej albo powiązanych rejestrach.
Dokumentuj:
Dowód do przygotowania: pełny pakiet dowodów aktualizacji bezpieczeństwa.
W modelu SaaS producent zwykle kontroluje środowisko produkcyjne i może szybciej wdrażać poprawki. Wyzwanie polega na kontroli zmian, testach regresji, komunikacji z klientami i monitorowaniu wpływu na integracje.
W SaaS szczególnie ważne są:
Przy oprogramowaniu instalowanym u klienta producent często nie ma pełnej kontroli nad momentem instalacji. Dlatego ważne są mechanizm aktualizacji, powiadomienia, instrukcje, kompatybilność i monitoring wersji, jeśli jest możliwy.
Aplikacje mobilne zależą od sklepów aplikacji, systemów operacyjnych i zachowania użytkowników. Firma powinna planować, jak szybko poprawka trafi do użytkownika i jak ograniczyć ryzyko dla starszych wersji.
W produktach IoT i systemach wbudowanych aktualizacja może dotyczyć firmware, urządzeń o ograniczonych zasobach, łączności niestabilnej i ryzyka fizycznego. Szczególnie ważne są podpisy, weryfikacja integralności, odporność na przerwaną aktualizację i możliwość bezpiecznego powrotu do działania.
Jeśli firma dostarcza komponent, bibliotekę, SDK albo API, powinna przygotować jasne wersjonowanie, komunikaty o podatnościach, instrukcje aktualizacji i informacje dla integratorów. Klient musi wiedzieć, jak bezpiecznie zaktualizować komponent w swoim produkcie.
Jeżeli firma nie wie, które wersje produktu wspiera, trudno ustalić, dla których wersji trzeba przygotować poprawkę i których klientów poinformować.
Presja czasu po wykryciu podatności może prowadzić do zbyt szybkiego wydania. Poprawka bezpieczeństwa nadal musi być przetestowana, szczególnie jeśli dotyczy uwierzytelniania, dostępu, danych klientów albo procesu instalacji.
Niepodpisane albo słabo chronione aktualizacje mogą zostać podmienione. Dla produktu cyfrowego mechanizm aktualizacji jest jednym z najbardziej wrażliwych elementów bezpieczeństwa.
Aktualizacja może się nie udać. Firma powinna wiedzieć, jak produkt wróci do działania, jak chronione są dane i jak użytkownik otrzyma pomoc.
Jeśli użytkownik musi instalować dużą zmianę funkcjonalną tylko po to, aby otrzymać poprawkę bezpieczeństwa, rośnie ryzyko opóźnień i problemów kompatybilności.
Użytkownik musi wiedzieć, że aktualizacja jest dostępna, jaki problem rozwiązuje i co powinien zrobić. Brak komunikacji wydłuża czas ekspozycji na podatność.
Jeżeli firma nie dokumentuje testów, zatwierdzeń, podpisów, publikacji i komunikacji, trudno wykazać zgodność z wymaganiami, nawet jeśli aktualizacja została wykonana poprawnie.
Firma tworzy aplikację desktopową używaną przez klientów B2B w sektorze regulowanym. Produkt ma moduł aktualizacji, ale nie ma jasnej polityki wsparcia, podpisywanie aktualizacji jest wykonywane ręcznie, a komunikaty do klientów są przygotowywane dopiero wtedy, gdy pojawia się problem.
Po analizie CRA firma zauważa, że musi uporządkować cały proces. Najpierw tworzy rejestr wersji wspieranych, określa okres wsparcia, wskazuje właściciela procesu aktualizacji i łączy podatności z wydaniami poprawek.
Następnie firma wprowadza podpisywanie artefaktów, testy instalacji aktualizacji, plan postępowania przy nieudanej aktualizacji i szablon komunikatu bezpieczeństwa. Dodaje też raport adopcji, aby widzieć, którzy klienci nadal korzystają ze starszych wersji.
Po 90 dniach firma nie tylko wydaje poprawki szybciej, ale też ma dowody: kto zatwierdził poprawkę, co naprawiono, jak ją przetestowano, kiedy ją opublikowano i ilu klientów ją zainstalowało.
ccyber.io pomaga firmom tworzącym produkty cyfrowe przygotować bezpieczny proces aktualizacji zgodny z wymaganiami CRA, praktykami Secure SDLC i realnym sposobem pracy zespołów produktowych.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest krótki assessment procesu aktualizacji. Pozwala ustalić, które produkty wymagają największej uwagi, gdzie brakuje kontroli i co trzeba wdrożyć przed terminami CRA.
To aktualizacja przygotowana, przetestowana, podpisana, dystrybuowana i monitorowana w taki sposób, aby usuwać ryzyko bezpieczeństwa bez tworzenia nowego ryzyka dla użytkownika i produktu.
CRA wskazuje automatyczne aktualizacje bezpieczeństwa tam, gdzie ma to zastosowanie, szczególnie dla produktów konsumenckich. Użytkownik powinien mieć też jasny mechanizm wyłączenia automatycznych aktualizacji i możliwość czasowego odroczenia.
CRA wskazuje, że gdy jest to technicznie możliwe, aktualizacje bezpieczeństwa powinny być dostarczane oddzielnie od aktualizacji funkcjonalnych. Celem jest to, aby użytkownik nie musiał instalować dużej zmiany funkcjonalnej tylko po to, aby otrzymać poprawkę bezpieczeństwa.
CRA wskazuje, że aktualizacje bezpieczeństwa służące usunięciu zidentyfikowanych problemów powinny być dostarczane bez opóźnień i bezpłatnie, chyba że inaczej uzgodniono między producentem a użytkownikiem biznesowym dla produktu tworzonego na zamówienie.
CRA wymaga, aby każda aktualizacja bezpieczeństwa udostępniona użytkownikom w okresie wsparcia pozostawała dostępna po wydaniu przez co najmniej 10 lat albo przez pozostałą część okresu wsparcia, w zależności od tego, który okres jest dłuższy.
Nie zawsze. Firma powinna zapewnić bezpieczny kanał dystrybucji, integralność aktualizacji, instrukcje dla użytkownika, komunikację, testy, monitorowanie i dowody. Samo opublikowanie pliku może być niewystarczające.
Tak. Proces aktualizacji, obsługi podatności, testów, wsparcia i dowodów powinien być powiązany z dokumentacją techniczną produktu oraz procesem oceny zgodności.
Najlepiej zacząć od rejestru produktów i wspieranych wersji, polityki aktualizacji bezpieczeństwa, połączenia z rejestrem podatności, przeglądu podpisywania aktualizacji oraz przygotowania komunikatów i dowodów.
Bezpieczne aktualizacje są jednym z najważniejszych elementów zgodności z CRA i realnego bezpieczeństwa produktu cyfrowego. Produkt, którego nie da się bezpiecznie aktualizować, będzie trudny do utrzymania, trudny do obrony przed klientami i trudny do wykazania w dokumentacji technicznej.
Najważniejsze elementy procesu to rejestr produktów, okres wsparcia, zarządzanie podatnościami, testowanie, podpisywanie, bezpieczna dystrybucja, automatyzacja tam, gdzie ma zastosowanie, komunikacja i monitoring adopcji aktualizacji.
Firmy, które przygotują ten proces wcześniej, będą lepiej gotowe na CRA, pytania klientów, audyty, incydenty i sytuacje, w których trzeba szybko wydać krytyczną poprawkę bezpieczeństwa.
Zarządzanie podatnościami dla produktów cyfrowych: od czego zacząć?
Zarządzanie podatnościami w produktach cyfrowych nie kończy się na skanowaniu bibliotek i czekaniu na raport z testu penetracyjnego. Firmy tworzące oprogramowanie powinny mieć proces wykrywania, oceny, priorytetyzacji, naprawy, testowania, komunikowania i dokumentowania podatności przez cały cykl życia produktu, szczególnie pod Cyber Resilience Act.
Opracowanie: Zespół redakcyjny CCyber
Zarządzanie podatnościami dla produktów cyfrowych to proces wykrywania, oceny, priorytetyzacji, naprawy, testowania, komunikowania i dokumentowania podatności w oprogramowaniu, komponentach, API, chmurze, konfiguracji, zależnościach i procesie wydawniczym. Firma powinna zacząć od rejestru produktów, rejestru komponentów, kanału zgłaszania podatności, jasnych ról, klasyfikacji ryzyka, terminów napraw, procesu aktualizacji, SBOM, testów bezpieczeństwa oraz procedury zgłoszeń pod Cyber Resilience Act.
Lipiec 2026
Zarządzanie podatnościami produktu cyfrowego to uporządkowany proces obsługi słabości bezpieczeństwa, które mogą występować w produkcie, jego komponentach, konfiguracji, bibliotekach, interfejsach API, środowisku chmurowym, procesie wdrożeniowym albo dokumentacji.
W praktyce proces odpowiada na pytania:
Dobre zarządzanie podatnościami nie polega na tym, że firma „ma skaner”. Skaner jest tylko jednym ze źródeł informacji. Najważniejszy jest proces, który zamienia informację o podatności w decyzję, poprawkę, test, komunikację i dowód.
Podatność to słabość produktu, komponentu, procesu lub konfiguracji, która może zostać wykorzystana do naruszenia bezpieczeństwa. Może dotyczyć kodu, zależności, ustawień chmury, kontroli dostępu, logiki biznesowej albo procesu aktualizacji.
Błąd to nieprawidłowe działanie systemu. Nie każdy błąd jest podatnością bezpieczeństwa, ale część błędów może prowadzić do podatności. Przykład: błąd w walidacji danych może umożliwić wstrzyknięcie polecenia albo obejście kontroli dostępu.
Ryzyko to połączenie prawdopodobieństwa wykorzystania podatności i skutków dla firmy, produktu oraz klientów. Ta sama podatność może mieć inny poziom ryzyka w różnych produktach.
Incydent to zdarzenie, które negatywnie wpływa lub może negatywnie wpłynąć na bezpieczeństwo produktu, danych, funkcji albo usług. Podatność może prowadzić do incydentu, ale nie każda podatność oznacza, że incydent już wystąpił.
Cyber Resilience Act wprowadza wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi. Dla firm tworzących oprogramowanie oznacza to konieczność zabezpieczania produktu przez cały cykl życia: od projektowania i rozwoju, przez wydanie, aż po aktualizacje, obsługę podatności i komunikację z użytkownikami.
Pod CRA producent musi być przygotowany na:
Od 11 września 2026 roku zaczynają obowiązywać wymagania raportowania aktywnie wykorzystywanych podatności i poważnych incydentów przez Single Reporting Platform. To oznacza, że firmy nie powinny czekać do 2027 roku z budową procesu. Bez rejestru podatności, właścicieli, klasyfikacji i ścieżki eskalacji trudno będzie dotrzymać terminów zgłoszeń.
Nie można skutecznie zarządzać podatnościami, jeśli firma nie wie, które produkty, wersje i komponenty utrzymuje. Pierwszy krok to rejestr produktów cyfrowych.
Rejestr powinien obejmować:
Dowód do przygotowania: rejestr produktów i wersji z właścicielami oraz statusem wsparcia.
Duża część podatności w produktach cyfrowych dotyczy komponentów zewnętrznych: bibliotek, pakietów, obrazów kontenerów, zależności pośrednich i narzędzi używanych w procesie budowania.
Firma powinna przygotować SBOM, czyli zestawienie komponentów oprogramowania, i powiązać je z konkretną wersją produktu.
SBOM pomaga odpowiedzieć na pytania:
Dowód do przygotowania: SBOM dla kluczowych produktów, rejestr komponentów i proces aktualizacji SBOM przy wydaniach.
Podatności mogą zostać wykryte na wiele sposobów. Firma powinna świadomie określić, z jakich źródeł korzysta i kto je monitoruje.
Typowe źródła:
Dowód do przygotowania: lista źródeł podatności, właściciele monitoringu i częstotliwość przeglądu.
Firma tworząca produkt cyfrowy powinna mieć jasny sposób przyjmowania zgłoszeń podatności. Bez tego badacz, klient albo partner może nie wiedzieć, gdzie zgłosić problem.
Warto przygotować:
Dowód do przygotowania: polityka zgłaszania podatności, publiczny kanał kontaktu i procedura obsługi zgłoszeń.
Rejestr podatności jest centrum procesu. Powinien zbierać wszystkie podatności niezależnie od źródła: skanera, klienta, testu penetracyjnego, badacza, incydentu albo informacji od dostawcy.
Rejestr powinien zawierać:
Dowód do przygotowania: centralny rejestr podatności z historią decyzji i działań.
Nie każda podatność z wynikiem wysokim oznacza, że produkt jest realnie narażony. I odwrotnie: podatność z wynikiem średnim może być krytyczna, jeśli dotyczy funkcji wystawionej publicznie, danych klientów albo dostępu administracyjnego.
Przy ocenie podatności uwzględnij:
Dowód do przygotowania: decyzja klasyfikacyjna z uzasadnieniem, a nie tylko wynik ze skanera.
Firma powinna mieć wewnętrzne terminy reakcji i naprawy. Terminy zależą od ważności podatności, ekspozycji produktu, dostępności poprawki i realnego ryzyka.
Przykładowy model:
Terminy nie powinny być kopiowane mechanicznie z internetu. Powinny wynikać z apetytu na ryzyko, wymagań klientów, regulacji i możliwości zespołu.
Dowód do przygotowania: polityka terminów napraw i historia realizacji terminów.
Dobra naprawa podatności nie powinna ograniczać się do zmiany jednej linii kodu, jeśli problem wynika z błędnego wzorca projektowego, braku testów albo słabej kontroli dostępu.
Przy każdej ważnej podatności zapytaj:
Dowód do przygotowania: opis przyczyny, poprawka, test regresji i działania zapobiegawcze.
Naprawa podatności powinna zostać przetestowana. W przeciwnym razie firma nie wie, czy problem rzeczywiście zniknął i czy nie pojawił się nowy błąd.
Weryfikacja może obejmować:
Dowód do przygotowania: wynik ponownej weryfikacji i potwierdzenie zamknięcia podatności.
Jeśli podatność wpływa na klientów lub użytkowników, trzeba zaplanować komunikację. Nie każda podatność wymaga publicznego komunikatu, ale każda ważna podatność powinna mieć decyzję komunikacyjną.
Komunikat bezpieczeństwa może zawierać:
Dowód do przygotowania: zatwierdzony komunikat, lista odbiorców, data publikacji i historia aktualizacji.
Od 11 września 2026 roku producenci produktów z elementami cyfrowymi muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty wpływające na bezpieczeństwo produktu przez Single Reporting Platform.
Proces powinien wskazywać:
Dowód do przygotowania: procedura zgłoszeń CRA, lista ról, wzory notatek i rejestr zgłoszeń.
Każda poważna podatność jest okazją do poprawy procesu. Firma powinna analizować nie tylko, jak szybko naprawiła problem, ale też dlaczego problem powstał i czy można zapobiec podobnym błędom.
Po ważnej podatności warto przeprowadzić krótkie podsumowanie:
Dowód do przygotowania: notatka lessons learned i lista działań usprawniających.
CVSS jest przydatnym standardem oceny technicznej ważności podatności, ale nie powinien być jedynym kryterium kolejności napraw. Produkt cyfrowy ma swój kontekst: klientów, dane, ekspozycję, architekturę, kontrole ograniczające i zobowiązania umowne.
Podatność aktywnie wykorzystywana przez atakujących powinna mieć wyższy priorytet niż podatność teoretyczna o podobnym wyniku technicznym. Pod CRA aktywne wykorzystanie może uruchamiać obowiązki zgłoszeniowe, jeśli dotyczy produktu z elementami cyfrowymi.
EPSS może wspierać ocenę prawdopodobieństwa wykorzystania podatności w najbliższym czasie. Nie zastępuje oceny zespołu, ale pomaga odróżnić podatności, które są tylko „wysokie technicznie”, od tych, które są bardziej prawdopodobne do wykorzystania.
Podatność w funkcji dostępnej publicznie przez internet ma inny priorytet niż podatność w komponencie niedostępnym z zewnątrz i nieużywanym w produkcie.
Jeśli podatność może prowadzić do dostępu do danych klientów, danych osobowych, danych finansowych, sekretów, kluczy API albo danych wielu najemców w SaaS, priorytet powinien wzrosnąć.
Czasem szybka aktualizacja biblioteki usuwa ważne ryzyko przy niewielkim koszcie. Innym razem poprawka wymaga zmiany architektury. Priorytetyzacja powinna uwzględniać zarówno ryzyko, jak i realny plan naprawy.
Skaner może znaleźć podatność, ale nie ustali właściciela, priorytetu, terminu, komunikacji, wpływu na klientów i obowiązków zgłoszeniowych. Firma potrzebuje procesu, nie tylko narzędzia.
Jeżeli podatność nie jest powiązana z konkretną wersją produktu, trudno ustalić, którzy klienci są narażeni i czy poprawka została wdrożona.
Jeśli badacz lub klient nie wie, gdzie zgłosić podatność, informacja może trafić do niewłaściwej osoby, zostać zignorowana albo zostać opublikowana bez koordynacji.
CVSS jest ważny, ale nie wystarcza. Priorytet naprawy musi uwzględniać produkt, klientów, ekspozycję, aktywne wykorzystanie i dostępność poprawki.
Zamknięcie zadania w systemie projektowym nie oznacza, że podatność została skutecznie usunięta. Potrzebny jest retest albo inna forma potwierdzenia.
Nie każda podatność wymaga publicznego komunikatu, ale brak jakiejkolwiek decyzji komunikacyjnej może spowodować chaos, gdy klient zapyta o ryzyko.
Firmy objęte CRA muszą być gotowe do raportowania aktywnie wykorzystywanych podatności i poważnych incydentów. Bez procedury i ról trudno będzie spełnić terminy.
Firma SaaS rozwija platformę dla klientów B2B. Produkt ma aplikację webową, API, moduł raportowy, kilka integracji i kilkaset zależności open source. Klient z sektora regulowanego pyta, jak firma obsługuje podatności i jak szybko potrafi odpowiedzieć na nową podatność w popularnej bibliotece.
Na początku zespół sprawdza podatności ręcznie. Część zależności jest w różnych repozytoriach, część w obrazach kontenerów, a część w narzędziach używanych podczas budowania. Nie ma jednego rejestru podatności ani jasnej decyzji, kto zatwierdza komunikację z klientem.
Firma wdraża proces zarządzania podatnościami. Tworzy rejestr produktów, generuje SBOM dla głównej aplikacji, uruchamia skanowanie zależności, przygotowuje kanał zgłaszania podatności, ustala terminy napraw i wzór komunikatu bezpieczeństwa.
Po 90 dniach firma może odpowiedzieć klientowi konkretnie: które produkty są objęte procesem, jak wykrywane są podatności, jak są oceniane, jakie są terminy napraw, jak wygląda komunikacja i jakie dowody można pokazać.
ccyber.io pomaga firmom tworzącym oprogramowanie wdrożyć praktyczny proces zarządzania podatnościami dla produktów cyfrowych, dostosowany do CRA, Secure SDLC, SBOM i wymagań klientów B2B.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest krótki assessment procesu podatności. Pozwala ustalić, gdzie firma ma największe luki, czy jest gotowa na CRA i które działania trzeba wdrożyć w pierwszych 30, 60 i 90 dniach.
To proces wykrywania, oceny, priorytetyzacji, naprawy, testowania, komunikowania i dokumentowania podatności w produkcie, jego komponentach, konfiguracji, API, chmurze i procesie wydawniczym.
Nie. Skaner pomaga wykrywać problemy, ale nie zastępuje procesu. Potrzebne są role, decyzje, priorytety, terminy, naprawy, testy, komunikacja i dowody.
Podatność to słabość, która może zostać wykorzystana. Incydent to zdarzenie, które już wpływa lub może wpływać na bezpieczeństwo produktu, danych albo funkcji.
Warto łączyć CVSS, aktywne wykorzystanie, EPSS, ekspozycję produktu, krytyczność danych, wpływ na klientów, dostępność poprawki i wymagania regulacyjne lub umowne.
Tak, szczególnie dla produktów cyfrowych. SBOM pomaga ustalić, które komponenty i wersje znajdują się w produkcie oraz czy nowa podatność dotyczy konkretnego wydania.
CRA wymaga, aby producenci produktów z elementami cyfrowymi obsługiwali podatności, dokumentowali je, wydawali aktualizacje bezpieczeństwa i zgłaszali aktywnie wykorzystywane podatności oraz poważne incydenty zgodnie z terminami.
Nie każdą. CRA koncentruje się na aktywnie wykorzystywanych podatnościach i poważnych incydentach wpływających na bezpieczeństwo produktu. Firma powinna mieć procedurę oceny, czy powstaje obowiązek zgłoszenia.
Najlepiej zacząć od rejestru produktów, rejestru podatności, kanału zgłaszania, podstawowej klasyfikacji ryzyka, skanowania zależności, SBOM dla głównego produktu i jasnych terminów napraw.
Zarządzanie podatnościami dla produktów cyfrowych to jeden z najważniejszych elementów bezpieczeństwa produktu. Nie wystarczy znaleźć podatność. Trzeba ją ocenić, naprawić, przetestować, udokumentować i w razie potrzeby zakomunikować lub zgłosić.
Dla firm tworzących oprogramowanie proces ten staje się coraz ważniejszy biznesowo i regulacyjnie. Klienci chcą dowodów, audytorzy chcą procesu, a CRA wzmacnia obowiązki producentów w zakresie podatności, aktualizacji i zgłoszeń.
Najlepsze podejście to zacząć prosto: rejestr produktów, SBOM, rejestr podatności, właściciele, priorytety, terminy, testy i procedura komunikacji. Dopiero potem warto automatyzować, skalować i integrować proces z całym Secure SDLC.
Zestawienie Materiałów Oprogramowania (SBOM): co firmy zajmujące się oprogramowaniem muszą przygotować pod CRA?
SBOM, czyli zestawienie materiałów oprogramowania, pomaga firmie pokazać, z jakich komponentów, bibliotek i zależności składa się produkt cyfrowy. Pod Cyber Resilience Act firmy tworzące oprogramowanie powinny przygotować proces generowania SBOM, kontrolę zależności, zarządzanie podatnościami, dokumentację techniczną i sposób udostępniania informacji na potrzeby klientów, audytów i organów nadzoru.
Opracowanie: Zespół redakcyjny CCyber
SBOM, czyli Software Bill of Materials, można po polsku opisać jako zestawienie materiałów oprogramowania albo spis komponentów oprogramowania. To formalny, uporządkowany zapis komponentów, bibliotek, zależności i relacji, z których składa się produkt cyfrowy. Pod Cyber Resilience Act firmy tworzące oprogramowanie powinny przygotować proces generowania SBOM w formacie maszynowo czytelnym, powiązać go z zarządzaniem podatnościami, dokumentacją techniczną, aktualizacjami bezpieczeństwa i dowodami zgodności.
Lipiec 2026
SBOM to uporządkowany zapis komponentów użytych w oprogramowaniu. Można go porównać do listy składników produktu. W produkcji fizycznej firma wie, z jakich części składa się urządzenie. W oprogramowaniu podobną rolę pełni SBOM.
SBOM powinien pomóc odpowiedzieć na pytania:
Najważniejsza rzecz: SBOM nie jest celem samym w sobie. Jest narzędziem do uzyskania widoczności w łańcuchu dostaw oprogramowania, zarządzania podatnościami, odpowiadania klientom i przygotowania dowodów zgodności.
Cyber Resilience Act wprowadza wymagania dotyczące cyberbezpieczeństwa produktów z elementami cyfrowymi. Dotyczy to między innymi produktów sprzętowych i programowych wprowadzanych na rynek UE.
CRA wymaga, aby producenci identyfikowali i dokumentowali podatności oraz komponenty zawarte w produktach z elementami cyfrowymi. Wprost wskazuje przygotowanie SBOM w powszechnie używanym i maszynowo czytelnym formacie, obejmującym co najmniej zależności najwyższego poziomu produktu.
W praktyce oznacza to, że firma tworząca produkt cyfrowy powinna wiedzieć, z czego produkt się składa. Jeżeli pojawi się nowa podatność w popularnej bibliotece, firma musi szybko ustalić:
Bez SBOM odpowiedź na te pytania często wymaga ręcznego przeszukiwania repozytoriów, pipeline’ów, obrazów kontenerów, dokumentacji i zgadywania, które komponenty faktycznie trafiły do wydania.
CRA wskazuje, że producenci mają identyfikować i dokumentować podatności oraz komponenty zawarte w produktach z elementami cyfrowymi, w tym przez przygotowanie SBOM. Taki SBOM powinien być w powszechnie używanym i maszynowo czytelnym formacie oraz obejmować co najmniej zależności najwyższego poziomu produktu.
W praktyce firmy powinny potraktować SBOM jako jeden z kluczowych elementów przygotowania do CRA, obok:
Ważne: SBOM nie musi automatycznie oznaczać publicznego ujawnienia pełnej listy komponentów każdemu użytkownikowi. CRA przewiduje, że dokumentacja techniczna, w tym SBOM, może być wymagana przez organy nadzoru rynku. Jeżeli producent zdecyduje się udostępniać SBOM użytkownikom, powinien wskazać, gdzie można go uzyskać.
Minimalny zakres SBOM zależy od standardu, narzędzia i celu użycia. Dla firm przygotowujących się do CRA ważne jest, aby SBOM był praktyczny, aktualny, maszynowo czytelny i powiązany z konkretną wersją produktu.
Zależności najwyższego poziomu to komponenty, które produkt wykorzystuje bezpośrednio. Przykład: aplikacja korzysta bezpośrednio z konkretnej biblioteki do uwierzytelniania, obsługi plików, logowania albo komunikacji z bazą danych.
Zależności pośrednie to komponenty używane przez inne komponenty. Przykład: Twoja aplikacja używa biblioteki A, a biblioteka A używa biblioteki B. Biblioteka B jest zależnością pośrednią.
CRA wskazuje co najmniej zależności najwyższego poziomu. Jednak z perspektywy realnego zarządzania podatnościami warto dążyć do widoczności również zależności pośrednich. Wiele poważnych podatności pojawia się właśnie w bibliotekach, które nie były dodane ręcznie przez zespół, lecz trafiły do produktu przez inne pakiety.
Praktyczna rekomendacja dla firm tworzących oprogramowanie:
SPDX to otwarty standard rozwijany przez Linux Foundation. Jest używany do opisu komponentów oprogramowania, licencji, zależności i informacji o łańcuchu dostaw. Specyfikacja SPDX jest dostępna jako międzynarodowy standard ISO/IEC 5962:2021.
SPDX dobrze sprawdza się tam, gdzie ważna jest zgodność licencyjna, wymiana informacji z klientami i interoperacyjność między narzędziami.
CycloneDX to standard OWASP dla zestawień materiałów, zaprojektowany z myślą o cyberbezpieczeństwie łańcucha dostaw. Obsługuje między innymi SBOM, zestawienia dla usług SaaS, kryptografii, sprzętu i AI.
CycloneDX jest często wykorzystywany w zespołach DevSecOps, przy automatycznym generowaniu SBOM, analizie podatności i integracji z narzędziami bezpieczeństwa.
Nie ma jednej odpowiedzi dla każdej firmy. Ważniejsze od samego formatu jest to, czy SBOM jest aktualny, maszynowo czytelny, powtarzalnie generowany, powiązany z wersją produktu i używany w procesie zarządzania podatnościami.
W praktyce warto wybrać format wspierany przez narzędzia używane w firmie, wymagania klientów i przyszłe wymagania regulacyjne. W wielu organizacjach dobrym podejściem jest obsługa zarówno SPDX, jak i CycloneDX, jeśli narzędzia oraz proces to umożliwiają.
SBOM ma największą wartość wtedy, gdy jest używany do działania. Sam plik przechowywany w repozytorium nie zmniejsza ryzyka, jeśli nikt go nie analizuje.
Dobry proces powinien wyglądać tak:
SBOM może wskazać, że produkt zawiera komponent z podatnością. To nie zawsze oznacza, że podatność jest możliwa do wykorzystania w danym produkcie. Zespół powinien ocenić kontekst: czy podatna funkcja jest używana, czy komponent jest osiągalny, czy istnieje kontrola ograniczająca ryzyko i czy produkt jest wystawiony na internet.
Dlatego coraz częściej obok SBOM pojawia się VEX, czyli sposób przekazywania informacji, czy dana podatność faktycznie wpływa na konkretny produkt.
SBOM odpowiada na pytanie: z jakich komponentów składa się produkt?
VEX odpowiada na pytanie: czy konkretna podatność w komponencie wpływa na ten produkt w praktyce?
Przykład:
Dla firm sprzedających oprogramowanie B2B połączenie SBOM i VEX może znacząco zmniejszyć liczbę chaotycznych pytań od klientów po ujawnieniu nowej podatności w popularnej bibliotece.
SBOM nie powinien być tylko zadaniem jednego developera. To element bezpieczeństwa produktu, zarządzania podatnościami i zgodności. Właścicielem może być product security, DevSecOps, CTO, security engineer albo zespół odpowiedzialny za jakość produktu.
Dowód do przygotowania: właściciel procesu SBOM, zakres odpowiedzialności i osoby wspierające.
Na początku nie trzeba obejmować wszystkiego. Najlepiej zacząć od produktów najważniejszych biznesowo, objętych CRA, sprzedawanych klientom B2B albo zawierających dane wrażliwe.
Priorytet:
Dowód do przygotowania: lista produktów i wersji objętych procesem SBOM.
Wybierz format, który będzie wspierany przez narzędzia zespołu i wymagania klientów. Najczęściej warto rozważyć SPDX lub CycloneDX.
Przy wyborze narzędzia sprawdź:
Dowód do przygotowania: decyzja o formacie, narzędziu i zakresie generowania SBOM.
Ręczne tworzenie SBOM szybko przestaje działać. Produkt zmienia się z każdym wydaniem, a zależności aktualizują się często. SBOM powinien być generowany automatycznie w procesie budowania lub wydania produktu.
Automatyzacja powinna obejmować:
Dowód do przygotowania: konfiguracja automatycznego generowania SBOM i przykładowy plik dla wydania produktu.
SBOM bez powiązania z wersją produktu ma ograniczoną wartość. Gdy klient zapyta o podatność w konkretnej wersji, firma musi wiedzieć, jaki SBOM dotyczy tej wersji.
Powiąż SBOM z:
Dowód do przygotowania: rejestr wydań produktu z przypisanym SBOM.
Po wygenerowaniu SBOM należy go używać do oceny podatności. Sam SBOM nie wystarczy. Potrzebna jest analiza komponentów względem źródeł informacji o podatnościach.
Proces powinien obejmować:
Dowód do przygotowania: raport podatności, decyzje triage, zadania naprawcze i potwierdzenie napraw.
SBOM może być niekompletny, błędny lub niespójny. Narzędzia nie zawsze wykrywają wszystkie komponenty tak samo. Dlatego potrzebny jest przegląd jakości.
Sprawdź:
Dowód do przygotowania: checklista jakości SBOM i wynik walidacji.
SBOM może zawierać informacje wrażliwe biznesowo lub technicznie. Firma powinna ustalić, komu, kiedy i w jakim zakresie udostępnia SBOM.
Możliwe modele:
Dowód do przygotowania: polityka udostępniania SBOM, ścieżka zatwierdzania i wzór odpowiedzi do klienta.
SBOM musi zmieniać się razem z produktem. Jeżeli produkt ma nowe wydanie, nowe zależności albo nowy obraz kontenera, SBOM również powinien zostać zaktualizowany.
Jeżeli nie wiadomo, który SBOM dotyczy której wersji produktu, trudno odpowiedzieć na pytanie klienta lub organu nadzoru. SBOM musi być związany z konkretnym wydaniem.
Samo wygenerowanie pliku nie zmniejsza ryzyka. SBOM powinien zasilać proces oceny podatności i aktualizacji.
Narzędzia mogą tworzyć różne wyniki. SBOM powinien być walidowany i sprawdzany pod kątem kompletności, poprawności oraz przydatności.
SBOM może ujawniać informacje o architekturze, zależnościach i potencjalnych słabościach produktu. Firma powinna ustalić, komu i w jakim zakresie udostępnia takie informacje.
Jeżeli nikt nie odpowiada za SBOM, proces szybko się rozpadnie. Potrzebny jest właściciel po stronie product security, DevSecOps, engineeringu albo bezpieczeństwa.
W produktach B2B część komponentów może pochodzić od klienta, integratora lub dostawcy. Warto ustalić, kto odpowiada za ich opis, podatności i aktualizacje.
SBOM powinien być powiązany z dokumentacją techniczną produktu. Pod CRA dokumentacja techniczna powinna pokazywać, jak produkt został zaprojektowany, wytworzony i utrzymywany pod kątem cyberbezpieczeństwa oraz jak producent obsługuje podatności.
W dokumentacji warto połączyć SBOM z:
Dobry SBOM pomaga również przy komunikacji z klientami. Kiedy pojawia się nowa podatność, firma nie musi odpowiadać ogólnie. Może sprawdzić wpływ na konkretne produkty i wersje.
Firma ma pierwszą listę komponentów, ale proces jest ręczny, nieregularny i niepowiązany z wydaniami produktu.
Firma używa narzędzia do generowania SBOM dla wybranego produktu, ale nie zawsze robi to przy każdym wydaniu.
SBOM jest generowany automatycznie przy wydaniu, powiązany z wersją produktu i przechowywany jako dowód.
SBOM zasila proces zarządzania podatnościami. Zespół może szybko odpowiedzieć, czy nowa podatność dotyczy produktu.
SBOM jest częścią dokumentacji technicznej, procesów CRA, odpowiedzi do klientów, audytów i zarządzania ryzykiem łańcucha dostaw.
Firma SaaS rozwija platformę dla klientów B2B. Produkt korzysta z kilkuset komponentów open source, kilku obrazów kontenerów, aplikacji webowej, API i modułu raportowego. Klient z sektora regulowanego pyta, czy firma jest w stanie wskazać, które wersje komponentów znajdują się w produkcie i czy podatność w popularnej bibliotece dotyczy jego środowiska.
Zespół początkowo sprawdza zależności ręcznie. Okazuje się, że różne repozytoria mają różne wersje bibliotek, kontenery zawierają dodatkowe pakiety, a dokumentacja nie pokazuje, które komponenty trafiły do konkretnego wydania.
Firma wdraża proces SBOM. Najpierw generuje SBOM dla głównej aplikacji i obrazów kontenerów. Następnie wiąże SBOM z wersją produktu, dodaje skanowanie podatności, przygotowuje procedurę udostępniania informacji klientom i włącza SBOM do dokumentacji technicznej produktu.
Po kilku tygodniach firma może szybciej odpowiadać na pytania klientów i lepiej zarządzać podatnościami. SBOM przestaje być dokumentem do audytu, a staje się narzędziem operacyjnym.
ccyber.io pomaga firmom tworzącym oprogramowanie przygotować proces SBOM w sposób praktyczny, dopasowany do CRA, zarządzania podatnościami i rzeczywistego procesu wytwarzania produktu.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest krótki SBOM readiness assessment. Pozwala ustalić, które produkty wymagają SBOM, jakie narzędzia są dostępne, jak wygląda proces wydań i co trzeba przygotować przed terminami CRA.
SBOM to formalny zapis komponentów i relacji w łańcuchu dostaw oprogramowania. Pokazuje, z jakich bibliotek, pakietów, modułów i zależności składa się produkt cyfrowy.
CRA wskazuje, że producenci mają identyfikować i dokumentować podatności oraz komponenty w produktach z elementami cyfrowymi, w tym przez przygotowanie SBOM w powszechnie używanym i maszynowo czytelnym formacie, obejmującym co najmniej zależności najwyższego poziomu.
CRA wskazuje co najmniej zależności najwyższego poziomu. Z praktycznego punktu widzenia warto jednak dążyć do widoczności zależności pośrednich, ponieważ wiele podatności pojawia się właśnie tam.
Nie zawsze. SBOM może być dokumentem wewnętrznym albo udostępnianym klientom lub organom nadzoru w określonych warunkach. Firma powinna ustalić zasady udostępniania, ponieważ SBOM może zawierać informacje wrażliwe.
Najczęściej warto rozważyć SPDX lub CycloneDX. Wybór powinien zależeć od narzędzi, wymagań klientów, procesu CI/CD, potrzeb analizy podatności i przyszłych wymagań regulacyjnych.
Nie. SBOM pokazuje komponenty i zależności, ale nie zastępuje testów aplikacji, przeglądów kodu, testów API, modelowania zagrożeń ani oceny architektury.
SBOM pokazuje, co znajduje się w produkcie. VEX pomaga przekazać, czy konkretna podatność faktycznie wpływa na dany produkt i jego sposób użycia.
Najlepiej zacząć od jednego produktu pilotażowego: wybrać format, wygenerować pierwszy SBOM, powiązać go z wersją produktu, sprawdzić podatności i przygotować procedurę aktualizacji oraz udostępniania.
SBOM staje się jednym z kluczowych elementów bezpieczeństwa produktów cyfrowych. Pod CRA nie wystarczy wiedzieć, że produkt „używa bibliotek open source”. Firma musi umieć pokazać, jakie komponenty znajdują się w produkcie, jak są dokumentowane, jak są monitorowane i jak wpływają na zarządzanie podatnościami.
Najlepsze podejście to traktowanie SBOM jako procesu, nie jako jednorazowego pliku. SBOM powinien być generowany automatycznie, powiązany z wersją produktu, analizowany pod kątem podatności i przechowywany jako element dokumentacji technicznej.
Firmy, które przygotują proces SBOM wcześniej, będą lepiej gotowe na CRA, wymagania klientów, audyty, incydenty związane z podatnościami i rosnące oczekiwania dotyczące przejrzystości łańcucha dostaw oprogramowania.
Piszemy o regulacjach takich jak NIS2, DORA, CRA i ISO 27001, o bezpieczeństwie MŚP i infrastruktury krytycznej, a także o cyberhigienie, cyberzagrożeniach i budowaniu świadomości bezpieczeństwa w organizacji.
Każdy artykuł to praktyczna wiedza - bez żargonu i z konkretnymi wskazówkami do wdrożenia, które pomagają firmom skutecznie chronić dane, ludzi i ciągłość działania.