Gli strumenti di sicurezza IA leggono il Suo codice. Qualcosa deve comunque registrare la build.

Probabilmente il Suo team sta già aggiungendo l'IA alla sicurezza

Oggi la maggior parte dei team di sviluppo ha almeno uno strumento IA nel ciclo di sicurezza. Un modello revisiona le pull request. Un altro suggerisce correzioni per gli avvisi dell'analisi statica. Un terzo smista i risultati degli scanner tra "da guardare" e "probabilmente rumore". Questi strumenti fanno risparmiare davvero tempo, e nulla in questa pagina li mette in discussione.

La domanda utile è quali compiti debbano svolgere e quali compiti richiedano invece un record che risulti identico ogni volta. La domanda complementare è che cosa leggono i Suoi strumenti IA quando prendono una decisione sulle Sue dipendenze.

Che cosa fanno bene gli strumenti di sicurezza IA

• Code review con l'IA. GitHub Copilot code review lascia commenti in linguaggio naturale e suggerimenti di codice sulle pull request, e può seguire istruzioni specifiche del repository. È bravo nel lavoro di lettura che un revisore oberato salta.
• Correzioni con l'IA. GitHub Copilot Autofix "genera automaticamente suggerimenti di modifica del codice per gli avvisi CodeQL rilevati nelle pull request e nel branch predefinito". Lo sviluppatore riceve una patch proposta accanto all'avviso invece di un link a una pagina CWE.
• Triage con l'IA. Le funzionalità IA di Semgrep eseguono l'autotriage dei risultati di Semgrep Code e suggeriscono correzioni. Semgrep dichiara che il suo filtro del rumore è "accurato oltre il 95% nel classificare come falsi positivi i risultati di Semgrep Code".

Noti lo schema negli ultimi due casi. Copilot Autofix lavora sugli avvisi di CodeQL. Il triage di Semgrep lavora sui risultati del motore a regole di Semgrep. L'IA aggiunge una valutazione a un output deterministico. Non produce essa stessa i risultati di partenza.

Che cosa dicono i vendor sui limiti

Le dichiarazioni più chiare su dove si fermano gli strumenti IA vengono dai vendor stessi, il che va a loro merito.

• Sulla code review, GitHub scrive che "Copilot potrebbe non individuare tutti i problemi presenti nel codice" e che "presenta un rischio di allucinazione", segnalando problemi che non esistono.
• Su Autofix, GitHub scrive che "usa un modello generativo non deterministico. 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."
• Sempre su Autofix: "Il sistema non sa quali versioni delle dipendenze siano supportate o sicure, e potrebbe suggerire dipendenze inventate pubblicate con nomi statisticamente probabili."

Nulla di tutto ciò rende questi strumenti meno utili. Ne definisce il compito: producono suggerimenti che una persona deve verificare. È un compito diverso dal produrre il record con cui quella persona li verifica.

Due livelli, due compiti

CRACI si colloca nel livello del record. Sostituisce il runner di GitHub Actions (Lei cambia runs-on in craci) e, durante l'esecuzione del job, un proxy che riconosce i pacchetti osserva il traffico della build verso le sorgenti dei pacchetti. Il risultato è una SBOM di ciò che il job ha effettivamente scaricato, uno stato di completezza per ogni job e ogni cache e una traccia di rete. L'API restituisce SBOM, tracce di rete e provenance.

Dove serve una visibilità deterministica

"Siamo coinvolti?"

Quando arriva un nuovo advisory, la prima domanda è se una qualsiasi delle Sue build abbia incluso la versione interessata. Gli elementi minimi SBOM 2026 della CISA formulano il requisito senza giri di parole: chi riceve una SBOM "dovrebbe poter concludere che una vulnerabilità appena segnalata non lo riguarda se la SBOM non elenca il componente". Questa conclusione regge solo se l'elenco è completo. Un modello può aiutarLa a leggere la risposta. Non dovrebbe essere ciò che decide che cosa c'era nella build.

CRACI aggrega le vulnerabilità di tutte le build e di tutti i repository e rivaluta le SBOM monitorate man mano che vengono pubblicate nuove vulnerabilità, così la risposta viene da ciò che è stato registrato.

Dipendenze aggiunte da un'IA

Gli assistenti di programmazione IA aggiungono dipendenze, e la ricerca mostra che a volte citano pacchetti che non esistono. Uno studio presentato a USENIX Security 2025 ha generato 576.000 campioni di codice con 16 modelli e ha rilevato che la quota media di pacchetti inventati era almeno del 5,2% per i modelli commerciali e del 21,7% per i modelli open source. Un nome che oggi non esiste può essere registrato domani. Chiunque o qualunque cosa abbia aggiunto una dipendenza, CRACI registra il pacchetto che la build ha effettivamente scaricato, e le policy di egress di rete possono limitare un job alle sorgenti dei pacchetti che Lei approva.

Audit e domande dei clienti

Un auditor o il team di sicurezza di un cliente Le chiederà come fa a sapere che cosa è stato rilasciato. "Lo ha detto il modello" è una risposta debole. "Ecco la SBOM registrata durante la build di rilascio, il suo stato di completezza e la traccia di rete di quel job" è una risposta solida. Le SBOM si esportano in CycloneDX o SPDX, vulnerabilità incluse, e l'API restituisce SBOM, tracce di rete e provenance.

Risposte ripetibili

Alcune domande richiedono la stessa risposta, chiunque la ponga e in qualunque momento. Quali pacchetti ha scaricato il rilascio di martedì scorso? Un modello generativo può formulare bene la risposta ma, per ammissione dei suoi stessi vendor, può formularla in modo diverso ogni volta. Una build registrata dà una sola risposta.

Come si combinano i due livelli

Lo schema che funziona è quello che Copilot Autofix e Semgrep usano già: dati deterministici alla base, giudizio dell'IA sopra.

1. Lasci che la code review e le correzioni con l'IA lavorino sulle pull request, con una persona che approva ogni modifica.
2. Lasci che CRACI registri ciò che ogni build ha scaricato e dichiari se quel record è completo.
3. Quando desidera l'aiuto dell'IA sul rischio delle dipendenze, fornisca al modello la SBOM registrata. La REST API pubblica di CRACI restituisce la SBOM in CycloneDX, la traccia di rete del job e la provenance dell'artefatto.
4. Conservi come evidenza la SBOM registrata, non il riepilogo che ne fa il modello.

Se il Suo team scrive gran parte del codice con assistenti IA, la nostra pagina sulla sicurezza dello sviluppo con l'IA tratta questa situazione, e la generazione di SBOM in fase di build spiega come viene prodotto il record.