Bezpečnostní nástroje s AI čtou váš kód. Váš build ale musí stále něco zaznamenat.

Váš tým už pravděpodobně přidává AI do bezpečnosti

Většina vývojářských týmů dnes má v bezpečnostním procesu alespoň jeden nástroj s AI. Jeden model kontroluje pull requesty. Další navrhuje opravy pro výstrahy statické analýzy. Třetí třídí nálezy skenerů na „podívejte se na to“ a „nejspíš šum“. Tyto nástroje šetří skutečný čas a nic na této stránce proti nim nemluví.

Užitečná otázka zní, které úkoly by měly patřit jim a které potřebují záznam, jenž vyjde pokaždé stejně. Doprovodná otázka zní, co vaše nástroje s AI čtou, když rozhodují o vašich závislostech.

Co bezpečnostní nástroje s AI dělají dobře

• AI code review. GitHub Copilot code review zanechává v pull requestech komentáře v přirozeném jazyce a návrhy kódu a umí se řídit pokyny specifickými pro repozitář. Dobře zvládá čtení, které vytížený recenzent vynechá.
• Opravy od AI. GitHub Copilot Autofix „automaticky generuje návrhy změn kódu pro výstrahy CodeQL nalezené v pull requestech a ve výchozí větvi“. Vývojář dostane navrženou opravu přímo u výstrahy místo odkazu na stránku CWE.
• AI triáž. Funkce AI v Semgrepu automaticky třídí nálezy ze Semgrep Code a navrhují opravy. Semgrep uvádí, že jeho filtrování šumu je „z více než 95 % přesné při kategorizaci nálezů Semgrep Code jako falešně pozitivních“.

Všimněte si vzorce v posledních dvou bodech. Copilot Autofix pracuje s výstrahami CodeQL. Triáž v Semgrepu pracuje s nálezy pravidlového enginu Semgrepu. AI přidává úsudek nad deterministický výstup. Samotné podkladové nálezy nevytváří.

Co o omezeních říkají sami dodavatelé

Nejjasněji popisují, kde nástroje s AI končí, sami dodavatelé, což jim slouží ke cti.

• O code review GitHub píše, že „Copilot nemusí odhalit všechny problémy, které se v kódu nacházejí“, a že u něj „existuje riziko halucinací“, tedy upozornění na problémy, které neexistují.
• O Autofixu GitHub píše, že „používá generativní model, který je nedeterministický. I při stejné výstraze a stejném kódu nemusí vytvořit použitelný návrh nebo se návrh může mezi pokusy lišit“.
• Také o Autofixu: „Systém neví, které verze závislostí jsou podporované nebo bezpečné, a může navrhovat smyšlené závislosti publikované pod statisticky pravděpodobnými názvy.“

Nic z toho nedělá tyto nástroje méně užitečnými. Vymezuje to jejich úkol: vytvářejí návrhy, které má zkontrolovat člověk. To je jiný úkol než vytvářet záznam, se kterým je člověk porovnává.

Dvě vrstvy, dva úkoly

CRACI působí ve vrstvě záznamu. Nahrazuje runner GitHub Actions (změníte runs-on na craci) a proxy, která rozumí balíčkům, sleduje během jobu provoz buildu ke zdrojům balíčků. Výstupem je SBOM toho, co job skutečně stáhl, stav úplnosti pro každý job a cache a síťový záznam. API vrací SBOM, síťové záznamy a údaje o původu.

Kde je potřeba deterministický přehled

„Týká se nás to?“

Když přijde nové bezpečnostní upozornění, první otázkou je, zda některý z vašich buildů obsahoval dotčenou verzi. Minimální prvky SBOM od CISA pro rok 2026 formulují požadavek jasně: příjemce SBOM „by měl být schopen dospět k závěru, že ho nově nahlášená zranitelnost nepostihuje, pokud SBOM danou komponentu neuvádí“. Tento závěr platí jen tehdy, je-li seznam úplný. Model vám může pomoci odpověď přečíst. Neměl by to ale být on, kdo rozhoduje, co v buildu bylo.

CRACI agreguje zranitelnosti napříč buildy a repozitáři a znovu vyhodnocuje monitorované SBOM, jakmile se zveřejní nové zranitelnosti, takže odpověď vychází z toho, co bylo zaznamenáno.

Závislosti, které přidala AI

AI asistenti pro programování přidávají závislosti a výzkum ukazuje, že někdy uvádějí balíčky, které neexistují. Studie prezentovaná na USENIX Security 2025 vygenerovala 576 000 ukázek kódu pomocí 16 modelů a zjistila, že průměrný podíl vymyšlených balíčků byl nejméně 5,2 % u komerčních modelů a 21,7 % u open source modelů. Název, který dnes neexistuje, si může zítra někdo zaregistrovat. Ať závislost přidal kdokoli nebo cokoli, CRACI zaznamená balíček, který build skutečně stáhl, a politiky odchozího provozu mohou omezit job na zdroje balíčků, které schválíte.

Audity a dotazy zákazníků

Auditor nebo bezpečnostní tým zákazníka se zeptá, jak víte, co bylo dodáno. „Model to řekl“ je slabá odpověď. „Tady je SBOM zaznamenaná během release buildu, její stav úplnosti a síťový záznam tohoto jobu“ je silná odpověď. SBOM se exportují jako CycloneDX nebo SPDX včetně zranitelností a API vrací SBOM, síťové záznamy a údaje o původu.

Opakovatelné odpovědi

Některé otázky potřebují stejnou odpověď bez ohledu na to, kdo se ptá a kdy. Které balíčky stáhlo vydání z minulého úterý? Generativní model tuto odpověď dokáže dobře formulovat, ale podle vlastních slov svých dodavatelů ji pokaždé může formulovat jinak. Zaznamenaný build dává jednu odpověď.

Jak do sebe obojí zapadá

Funguje vzorec, který už používají Copilot Autofix i Semgrep: deterministická data dole, úsudek AI nahoře.

1. Nechte AI code review a opravy od AI pracovat na pull requestech, přičemž každou změnu schvaluje člověk.
2. Nechte CRACI zaznamenat, co každý build stáhl, a uvést, zda je tento záznam úplný.
3. Když chcete pomoc AI s riziky závislostí, dejte modelu zaznamenanou SBOM. Veřejné REST API CRACI vrací SBOM ve formátu CycloneDX, síťový záznam jobu a údaje o původu artefaktu.
4. Jako důkaz uchovávejte zaznamenanou SBOM, ne shrnutí, které z ní udělal model.

Pokud váš tým píše velkou část kódu s AI asistenty, tuto situaci pokrývá naše stránka o bezpečnosti vývoje s AI a generování SBOM v době buildu vysvětluje, jak záznam vzniká.