Waar AI-beveiligingstools tekortschieten, en wat deterministisch buildbewijs afdekt

Het argument, scherp afgebakend

Dit is geen pleidooi tegen AI in beveiliging. Modellen zijn goed in het lezen van code, het uitleggen van een bevinding en het voorstellen van een oplossing, en teams die ze goed gebruiken, werken sneller. Het argument is beperkter: voor vastleggingen die later stand moeten houden, is een probabilistisch model de verkeerde primaire bron. Dat geldt voor de SBOM die u aan een toezichthouder overhandigt, de herkomst van het artefact dat u hebt geleverd en het antwoord op "werden wij getroffen?"

Drie eigenschappen bepalen of een vastlegging standhoudt. Elk onderdeel hieronder behandelt er één, met voorbeelden en bronnen.

1. Reproduceerbaarheid: twee keer vragen, hetzelfde antwoord krijgen

Een beveiligingsvastlegging is alleen nuttig als iemand anders uit dezelfde invoer hetzelfde antwoord kan halen. Taalmodellen beloven dat niet, en de leveranciers zeggen dat ook.

• De documentatie van Anthropic: "Zelfs met de temperatuur op 0 zijn de resultaten niet volledig deterministisch en kan identieke invoer verschillende uitvoer opleveren tussen API-aanroepen."
• GitHub over Copilot Autofix: "Zelfs met dezelfde melding en code kan het er niet in slagen een bruikbare suggestie te doen, of kan de suggestie per poging verschillen."
• Onderzoekers die het SecLLMHolmes-framework bouwden, testten acht LLM's op 228 codescenario's voor IEEE S&P 2024. Ze melden dat de modellen "niet-deterministische antwoorden geven", en dat PaLM2 en GPT-4 "louter door het wijzigen van functie- of variabelenamen, of door het toevoegen van bibliotheekfuncties aan de broncode" in 26% en 17% van de gevallen onjuiste antwoorden gaven.

Voorbeeld. Twee engineers vragen dezelfde assistent of een service blootstaat aan een nieuwe advisory. De een krijgt "nee", de ander "mogelijk, controleer de transitieve boom." Geen van beide antwoorden is een vastlegging, en geen van beide kan zes maanden later voor een auditor worden gereproduceerd.

Een vastgelegde build heeft dit probleem niet, omdat er niets wordt afgeleid. CRACI observeert de pakketten die een job tijdens de uitvoering uit pakketbronnen ophaalt, en de SBOM is een vastlegging van die observatie.

2. Controleerbaarheid: laat zien hoe u het weet

Audits draaien om de vraag "hoe weet u dat?" Een model kan een vloeiend antwoord geven, maar zijn uitleg is geen bewijs. De evaluatie van SecLLMHolmes stelde vast dat LLM's "onjuiste en niet-getrouwe redeneringen" geven over de kwetsbaarheden die ze beoordelen, zodat een correct oordeel vergezeld kan gaan van een uitleg die geen stand houdt.

De standaarden bewegen zich naar vastleggingen die hun eigen oorsprong verklaren. De SBOM-minimumelementen van 2026, gepubliceerd door CISA met de NSA, de FBI en internationale partners, voegen een SBOM Tool Name, een SBOM Tool Version en een SBOM Generation Context toe, die aangeeft of de SBOM "vóór de build", tijdens de "build" of "na de build" is gemaakt. Hetzelfde document waarschuwt dat "organisaties fouten, of die nu voortkomen uit de werkwijze van de SBOM-auteur of uit de keuze voor ontoereikende tools, kunnen meewegen in beslissingen over organisatorisch risicobeheer."

Voorbeeld. Een vragenlijst van een klant vraagt hoe uw SBOM tot stand is gekomen. "Een assistent heeft de repository gelezen en hem geschreven" geeft een generatiecontext, maar niet een die een reviewer kan controleren. "Hij is tijdens de releasebuild in de CI-runner vastgelegd, en de volledigheidsstatus van de job is Complete" kan de reviewer wel verifiëren aan de hand van de build.

3. Volledigheid: u kunt niet melden wat u nooit hebt gezien

Een model redeneert over wat het te zien krijgt. Als de bestanden die het leest de software niet beschrijven, doet het antwoord dat ook niet, en niets in de uitvoer zegt dat. De richtlijn van CISA uit 2026 legt de lat bij de beslissing van de ontvanger: die "moet kunnen concluderen dat een nieuw gemelde kwetsbaarheid hem niet treft als de SBOM het component niet vermeldt." Dat werkt alleen als ontbreken in de lijst betekent dat het ook in de build ontbreekt.

Voorbeeld. De repository anthropics/claude-code heeft bij v2.1.259 geen enkel afhankelijkheidsmanifest of lockfile. Het gepubliceerde npm-pakket declareert nul runtime-afhankelijkheden en omhult een voorgecompileerde native binary. Elke tool die de repository leest, AI of niet, heeft vrijwel niets om te vermelden, terwijl het programma dat draait een gecompileerde binary is.

Voorbeeld. AI-codeertools kunnen het gat ook zelf veroorzaken. GitHub waarschuwt dat Copilot Autofix "verzonnen afhankelijkheden kan voorstellen die onder statistisch waarschijnlijke namen zijn gepubliceerd." Een studie op USENIX Security 2025 van 576.000 gegenereerde codevoorbeelden van 16 modellen vond een gemiddeld aandeel gehallucineerde pakketten van minstens 5,2% bij commerciële modellen en 21,7% bij open-sourcemodellen, met 205.474 unieke gehallucineerde pakketnamen.

Deterministisch is noodzakelijk, niet voldoende

Een eerlijke versie van dit argument moet ook het volgende punt bevatten. SBOM-generatoren zijn deterministisch, en toch zijn ze het onderling oneens. Gericht op dezelfde commit van expressjs/express kunnen ze verschillende lijsten opleveren, omdat elk zelf bepaalt wat als component telt en welke bestanden te vertrouwen zijn. De repository commit geen lockfile, dus een tool die afhankelijkheden uit een lockfile haalt, heeft helemaal geen van de package.json-afhankelijkheden om te melden.

Een deterministische scanner reproduceert elke keer hetzelfde onvolledige antwoord. Herhaalbaarheid is noodzakelijk, maar wat het gat dicht, is observatie: vastleggen wat de build daadwerkelijk heeft opgehaald, en aangeven wanneer de vastlegging onvolledig is. CRACI markeert elke job en cache als Complete, Complete with connections, Incomplete, Unavailable of Not recorded.

Een uitgewerkt voorbeeld: een nieuwe advisory afbakenen

Een hypothetisch geval: er wordt een advisory gepubliceerd voor een versie van een veelgebruikt npm-pakket. Volgens de Cyber Resilience Act hebben fabrikanten 24 uur om een actief misbruikte kwetsbaarheid bij ENISA te melden, dus de afbakening moet snel en juist zijn.

De route met AI eerst

U vraagt een assistent uw repositories te controleren. Die leest manifests en lockfiles, en misschien een Dockerfile. Hij ziet geen pakketten die uit een CI-cache worden teruggezet, tools die een buildstap downloadt, of versies die bij de installatie worden bepaald in een repository zonder lockfile. Twee keer gevraagd, kan hij verschillend antwoorden. Zijn samenvatting is nuttig, maar daarop kunt u uw melding niet ondertekenen.

De route met de vastlegging eerst

CRACI bundelt kwetsbaarheden over builds en repositories heen, afgebakend tot de standaardbranch op organisatieniveau, en beoordeelt gemonitorde SBOM's opnieuw zodra er nieuwe kwetsbaarheden verschijnen. De API levert voor elke build de CycloneDX-SBOM, de netwerktrace en de herkomst. Als de vastlegging van een job onvolledig is, vertelt de volledigheidsstatus u waar u handmatig moet kijken. U kunt een model nog steeds vragen het resultaat samen te vatten. Het vat dan een vastlegging samen, in plaats van er een te genereren.

Met de vastlegging is de vraag "welke releases bevatten dit pakket?" een kwestie van opzoeken, geen onderzoek.

Naast elkaar

Zet elke tool in waar hij sterk is

Gebruik AI waar oordeel helpt en een mens de uitvoer controleert: codereview, het uitleggen van een bevinding, het opstellen van een fix. Gebruik deterministische buildvastleggingen waar de uitvoer moet worden gereproduceerd, gecontroleerd of als volledig moet kunnen gelden: SBOM's, herkomst en afbakening van incidenten. CRACI automatiseert een aanzienlijk deel van dat bewijs over de softwareketen binnen een breder CRA-proces. Op zichzelf maakt het u niet compliant.

Lees hoe de vastlegging tot stand komt in SBOM-generatie tijdens de build, of begin met wat de CRA vraagt.