Dove gli strumenti di sicurezza IA non bastano, e che cosa coprono le evidenze di build deterministiche

La tesi, in termini precisi

Questa non è una presa di posizione contro l'IA nella sicurezza. I modelli sono bravi a leggere il codice, spiegare un risultato e suggerire una correzione, e i team che li usano bene vanno più veloci. La tesi è più circoscritta: per i record che devono reggere nel tempo, un modello probabilistico è la fonte primaria sbagliata. Questo vale per la SBOM che consegna a un'autorità di regolamentazione, per la provenance dell'artefatto che ha rilasciato e per la risposta alla domanda "eravamo coinvolti?"

Tre proprietà decidono se un record regge. Ciascuna delle sezioni seguenti ne affronta una, con esempi e fonti.

1. Riproducibilità: chiedere due volte, ottenere la stessa risposta

Un record di sicurezza è utile solo se qualcun altro può ottenere la stessa risposta dallo stesso input. I modelli linguistici non lo promettono, e i vendor lo dicono.

• La documentazione di Anthropic: "Anche con la temperatura impostata a 0, i risultati non saranno completamente deterministici e input identici possono produrre output diversi tra una chiamata API e l'altra."
• GitHub su Copilot Autofix: "Anche con lo stesso avviso e lo stesso codice, potrebbe non riuscire a produrre un suggerimento valido, oppure il suggerimento potrebbe variare da un tentativo all'altro."
• I ricercatori che hanno sviluppato il framework SecLLMHolmes hanno testato otto LLM su 228 scenari di codice per IEEE S&P 2024. Riferiscono che i modelli "forniscono risposte non deterministiche" e che "semplicemente cambiando i nomi di funzioni o variabili, o aggiungendo funzioni di libreria nel codice sorgente", PaLM2 e GPT-4 hanno dato risposte errate rispettivamente nel 26% e nel 17% dei casi.

Esempio. Due ingegneri chiedono allo stesso assistente se un servizio è esposto a un nuovo advisory. Uno riceve "no", l'altro "forse, controlli l'albero transitivo". Nessuna delle due risposte è un record, e nessuna può essere riprodotta per un auditor sei mesi dopo.

Una build registrata non ha questo problema, perché non c'è nulla da dedurre. CRACI osserva i pacchetti che un job scarica dalle sorgenti dei pacchetti durante l'esecuzione, e la SBOM è il record di quell'osservazione.

2. Verificabilità: mostrare come lo si sa

Gli audit ruotano attorno alla domanda "come lo sa?" Un modello può dare una risposta scorrevole, ma la sua spiegazione non è un'evidenza. La valutazione SecLLMHolmes ha rilevato che gli LLM forniscono "ragionamenti errati e non fedeli" sulle vulnerabilità che valutano, quindi un verdetto corretto può accompagnarsi a una spiegazione che non regge.

Gli standard si stanno orientando verso record che spiegano la propria origine. Gli elementi minimi SBOM 2026, pubblicati dalla CISA insieme a NSA, FBI e partner internazionali, aggiungono SBOM Tool Name, SBOM Tool Version e un SBOM Generation Context che indica se la SBOM è stata prodotta "prima della build", durante la "build" o "dopo la build". Lo stesso documento avverte che "le organizzazioni possono considerare gli errori, che derivino dalle pratiche dell'autore della SBOM o dalla scelta di strumenti inadeguati, nelle decisioni di gestione del rischio".

Esempio. Il questionario di un cliente chiede come è stata prodotta la Sua SBOM. "Un assistente ha letto il repository e l'ha scritta" fornisce un contesto di generazione, ma non uno che un revisore possa controllare. "È stata registrata all'interno del runner CI durante la build di rilascio, e lo stato di completezza del job è Complete" è qualcosa che il revisore può verificare rispetto alla build.

3. Completezza: non si può riportare ciò che non si è mai visto

Un modello ragiona su ciò che gli viene mostrato. Se i file che legge non descrivono il software, nemmeno la risposta lo farà, e nulla nell'output lo segnala. Le linee guida 2026 della CISA fissano l'asticella sulla decisione del destinatario: questi "dovrebbe poter concludere che una vulnerabilità appena segnalata non lo riguarda se la SBOM non elenca il componente". Funziona solo se l'assenza dall'elenco significa assenza dalla build.

Esempio. Il repository anthropics/claude-code alla v2.1.259 non ha alcun manifest di dipendenze né lockfile di alcun tipo. Il pacchetto npm pubblicato dichiara zero dipendenze di runtime e incapsula un binario nativo precompilato. Qualsiasi strumento che legga il repository, IA o meno, non ha quasi nulla da elencare, mentre il programma che viene eseguito è un binario compilato.

Esempio. Anche gli strumenti di programmazione IA possono creare essi stessi la lacuna. GitHub avverte che Copilot Autofix "potrebbe suggerire dipendenze inventate pubblicate con nomi statisticamente probabili". Uno studio di USENIX Security 2025 su 576.000 campioni di codice generati da 16 modelli ha rilevato un tasso medio di pacchetti inventati di almeno il 5,2% per i modelli commerciali e del 21,7% per i modelli open source, con 205.474 nomi univoci di pacchetti inventati.

Il determinismo è necessario, non sufficiente

Una versione onesta di questa tesi deve includere il punto successivo. I generatori di SBOM sono deterministici, eppure non concordano tra loro. Puntati sullo stesso commit di expressjs/express, possono restituire elenchi diversi, perché ognuno decide da sé che cosa conta come componente e di quali file fidarsi. Il repository non include alcun lockfile, quindi uno strumento che risolve le dipendenze da un lockfile non ha proprio nessuna delle dipendenze di package.json da riportare.

Uno scanner deterministico riproduce ogni volta la stessa risposta incompleta. La ripetibilità è necessaria, ma ciò che colma la lacuna è l'osservazione: registrare ciò che la build ha effettivamente scaricato e dichiarare quando il record è incompleto. CRACI contrassegna ogni job e ogni cache come Complete, Complete with connections, Incomplete, Unavailable o Not recorded.

Un esempio concreto: delimitare l'impatto di un nuovo advisory

Un caso ipotetico: viene pubblicato un advisory per una versione di un pacchetto npm molto diffuso. Ai sensi del Cyber Resilience Act, i fabbricanti hanno 24 ore per segnalare all'ENISA una vulnerabilità attivamente sfruttata, quindi la delimitazione dell'impatto deve essere rapida e corretta.

Il percorso che parte dall'IA

Lei chiede a un assistente di controllare i Suoi repository. L'assistente legge manifest e lockfile, e forse un Dockerfile. Non vede i pacchetti ripristinati da una cache CI, gli strumenti scaricati da un passaggio della build né le versioni risolte al momento dell'installazione in un repository senza lockfile. Interrogato due volte, può rispondere in modo diverso. Il suo riepilogo è utile, ma Lei non può firmare la Sua segnalazione sulla base di esso.

Il percorso che parte dal record

CRACI aggrega le vulnerabilità di tutte le build e di tutti i repository, limitate al branch predefinito a livello di organizzazione, e rivaluta le SBOM monitorate man mano che compaiono nuove vulnerabilità. L'API restituisce per ogni build la SBOM CycloneDX, la traccia di rete e la provenance. Se il record di un job è incompleto, il suo stato di completezza Le indica dove controllare a mano. Può comunque chiedere a un modello di riassumere il risultato. Starà riassumendo un record, non generandone uno.

Con il record, la domanda "quali release hanno distribuito questo pacchetto?" è una ricerca, non un'indagine.

Fianco a fianco

Usi ogni strumento dove rende di più

Usi l'IA dove il giudizio aiuta e una persona controlla l'output: code review, spiegazione di un risultato, bozza di una correzione. Usi i record di build deterministici dove l'output deve essere riprodotto, verificato o considerato completo: SBOM, provenance e delimitazione degli incidenti. CRACI automatizza una parte significativa di queste evidenze sulla supply chain all'interno di un processo CRA più ampio. Da solo non La rende conforme.

Scopra come viene prodotto il record nella generazione di SBOM in fase di build, oppure inizi da che cosa richiede il CRA.