AI-beveiligingstools lezen uw code. Iets moet nog steeds uw build vastleggen.

Uw team voegt waarschijnlijk al AI toe aan beveiliging

De meeste engineeringteams hebben inmiddels minstens één AI-tool in de beveiligingscyclus. Een model beoordeelt pull requests. Een ander stelt oplossingen voor bij meldingen van statische analyse. Een derde sorteert scannerbevindingen in "bekijk dit" en "waarschijnlijk ruis". Deze tools besparen echt tijd, en niets op deze pagina pleit ertegen.

De nuttige vraag is welke taken ze zouden moeten krijgen en welke taken een vastlegging nodig hebben die elke keer hetzelfde uitkomt. De bijbehorende vraag is wat uw AI-tools lezen wanneer ze een oordeel vellen over uw afhankelijkheden.

Waar AI-beveiligingstools goed in zijn

• AI-codereview. GitHub Copilot code review plaatst opmerkingen in natuurlijke taal en codesuggesties bij pull requests, en kan repositoryspecifieke instructies volgen. Het is goed in het leeswerk dat een drukke reviewer overslaat.
• AI-fixes. GitHub Copilot Autofix "genereert automatisch suggesties voor codewijzigingen voor CodeQL-meldingen in pull requests en op de standaardbranch." Een ontwikkelaar krijgt een voorgestelde patch naast de melding in plaats van een link naar een CWE-pagina.
• AI-triage. De AI-functies van Semgrep voeren autotriage uit op bevindingen van Semgrep Code en stellen oplossingen voor. Semgrep documenteert zijn ruisfilter als "meer dan 95% nauwkeurig in het categoriseren van bevindingen van Semgrep Code als fout-positieven."

Let op het patroon in de laatste twee. Copilot Autofix werkt op CodeQL-meldingen. De triage van Semgrep werkt op bevindingen van de regelgebaseerde engine van Semgrep. De AI voegt oordeel toe bovenop deterministische uitvoer. De onderliggende bevindingen produceert ze niet zelf.

Wat de leveranciers zeggen over de grenzen

De duidelijkste uitspraken over waar AI-tools ophouden, komen van de leveranciers zelf, wat hun siert.

• Over code review schrijft GitHub dat "Copilot mogelijk niet alle problemen in code vindt" en dat het "een risico op hallucinatie heeft", waarbij het problemen aanwijst die niet bestaan.
• Over Autofix schrijft GitHub dat het "een generatief model gebruikt dat niet-deterministisch is. Zelfs met dezelfde melding en code kan het er niet in slagen een bruikbare suggestie te doen, of kan de suggestie per poging verschillen."
• Ook over Autofix: "Het systeem weet niet welke versies van afhankelijkheden ondersteund of veilig zijn, en kan verzonnen afhankelijkheden voorstellen die onder statistisch waarschijnlijke namen zijn gepubliceerd."

Niets hiervan maakt de tools minder nuttig. Het bepaalt hun taak: ze doen suggesties die een mens moet controleren. Dat is een andere taak dan het maken van de vastlegging waartegen die mens controleert.

Twee lagen, twee taken

CRACI zit in de vastleggingslaag. Het vervangt de GitHub Actions-runner (u wijzigt runs-on in craci), en een proxy die pakketten herkent, observeert tijdens de job het verkeer van de build naar pakketbronnen. Het resultaat is een SBOM van wat de job daadwerkelijk heeft opgehaald, een volledigheidsstatus voor elke job en cache, en een netwerktrace. De API levert SBOM's, netwerktraces en herkomstgegevens.

Waar deterministisch inzicht nodig is

"Zijn wij getroffen?"

Wanneer er een nieuwe advisory verschijnt, is de eerste vraag of een van uw builds de getroffen versie bevatte. De SBOM-minimumelementen van CISA uit 2026 formuleren de eis helder: de ontvanger van een SBOM "moet kunnen concluderen dat een nieuw gemelde kwetsbaarheid hem niet treft als de SBOM het component niet vermeldt." Die conclusie houdt alleen stand als de lijst volledig is. Een model kan u helpen het antwoord te lezen. Het mag niet bepalen wat er in de build zat.

CRACI bundelt kwetsbaarheden over builds en repositories heen en beoordeelt gemonitorde SBOM's opnieuw zodra nieuwe kwetsbaarheden worden gepubliceerd, zodat de vraag wordt beantwoord op basis van wat is vastgelegd.

Afhankelijkheden die een AI heeft toegevoegd

AI-codeerassistenten voegen afhankelijkheden toe, en onderzoek toont aan dat ze soms pakketten noemen die niet bestaan. Een studie die op USENIX Security 2025 werd gepresenteerd, genereerde 576.000 codevoorbeelden met 16 modellen en vond dat het gemiddelde aandeel gehallucineerde pakketten minstens 5,2% was bij commerciële modellen en 21,7% bij open-sourcemodellen. Een naam die vandaag niet bestaat, kan morgen worden geregistreerd. Wie of wat een afhankelijkheid ook heeft toegevoegd, CRACI legt het pakket vast dat de build daadwerkelijk heeft gedownload, en egressbeleid voor het netwerk kan een job beperken tot de pakketbronnen die u goedkeurt.

Audits en vragen van klanten

Een auditor of het securityteam van een klant zal vragen hoe u weet wat er is geleverd. "Het model zei het" is een zwak antwoord. "Hier is de SBOM die tijdens de releasebuild is vastgelegd, de volledigheidsstatus ervan en de netwerktrace van die job" is een sterk antwoord. SBOM's worden geëxporteerd als CycloneDX of SPDX, inclusief kwetsbaarheden, en de API levert SBOM's, netwerktraces en herkomstgegevens.

Herhaalbare antwoorden

Sommige vragen vereisen hetzelfde antwoord, ongeacht wie het vraagt of wanneer. Welke pakketten heeft de release van afgelopen dinsdag binnengehaald? Een generatief model kan dat antwoord goed verwoorden, maar volgens zijn eigen leveranciers verwoordt het dat misschien elke keer anders. Een vastgelegde build geeft één antwoord.

Hoe de twee samengaan

Het patroon dat werkt, is het patroon dat Copilot Autofix en Semgrep al gebruiken: deterministische gegevens eronder, AI-oordeel erbovenop.

1. Laat AI-codereview en AI-fixes op pull requests werken, waarbij een mens elke wijziging goedkeurt.
2. Laat CRACI vastleggen wat elke build heeft binnengehaald en aangeven of die vastlegging volledig is.
3. Wanneer u AI-hulp wilt bij afhankelijkheidsrisico's, geef het model dan de vastgelegde SBOM. De openbare REST API van CRACI levert de SBOM als CycloneDX, de netwerktrace van de job en de herkomst van het artefact.
4. Bewaar de vastgelegde SBOM als bewijs, niet de samenvatting die het model ervan maakt.

Als uw team een groot deel van zijn code met AI-assistenten schrijft, gaat onze pagina over beveiliging van AI-ontwikkeling in op die situatie, en SBOM-generatie tijdens de build legt uit hoe de vastlegging tot stand komt.