SBOM-y jako dowód zapewnienia zgodności z ISO 27001, NIS2 i DORA

Jest piątek, 07:42, gdy Amelia, dyrektorka ds. bezpieczeństwa informacji w szybko rozwijającej się spółce FinTech, otrzymuje alert, którego nie chce zobaczyć żaden lider bezpieczeństwa.

Szeroko używany pakiet open source ma krytyczną podatność umożliwiającą zdalne wykonanie kodu. Narzędzie do analizy składu oprogramowania wskazuje, że komponent może występować w usłudze uwierzytelniania, potencjalnie w rozliczeniach, a być może także w adapterze API dostawcy zewnętrznego używanym w procesie płatności. Zespół inżynieryjny potrzebuje czasu na potwierdzenie. Dział prawny pyta, czy rozpoczął się termin zgłoszenia w NIS2. Menedżer programu DORA pyta, czy usługa, której może dotyczyć podatność, wspiera krytyczną lub istotną funkcję podmiotu finansowego. Sprzedaż pyta, czy zablokuje to odnowienie umowy. Zarząd zadaje najprostsze i najtrudniejsze pytanie: „Czy jesteśmy narażeni?”

Bez wykazu składników oprogramowania uczciwa odpowiedź często brzmi: „Jeszcze nie wiemy”.

W 2026 r. taka odpowiedź nie jest już wyłącznie luką techniczną. To słabość ładu zarządczego, ryzyko umowne, ekspozycja audytowa oraz — dla podmiotów regulowanych — problem odporności. SBOM-y przeszły drogę od praktyki higieny DevSecOps do dowodu na poziomie zarządu w zakresie zapewnienia łańcucha dostaw oprogramowania, skuteczności zabezpieczeń ISO/IEC 27001:2022, zarządzania ryzykiem cyberbezpieczeństwa w NIS2, nadzoru DORA nad zewnętrznymi dostawcami usług ICT, rozliczalności GDPR oraz due diligence klientów.

Kluczowe nie jest samo wygenerowanie pliku SBOM. Kluczowe jest wykazanie, że komponenty oprogramowania są identyfikowane, zatwierdzane, monitorowane, oceniane pod kątem ryzyka, aktualizowane poprawkami, objęte umowami oraz identyfikowalne do odpowiedzialnych właścicieli. Właśnie w tym miejscu biblioteka polityk Clarysec, Zenith Blueprint: An Auditor’s 30-Step Roadmap oraz Zenith Controls: The Cross-Compliance Guide przekształcają artefakt programistyczny w możliwe do obrony dowody zgodności.

Dlaczego SBOM-y są obecnie dowodem zapewnienia łańcucha dostaw oprogramowania

SBOM to inwentarz komponentów oprogramowania, obejmujący pakiety open source, biblioteki komercyjne, wersje, źródła, licencje oraz relacje zależności. Przydatny SBOM pomaga odpowiedzieć na cztery pytania, które dziś interesują organy regulacyjne, klientów i zarządy:

1. Co znajduje się w naszym oprogramowaniu?
2. Gdzie zostało wdrożone?
3. Czy jest podatne, niewspierane, nielicencjonowane lub niezatwierdzone?
4. Kto odpowiada za działania naprawcze, środki łagodzące albo akceptację ryzyka?

Te pytania bezpośrednio odpowiadają współczesnym oczekiwaniom prawnym i regulacyjnym.

NIS2 ma zastosowanie do wielu średnich i dużych podmiotów w sektorach kluczowych i ważnych, w tym infrastruktury cyfrowej, dostawców usług chmury obliczeniowej, dostawców usług centrów danych, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa, internetowych platform handlowych, wyszukiwarek, platform społecznościowych oraz określonych dostawców cyfrowych. Może mieć również zastosowanie na podstawie krajowego wskazania oraz transpozycji sektorowej. W przypadku podmiotów objętych zakresem NIS2 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa i nadzorowały ich wdrożenie. Article 21 obejmuje bezpieczeństwo łańcucha dostaw, bezpieczne pozyskiwanie, bezpieczne wytwarzanie i utrzymanie oprogramowania, obsługę i ujawnianie podatności, obsługę incydentów, ciągłość działania, zarządzanie aktywami, kontrolę dostępu, kryptografię, ocenę skuteczności oraz cyberhigienę.

DORA, stosowane od 17 stycznia 2025 r., tworzy jednolite unijne ramy cyfrowej odporności operacyjnej dla podmiotów finansowych. Obejmuje zarządzanie ryzykiem ICT, zgłaszanie incydentów związanych z ICT, testowanie odporności, zarządzanie ryzykiem zewnętrznych dostawców usług ICT, uzgodnienia umowne oraz nadzór nad krytycznymi zewnętrznymi dostawcami usług ICT. DORA wymaga, aby podmioty finansowe identyfikowały aktywa ICT, funkcje biznesowe wspierane przez ICT, zależności, połączenia, podatności, scenariusze ryzyka, zmiany oraz procesy wspierane przez strony trzecie.

GDPR dodaje warstwę prywatności. Jeżeli podatny komponent wpływa na systemy przetwarzające dane osobowe, pytanie brzmi, czy mogło dojść do uzyskania dostępu do danych osobowych, ich zmiany, utraty, ujawnienia albo innego naruszenia. Administratorzy i podmioty przetwarzające potrzebują dowodów pokazujących, że potrafią zidentyfikować systemy, przepływy danych, podwykonawców przetwarzania oraz skutki naruszenia.

NIST CSF 2.0 wzmacnia ten sam model operacyjny poprzez GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER. Wyniki dotyczące łańcucha dostaw wymagają odpowiedzialności dostawców, określenia krytyczności, wymogów umownych, due diligence, monitorowania, planowania incydentów oraz postanowień dotyczących zakończenia relacji.

Gdy zarząd Amelii pyta, czy FinTech jest narażony, organizacja wspierana przez SBOM może odpowiedzieć dowodami:

• Które produkty i wydania zawierają podatny komponent
• Które wdrożone środowiska są dotknięte
• Którzy klienci, regiony, funkcje i przepływy danych są powiązane
• Który dostawca lub właściciel wewnętrzny ponosi odpowiedzialność
• Które środki kompensujące są aktywne
• Czy mogą zostać uruchomione progi NIS2, DORA, GDPR albo umowne
• Która poprawka, środek łagodzący, wyjątek albo akceptacja ryzyka zostały zatwierdzone

To różnica między listą komponentów a systemem kontroli.

ISO 27001:2022 jako podstawa nadzoru nad SBOM

ISO/IEC 27001:2022 jest mocną podstawą nadzoru nad SBOM, ponieważ jest normą systemu zarządzania, a nie tylko techniczną listą kontrolną. Jej klauzule wymagają, aby organizacje definiowały kontekst, strony zainteresowane, zakres, zaangażowanie kierownictwa, politykę, role, ocenę ryzyka, postępowanie z ryzykiem, cele, ocenę wyników, audyt wewnętrzny, przegląd zarządzania i ciągłe doskonalenie.

Programy SBOM zawodzą, gdy funkcjonują poza SZBI. Zespół inżynieryjny może generować pliki, ale nikt nie egzekwuje SLA dla działań naprawczych wobec podatności, zobowiązań dostawców, przechowywania dowodów, akceptacji ryzyka ani zasad ujawniania informacji klientom. ISO 27001 rozwiązuje ten problem, włączając SBOM-y do systemu zarządzania ryzykiem organizacji.

Zgodnie z Klauzulami 4.1–4.4 organizacja określa kwestie wewnętrzne i zewnętrzne, wymagania stron zainteresowanych, obowiązki prawne i regulacyjne, oczekiwania umowne oraz zakres SZBI. Dla zapewnienia SBOM zakres powinien wyraźnie obejmować:

• Produkty i usługi dostarczane klientom
• Środowiska produkcyjne chmury obliczeniowej i SaaS
• Potoki CI/CD, repozytoria kodu źródłowego i rejestry artefaktów
• Komponenty oprogramowania open source i komercyjnego
• Partnerów w zakresie rozwoju realizowanego w modelu outsourcingowym i integracji
• Zewnętrznych dostawców ICT i podwykonawców
• Wymagania bezpieczeństwa klientów wynikające z DORA, NIS2, GDPR i umów

Klauzule 5.1–5.3 czynią ryzyko łańcucha dostaw oprogramowania zagadnieniem dla kierownictwa. Kierownictwo musi powiązać cele bezpieczeństwa z kierunkiem biznesowym, zapewnić zasoby, przypisać odpowiedzialności i komunikować politykę. Klauzule 6.1.2 i 6.1.3 przekształcają ustalenia z SBOM w dowody oceny ryzyka i postępowania z ryzykiem. Krytyczny podatny komponent w dostępnej z Internetu usłudze uwierzytelniania nie jest tylko zgłoszeniem. To scenariusz ryzyka wpływający na poufność, integralność, dostępność, zobowiązania umowne, raportowanie regulacyjne i odporność operacyjną.

Najbardziej istotne zabezpieczenia ISO/IEC 27001:2022 z Załącznika A dla zapewnienia SBOM to:

Clarysec mapuje te relacje poprzez atrybuty ISO/IEC 27002:2022 w Zenith Controls. Na przykład Zenith Controls traktuje zabezpieczenie ISO/IEC 27002:2022 5.21, „Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT”, jako zapobiegawcze, chroniące poufność, integralność i dostępność, dostosowane do koncepcji cyberbezpieczeństwa Identify oraz działające w obszarach ładu zarządczego, ekosystemu i ochrony. Zabezpieczenie 8.25, „cykl życia rozwoju oprogramowania”, traktuje jako zapobiegawcze i dostosowane do Protect. Zabezpieczenie 8.8, „Zarządzanie podatnościami technicznymi”, traktuje jako zapobiegawcze i dostosowane do Identify i Protect, łącząc zarządzanie podatnościami z ładem zarządczym, ekosystemem, ochroną i obroną.

To przełożenie ma znaczenie, ponieważ różni recenzenci zadają różne pytania. Audytor ISO może zapytać, czy ryzyko komponentów jest ujęte w Deklaracji stosowania. Recenzent DORA może zapytać, czy komponent wspiera krytyczną lub istotną funkcję. Klient może zapytać, czy nierozwiązane podatności przekraczają umowne SLA. Te same dowody SBOM mogą wspierać wszystkie trzy potrzeby, jeżeli są prawidłowo zarządzane.

Warstwa polityk Clarysec dla gotowych do audytu SBOM-ów

Wiarygodny program SBOM wymaga języka polityk. Programiści muszą wiedzieć, co należy rejestrować. Zakupy muszą wiedzieć, czego należy wymagać od dostawców. Bezpieczeństwo musi wiedzieć, które ustalenia uruchamiają eskalację. Funkcja zgodności musi wiedzieć, które dowody należy przechowywać.

Dla mniejszych organizacji Polityka bezpiecznego rozwoju oprogramowania - MŚP ustanawia minimalnie wystarczający mechanizm kontroli SBOM:

GM lub wyznaczony programista musi prowadzić listę wszystkich używanych komponentów zewnętrznych, obejmującą: 6.6.2.1 Wersję i źródło 6.6.2.2 Znane podatności lub status poprawki 6.6.2.3 Datę ostatniej aktualizacji lub przeglądu

To wymaganie jest proste, ale skuteczne. Ustanawia widoczność wersji, identyfikowalność źródła, status podatności oraz rytm przeglądu.

Polityka wymagań bezpieczeństwa aplikacji - MŚP dodaje przegląd cyklu życia:

Każde narzędzie strony trzeciej, wtyczka lub zewnętrzna biblioteka kodu używana w aplikacji musi zostać zarejestrowana i co roku poddana przeglądowi pod kątem wpływu na bezpieczeństwo oraz statusu poprawek.

Polityka zarządzania podatnościami i poprawkami - MŚP łączy SBOM-y z działaniami naprawczymi:

Programiści muszą monitorować i aktualizować biblioteki stron trzecich (np. pakiety open source)

W środowiskach korporacyjnych Polityka bezpiecznego rozwoju oprogramowania podnosi oczekiwania:

Użycie kodu open source lub kodu stron trzecich musi być zatwierdzane, ewidencjonowane i walidowane poprzez:

Wprowadza również obowiązkowe skanowanie:

Wszystkie komponenty stron trzecich muszą być skanowane pod kątem podatności przed wdrożeniem oraz w czasie działania przy użyciu zautomatyzowanych narzędzi.

Rozwój realizowany w modelu outsourcingowym musi spełniać ten sam standard. Polityka rozwoju oprogramowania w modelu outsourcingowym wymaga:

Bezpiecznego korzystania z bibliotek open source, podlegającego skanowaniu podatności i zatwierdzeniu

Umowy z dostawcami wymagają egzekwowalnych praw do dowodów. Polityka bezpieczeństwa dostawców i stron trzecich - MŚP wymaga klauzul umownych obejmujących poufność, obowiązki bezpieczeństwa, terminy zgłoszenia naruszenia, prawa do audytu, ograniczenia podwykonawstwa i bezpieczne zakończenie współpracy:

Umowy muszą zawierać obowiązkowe klauzule obejmujące: 5.3.1 Poufność i nieujawnianie 5.3.2 Obowiązki w zakresie bezpieczeństwa informacji 5.3.3 Terminy zgłoszenia naruszenia ochrony danych (np. w ciągu 24–72 godzin) 5.3.4 Prawa do audytu lub dostępność dowodów zgodności 5.3.5 Ograniczenia dalszego podwykonawstwa bez zatwierdzenia 5.3.6 Warunki zakończenia współpracy, w tym bezpieczny zwrot lub zniszczenie danych

Dla klientów korporacyjnych Polityka bezpieczeństwa dostawców i stron trzecich obejmuje:

Prawo do audytu, kontroli i żądania dowodów bezpieczeństwa

Jeżeli dostawca SaaS, partner rozwoju realizowanego w modelu outsourcingowym albo dostawca oprogramowania komercyjnego nie zapewnia dowodów bezpieczeństwa, statusu podatności, zobowiązań dotyczących powiadamiania ani dostępu audytowego, zapewnienie łańcucha dostaw oprogramowania ma martwy punkt.

Polityka zarządzania ryzykiem zależności od dostawców przekształca koncentrację zależności w mierzalne ryzyko odporności:

Rejestr zależności od dostawców: VMO prowadzi aktualny rejestr wszystkich dostawców krytycznych, obejmujący takie szczegóły jak świadczone usługi / dostarczane produkty; informację, czy dostawca jest jedynym źródłem; dostępne alternatywne źródła dostaw lub możliwość zastąpienia; aktualne warunki umowy; oraz ocenę wpływu w przypadku awarii dostawcy lub naruszenia jego bezpieczeństwa. Rejestr jasno identyfikuje dostawców o wysokim poziomie zależności (np. takich, dla których nie istnieje szybka alternatywa).

Ten rejestr powinien być powiązany z SBOM-ami. Jeżeli krytyczna biblioteka pochodzi od dostawcy będącego jedynym źródłem, wspiera regulowany proces klienta i nie ma szybkiego zamiennika, nie jest tylko pakietem. Jest zależnością wpływającą na odporność.

Od pliku SBOM do operacyjnego mechanizmu kontrolnego w jednym sprincie

Praktyczny program SBOM powinien zacząć się od jednej linii produktowej i jednego środowiska produkcyjnego. Nie należy próbować zinwentaryzować całego przedsiębiorstwa pierwszego dnia. Jeżeli FinTech Amelii zacznie od onboardingu klientów i procesu płatności, zespół może stworzyć powtarzalny model dowodowy przed skalowaniem.

Krok 1: Zdefiniuj zakres SBOM w SZBI

Utwórz deklarację zakresu powiązaną z zakresem SZBI oraz czynnikami regulacyjnymi:

• Produkt: platforma SaaS do onboardingu klientów i płatności
• Środowisko: produkcja UE
• Repozytoria: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Systemy budowania: dostawca Git, platforma CI/CD, rejestr kontenerów
• Wdrożenie: klaster Kubernetes, zarządzana baza danych, obiektowa pamięć masowa
• Dane: dane kont, logi uwierzytelniania, metadane rozliczeń, referencje płatności
• Klienci: unijne podmioty finansowe i klienci komercyjni
• Czynniki regulacyjne: ISO 27001:2022, zapewnienie klientów w zakresie NIS2, due diligence zewnętrznych dostawców usług ICT według DORA, rozliczalność bezpieczeństwa w GDPR

Jest to zgodne z logiką zakresu z Klauzuli 4 ISO 27001 oraz zakresem profilu NIST CSF.

Krok 2: Generuj i przechowuj SBOM-y podczas budowania

Skonfiguruj potoki CI/CD tak, aby generowały SBOM dla każdego artefaktu budowania, w tym obrazów kontenerów. Powszechnie stosuje się standardowe formaty, takie jak CycloneDX i SPDX. Każdy SBOM należy przechowywać w kontrolowanym repozytorium materiału dowodowego powiązanym z identyfikatorem kompilacji, hashem commita, zapisem wdrożenia i wersją wydania.

Bezpośrednio wspiera to wymaganie Polityki bezpiecznego rozwoju oprogramowania - MŚP dotyczące utrzymywania wersji, źródła, znanej podatności lub statusu poprawki oraz daty przeglądu.

Krok 3: Wzbogać dane SBOM o wykorzystywalność i kontekst biznesowy

Nie należy kończyć na liście pakietów. Należy dodać kontekst ryzyka operacyjnego:

• Czy komponent jest podatny?
• Czy podatna funkcja jest osiągalna?
• Czy usługa jest dostępna z Internetu?
• Czy usługa przetwarza dane osobowe?
• Czy wspiera krytyczną lub istotną funkcję klienta DORA?
• Czy dostępna jest poprawka?
• Czy istnieje środek kompensujący?
• Czy akceptacja ryzyka została zatwierdzona przez właściciela ryzyka?

Krytyczne CVE w pakiecie używanym wyłącznie w testach różni się od krytycznego CVE w produkcyjnej usłudze uwierzytelniania. Klauzule ISO 27001 dotyczące oceny ryzyka i postępowania z ryzykiem pomagają uzasadnić to rozróżnienie.

Krok 4: Powiąż SBOM-y z kontrolami dostawców i rozwoju realizowanego w modelu outsourcingowym

Jeżeli komponent jest dostarczany przez dostawcę komercyjnego lub partnera rozwoju realizowanego w modelu outsourcingowym, zaktualizuj zapis dostawcy:

Wspiera to bezpieczeństwo łańcucha dostaw według NIS2 Article 21 oraz oczekiwania DORA Article 28 dotyczące strategii zarządzania ryzykiem zewnętrznych dostawców usług ICT, due diligence, zabezpieczeń umownych, rejestrów informacji, planowania audytu, praw do wypowiedzenia oraz strategii wyjścia.

Krok 5: Zdefiniuj zasady działań naprawczych i dowody

Powiąż SLA działań naprawczych z wpływem biznesowym, a nie tylko z punktacją CVSS.

W tym miejscu SBOM-y stają się użyteczne dla NIS2, DORA i GDPR. Przepływ działań naprawczych powinien uwzględniać potencjał istotnego incydentu, wpływ poważnego incydentu związanego z ICT, kryteria naruszenia ochrony danych osobowych, umowne obowiązki powiadomienia oraz wpływ na odporność operacyjną.

Krok 6: Dodaj bramkę wydania

Przed wdrożeniem wymagaj, aby potok lub proces zmiany potwierdził:

• SBOM został wygenerowany pomyślnie
• Nie pozostają żadne krytyczne, niezatwierdzone podatności
• Nowe komponenty stron trzecich zostały zatwierdzone
• Polityka licencyjna została spełniona
• SCA, SAST, DAST lub inne wymagane testowanie zostało zakończone
• Zgłoszenie zmiany jest powiązane
• Plan wycofania zmian jest udokumentowany dla wydań wysokiego ryzyka

Łączy to A.8.25 bezpieczny rozwój oprogramowania, A.8.29 testy bezpieczeństwa i A.8.32 zarządzanie zmianami w jeden przepływ pracy możliwy do prześledzenia audytowo.

Krok 7: Zbuduj pakiet dowodowy wydania

Dla każdego wydania przechowuj:

• Plik SBOM
• Identyfikator kompilacji i hash commita
• Wynik skanowania SCA
• Zapis triage podatności
• Zatwierdzone wyjątki
• Zatwierdzenie zmiany
• Zapis wdrożenia
• Wyniki testów
• Dowody dostawcy, jeżeli mają zastosowanie
• Zapis incydentu lub problemu, jeżeli wydanie usuwało podatność

Gdy audytor pyta, jak biblioteki stron trzecich są zarządzane w środowisku produkcyjnym, zespół Amelii nie przeszukuje w pośpiechu wątków na Slacku. Otwiera pakiet dowodowy wydania.

Mapowanie zgodności między ramami: jeden program SBOM, wiele obowiązków

Wartość biznesowa programu SBOM rośnie, gdy zostanie zmapowany raz i ponownie wykorzystany w różnych frameworkach. Podejście Clarysec do zgodności między ramami eliminuje duplikację pracy, przekładając te same dowody na różne języki zapewnienia.

Zgłaszanie incydentów w NIS2 może przebiegać szybko, gdy wykorzystanie podatności powoduje lub może spowodować poważne zakłócenie operacyjne, stratę finansową albo znaczną szkodę materialną lub niematerialną. NIS2 stosuje etapowe raportowanie, obejmujące wczesne ostrzeżenie w ciągu 24 godzin od uzyskania świadomości, zgłoszenie incydentu w ciągu 72 godzin oraz raport końcowy w ciągu miesiąca od zgłoszenia incydentu. SBOM-y pomagają ustalić, czy komponent, którego dotyczy podatność, jest obecny, czy dotknięte są usługi klientów i czy prawdopodobny jest wpływ transgraniczny.

DORA stosuje ustrukturyzowany cykl życia incydentu ICT, obejmujący wykrycie, rejestrację, klasyfikację, analizę przyczyny źródłowej, eskalację, plany komunikacji, eskalację do organu zarządzającego oraz raportowanie regulacyjne poważnych incydentów związanych z ICT. Dowody SBOM wspierają klasyfikację, ponieważ łączą podatny komponent z dotkniętymi klientami, czasem niedostępności, zasięgiem geograficznym, utratą danych, krytycznością usługi oraz wpływem ekonomicznym.

NIST CSF 2.0 dodaje użyteczny język dla zapewnienia klienta. Zenith Controls mapuje A.5.21 do wyników ładu zarządczego łańcucha dostaw, takich jak GV.SC-05, gdzie wymagania cyberbezpieczeństwa dla dostawców są ustanawiane, komunikowane i włączane do umów oraz innych uzgodnień. Wymaganie SBOM-ów, ujawniania podatności, dowodów audytowych i terminów działań naprawczych staje się kontrolą umowną, a nie wnioskiem ad hoc.

Jak Zenith Blueprint sekwencjonuje prace

Zenith Blueprint przekształca język zabezpieczeń w mapę drogową wdrożenia.

W fazie zarządzania ryzykiem Krok 14 łączy bezpieczny rozwój oprogramowania, kontrole CI/CD, skanowanie zależności, zarządzanie zmianami, obsługę incydentów i szkolenie programistów. W fazie zabezpieczeń w działaniu Krok 20 wprost odnosi się do komponentów stron trzecich i open source:

Ten środek kontrolny ma zastosowanie także do komponentów stron trzecich i open source. Korzystanie z zewnętrznych bibliotek jest standardową praktyką, ale każde włączenie jest decyzją opartą na zaufaniu. Programiści powinni oceniać zależności na podstawie reputacji, częstotliwości utrzymania, znanych podatności oraz ograniczeń licencyjnych. Narzędzia takie jak SBOM-y (wykazy składników oprogramowania) są coraz bardziej istotne do śledzenia tego, co jest osadzone w stosie technologicznym.

Krok 21 ujmuje testy bezpieczeństwa jako zależne od kontekstu i rekomenduje testowanie warstwowe dla systemów krytycznych biznesowo lub wystawionych do Internetu, w tym analizę składu oprogramowania dla bibliotek stron trzecich, analizę statyczną i dynamiczną, testy penetracyjne, walidację modelowania zagrożeń, testowanie scenariuszy nadużyć, fuzzing oraz ręczne testowanie eksploracyjne.

Krok 23 dotyczy umów z dostawcami, w tym obowiązków dotyczących poufności, odpowiedzialności za kontrolę dostępu, środków technicznych i organizacyjnych, terminów zgłaszania incydentów, prawa do audytu, kontroli podwykonawców oraz postanowień końcowych umowy.

Praktyczna lekcja jest prosta. SBOM-y należą do zarządzania ryzykiem, bezpiecznego rozwoju oprogramowania, testowania, nadzoru nad dostawcami, reagowania na incydenty oraz raportowania zarządczego.

Perspektywa audytu: co będą sprawdzać różni recenzenci

Dojrzały program SBOM musi wytrzymać różne style audytu.

Audytor ISO 27001:2022 zacznie od SZBI. Zapyta, czy ryzyko łańcucha dostaw oprogramowania jest objęte zakresem, czy wymagania stron zainteresowanych obejmują klientów NIS2, DORA, GDPR i umowy, czy ryzyko komponentów jest częścią metodyki ryzyka, czy Deklaracja stosowania obejmuje właściwe zabezpieczenia z Załącznika A oraz czy polityki są wdrażane w czasie. Może pobrać próbkę jednego wydania i prześledzić je od polityki do potoku, SBOM, skanu podatności, zatwierdzenia zmiany, wdrożenia i monitorowania po wydaniu.

Recenzent DORA lub klient finansowy skupi się na odporności operacyjnej i ryzyku zewnętrznych dostawców usług ICT. Może zapytać, które komponenty wspierają usługę używaną przez podmiot finansowy, czy usługa wspiera krytyczną lub istotną funkcję, jak dokumentowane są aktywa i zależności ICT, czy podatności są monitorowane, czy coroczne testowanie obejmuje systemy krytyczne oraz czy umowy zawierają wsparcie, prawa do audytu, powiadamianie o incydentach, lokalizację danych, podwykonawstwo i warunki zakończenia.

Asesor NIST CSF będzie szukał wyników. W ramach GOVERN sprawdzi ład prawny, regulacyjny, umowny, prywatnościowy i łańcucha dostaw. W ramach IDENTIFY będzie oczekiwać widoczności aktywów, oprogramowania i usług. W ramach PROTECT sprawdzi bezpieczny rozwój oprogramowania i kontrole potoków. W ramach DETECT i RESPOND zbada alerty podatności, analizę, eskalację i komunikację. W ramach RECOVER zapyta, jak naruszenie komponentu wpływa na odtworzenie i komunikację z klientami.

Audytor w stylu COBIT lub ISACA skupi się na ładzie zarządczym, rozliczalności, własności ryzyka, projekcie kontroli i wiarygodności dowodów. Może sprawdzić, czy SBOM-y są kompletne, czy zgłoszenia podatności są zamykane zgodnie z polityką, czy wyjątki wygasają, czy dowody dostawców są aktualne oraz czy kierownictwo otrzymuje wartościowe raportowanie.

Typowe błędy programów SBOM, których należy unikać

Programy SBOM zwykle zawodzą z przewidywalnych powodów.

Pierwszym błędem jest generowanie SBOM-ów bez przechowywania ich jako kontrolowanych dowodów. Jeżeli plik jest nadpisywany przy każdej kompilacji i nie można go powiązać z wydaniem, jest słabym dowodem z audytu.

Drugim błędem jest oddzielenie SBOM-ów od zarządzania podatnościami. Lista komponentów bez triage, własności, działań naprawczych lub akceptacji ryzyka nie dowodzi działania kontroli.

Trzecim błędem jest pomijanie zależności przechodnich. Podatności często ukrywają się poniżej warstwy zależności bezpośrednich.

Czwartym błędem jest pozostawienie rozwoju realizowanego w modelu outsourcingowym poza procesem. Jeżeli dostawca dostarcza kod bez ujawnienia komponentów, dowodów skanowania lub zapisów zatwierdzeń, łańcuch dostaw oprogramowania ma niezarządzany martwy punkt.

Piątym błędem jest podpisywanie umów z dostawcami bez praw do dowodów. Zakupy podpisują umowę, zespół inżynieryjny korzysta z usługi, a bezpieczeństwo później odkrywa, że nie ma prawa do audytu, obowiązku ujawniania podatności, ograniczenia podwykonawców ani wsparcia wyjścia.

Szóstym błędem jest brak mapowania komponentów do usług biznesowych. Podatny pakiet niewiele znaczy, dopóki nie wiadomo, czy wpływa na uwierzytelnianie, płatności, raportowanie, dokumentację pacjentów, administrację chmurą, onboarding klientów czy regulowany proces finansowy.

Siódmym błędem jest ukrywanie nierozwiązanych krytycznych podatności przed kierownictwem. Zarówno NIS2, jak i DORA wyraźnie wskazują rozliczalność kierownictwa. Ryzyko krytycznych komponentów powinno być widoczne dla forów ładu zarządczego, a nie zakopane w backlogach zespołu inżynieryjnego.

Jak wygląda dobry stan w 2026 r.

Gotowy do audytu program SBOM ma widoczne cechy.

Istnieje zatwierdzona polityka wymagająca, aby komponenty stron trzecich i open source były zatwierdzane, ewidencjonowane, skanowane i przeglądane. Potok CI/CD automatycznie generuje SBOM-y. Skany SCA działają przed wdrożeniem oraz w czasie działania, jeżeli ma to zastosowanie. Krytyczne podatności uruchamiają zdefiniowaną eskalację. Wyjątki mają właścicieli, daty wygaśnięcia, środki kompensujące i akceptację ryzyka.

Umowy z dostawcami obejmują obowiązki bezpieczeństwa, terminy zgłoszenia naruszenia, prawa do audytu, kontrole podwykonawstwa i postanowienia dotyczące zakończenia. Dostawcy krytyczni są przeglądani co najmniej raz w roku. Widoczne są zależności od dostawców i ryzyka koncentracji. Zespoły rozwoju realizowanego w modelu outsourcingowym stosują te same zasady bezpiecznego rozwoju oprogramowania i zatwierdzania komponentów co zespoły wewnętrzne.

Raportowanie zarządcze łączy ryzyko techniczne z wpływem biznesowym:

• Krytyczne podatne komponenty według produktu
• Ekspozycja według klienta lub usługi regulowanej
• Otwarte działania naprawcze po przekroczeniu SLA
• Komponenty bez zatwierdzonego źródła
• Biblioteki niewspierane lub o zakończonym cyklu życia
• Luki w dowodach dostawców
• Wyjątki oczekujące na odnowienie lub zamknięcie
• Incydenty powiązane z podatnościami komponentów

Wtedy SBOM-y przestają być artefaktem zgodności, a stają się narzędziem zarządczym.

Przekształć SBOM-y w możliwe do obrony dowody zgodności

Następnym razem, gdy alert dotyczący krytycznego komponentu pojawi się o 07:42, odpowiedź nie powinna brzmieć: „Potrzebujemy dwóch godzin, żeby ustalić, gdzie on jest”.

Powinna brzmieć: „Oto komponent, którego dotyczy podatność, oto usługi, oto klienci, oto ocena ryzyka, oto plan działań naprawczych i oto dowody”.

Clarysec może pomóc zaprojektować taki system kontroli. Pomagamy organizacjom definiować zakres SBOM w SZBI, mapować zabezpieczenia ISO 27001:2022 z Załącznika A na oczekiwania audytowe NIS2, DORA, GDPR, NIST CSF 2.0 i w stylu COBIT, wdrażać polityki bezpiecznego rozwoju oprogramowania i dostawców, budować pakiety dowodowe wydań oraz przygotować gotowe do audytu zapewnienie z użyciem Zenith Controls i Zenith Blueprint.

Gotowi przekształcić łańcuch dostaw oprogramowania ze źródła niepewności w potwierdzenie odporności?

Pobierz właściwe polityki Clarysec, użyj Zenith Blueprint do sekwencjonowania wdrożenia i użyj Zenith Controls do mapowania dowodów w ISO 27001:2022, NIS2, DORA oraz wymaganiach zapewnienia klientów. Skontaktuj się z Clarysec, aby zacząć od ukierunkowanej oceny gotowości SBOM i zbudować praktyczny, gotowy do audytu program zapewnienia łańcucha dostaw oprogramowania.