04/09/2026
Per molti sarà "aramaico", ma da azienda di Progettazione Hardware e Software, ogni tanto ci tocca essere più tecnici del solito, soprattutto quando ci troviamo a 7 giorni dalla deadline CRA dell'11 settembre.
Si tratta infatti di un tema che sta tenendo occupati molti CTO industriali, ovvero: come si costruisce nel concreto una SBOM che superi un audit vero e proprio?
Il Cyber Resilience Act non nomina uno standard specifico. Chiede un formato "comunemente usato e machine-readable" che copra almeno le dipendenze di primo livello.
Sembra semplice. Non lo è affatto!
Ecco i 5 passi operativi che stiamo consolidando internamente e che condividiamo pubblicamente per chi sta partendo adesso:
1. Scegliere il formato: CycloneDX 1.6 come default.
CycloneDX (OWASP Foundation) è al 44% di adozione, SPDX (Linux Foundation) al 29% secondo ENISA. CycloneDX 1.6 copre anche VEX (Vulnerability Disclosure) e ML-BOM. SPDX 3.0.1 se il cliente finale lo richiede esplicitamente. Non improvvisate formati proprietari: non superano audit europei.
2. Scegliere il tool: Syft per artefatti generici, Trivy per container, cdxgen per source code.
Tre tool open-source coprono la maggior parte dei casi industriali. Syft (Anchore) è il più diffuso in produzione. Trivy è ottimo per pipeline container-based. cdxgen è specializzato in analisi da source code. Non esiste "il migliore": esiste "quello giusto per il vostro deliverable".
3. Generare dall'artefatto finale, MAI solo dai lockfiles.
Errore tipico: generare la SBOM da package.json o requirements.txt. Cattura le dipendenze dichiarate, non le runtime, non i pacchetti OS, non le librerie native. Sempre dall'immagine container o build finale. Chi genera dai soli lockfiles se ne accorge alla prima vulnerabilità zero-day.
4. Integrare nel CI/CD.
La SBOM non è un documento generato una volta. Deve essere rigenerata ad ogni build e allegata all'artefatto. Investimento infrastrutturale che paga dal secondo audit in poi.
5. Retention 10 anni + processo di aggiornamento.
Il CRA richiede conservazione documentale della SBOM per 10 anni dopo l'immissione sul mercato. Non basta generarla: serve un processo che sopravviva più a lungo del team che l'ha creato.
Il paradosso che stiamo vedendo: la SBOM non è formalmente obbligatoria fino all'11 dicembre 2027, ma è precondizione operativa per l'obbligo di reporting vulnerabilità che parte l'11 settembre. Chi arriva a settembre 2026 senza una SBOM strutturata, non ha su cosa fare reporting.
Nei prossimi mesi torneremo su questi temi con maggiore profondità operativa.