Narzędzia AI czytają Państwa kod. Ktoś wciąż musi zarejestrować build.

Państwa zespół prawdopodobnie już dodaje AI do bezpieczeństwa

Większość zespołów inżynierskich ma dziś w procesie bezpieczeństwa co najmniej jedno narzędzie AI. Jeden model przegląda pull requesty. Inny proponuje poprawki dla alertów analizy statycznej. Trzeci sortuje znaleziska skanerów na „warto sprawdzić” i „prawdopodobnie szum”. Te narzędzia realnie oszczędzają czas i nic na tej stronie nie przemawia przeciwko nim.

Pożyteczne pytanie brzmi: które zadania powinny do nich należeć, a które wymagają zapisu dającego za każdym razem ten sam wynik. Pytanie towarzyszące: co czytają Państwa narzędzia AI, gdy podejmują decyzję o zależnościach.

Co narzędzia AI do bezpieczeństwa robią dobrze

• Przegląd kodu z AI. GitHub Copilot code review zostawia w pull requestach komentarze w języku naturalnym i sugestie kodu, a przy tym potrafi stosować instrukcje specyficzne dla repozytorium. Dobrze radzi sobie z czytaniem, które zapracowany recenzent pomija.
• Poprawki z AI. GitHub Copilot Autofix „automatycznie generuje sugestie zmian w kodzie dla alertów CodeQL wykrytych w pull requestach i na gałęzi domyślnej”. Programista dostaje proponowaną poprawkę obok alertu zamiast linku do strony CWE.
• Triaż z AI. Funkcje AI w Semgrep automatycznie klasyfikują znaleziska z Semgrep Code i proponują poprawki. Semgrep podaje, że jego filtrowanie szumu jest „w ponad 95% trafne w klasyfikowaniu znalezisk Semgrep Code jako fałszywie pozytywnych”.

Proszę zwrócić uwagę na wzorzec w dwóch ostatnich punktach. Copilot Autofix działa na alertach CodeQL. Triaż Semgrep działa na znaleziskach silnika Semgrep opartego na regułach. AI dodaje ocenę do deterministycznego wyniku. Sama nie tworzy znalezisk, na których się opiera.

Co dostawcy mówią o ograniczeniach

Najjaśniej o tym, gdzie kończą się możliwości narzędzi AI, piszą sami dostawcy, co przemawia na ich korzyść.

• O przeglądzie kodu GitHub pisze, że „Copilot może nie wykryć wszystkich problemów obecnych w kodzie” oraz że „istnieje ryzyko halucynacji”, czyli wskazywania problemów, które nie istnieją.
• O Autofix GitHub pisze, że „wykorzystuje model generatywny, który jest niedeterministyczny. 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”.
• Również o Autofix: „System nie wie, które wersje zależności są wspierane lub bezpieczne, i może sugerować zmyślone zależności publikowane pod statystycznie prawdopodobnymi nazwami”.

Nic z tego nie czyni tych narzędzi mniej przydatnymi. To określa ich zadanie: tworzą sugestie, które człowiek sprawdza. To inne zadanie niż tworzenie zapisu, względem którego człowiek je sprawdza.

Dwie warstwy, dwa zadania

CRACI działa w warstwie zapisu. Zastępuje runner GitHub Actions (wystarczy zmienić runs-on na craci), a proxy rozpoznające pakiety obserwuje ruch buildu do źródeł pakietów w trakcie zadania. Wynikiem jest SBOM tego, co zadanie faktycznie pobrało, stan kompletności dla każdego zadania i cache oraz ślad sieciowy. API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu.

Gdzie potrzebna jest deterministyczna widoczność

„Czy to nas dotyczy?”

Gdy pojawia się nowy biuletyn bezpieczeństwa, pierwsze pytanie brzmi, czy którykolwiek z Państwa buildów zawierał podatną wersję. Minimalne elementy SBOM opublikowane przez CISA w 2026 roku ujmują ten wymóg wprost: odbiorca SBOM „powinien móc stwierdzić, że nowo zgłoszona podatność go nie dotyczy, jeśli SBOM nie wymienia danego komponentu”. Ten wniosek jest prawdziwy tylko wtedy, gdy lista jest kompletna. Model może pomóc odczytać odpowiedź. Nie powinien jednak decydować o tym, co znalazło się w buildzie.

CRACI agreguje podatności z wielu buildów i repozytoriów oraz ponownie ocenia monitorowane SBOM-y w miarę publikowania nowych podatności, więc odpowiedź opiera się na tym, co zostało zarejestrowane.

Zależności dodane przez AI

Asystenci kodowania AI dodają zależności, a badania pokazują, że czasem podają nazwy pakietów, które nie istnieją. W badaniu zaprezentowanym na USENIX Security 2025 wygenerowano 576 000 próbek kodu za pomocą 16 modeli i stwierdzono, że średni udział zmyślonych pakietów wynosił co najmniej 5,2% w modelach komercyjnych i 21,7% w modelach open source. Nazwę, która dziś nie istnieje, ktoś może zarejestrować jutro. Niezależnie od tego, kto lub co dodało zależność, CRACI rejestruje pakiet, który build faktycznie pobrał, a polityki ruchu wychodzącego mogą ograniczyć zadanie do zatwierdzonych przez Państwa źródeł pakietów.

Audyty i pytania klientów

Audytor lub zespół bezpieczeństwa klienta zapyta, skąd Państwo wiedzą, co trafiło do wydania. „Tak powiedział model” to słaba odpowiedź. „Oto SBOM zarejestrowany podczas buildu wydania, jego stan kompletności i ślad sieciowy tego zadania” to mocna odpowiedź. SBOM-y eksportuje się w formatach CycloneDX lub SPDX, łącznie z podatnościami, a API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu.

Powtarzalne odpowiedzi

Niektóre pytania wymagają tej samej odpowiedzi niezależnie od tego, kto i kiedy pyta. Jakie pakiety pobrało wydanie z zeszłego wtorku? Model generatywny może dobrze sformułować tę odpowiedź, ale według jego własnych dostawców za każdym razem może sformułować ją inaczej. Zarejestrowany build daje jedną odpowiedź.

Jak obie warstwy się uzupełniają

Sprawdza się wzorzec, którego Copilot Autofix i Semgrep już używają: deterministyczne dane pod spodem, ocena AI na wierzchu.

1. Przegląd kodu i poprawki z AI niech działają na pull requestach, a każdą zmianę zatwierdza człowiek.
2. CRACI niech rejestruje, co pobrał każdy build, i określa, czy ten zapis jest kompletny.
3. Gdy chcą Państwo pomocy AI przy ryzyku zależności, proszę przekazać modelowi zarejestrowany SBOM. Publiczne REST API CRACI zwraca SBOM w formacie CycloneDX, ślad sieciowy zadania i dane o pochodzeniu artefaktu.
4. Jako dowód proszę zachować zarejestrowany SBOM, a nie jego podsumowanie przygotowane przez model.

Jeśli Państwa zespół pisze dużą część kodu z asystentami AI, tę sytuację opisuje nasza strona o bezpieczeństwie rozwoju oprogramowania z AI, a strona o generowaniu SBOM w czasie buildu wyjaśnia, jak powstaje zapis.