Una SBOM generata dall'IA è un'ipotesi sulla Sua build. Le autorità chiedono un record.

Perché i team ci provano

L'attrattiva è reale. Si incolla un repository o un lockfile in un assistente di programmazione, si chiede un CycloneDX, e in pochi secondi torna un documento ben formato. Può persino compilare campi che gli scanner lasciano di solito vuoti. L'esempio tipico è il campo supplier: la maggior parte dei generatori non ha una fonte per questo dato, quindi resta vuoto. Un modello a cui si chiede un documento completo può scrivere qualcosa in ogni campo.

Quest'ultimo punto è il problema in miniatura. Uno scanner che non conosce il supplier lascia il campo vuoto. Un modello che non lo conosce può comunque produrre una risposta plausibile. Il documento sembra più completo ed è meno affidabile.

Che cosa vede davvero il modello

Un modello che genera una SBOM lavora sul testo che ha davanti: manifest, lockfile, magari un Dockerfile. Non osserva la build. Quindi non può vedere:

• quali versioni ha risolto il package manager quando un repository non include alcun lockfile,
• i pacchetti ripristinati da una cache CI,
• strumenti, pacchetti del sistema operativo e binari che uno step di build scarica direttamente,
• che cosa è entrato in un binario compilato distribuito insieme a un manifest quasi vuoto.

Due repository mostrano quanto possano essere scarni i file. expressjs/express 5.2.1 non include alcun lockfile, quindi il suo package.json elenca le dipendenze come intervalli di versioni e le versioni effettive vengono decise al momento dell'installazione. Il repository anthropics/claude-code alla v2.1.259 non ha alcun manifest di dipendenze né lockfile, e il suo pacchetto npm pubblicato dichiara zero dipendenze di runtime pur includendo un binario nativo precompilato. Uno scanner deterministico puntato su quel repository non ha nulla da leggere che descriva il binario. Un modello che riceve gli stessi file ha la stessa mancanza di informazioni, e più libertà di colmare la lacuna.

L'allucinazione è un tipo di errore documentato

I modelli linguistici citano pacchetti che non esistono. Il caso meglio misurato riguarda la generazione di codice più che la scrittura di SBOM, ma l'errore che mette in luce vale altrettanto per un elenco di componenti. Uno studio di USENIX Security 2025 ha generato 576.000 campioni di codice con 16 modelli e 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 unici di pacchetti inventati. La stessa documentazione di GitHub per Copilot Autofix avverte che lo strumento può suggerire dipendenze inventate, pubblicate con nomi statisticamente probabili.

I modelli inoltre non danno due volte la stessa risposta. La documentazione di Anthropic afferma che, anche con la temperatura impostata a 0, i risultati non saranno del tutto deterministici e input identici possono produrre output diversi tra una chiamata API e l'altra. Due SBOM generate dallo stesso commit possono differire, e nessuna delle due dice quale sia quella giusta.

In una SBOM, una voce inventata non è un innocuo refuso. Un pacchetto che non esiste, o la versione sbagliata di uno che esiste, indirizza la ricerca delle vulnerabilità nel posto sbagliato, e il risultato torna sicuro di sé e sbagliato.

Che cosa si aspettano gli standard da una SBOM

Elementi minimi NTIA (2021)

La baseline NTIA ha definito sette campi di dati: nome del supplier, nome del componente, versione del componente, altri identificatori univoci, relazione di dipendenza, autore dei dati SBOM e timestamp. Li ha affiancati al supporto per l'automazione e a un insieme di pratiche e processi. Ogni campo descrive un fatto sul software, non un'opinione su di esso.

Elementi minimi CISA 2026

Il 29 luglio 2026, CISA, NSA, FBI e partner internazionali hanno pubblicato elementi minimi aggiornati che sostituiscono la baseline del 2021. Diverse aggiunte sono difficili da soddisfare senza osservare la build:

• SBOM Generation Context: "the relative software lifecycle phase and data available at the time the SBOM author generated the SBOM", con "before build", "build" e "after build" come esempi. Un modello che legge un repository si trova, al massimo, in "before build".
• Component Hash Value: "the output generated from applying a cryptographic hash algorithm to an executable component artifact". Se l'autore non dispone dell'artefatto, "the SBOM author should indicate the value is unknown". Un modello che non ha mai toccato l'artefatto non può produrre un hash, solo un testo che gli somiglia.
• SBOM Tool Name and Version: lo strumento usato per generare la SBOM deve essere indicato.
• Coverage: "An SBOM should include information for all components that make up the target software, including transitive dependencies. There is no minimum depth."
• Identificazione esplicita delle informazioni ignote: l'autore "should explicitly state whether the information is unknown". Un valore inventato è l'esatto contrario.

Il Cyber Resilience Act dell'UE

Il CRA fa della SBOM un obbligo di legge per i fabbricanti di prodotti con elementi digitali. L'allegato I, parte II, impone loro di individuare e documentare le vulnerabilità e i componenti contenuti nei prodotti con elementi digitali, anche redigendo una distinta base del software in un formato di uso comune e leggibile da dispositivo automatico, che comprenda almeno le dipendenze di primo livello dei prodotti. L'allegato VII colloca la SBOM nella documentazione tecnica, e un'autorità di vigilanza del mercato può richiederla per verificare la conformità ai requisiti essenziali.

Nessuno di questi testi vieta gli strumenti di IA. Ciò che chiedono sono dati che descrivano il prodotto reale e dichiarazioni oneste su ciò che è ignoto. Una SBOM scritta per deduzione fatica su entrambi i fronti.

Come CRACI produce la SBOM

CRACI esegue i Suoi job GitHub Actions sui propri runner. Lei cambia runs-on in craci, e le esecuzioni continuano a comparire in GitHub. Durante l'esecuzione del job, un proxy che riconosce i pacchetti osserva il traffico verso le sorgenti di pacchetti, quindi la SBOM registra ciò che la build ha effettivamente scaricato, comprese le dipendenze transitive. Le evidenze sulle dipendenze viaggiano con le cache CI, così un pacchetto ripristinato da una cache resta nel record.

• Ecosistemi: sorgenti npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, oltre ai preset di download.
• Completezza: ogni job e cache è contrassegnato come Complete, Complete with connections, Incomplete, Unavailable o Not recorded, quindi le informazioni ignote vengono dichiarate anziché colmate.
• Formati: CycloneDX e SPDX, con i metadati delle licenze dichiarate inclusi nell'esportazione.
• Provenance: l'API restituisce SBOM, tracce di rete e provenance.

CRACI automatizza una parte significativa della visibilità e delle evidenze sulla supply chain di cui ha bisogno un più ampio processo di conformità al CRA. Da solo non rende conforme un prodotto. La generazione di SBOM in fase di build approfondisce i dettagli, e la nostra panoramica sul CRA ne illustra le scadenze.

Dove l'IA aiuta davvero con le SBOM

Una volta ottenuta una SBOM registrata, un modello è bravo a lavorarci: riassumere quali componenti comportano rischi, spiegare un advisory in linguaggio semplice o preparare la documentazione relativa perché una persona la riveda. La regola è semplice. Lasci che sia la build a produrre il record, e che il modello lo legga.