I team security e compliance chiedono un software bill of materials, un SBOM, da anni, quasi sempre per rispondere a una domanda precisa dopo l'ultima vulnerabilità open source finita sui giornali: siamo esposti. È una domanda che esiste da prima degli agenti di coding. Non è sparita ora che una parte crescente dei commit di un repository arriva da una sessione lanciata da un agente, non da una persona che digita.
La sovrapposizione tra i due mondi non è un caso. Un SBOM è un inventario. Nel momento in cui parte di quell'inventario è stata scelta da un agente e non da uno sviluppatore, l'inventario da solo smette di bastare.
Cos'è un SBOM
Un SBOM è un elenco strutturato e leggibile in modo automatico di ogni componente e dipendenza dentro un software: librerie, versioni, licenze, e sempre più spesso i loro hash crittografici, così chi riceve il pacchetto può controllare che corrisponda a quanto dichiarato. I due formati dominanti, CycloneDX e SPDX, puntano allo stesso obiettivo da angolazioni leggermente diverse, e gran parte degli strumenti di build oggi può generarne uno o l'altro in automatico dentro una pipeline.
Le linee guida CISA 2026 sugli elementi minimi, che sostituiscono la base NTIA del 2021, sono quanto di più simile esista a una definizione condivisa di cosa deve contenere un SBOM utilizzabile. È anche, ed è degno di nota, la prima versione di quelle linee guida a nominare i sistemi AI come categoria di prodotto distinta, invece di farli rientrare per default dentro "software".
Cosa già garantisce
Un buon SBOM risponde bene a un set ristretto di domande: cosa c'è in questa build, quale versione, sotto quale licenza, e se qualcosa corrisponde a una CVE nota. È utile davvero. È il motivo per cui i team di procurement lo chiedono prima di chiudere un contratto con un fornitore, e il motivo per cui la revisione CISA 2026 aggiunge campi come l'algoritmo di hash del componente e il contesto di generazione dell'SBOM, oltre alla base originale di componente e versione: l'obiettivo è rendere il documento verificabile, non solo presente.
Gli strumenti di software composition analysis si appoggiano esattamente a questo inventario per segnalare in automatico le dipendenze con vulnerabilità note, ed è per questo che "SCA" e "SBOM" compaiono insieme nella maggior parte delle conversazioni di procurement. Nessuno dei due, da solo, dice qualcosa su come è stato scritto il codice attorno a quelle dipendenze.
Cosa non copre quando il codice lo scrive un agente
Un SBOM descrive cosa è finito in una build, nel momento in cui la build è stata eseguita. Non descrive il percorso decisionale che ci è arrivato: quale prompt o task ha prodotto un determinato file, quali vincoli o contesto sono stati dati all'agente, se un umano ha revisionato il diff prima che venisse unito, o perché è stata scelta una libreria invece di un'equivalente. Non è un limite di un singolo strumento SBOM. È fuori dal perimetro che il formato è stato pensato per coprire fin dall'inizio, che il codice lo abbia scritto una persona o una sessione.
Questa distinzione contava meno quando la risposta a "perché è qui" era quasi sempre una persona a cui si poteva chiedere. Quando un agente esegue un loop, pianifica una modifica, edita file e fa commit, la sessione che ha preso quelle decisioni si chiude nel momento in cui il task finisce. L'SBOM elenca cosa quella sessione ha prodotto. Non dice nulla sulla sessione in sé.
Perché anche il codice generato dall'AI ha bisogno di provenienza
È esattamente la direzione presa dai regolatori nel 2026. Oltre ad aggiungere i campi su hash e strumento, CISA ha pubblicato una risorsa dedicata ai sistemi AI, costruita con i partner G7, che chiede la documentazione di modelli, dataset, fornitori e dipendenze dietro un sistema AI, non solo dei suoi componenti a livello di codice. La logica è la stessa che aveva spinto il primo SBOM: non si può gestire il rischio di supply chain in qualcosa che non si riesce a inventariare, e "il codice" non è più l'unica cosa nella supply chain che vale la pena inventariare, ora che un agente, non solo una libreria, sta a monte di quello che è stato consegnato.
Una funzione generata dall'AI, introdotta tramite una sessione agentica, cade esattamente nello stesso vuoto. La dipendenza che porta con sé comparirà correttamente nel prossimo SBOM. Il motivo per cui esiste, e se qualcuno l'ha approvata prima del rilascio, no.
SBOM, SLSA e attestazione della consegna
Qui l'SBOM incontra un secondo standard, complementare: SLSA (Supply-chain Levels for Software Artifacts), che valuta quanto è affidabile il processo di build in sé, non cosa c'è dentro l'artefatto. Ai livelli più alti di SLSA, la provenienza è firmata da una piattaforma di build irrigidita ed espressa come attestazione in-toto: una dichiarazione verificabile che un builder specifico ha prodotto un artefatto specifico, a partire da input specifici, seguendo una ricetta specifica. Dove l'SBOM risponde a "cosa c'è qui dentro", la provenienza SLSA risponde a "come è stato costruito davvero questo artefatto, e posso fidarmi della pipeline che l'ha costruito".
Sono entrambi progressi reali. Nessuno dei due risponde alla domanda che una software house si sente fare davvero quando un cliente contesta una consegna: non solo cosa c'è nella build e come è stata assemblata, ma chi ha autorizzato il lavoro, cosa è stato chiesto all'agente di fare, e chi ha revisionato il risultato prima che uscisse. È il livello sopra SBOM e SLSA che gli strumenti di oggi lasciano ancora scoperto: quello che tiene insieme intento, esecuzione e firma umana come un'unica catena verificabile, la stessa linea dalla richiesta al production-ready trattata altrove su questo blog quando la domanda è cosa resta di un agente quando la sessione finisce.
Un SBOM è necessario. Non è mai stato pensato per rispondere a quella domanda, e ancora non lo fa.