Gdzie narzędzia AI do bezpieczeństwa zawodzą i co obejmują deterministyczne dowody z buildu

Teza w wąskim ujęciu

To nie jest argument przeciwko AI w bezpieczeństwie. Modele dobrze czytają kod, wyjaśniają znaleziska i proponują poprawki, a zespoły, które dobrze z nich korzystają, pracują szybciej. Teza jest węższa: dla zapisów, które muszą się później obronić, model probabilistyczny jest niewłaściwym głównym źródłem. Dotyczy to SBOM przekazywanego regulatorowi, pochodzenia wydanego artefaktu i odpowiedzi na pytanie „czy to nas dotyczyło?”.

O tym, czy zapis się obroni, decydują trzy właściwości. Każda z poniższych sekcji omawia jedną z nich, z przykładami i źródłami.

1. Powtarzalność: dwa razy to samo pytanie, ta sama odpowiedź

Zapis bezpieczeństwa jest przydatny tylko wtedy, gdy ktoś inny może uzyskać tę samą odpowiedź z tego samego wejścia. Modele językowe tego nie obiecują i dostawcy mówią o tym otwarcie.

• Dokumentacja Anthropic: „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 kolejnych wywołaniach API”.
• GitHub o Copilot Autofix: „Nawet przy tym samym alercie i kodzie może nie wygenerować użytecznej sugestii, a sugestia może się różnić między próbami”.
• Badacze, którzy stworzyli framework SecLLMHolmes, przetestowali osiem LLM na 228 scenariuszach kodu na potrzeby IEEE S&P 2024. Podają, że modele „udzielają niedeterministycznych odpowiedzi” oraz że „wystarczy zmienić nazwy funkcji lub zmiennych albo dodać funkcje biblioteczne w kodzie źródłowym”, by PaLM2 i GPT-4 udzieliły błędnych odpowiedzi odpowiednio w 26% i 17% przypadków.

Przykład. Dwóch inżynierów pyta tego samego asystenta, czy usługa jest narażona na nową podatność z biuletynu. Jeden słyszy „nie”, drugi „możliwe, proszę sprawdzić drzewo zależności przechodnich”. Żadna z tych odpowiedzi nie jest zapisem i żadnej nie da się odtworzyć dla audytora pół roku później.

Zarejestrowany build nie ma tego problemu, ponieważ nic nie jest wnioskowane. CRACI obserwuje pakiety, które zadanie pobiera ze źródeł pakietów w trakcie działania, a SBOM jest zapisem tej obserwacji.

2. Audytowalność: pokazać, skąd to wiadomo

Audyty sprowadzają się do pytania „skąd Państwo to wiedzą?”. Model może udzielić płynnej odpowiedzi, ale jego wyjaśnienie nie jest dowodem. Ewaluacja SecLLMHolmes wykazała, że LLM podają „błędne i nierzetelne uzasadnienia” dotyczące ocenianych podatności, więc poprawny werdykt może iść w parze z wyjaśnieniem, które się nie broni.

Standardy zmierzają w stronę zapisów, które wyjaśniają własne pochodzenie. Minimalne elementy SBOM z 2026 roku, opublikowane przez CISA wraz z NSA, FBI i partnerami międzynarodowymi, dodają pola SBOM Tool Name, SBOM Tool Version i SBOM Generation Context, które określa, czy SBOM powstał „przed buildem”, w trakcie „buildu” czy „po buildzie”. Ten sam dokument ostrzega, że „organizacje mogą uwzględniać błędy, wynikające z praktyk autora SBOM lub wyboru nieodpowiednich narzędzi, w decyzjach dotyczących zarządzania ryzykiem organizacyjnym”.

Przykład. Kwestionariusz klienta pyta, jak powstał Państwa SBOM. „Asystent przeczytał repozytorium i go napisał” podaje kontekst generowania, ale nie taki, który recenzent może sprawdzić. „Został zarejestrowany wewnątrz runnera CI podczas buildu wydania, a stan kompletności zadania to Complete” to coś, co recenzent może zweryfikować względem buildu.

3. Kompletność: nie da się zgłosić czegoś, czego się nigdy nie widziało

Model wnioskuje na podstawie tego, co mu pokazano. Jeśli czytane pliki nie opisują oprogramowania, odpowiedź również go nie opisze, a nic w wyniku tego nie zasygnalizuje. Wytyczne CISA z 2026 roku stawiają poprzeczkę na poziomie decyzji odbiorcy: odbiorca „powinien móc stwierdzić, że nowo zgłoszona podatność go nie dotyczy, jeśli SBOM nie wymienia danego komponentu”. To działa tylko wtedy, gdy brak na liście oznacza brak w buildzie.

Przykład. Repozytorium anthropics/claude-code w wersji v2.1.259 nie ma żadnego manifestu zależności ani lockfile. Opublikowany pakiet npm deklaruje zero zależności runtime i opakowuje gotowy natywny plik binarny. Każde narzędzie, które czyta repozytorium, AI czy nie, ma niemal nic do wymienienia, podczas gdy program, który faktycznie działa, jest skompilowanym plikiem binarnym.

Przykład. Narzędzia AI do kodowania mogą też same tworzyć tę lukę. GitHub ostrzega, że Copilot Autofix „może sugerować zmyślone zależności publikowane pod statystycznie prawdopodobnymi nazwami”. Badanie z USENIX Security 2025 obejmujące 576 000 wygenerowanych próbek kodu z 16 modeli wykazało średni odsetek zmyślonych pakietów na poziomie co najmniej 5,2% dla modeli komercyjnych i 21,7% dla modeli open source, z 205 474 unikalnymi zmyślonymi nazwami pakietów.

Determinizm jest konieczny, ale niewystarczający

Uczciwa wersja tego argumentu musi uwzględnić kolejny punkt. Generatory SBOM są deterministyczne, a mimo to dają różne wyniki. Uruchomione na tym samym commicie expressjs/express mogą zwrócić różne listy, ponieważ każdy sam decyduje, co uznaje za komponent i którym plikom ufa. Repozytorium nie zawiera lockfile, więc narzędzie, które rozwiązuje zależności na jego podstawie, nie ma do zgłoszenia żadnej z zależności z package.json.

Deterministyczny skaner za każdym razem odtwarza tę samą niekompletną odpowiedź. Powtarzalność jest konieczna, ale lukę zamyka obserwacja: rejestrowanie tego, co build faktycznie pobrał, i informowanie, gdy zapis jest niekompletny. CRACI oznacza każde zadanie i cache jako Complete, Complete with connections, Incomplete, Unavailable lub Not recorded.

Przykład z praktyki: ustalanie zakresu nowej podatności

Scenariusz hipotetyczny: opublikowano biuletyn dotyczący wersji szeroko używanego pakietu npm. Zgodnie z Cyber Resilience Act producenci mają 24 godziny na zgłoszenie aktywnie wykorzystywanej podatności do ENISA, więc ustalenie zakresu musi być szybkie i trafne.

Ścieżka „najpierw AI”

Proszą Państwo asystenta o sprawdzenie repozytoriów. Czyta manifesty i lockfile, być może także Dockerfile. Nie widzi pakietów przywróconych z cache CI, narzędzi pobranych przez krok buildu ani wersji rozwiązanych podczas instalacji w repozytorium bez lockfile. Zapytany dwa razy może odpowiedzieć inaczej. Jego podsumowanie jest przydatne, ale nie można na nim oprzeć podpisanego zgłoszenia.

Ścieżka „najpierw zapis”

CRACI agreguje podatności z wielu buildów i repozytoriów, w zakresie gałęzi domyślnej na poziomie organizacji, i ponownie ocenia monitorowane SBOM-y w miarę pojawiania się nowych podatności. API zwraca dla każdego buildu SBOM w formacie CycloneDX, jego ślad sieciowy i dane o pochodzeniu. Jeśli zapis zadania jest niekompletny, jego stan kompletności wskazuje, gdzie trzeba sprawdzić ręcznie. Nadal można poprosić model o podsumowanie wyniku. Model podsumowuje wtedy zapis, a nie go wytwarza.

Dzięki zapisowi pytanie „które wydania zawierały ten pakiet?” to wyszukanie, a nie śledztwo.

Zestawienie

Każde narzędzie tam, gdzie jest mocne

AI warto stosować tam, gdzie pomaga ocena, a człowiek sprawdza wynik: przy przeglądzie kodu, wyjaśnianiu znaleziska, szkicowaniu poprawki. Deterministyczne zapisy buildów warto stosować tam, gdzie wynik trzeba odtworzyć, zaudytować lub traktować jako kompletny: przy SBOM-ach, pochodzeniu i ustalaniu zakresu incydentów. CRACI automatyzuje znaczną część tych dowodów dotyczących łańcucha dostaw w szerszym procesie CRA. Sam w sobie nie zapewnia zgodności.

Jak powstaje zapis, wyjaśnia strona o generowaniu SBOM w czasie buildu; można też zacząć od tego, czego wymaga CRA.