SBOM wygenerowany przez AI to domysł na temat buildu. Regulatorzy proszą o zapis.

Dlaczego zespoły tego próbują

Atrakcyjność jest realna. Wkleja się repozytorium lub lockfile do asystenta kodowania, prosi o CycloneDX i po kilku sekundach otrzymuje poprawnie sformatowany dokument. Może on nawet wypełnić pola, które skanery zwykle zostawiają puste. Typowym przykładem jest pole dostawcy: większość generatorów nie ma dla niego źródła, więc pozostaje puste. Model poproszony o kompletny dokument potrafi wpisać coś w każde pole.

Ten ostatni punkt to problem w miniaturze. Skaner, który nie zna dostawcy, zostawia pole puste. Model, który go nie zna, może mimo to podać wiarygodnie brzmiącą odpowiedź. Dokument wygląda na bardziej kompletny, a jest mniej wiarygodny.

Co model naprawdę widzi

Model generujący SBOM pracuje na tekście, który ma przed sobą: manifestach, lockfile, ewentualnie pliku Dockerfile. Nie obserwuje buildu. Dlatego nie widzi:

• które wersje rozwiązał menedżer pakietów, gdy repozytorium nie zawiera lockfile,
• pakietów przywróconych z cache CI,
• narzędzi, pakietów systemowych i plików binarnych pobieranych bezpośrednio przez krok buildu,
• tego, co trafiło do skompilowanego pliku binarnego dostarczanego obok niemal pustego manifestu.

Dwa repozytoria pokazują, jak skąpe mogą być te pliki. expressjs/express 5.2.1 nie zawiera lockfile, więc jego package.json podaje zależności jako zakresy wersji, a faktyczne wersje są ustalane podczas instalacji. Repozytorium anthropics/claude-code w wersji v2.1.259 nie ma żadnego manifestu zależności ani lockfile, a jego opublikowany pakiet npm deklaruje zero zależności uruchomieniowych, opakowując gotowy natywny plik binarny. Skaner deterministyczny skierowany na to repozytorium nie ma czego odczytać, aby opisać ten plik binarny. Model, który dostanie te same pliki, ma ten sam brak informacji i większą swobodę w wypełnianiu luki.

Halucynacje to udokumentowany sposób awarii

Modele językowe podają nazwy pakietów, które nie istnieją. Najlepiej zmierzony przypadek dotyczy generowania kodu, a nie pisania SBOM, ale ujawniona w nim awaria równie dobrze dotyczy listy komponentów. W badaniu z USENIX Security 2025 wygenerowano 576 000 próbek kodu za pomocą 16 modeli i stwierdzono średni odsetek halucynowanych pakietów na poziomie co najmniej 5,2% dla modeli komercyjnych i 21,7% dla modeli open source, przy 205 474 unikalnych halucynowanych nazwach pakietów. Własna dokumentacja GitHub dla Copilot Autofix ostrzega, że może on sugerować zmyślone zależności publikowane pod statystycznie prawdopodobnymi nazwami.

Modele nie dają też dwa razy tej samej odpowiedzi. Dokumentacja Anthropic podaje, że nawet przy temperaturze ustawionej na 0 wyniki nie będą w pełni deterministyczne, a identyczne dane wejściowe mogą dawać różne wyniki w różnych wywołaniach API. Dwa SBOM-y wygenerowane z tego samego commita mogą się różnić i żaden z nich nie mówi, który jest poprawny.

W SBOM halucynowany wpis nie jest niegroźną literówką. Pakiet, który nie istnieje, lub niewłaściwa wersja istniejącego kieruje wyszukiwanie podatności w złe miejsce, a wynik wraca pewny siebie i błędny.

Czego standardy oczekują od zawartości SBOM

Minimalne elementy NTIA (2021)

Punkt odniesienia NTIA zdefiniował siedem pól danych: nazwę dostawcy, nazwę komponentu, wersję komponentu, inne unikalne identyfikatory, relację zależności, autora danych SBOM i znacznik czasu. Połączył je z obsługą automatyzacji oraz zestawem praktyk i procesów. Każde pole opisuje fakt dotyczący oprogramowania, a nie opinię o nim.

Minimalne elementy CISA z 2026 roku

29 lipca 2026 CISA, NSA, FBI i partnerzy międzynarodowi opublikowali zaktualizowane minimalne elementy, które zastępują punkt odniesienia z 2021 roku. Kilka nowości trudno spełnić bez obserwowania buildu:

• SBOM Generation Context: względna faza cyklu życia oprogramowania i dane dostępne w chwili, gdy autor SBOM go generował; jako przykłady podano fazy przed buildem, build i po buildzie. Model czytający repozytorium jest w najlepszym razie przed buildem.
• Component Hash Value: wynik zastosowania kryptograficznego algorytmu skrótu do artefaktu wykonywalnego komponentu. Jeśli autor nie ma artefaktu, powinien wskazać, że wartość jest nieznana. Model, który nigdy nie miał styczności z artefaktem, nie może wytworzyć skrótu, a jedynie tekst, który go przypomina.
• SBOM Tool Name and Version: należy podać narzędzie użyte do wygenerowania SBOM.
• Coverage: SBOM powinien zawierać informacje o wszystkich komponentach składających się na docelowe oprogramowanie, łącznie z zależnościami przechodnimi, bez minimalnej głębokości.
• Explicitly identifying unknown information: autor powinien wyraźnie zaznaczyć, czy dana informacja jest nieznana. Zmyślona wartość to przeciwieństwo takiego działania.

Unijny Cyber Resilience Act

CRA czyni SBOM obowiązkiem prawnym producentów produktów z elementami cyfrowymi. Załącznik I, część II wymaga od nich zidentyfikowania i udokumentowania podatności oraz komponentów zawartych w produktach z elementami cyfrowymi, w tym przez sporządzenie zestawienia komponentów oprogramowania w powszechnie stosowanym formacie czytelnym maszynowo, obejmującego co najmniej zależności najwyższego poziomu produktów. Załącznik VII umieszcza SBOM w dokumentacji technicznej, a organ nadzoru rynku może go zażądać, aby sprawdzić zgodność z zasadniczymi wymaganiami.

Żaden z tych tekstów nie zakazuje narzędzi AI. Wymagają one danych opisujących faktyczny produkt i uczciwych informacji o tym, co jest nieznane. SBOM napisany na podstawie wnioskowania ma problem z jednym i drugim.

Jak CRACI tworzy SBOM

CRACI uruchamia Państwa zadania GitHub Actions na własnych runnerach. Wystarczy zmienić runs-on na craci, a uruchomienia nadal pojawiają się w GitHub. Podczas działania zadania proxy rozpoznające pakiety obserwuje ruch do źródeł pakietów, więc SBOM rejestruje to, co build faktycznie pobrał, łącznie z zależnościami przechodnimi. Dowody zależności przemieszczają się razem z cache CI, więc pakiet przywrócony z cache pozostaje w zapisie.

• Ekosystemy: źródła npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i Git, a także presety pobierania.
• Kompletność: każde zadanie i cache są oznaczone jako Complete, Complete with connections, Incomplete, Unavailable lub Not recorded, więc niewiadome są wskazane, a nie wypełnione.
• Formaty: CycloneDX i SPDX, z deklarowanymi metadanymi licencji w eksporcie.
• Dane o pochodzeniu: API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu.

CRACI automatyzuje znaczną część widoczności łańcucha dostaw i dowodów potrzebnych w szerszym procesie zgodności z CRA. Sam w sobie nie zapewnia zgodności produktu. Szczegóły opisuje strona generowanie SBOM w czasie buildu, a harmonogram nasz przegląd CRA.

W czym AI pomaga przy SBOM

Gdy mają Państwo zarejestrowany SBOM, model dobrze sobie z nim radzi: podsumowuje, które komponenty niosą ryzyko, wyjaśnia biuletyn prostym językiem lub przygotowuje projekt towarzyszącej dokumentacji do przeglądu przez człowieka. Zasada jest prosta. Niech zapis powstaje w buildzie, a model go czyta.