Come Generare un SBOM Conforme al CRA: Strumenti, Formati e Integrazione CI/CD

Il CRA richiede un Software Bill of Materials. Tutti gli articoli dei competitor te lo dicono. Nessuno ti mostra come generarne uno.

Questa guida copre strumenti open source, selezione dei formati e integrazione CI/CD, senza vendor lock-in.

Cosa Richiede Realmente il CRA

Iniziamo con cosa dice il regolamento. L'Allegato I, Parte II del CRA richiede ai fabbricanti di:

"identificare e documentare le vulnerabilità e i componenti contenuti nel prodotto, anche redigendo una distinta base del software in un formato comunemente usato e leggibile da macchina"

Punti chiave:

• Formato leggibile da macchina: Non un PDF, non un foglio di calcolo, dati strutturati
• Almeno le dipendenze di primo livello: L'ambito minimo, anche se di più è meglio
• Non obbligatoriamente pubblico: Fornito alle autorità su richiesta
• Deve essere aggiornato: Con ogni release, patch o cambio di componente

Il CRA non impone un formato specifico, ma gli sforzi di standardizzazione puntano chiaramente a CycloneDX e SPDX.

Selezione del Formato: CycloneDX vs SPDX

Due formati dominano il panorama SBOM. Entrambi sono accettabili per la conformità CRA.

CycloneDX

Origine: Progetto OWASP, focalizzato sulla sicurezza Versione corrente: 1.6 (1.4+ raccomandato per CRA) Ideale per: Sicurezza e gestione delle vulnerabilità

Punti di forza:

• Supporto nativo VEX (Vulnerability Exploitability eXchange)
• Progettato per casi d'uso di sicurezza
• Specifica più leggera, più facile da implementare
• Forte ecosistema di strumenti
• Collegamento diretto CVE/vulnerabilità

Esempio JSON:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "cc6d..."
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
    }
  ]
}

SPDX

Origine: Linux Foundation, focalizzato sulla conformità delle licenze Versione corrente: 2.3 (standard ISO/IEC 5962:2021) Ideale per: Conformità delle licenze e revisione legale

Punti di forza:

• Standard internazionale ISO
• Sintassi completa per espressioni di licenza
• Solido nei contesti di conformità open source
• Track record più lungo
• Migliore per scenari di licenza complessi

Esempio JSON:

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-application",
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-lodash",
      "name": "lodash",
      "versionInfo": "4.17.21",
      "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "licenseConcluded": "MIT",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "cc6d..."
        }
      ]
    }
  ]
}

Quale Scegliere?

Per la conformità CRA, entrambi i formati funzionano. Scegline uno e sii coerente.

Strumenti Open Source per Generazione SBOM

Nessun vendor lock-in richiesto. Questi strumenti sono gratuiti, open source e pronti per la produzione.

Syft (Anchore)

Ideale per: Immagini container, filesystem, archivi Licenza: Apache 2.0 Formati di output: CycloneDX, SPDX, Syft JSON

Installazione:

# Linux/macOS
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Homebrew
brew install syft

# Docker
docker pull anchore/syft

Esempi di utilizzo:

# Scansiona un'immagine container
syft alpine:latest -o cyclonedx-json > sbom.cdx.json

# Scansiona una directory
syft dir:/percorso/al/progetto -o cyclonedx-json > sbom.cdx.json

# Scansiona un archivio
syft /percorso/all/archivio.tar.gz -o spdx-json > sbom.spdx.json

# Scansiona con catalogatori specifici (es. solo Python)
syft dir:. -o cyclonedx-json --select-catalogers python

Ecosistemi supportati: Python, Node.js, Ruby, Java, Go, Rust, PHP, .NET, e altri.

Trivy (Aqua Security)

Ideale per: Immagini container con contesto vulnerabilità integrato Licenza: Apache 2.0 Formati di output: CycloneDX, SPDX, più report vulnerabilità

Installazione:

# Linux (Debian/Ubuntu)
sudo apt-get install trivy

# macOS
brew install trivy

# Docker
docker pull aquasec/trivy

Esempi di utilizzo:

# Genera SBOM da immagine container
trivy image --format cyclonedx --output sbom.cdx.json alpine:latest

# Genera SBOM da filesystem
trivy fs --format cyclonedx --output sbom.cdx.json /percorso/al/progetto

# Genera SBOM con info vulnerabilità
trivy image --format cyclonedx --output sbom.cdx.json \
  --scanners vuln nginx:latest

Vantaggio: Trivy può generare SBOM e scansionare vulnerabilità in un solo passaggio.

cdxgen (CycloneDX)

Ideale per: Analisi del codice sorgente in molti linguaggi Licenza: Apache 2.0 Formato di output: CycloneDX

Installazione:

# npm (richiede Node.js)
npm install -g @cyclonedx/cdxgen

# Docker
docker pull ghcr.io/cyclonedx/cdxgen

Esempi di utilizzo:

# Scansiona la directory corrente
cdxgen -o sbom.json

# Scansiona un tipo di progetto specifico
cdxgen -t python -o sbom.json

# Scansiona con risoluzione profonda delle dipendenze
cdxgen --deep -o sbom.json

# Scansiona una directory specifica
cdxgen -o sbom.json /percorso/al/progetto

Linguaggi supportati: JavaScript, Python, Java, Go, Rust, PHP, Ruby, .NET, C/C++, e altri.

Confronto degli Strumenti

Raccomandazione: Inizia con Syft per la maggior parte dei casi. Aggiungi Trivy se hai bisogno di scansione vulnerabilità integrata. Usa cdxgen per progetti di codice sorgente complessi.

Integrazione CI/CD

La generazione manuale di SBOM non scala. Integrala nella tua pipeline di build.

GitHub Actions

name: Generazione SBOM

on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Installa Syft
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

      - name: Genera SBOM
        run: |
          syft dir:. -o cyclonedx-json > sbom.cdx.json

      - name: Carica SBOM come artefatto
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cdx.json
          retention-days: 90

      # Opzionale: Upload a CRA Evidence
      - name: Upload a CRA Evidence
        if: github.event_name == 'release'
        env:
          CRA_EVIDENCE_TOKEN: ${{ secrets.CRA_EVIDENCE_TOKEN }}
        run: |
          curl -X POST https://app.craevidence.com/api/v1/ci/sbom \
            -H "Authorization: Bearer $CRA_EVIDENCE_TOKEN" \
            -F "file=@sbom.cdx.json" \
            -F "product_id=${{ vars.PRODUCT_ID }}" \
            -F "version=${{ github.ref_name }}"

GitLab CI

generate-sbom:
  stage: build
  image: anchore/syft:latest
  script:
    - syft dir:. -o cyclonedx-json > sbom.cdx.json
  artifacts:
    paths:
      - sbom.cdx.json
    expire_in: 90 days
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_COMMIT_TAG

Jenkins

pipeline {
    agent any

    stages {
        stage('Genera SBOM') {
            steps {
                sh '''
                    curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b .
                    ./syft dir:. -o cyclonedx-json > sbom.cdx.json
                '''
            }
        }

        stage('Archivia SBOM') {
            steps {
                archiveArtifacts artifacts: 'sbom.cdx.json', fingerprint: true
            }
        }
    }
}

Integrazione Build Docker

Genera SBOM durante il build Docker:

# Build multi-stage con generazione SBOM
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Genera SBOM nello stage di build
FROM anchore/syft:latest AS sbom
COPY --from=builder /app /app
RUN syft dir:/app -o cyclonedx-json > /sbom.cdx.json

# Immagine finale
FROM node:20-slim
COPY --from=builder /app/dist /app
COPY --from=sbom /sbom.cdx.json /app/sbom.cdx.json
CMD ["node", "/app/index.js"]

Qualità SBOM: Rispettare TR-03183

La linea guida tecnica tedesca BSI TR-03183 estende gli elementi minimi NTIA. Anche se non legalmente richiesta in tutta l'UE, seguire TR-03183 assicura SBOM di alta qualità.

Campi Richiesti

Validare la Qualità SBOM

Usa questi strumenti per verificare il tuo SBOM:

# Valida il formato CycloneDX
npm install -g @cyclonedx/cyclonedx-cli
cyclonedx validate --input-file sbom.cdx.json

# Verifica i campi minimi con jq
jq '.components[] | select(.version == null or .purl == null)' sbom.cdx.json

# Conta i componenti con hash
jq '[.components[] | select(.hashes != null)] | length' sbom.cdx.json

Migliorare la Qualità SBOM

Se al tuo SBOM mancano dati:

1. Usa i file di lock: package-lock.json, Pipfile.lock, go.sum contengono più metadati
2. Scansiona artefatti compilati: Più completo delle sole scansioni del sorgente
3. Combina gli strumenti: Strumenti diversi trovano componenti diversi
4. Aggiungi voci manuali: Per componenti commerciali o interni

Mantenere gli SBOM Aggiornati

Un SBOM è uno snapshot. Deve essere aggiornato per rimanere utile.

Quando Rigenerare

• Ogni release (major, minor, patch)
• Dopo aggiornamenti delle dipendenze
• Dopo patch di sicurezza
• Quando la configurazione di build cambia

Strategia di Versionamento

prodotto-v1.0.0-sbom.cdx.json
prodotto-v1.0.1-sbom.cdx.json
prodotto-v1.1.0-sbom.cdx.json

Oppure usa timestamp:

prodotto-sbom-2026-01-15T10-30-00Z.cdx.json

Conservazione

Il CRA richiede conservazione di 10 anni. Archivia gli SBOM storici:

• Nel tuo repository di artefatti
• In S3/storage cloud con policy di ciclo di vita
• In CRA Evidence per tracking di conformità integrato

Errori Comuni

Generazione SBOM una tantum

Problema: Creare un SBOM una volta e non aggiornarlo mai.

Soluzione: Automatizza la generazione SBOM in CI/CD. Ogni build dovrebbe produrre un SBOM fresco.

Dipendenze transitive mancanti

Problema: Il SBOM elenca solo le dipendenze dirette, mancando i pacchetti annidati.

Soluzione: Usa i file di lock, scansiona artefatti compilati, abilita opzioni di scansione profonda.

Versione formato errata

Problema: Usare CycloneDX 1.3 quando TR-03183 raccomanda 1.4+.

Soluzione: Controlla la versione di output del tuo strumento. Aggiorna gli strumenti regolarmente.

Nessun valore hash

Problema: I componenti senza hash crittografici non possono essere verificati.

Soluzione: Assicurati che il tuo strumento includa gli hash. Scansiona artefatti compilati piuttosto che solo il sorgente.

Creazione manuale

Problema: Creare SBOM a mano è soggetto a errori e non sostenibile.

Soluzione: Automatizza sempre. Voci manuali solo per componenti che gli strumenti non possono rilevare.

Ignorare componenti interni

Problema: Documentare solo le dipendenze open source, non il codice proprietario.

Soluzione: Anche i componenti interni hanno bisogno di documentazione. Aggiungili manualmente o configura gli strumenti appropriatamente.

Checklist di Implementazione SBOM

CHECKLIST DI IMPLEMENTAZIONE SBOM

SELEZIONE FORMATO:
[ ] CycloneDX 1.4+ o SPDX 2.3+ scelto
[ ] Formato JSON (leggibile da macchina)
[ ] Decisione documentata

STRUMENTI:
[ ] Strumento principale selezionato (Syft/Trivy/cdxgen)
[ ] Strumento installato e testato localmente
[ ] Output validato contro lo schema

INTEGRAZIONE CI/CD:
[ ] Generazione SBOM aggiunta alla pipeline di build
[ ] Artefatti archiviati con conservazione appropriata
[ ] Generazione attivata sulle release

ASSICURAZIONE QUALITÀ:
[ ] Tutti i componenti hanno: nome, versione, fornitore
[ ] Valori hash presenti (SHA-256+)
[ ] Informazione licenza inclusa
[ ] Dipendenze transitive catturate
[ ] Identificatori PURL usati

OPERAZIONI:
[ ] SBOM versionato insieme alle release prodotto
[ ] SBOM storici archiviati (conservazione 10 anni)
[ ] Processo documentato per il team

OPZIONALE - INTEGRAZIONE CRA EVIDENCE:
[ ] Token API configurato
[ ] Upload automatizzato su release
[ ] Scoring qualità abilitato

Prossimi Passi

Con la generazione SBOM automatizzata, sei pronto per:

1. Scansione vulnerabilità: Collega gli SBOM ai database delle vulnerabilità
2. Conformità licenze: Analizza gli obblighi di licenza
3. Integrazione fascicolo tecnico: Includi gli SBOM nella documentazione CRA
4. Preparazione reporting ENISA: Gli SBOM permettono identificazione rapida delle vulnerabilità

CRA Evidence automatizza tutto questo workflow:

• Upload degli SBOM via CLI o CI/CD
• Scansione automatica delle vulnerabilità con Trivy
• Scoring qualità TR-03183
• Export del fascicolo tecnico con SBOM integrati

Inizia a generare SBOM conformi su app.craevidence.com.

Requisiti: Comprendi cosa richiede il CRA per gli SBOM nella nostra guida ai requisiti SBOM.

Qualità: Valida il tuo SBOM rispetto allo standard BSI TR-03183.

VEX: Aggiungi contesto di vulnerabilità al tuo SBOM con i documenti VEX.

Questo articolo è solo a scopo informativo e non costituisce consulenza legale. Per indicazioni specifiche sulla conformità, consultare un consulente legale qualificato esperto in regolamenti sui prodotti UE.