Un SBOM dice quali componenti ci sono dentro un prodotto, non se siano stati verificati. Il progetto Horizon Europe RESCALE ha lavorato su un artefatto che prova entrambe le cose: il Trusted Bill of Materials.
Il deficit di fiducia nelle supply chain digitali
Da SolarWinds a Log4j, lo schema è sempre lo stesso: una singola dipendenza compromessa, annidata in profondità in un grafo di dipendenze transitive, si propaga a migliaia di sistemi a valle. Il software moderno viene assemblato a partire da centinaia di librerie open source, immagini firmware e componenti hardware forniti da terzi, ciascuno con un profilo di rischio opaco. La postura di sicurezza di un’organizzazione è solida solo quanto l’anello meno visibile della sua catena di fornitura, come mostrano le campagne che negli ultimi anni hanno preso di mira i registri pubblici npm e PyPI.
Eppure l’SBOM, di per sé, non è sufficiente rispetto ai requisiti di assurance che stanno entrando nei testi normativi. Elenca cosa c’è all’interno di un prodotto software, ma non dice se quei componenti siano stati testati, se le prove siano verificabili o se restino sicuri man mano che emergono nuove vulnerabilità. Questo scarto genera un deficit di fiducia: le organizzazioni possono risultare conformi agli obblighi di trasparenza senza disporre di prove crittograficamente verificabili della solidità della propria supply chain.
Il progetto RESCALE (Revolutionised Enhanced Supply Chain Automation with Limited Threats Exposure) affronta proprio questo deficit, trasformando trasparenza e assurance in un unico artefatto continuamente validato: il Trusted Bill of Materials (TBOM). Si tratta di un’azione di ricerca e innovazione finanziata dal programma Horizon Europe, con un costo complessivo di 4.998.250 euro, avviata il 1° ottobre 2023 e conclusa il 30 settembre 2026, coordinata dall’Athena Research Center di Atene con un consorzio misto di enti di ricerca e partner industriali.
Nota della redazione Il Trusted Bill of Materials descritto in questo articolo è un concetto sviluppato in ambito di ricerca dal progetto RESCALE, concluso il 30 settembre 2026. Non costituisce uno standard né uno strumento di conformità formalmente riconosciuto dalle autorità: gli obblighi in materia di distinta base del software restano quelli fissati dal Cyber Resilience Act e dalla direttiva NIS2. Le valutazioni sull’efficacia della piattaforma sono del consorzio di progetto e non sono state verificate in modo indipendente dalla redazione.
Il quadro normativo: CRA, NIS2 e il cambio di rotta statunitense
I regolatori hanno reagito con urgenza. Il Cyber Resilience Act (Regolamento UE 2024/2847), adottato nel 2024, obbliga i produttori di prodotti con elementi digitali a redigere e tenere aggiornata una distinta base del software in formato leggibile da dispositivo automatico, che copra almeno le dipendenze di primo livello del prodotto. La distinta non va pubblicata: va messa a disposizione delle autorità di vigilanza del mercato solo a seguito di una richiesta motivata.
I produttori devono inoltre garantire la gestione delle vulnerabilità per un periodo di assistenza di almeno cinque anni, o pari alla durata di utilizzo prevista se inferiore, come stabilito dall’articolo 13, paragrafo 8. Le obbligazioni principali del regolamento decorrono dall’11 dicembre 2027. L’obbligo di segnalazione è invece già operativo: dall’11 settembre 2026 i fabbricanti devono notificare le vulnerabilità sfruttate attivamente e gli incidenti gravi, con un preallarme entro 24 ore e una notifica completa entro 72, attraverso la Single Reporting Platform gestita da ENISA.
La direttiva NIS2 richiede ai soggetti essenziali e importanti di adottare misure di gestione del rischio legate ai fornitori. In Italia il recepimento è avvenuto con il D.Lgs. 138/2024, che estende tali obblighi a una platea più ampia di operatori nazionali. Parallelamente, l’applicazione del CRA inciderà sui produttori italiani di dispositivi embedded e IoT, spingendoli ad adottare processi rigorosi di tracciabilità dei componenti.
Negli Stati Uniti la direzione è opposta. L’Executive Order 14028 del 2021 aveva introdotto requisiti SBOM per gli acquisti federali, ma l’EO 14306 e il memorandum OMB M-26-05 ne hanno smantellato l’impianto attuativo: il primo ha rimosso i meccanismi di attuazione, il secondo ha abrogato le direttive OMB M-22-18 e M-23-16. Attestazioni di sicurezza e distinte base restano oggi una scelta rimessa alla valutazione del rischio di ciascuna agenzia. In Europa, al contrario, trasparenza e responsabilità sulla catena di fornitura digitale stanno diventando obblighi di legge.
La metodologia: progettare il Trusted Bill of Materials
Il TBOM estende l’SBOM convenzionale, portandolo da inventario passivo a pacchetto di evidenze crittograficamente verificabili. Se un SBOM dichiara quali componenti esistono, un TBOM collega ciascun componente alla prova che sia stato valutato, che i risultati siano autentici e che lo stato della valutazione venga mantenuto nel tempo. Lo fa aggregando artefatti di assurance complementari.
Garanzie statiche e dinamiche della supply chain
L’SSCG (Static Supply Chain Guarantee) raccoglie i risultati dell’analisi statica, cioè l’esame del codice sorgente e dei binari senza eseguirli. Include risultati ottenuti tramite pattern matching, taint analysis e verifica della conformità a regole di sicurezza. L’SSCG viene generato dal produttore del componente durante la fase di build.
Il DSCG (Dynamic Supply Chain Guarantee) integra l’SSCG raccogliendo i risultati dei test dinamici: fuzzing, penetration test, individuazione di vulnerabilità a runtime e altre tecniche che richiedono l’esecuzione del software. In genere il DSCG viene generato da un consumer o da un valutatore indipendente.
Un aspetto cruciale è che sia l’SSCG sia il DSCG vengono firmati digitalmente prima dell’invio e sono conformi alla specifica CycloneDX. Questa aderenza allo standard non è un dettaglio: assicura che ogni artefatto dell’ecosistema TBOM sia interpretabile dalle macchine, interoperabile con gli strumenti esistenti e allineato ai requisiti di formato sempre più spesso imposti da regolatori e procedure di acquisto.
Fingerprinting hardware e HBOM
Il software è solo metà della supply chain. I sistemi embedded, i dispositivi IoT e le infrastrutture ad alte prestazioni dipendono da componenti hardware la cui identità e integrità vengono spesso date per scontate, ma raramente verificate. RESCALE affronta questo aspetto tramite l’HBOM (Hardware Bill of Materials) e l’HWF (Hardware Fingerprint).
L’HBOM elenca i componenti fisici di un assemblaggio hardware (chip, versioni del firmware, configurazioni della scheda) in un formato che rispecchia la struttura CycloneDX usata per il software. L’HWF fornisce un’identità crittografica dell’hardware, derivata da caratteristiche fisiche come le Physically Unclonable Functions (PUF) o da log di misurazione radicati nell’hardware. Prima che si possa generare un TBOM per un componente hardware, la piattaforma verifica che l’HBOM faccia esplicito riferimento al relativo HWF. Questo collegamento garantisce che l’identità hardware sia legata in modo crittografico e logico all’inventario hardware prima di qualsiasi elaborazione successiva legata alla fiducia.
Aggregazione nel TBOM
Una volta che SSCG, DSCG e, per l’hardware, HBOM e HWF sono stati generati, firmati e validati, il Trust Orchestrator (TrustOR) li aggrega nel TBOM. Nella sua implementazione attuale il TBOM funge da documento di collegamento: aggrega e referenzia i documenti fondazionali (SBOM, HBOM, SSCG, DSCG) come artefatti distinti, invece di inglobare tutti i dati in un’unica struttura monolitica.
Il TBOM include quindi i collegamenti all’SBOM o all’HBOM sottostante, i riferimenti alle vulnerabilità, i documenti SSCG e DSCG, i metadati di assurance e le prove dei test. Se per quel componente esiste già un TBOM attivo, la versione precedente viene deprecata e ne viene generata una nuova che incorpora tutti i DSCG accumulati. Il TBOM risultante viene a sua volta firmato digitalmente, registrato sul distributed ledger e aggiornato in modo continuo con informazioni sulle vulnerabilità tramite aggiornamenti asincroni del Bill of Vulnerabilities (BOV).
Il ciclo di vita del TBOM è modellato in modo esplicito, con stati che vanno dalla generazione dell’SSCG a quella del DSCG, dalla creazione del TBOM alla validazione, allo stato attivo e infine alla deprecazione. Ogni transizione di stato viene registrata e resta tracciabile, come documentato nella specifica della struttura del TBOM pubblicata dal progetto.
L’infrastruttura del trust: documenti off-chain e ancoraggi on-chain
Una scelta architetturale fondamentale di RESCALE è la separazione tra l’archiviazione dei documenti TBOM e l’ancoraggio della loro integrità sul ledger. Questo disegno ibrido risolve una tensione di fondo nell’uso della distributed ledger technology per l’assurance della supply chain: da un lato il bisogno di evidenze immutabili, dall’altro i limiti pratici della capacità on-chain e la necessità di mantenere il controllo sui documenti organizzativi.
Dallo storage distribuito al controllo organizzativo
I documenti TBOM possono essere voluminosi e contenere informazioni sensibili sull’assetto tecnico di un’organizzazione. Scriverli direttamente sul ledger sarebbe insostenibile sul piano dei costi e incompatibile con la riservatezza richiesta da fornitori e clienti.
La prima versione dell’infrastruttura prevedeva l’uso di IPFS (InterPlanetary File System) come strato di storage distribuito, con i relativi identificativi di contenuto registrati on-chain come riferimenti immutabili. IPFS è però una rete peer-to-peer in cui il contenuto, una volta pubblicato, resta recuperabile da qualsiasi nodo.
Un modello di accesso così aperto è incompatibile con il requisito di sovranità documentale, che esige che sia solo l’organizzazione proprietaria a decidere chi può leggere, modificare o revocare l’accesso ai propri TBOM. La scelta è stata quindi abbandonata, come si può ricostruire confrontando la prima versione del meccanismo di sicurezza e fiducia del TBOM con l’assetto finale.
Oggi lo storage dei documenti resta interamente sotto il controllo dell’organizzazione, senza vincoli a una specifica tecnologia di memorizzazione, mentre sul ledger permissioned vengono ancorate soltanto evidenze di integrità compatte.
Cosa finisce on-chain
Sul ledger vengono registrate evidenze di integrità compatte: hash crittografici dei documenti TBOM, eventi di transizione del ciclo di vita (creazione, deprecazione) e, dove rilevante, relazioni strutturali tra hash che rappresentano dipendenze o filiazioni. Questi record fungono da ancore antimanomissione: qualsiasi modifica a un documento TBOM off-chain produrrebbe un hash diverso, immediatamente rilevabile rispetto al record on-chain.
L’infrastruttura è realizzata su Hyperledger Besu con consenso QBFT, acronimo di Quorum Byzantine Fault Tolerant. Rispetto all’impostazione iniziale del progetto, che nei materiali di obiettivo faceva riferimento a una public blockchain e al paradigma Blockchain 2.0, la scelta definitiva è una rete public permissioned: la trasparenza e la verificabilità delle evidenze restano centrali, ma la partecipazione alla validazione e le operazioni di scrittura sono riservate a nodi e partner autorizzati.
Questa evoluzione consente di mantenere i benefici propri dell’ancoraggio blockchain, cioè immutabilità, audit trail e consenso distribuito, adattandoli ai requisiti tipici di una supply chain industriale, dove servono controllo degli accessi, riservatezza e conformità normativa. I validatori noti concordano, mediante QBFT, sulla sequenza e sul contenuto delle evidenze di integrità, con finalità immediata dei blocchi confermati. La piattaforma supporta inoltre autenticazione JSON-RPC opzionale e TLS al confine del ledger, così da proteggere e limitare l’accesso all’interfaccia RPC del nodo.
Canonicalizzazione deterministica e Certification Authority esterne
Alla base della garanzia di integrità c’è una sfida sottile ma essenziale: due documenti JSON semanticamente identici devono produrre lo stesso hash, anche se differiscono nell’ordine delle chiavi o negli spazi bianchi. RESCALE tratta la canonicalizzazione deterministica del JSON come una precondizione sia per l’hashing sia per la firma, e implementa la RFC 8785 (JSON Canonicalization Scheme) per normalizzare ricorsivamente le strutture JSON.
Per la firma digitale la piattaforma integra una Certification Authority esterna tramite mutual TLS con certificati client PKCS#12, secondo l’architettura di alto livello definita dal progetto. La CA calcola un digest SHA-256 del documento canonicalizzato, lo invia all’endpoint remoto di firma e riceve in risposta una busta di firma leggibile dalla macchina. In questo modo la responsabilità giuridica viene ancorata alle firme crittografiche: i certificati sono emessi da un’autorità riconosciuta e offrono garanzie di non ripudio che gli artefatti autofirmati non possono dare.
Assurance continua e Supply Chain Graph
Un TBOM generato in fase di build è soltanto una fotografia istantanea. Nuove vulnerabilità vengono rese note ogni giorno e la postura di sicurezza di ogni componente cambia continuamente. RESCALE affronta il problema tramite il componente Security Assurance, che confronta i componenti registrati nel TBOM con una copia localizzata del National Vulnerability Database (NVD) e genera avvisi in tempo reale quando nuovi CVE colpiscono i componenti tracciati.
Il monitoraggio continuo, da solo, non basta. Le organizzazioni devono capire non solo se un componente è vulnerabile, ma anche quali sistemi propri dipendono da quel componente e fin dove si propaga la vulnerabilità.
Il Supply Chain Graph come modello di dipendenza e propagazione
È qui che entra in gioco il Supply Chain Graph. La Graph Application, appoggiata a un database a grafo Neo4j, costruisce e interroga un grafo di dipendenze che modella le relazioni tra componenti, vulnerabilità, numeri di serie e riferimenti esterni.
Gli standard BOM esistenti, come CycloneDX e SPDX, mappano le dipendenze, cioè registrano da quali componenti dipende un determinato BOM, ma non offrono nativamente un motore di interrogazione per le dipendenze inverse. Strumenti di terze parti come OWASP Dependency-Track interpretano questi formati e abilitano ricerche analoghe. Secondo il consorzio, l’elemento distintivo di RESCALE è l’integrazione nativa: il Supply Chain Graph dialoga direttamente con l’ecosistema dei TBOM e con gli artefatti di assurance continua, e calcola il raggio d’impatto all’interno della stessa piattaforma. Il progetto non ha pubblicato un confronto quantitativo con gli strumenti esistenti.
Il grafo acquisisce artefatti TBOM, SBOM, BOV, HBOM, DSCG e SSCG e ne normalizza identificativi e relazioni in entità collegate da relazioni semantiche. Una visita in ampiezza, avviata a partire da un identificatore fornito in input, procede a valle attraverso le radici BOM le cui dipendenze contengono quell’identificatore, e restituisce una vista stratificata delle dipendenze inverse, ordinata dal nodo iniziale ai livelli successivi dei componenti dipendenti.
Calcolare il raggio d’impatto
Quando viene resa nota una nuova vulnerabilità in una libreria a monte, i team di sicurezza possono usare l’endpoint di dipendenza inversa per calcolare il raggio d’impatto, cioè l’insieme degli SBOM a valle e dei relativi TBOM che dipendono transitivamente dal componente vulnerabile.
Ogni livello della risposta include le vulnerabilità collegate e il numero di serie del TBOM, il che consente di passare da un avviso di vulnerabilità a una vista verificabile di tutti i sistemi interessati. Quando una radice BOM dichiara una dipendenza per cui non esiste alcun BOM, viene creato un nodo segnaposto: in questo modo le lacune del dataset diventano visibili e l’espansione si arresta all’ultimo BOM risolvibile.
Allineamento normativo e standardizzazione
La metodologia RESCALE non è soltanto un esercizio tecnico: è allineata sul piano architetturale con la direzione normativa dell’Unione Europea e con gli sforzi di standardizzazione internazionali.
Allineamento con il Cyber Resilience Act e NIS2
Il CRA richiede ai produttori di dimostrare di aver implementato processi di gestione delle vulnerabilità e di poter fornire la distinta base dei propri prodotti. L’intento del regolamento, però, va oltre la semplice enumerazione: chiede che la gestione delle vulnerabilità sia continua, che gli aggiornamenti risolvano le vulnerabilità individuate e che le informazioni fornite agli utenti siano accurate e aggiornate. Un SBOM statico, generato una sola volta in fase di build e mai aggiornato, può rispettare formalmente l’obbligo di trasparenza, ma tradisce lo spirito dell’assurance continua. È la stessa distanza che separa la generazione di un SBOM dalla sua gestione operativa.
Il TBOM, al contrario, è progettato per evolvere. Il suo ciclo di vita include esplicitamente gli stati legati alle vulnerabilità, e il meccanismo asincrono di aggiornamento del BOV mantiene allineate le informazioni. L’ancoraggio on-chain delle transizioni fornisce una traccia di evidenze verificabile, che le autorità possono esaminare per accertare che un produttore abbia adempiuto ai propri obblighi non solo al momento della vendita, ma per l’intero periodo di assistenza obbligatoria.
Anche i requisiti NIS2 in materia di sicurezza della catena di fornitura impongono ai soggetti essenziali e importanti di gestire i rischi posti dai propri fornitori e dalla sicurezza dei prodotti e servizi che acquistano. La capacità del Supply Chain Graph di tracciare la propagazione delle vulnerabilità oltre i confini organizzativi risponde direttamente a questo obbligo.
Affidamento a standard aperti
Una scelta progettuale deliberata di RESCALE è l’adozione di CycloneDX come formato base per tutti gli artefatti (SBOM, HBOM, SSCG, DSCG e gli stessi TBOM), esteso per dar vita al concetto di TBOM. CycloneDX è uno standard aperto gestito da OWASP e ratificato come standard internazionale ECMA-424 attraverso il comitato tecnico TC54 di Ecma International, con ampia adozione industriale e un ecosistema di strumenti attivo.
La scelta garantisce che gli artefatti siano interoperabili con le piattaforme esistenti per la sicurezza della supply chain, come OWASP Dependency-Track, e che le organizzazioni possano integrare i TBOM nei propri flussi di lavoro senza restare vincolate a formati proprietari.
Il progetto ha inoltre condiviso i propri risultati con la comunità della standardizzazione, come documentato nel white paper RESCALE Contribution to Standardisation del 2025. Le attività si sono concentrate su ETSI TC CYBER, IETF SCITT e CEN-CENELEC JTC 13. Il progetto adotta CycloneDX come formato, ma non partecipa formalmente all’evoluzione della specifica in sede OWASP ed ECMA.
Integrazione CI/CD e co-progettazione hardware-software
Una metodologia che non può essere resa operativa è una metodologia che non verrà adottata. RESCALE è stato concepito come piattaforma nativa per il CI/CD, con i flussi di instaurazione della fiducia integrati direttamente nella pipeline di build e rilascio.
Rendere operativo il workflow TBOM
Il flusso software del TBOM si articola in cinque fasi automatizzate. Il produttore genera e invia SBOM e SSCG; TrustOR li valida; il consumer genera e invia il DSCG; TrustOR valida anche quest’ultimo. Nell’ultima fase il TBOM viene assemblato, firmato, registrato sul ledger e mappato tramite Security Assurance.
Gli strumenti di analisi containerizzati vengono recuperati da un registry Harbor, eseguiti sul codice target, e i loro output vengono firmati e inviati tramite le API della piattaforma. Le pipeline sono orchestrate da Jenkins, secondo quanto descritto nella prima versione del Trust Orchestrator.
La dimensione hardware
Il flusso TBOM per l’hardware rispecchia quello software, ma introduce validazioni specifiche. HBOM e HWF vengono generati e inviati insieme, e TrustOR impone una validazione esplicita del collegamento tra i due prima di consentire l’elaborazione a valle. Il DSCG hardware è soggetto a controlli aggiuntivi, tra cui la verifica che esista il numero di serie HBOM referenziato e che il collegamento con l’HWF sia già stato validato.
Questo approccio di co-progettazione, che tratta catena di fornitura hardware e software all’interno di un quadro unitario, è essenziale per i sistemi embedded e le infrastrutture critiche, dove un’immagine firmware compromessa o un chip contraffatto possono essere dannosi quanto una libreria software vulnerabile.
Verso un’assurance crittografica continua basata su evidenze
Il passaggio da SBOM statici a TBOM continuamente validati rappresenta un cambiamento strutturale nel modo in cui la fiducia viene costruita negli ecosistemi digitali. Collegando ogni componente a una prova crittografica, ancorando quella prova su un ledger permissioned e propagando le informazioni sulle vulnerabilità attraverso un grafo di dipendenze, RESCALE fornisce l’infrastruttura tecnica per passare da una conformità reattiva, fatta di caselle da spuntare, a un’assurance proattiva basata su evidenze.
Il quadro normativo si sta muovendo nella stessa direzione. CRA e NIS2 chiedono alle organizzazioni di dimostrare vigilanza continua, mantenere l’integrità delle proprie evidenze e comunicare l’impatto delle vulnerabilità oltre i confini della supply chain. La metodologia TBOM, l’architettura ibrida del ledger e il Supply Chain Graph rispondono a queste esigenze sul piano ingegneristico.
Resta molto lavoro da fare: integrazione completa con gli ambienti pilota, formalizzazione della custodia delle credenziali per chiavi blockchain e materiali PKCS#12, valutazione di meccanismi avanzati come le prove a conoscenza zero per la divulgazione selettiva. Le fondamenta architetturali, però, sono posate: sovranità dei documenti off-chain, ancoraggio dell’integrità on-chain, canonicalizzazione deterministica, firma supportata da CA esterne e propagazione delle vulnerabilità basata su grafi. Delineano un percorso coerente verso una catena di fornitura in cui ogni componente porta con sé evidenze verificabili e continuamente aggiornate del proprio stato di sicurezza.
Fonti:
- Regolamento (UE) 2024/2847 (Cyber Resilience Act), testo italiano: https://eur-lex.europa.eu/legal-content/IT/ALL/?uri=CELEX%3A32024R2847
- Commissione europea, obblighi di segnalazione CRA e Single Reporting Platform ENISA: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- Scheda del progetto RESCALE su CORDIS: https://cordis.europa.eu/project/id/101120962
- RESCALE, Contribution to Standardisation, white paper 2025: https://zenodo.org/records/17896135
- Sito del progetto RESCALE: https://rescale-project.eu/
- RFC 8785, JSON Canonicalization Scheme (JCS), IETF
Nota sulle fonti di progetto. I documenti citati nel testo sono deliverable del progetto RESCALE. Al 13 ottobre 2026 risultano pubblici sul portale CORDIS della Commissione europea la specifica della struttura del TBOM (D4.1), la prima versione del Trust Orchestrator (D5.1) e le prime versioni del meccanismo di sicurezza e fiducia del TBOM e dell’architettura di alto livello, tutti collegati nel corpo dell’articolo. Le versioni finali degli stessi documenti (D2.4, D2.6, D4.5 e D5.2), consegnate alla conclusione del progetto, non sono ancora disponibili sul portale: le informazioni che ne derivano sono fornite dagli autori e non sono al momento verificabili su fonte pubblica.
https://www.ictsecuritymagazine.com/articoli/trusted-bill-of-materials/
