Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Software Bill of Materials, czyli SBOM, od lat pełni funkcję uporządkowanej listy komponentów oprogramowania, wspierając identyfikację zależności, ocenę ryzyka oraz szybsze reagowanie na podatności w łańcuchu dostaw. W przypadku systemów sztucznej inteligencji tradycyjne podejście okazuje się jednak niewystarczające, ponieważ sam kod aplikacji to tylko część całego ekosystemu.
W środowiskach AI znaczenie mają również modele, zbiory danych, procesy trenowania, pipeline’y MLOps, komponenty inferencyjne oraz wdrożone mechanizmy bezpieczeństwa. Właśnie dlatego partnerzy G7 opublikowali nowe minimalne wytyczne dla SBOM w kontekście AI, aby rozszerzyć zakres transparentności i ułatwić ocenę pochodzenia oraz bezpieczeństwa takich systemów.
W skrócie
12 maja 2026 r. międzynarodowi partnerzy G7, przy udziale agencji cyberbezpieczeństwa z USA, Niemiec, Francji, Włoch, Kanady, Wielkiej Brytanii i Japonii oraz we współpracy z Komisją Europejską, ogłosili dokument określający minimalne elementy SBOM dla AI. Wytyczne mają charakter uzupełniający wobec klasycznego SBOM i nie zastępują dotychczasowych praktyk, lecz rozszerzają je o elementy specyficzne dla sztucznej inteligencji.
- obejmują identyfikację modeli i ich wersji,
- uwzględniają źródła oraz charakter danych,
- opisują proces uczenia i dostrajania,
- wskazują na potrzebę dokumentowania mechanizmów bezpieczeństwa i ochrony,
- promują automatyzację i przetwarzalność maszynową.
Kontekst / historia
Wzrost znaczenia SBOM był bezpośrednio związany z incydentami supply chain, które pokazały, jak duże ryzyko niesie brak widoczności zależności programistycznych. W ostatnich latach standardy dotyczące przejrzystości oprogramowania stały się ważnym elementem praktyk bezpieczeństwa, audytu i zgodności regulacyjnej.
W 2025 r. partnerzy G7 przedstawili wspólną wizję dotyczącą SBOM dla AI, sygnalizując, że tradycyjna inwentaryzacja bibliotek i pakietów nie odzwierciedla realnych zagrożeń w systemach opartych na modelach uczenia maszynowego. Problem wynika z tego, że zachowanie systemu AI zależy nie tylko od kodu, ale również od źródeł danych, procesu trenowania, metod fine-tuningu oraz użytych usług zewnętrznych.
Brak spójnego opisu tych elementów utrudnia ocenę ekspozycji na ataki, analizę zgodności, prowadzenie audytów oraz dochodzenia po incydentach. Nowe wytyczne mają uporządkować ten obszar i stworzyć wspólną podstawę dla organizacji rozwijających lub wdrażających rozwiązania AI.
Analiza techniczna
Nowe podejście traktuje AI jako rozszerzenie istniejącego ekosystemu software supply chain, a nie jako zupełnie odrębną kategorię technologii. Oznacza to, że bazowy SBOM nadal pozostaje istotny, ale powinien zostać uzupełniony o dane opisujące komponenty i procesy właściwe dla AI.
Pierwszy kluczowy obszar dotyczy modeli. Organizacje powinny być w stanie jednoznacznie zidentyfikować model, jego wersję, pochodzenie, sposób utworzenia oraz deklarowane zastosowanie. Ma to szczególne znaczenie tam, gdzie wykorzystywane są modele bazowe dostarczane przez zewnętrznych dostawców, rozwiązania open source lub własne warianty po fine-tuningu.
Drugi filar obejmuje proces uczenia. Dokumentowanie technik trenowania, etapów przygotowania danych oraz pipeline’ów ML pozwala lepiej odtworzyć sposób wytworzenia modelu. Z perspektywy bezpieczeństwa zwiększa to możliwość wykrywania ryzyk związanych z przejęciem pipeline’u, nieautoryzowaną modyfikacją procesu treningowego lub manipulacją na etapie dostrajania.
Trzecim obszarem są dane. Wytyczne podkreślają potrzebę opisu datasetów, ich źródeł, przeznaczenia i pochodzenia. To istotne nie tylko z punktu widzenia bezpieczeństwa, ale także prywatności, zgodności licencyjnej i wymogów regulacyjnych. W systemach AI dane wpływają bezpośrednio na zachowanie modelu, dlatego stają się integralnym elementem analizy ryzyka.
Czwarty element odnosi się do właściwości bezpieczeństwa i ochrony. Chodzi o możliwość powiązania systemu AI z zastosowanymi zabezpieczeniami, guardrails, praktykami cyberbezpieczeństwa, deklaracjami zgodności oraz mechanizmami safety alignment. Dzięki temu AI SBOM nie jest wyłącznie statyczną listą składników, lecz narzędziem wspierającym ocenę poziomu ochrony rozwiązania.
Wytyczne akcentują również znaczenie automatyzacji. AI SBOM powinien być generowany w sposób powtarzalny i przetwarzalny maszynowo, tak aby mógł zostać zintegrowany z procesami DevSecOps, MLOps, zarządzaniem ryzykiem dostawców oraz monitoringiem zmian w środowisku produkcyjnym.
Konsekwencje / ryzyko
Publikacja nowych wytycznych potwierdza, że ryzyko łańcucha dostaw AI jest już traktowane jako problem operacyjny, wymagający konkretnych mechanizmów nadzoru. Organizacje korzystające z AI bez ewidencji modeli, danych i zależności zewnętrznych mają ograniczoną zdolność do oceny podatności, błędów konfiguracyjnych czy wpływu zmian po stronie dostawcy.
Brak rozszerzonego SBOM dla AI utrudnia odpowiedź na kluczowe pytania incydentowe. W praktyce może być niejasne, jaki model działał w momencie zdarzenia, z jakich danych korzystał, jakie zabezpieczenia były aktywne oraz które komponenty zewnętrzne mogły wpłynąć na profil ryzyka. W środowiskach regulowanych dochodzą do tego problemy z audytem, zgodnością i raportowaniem ryzyka wobec partnerów biznesowych.
Szczególnie narażone są architektury oparte na usługach zewnętrznych, agentach AI i rozbudowanych pipeline’ach danych. W takich modelach pojedyncza organizacja często nie ma pełnej kontroli nad całym stosem technologicznym, a brak standardowego opisu komponentów znacząco utrudnia ocenę zaufania do dostawcy.
Rekomendacje
Organizacje rozwijające lub wdrażające rozwiązania AI powinny potraktować nowe wytyczne jako praktyczny punkt wyjścia do budowy pełniejszej widoczności łańcucha dostaw. Pierwszym krokiem powinno być połączenie klasycznego SBOM z dodatkowymi metadanymi dotyczącymi modeli, datasetów, pipeline’ów treningowych i usług inferencyjnych.
- mapować pełny cykl życia modelu, od źródła modelu bazowego po etap wdrożenia,
- dokumentować dane użyte do trenowania, walidacji i dostrajania,
- ewidencjonować zależności od zewnętrznych API, repozytoriów modeli i platform obliczeniowych,
- automatyzować generowanie AI SBOM w procesach CI/CD i MLOps,
- uwzględniać wymagania dotyczące transparentności AI w ocenie i umowach z dostawcami,
- powiązać AI SBOM z kontrolami integralności artefaktów, monitorowaniem driftu i testami bezpieczeństwa.
W praktyce dojrzałe podejście powinno łączyć dokumentację komponentów z realnymi mechanizmami ochrony. Sam opis środowiska AI nie wystarczy, jeśli nie towarzyszy mu walidacja integralności, monitorowanie zmian oraz ocena odporności na zagrożenia takie jak prompt injection, zatruwanie danych czy kompromitacja pipeline’u treningowego.
Podsumowanie
Nowe wytyczne G7 dotyczące SBOM dla AI stanowią ważny krok w kierunku standaryzacji transparentności łańcucha dostaw sztucznej inteligencji. Dokument jasno pokazuje, że klasyczne SBOM nie obejmują pełnego krajobrazu ryzyk związanych z nowoczesnymi systemami AI, ponieważ pomijają modele, dane, proces uczenia oraz warstwę zabezpieczeń specyficzną dla tego typu rozwiązań.
Dla zespołów cyberbezpieczeństwa oznacza to konieczność rozszerzenia dotychczasowych praktyk software supply chain security o komponenty AI. W najbliższych latach AI SBOM może stać się jednym z podstawowych artefaktów bezpieczeństwa, compliance i zarządzania ryzykiem dostawców, szczególnie w organizacjach intensywnie wykorzystujących modele generatywne i usługi oparte na uczeniu maszynowym.
Źródła
- https://www.infosecurity-magazine.com/news/new-sboms-for-ai-guidance-2026/
- https://www.hstoday.us/subject-matter-areas/cybersecurity/cisa-and-partners-release-new-software-bill-of-materials-for-ai-guidance/
- https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_Food-for-thoughts.pdf
- https://www.csoonline.com/article/4170694/cisas-ai-sbom-guidance-pushes-software-supply-chain-oversight-into-new-territory.html