Generare un SBOM per il CRA: strumenti, formati e pipeline CI/CD

Il CRA richiede un Software Bill of Materials. Ogni articolo dei concorrenti lo ripete. Nessuno 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:

«identificano e documentano le vulnerabilità e i componenti contenuti nel prodotto con elementi digitali, redigendo anche una distinta base del software in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello del prodotto»

Punti chiave:

• Formato leggibile da macchina: non un PDF, non un foglio di calcolo, ma dati strutturati
• Almeno le dipendenze di primo livello: l'ambito minimo, anche se una copertura maggiore è preferibile
• 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.

Lo SBOM rientra nella documentazione tecnica CRA prevista dall'Allegato VII. I fabbricanti devono redigere tale documentazione prima di immettere il prodotto sul mercato e mantenerla a disposizione delle autorità di vigilanza del mercato per almeno 10 anni, o per il periodo di assistenza, a seconda di quale sia più lungo (Articolo 13, paragrafo 13). Uno SBOM conservato localmente senza collegamento a una specifica versione del prodotto non soddisfa questo requisito: deve essere recuperabile, versionato e associato alla versione del prodotto che descrive.

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. ISO/IEC 5962:2021 ha standardizzato SPDX 2.2.1 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. Scegliere uno e usarlo in modo coerente.

Strumenti open source per la generazione di 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:/path/to/project -o cyclonedx-json > sbom.cdx.json

# Scansiona un archivio
syft /path/to/archive.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 /path/to/project

# 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 /path/to/project

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

Confronto degli strumenti

Raccomandazione: iniziare con Syft per la maggior parte dei casi. Aggiungere Trivy se si ha bisogno di scansione vulnerabilità integrata. Usare cdxgen per progetti di codice sorgente complessi.

Firmware e dispositivi embedded

Gli strumenti sopra indicati funzionano bene per container e package manager. Per firmware e dispositivi embedded (il target principale del CRA), l'approccio è diverso.

Le immagini firmware sono blob binari, non registry di pacchetti. Il primo passo standard è estrarre il filesystem:

# Estrai il filesystem dall'immagine firmware
binwalk -Me firmware.bin

# Esegui Syft sul filesystem estratto
syft dir:_firmware.bin.extracted/squashfs-root -o cyclonedx-json > sbom.cdx.json

Usare binwalk -Me (estrazione ricorsiva) invece di -e per immagini annidate o compresse. La copertura sarà inferiore rispetto alle immagini container. I binari stripped perdono le informazioni sui simboli e Syft potrebbe non identificare tutti i componenti.

Per l'analisi a livello binario dei componenti compilati, BLint, cve-bin-tool o EMBA offrono un'ispezione più approfondita. SDK proprietari e librerie closed-source embedded nel firmware richiedono in genere voci SBOM manuali. Documentare il vendor, la versione e l'URL sorgente.

Integrazione CI/CD

La generazione manuale di SBOM non scala. Integrarla nella pipeline di build.

GitHub Actions

name: Generazione SBOM

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

jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # richiesto per la firma keyless con Cosign
    steps:
      - name: Checkout del codice
        uses: actions/checkout@v4

      - name: Compila l'immagine container
        run: |
          docker build -t myapp:${{ github.sha }} .

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

      - name: Genera SBOM dall'immagine compilata
        run: |
          syft myapp:${{ github.sha }} -o cyclonedx-json > sbom.cdx.json

      - name: Installa Cosign
        uses: sigstore/cosign-installer@v3

      - name: Firma l'SBOM (keyless)
        run: |
          cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json --yes

      - name: Carica SBOM e firma come artefatti
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: |
            sbom.cdx.json
            sbom.cdx.json.sigstore.json
          retention-days: 90

      # Opzionale: carica su CRA Evidence per archiviazione a lungo termine conforme al CRA
      - name: Carica su CRA Evidence
        if: github.event_name == 'release'
        env:
          CRA_EVIDENCE_TOKEN: ${{ secrets.CRA_EVIDENCE_TOKEN }}
        run: |
          curl -X POST https://api.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

Generare 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"]

Firma degli SBOM

Il CRA non impone la firma degli SBOM, ma la firma attesta che il file non è stato modificato dalla generazione. I team di procurement enterprise e gli organismi notificati si aspettano sempre più una firma verificabile accanto all'SBOM.

Cosign (parte del progetto Sigstore) è lo strumento standard:

# Installa Cosign
brew install cosign

# Firma un file SBOM. Produce un bundle con firma e certificato
cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json

# Verifica in seguito
cosign verify-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json \
  --certificate-identity <your-identity> \
  --certificate-oidc-issuer <your-issuer>

Conservare sbom.cdx.json e sbom.cdx.json.sigstore.json insieme. Il bundle contiene la firma, il certificato di firma e la voce nel registro di trasparenza Rekor. Chiunque disponga del bundle può verificare l'SBOM senza contattare il fabbricante.

Per CI/CD, Cosign supporta la firma keyless tramite l'identità OIDC della pipeline (GitHub Actions, GitLab CI). Nessuna chiave da gestire. L'esempio GitHub Actions sopra include già questa configurazione: il job richiede il permesso id-token: write e sign-blob accetta --yes per l'esecuzione senza prompt interattivo. Con Cosign 2.0 e versioni successive la firma keyless è il comportamento predefinito: il vecchio flag COSIGN_EXPERIMENTAL non è più necessario.

Monitoraggio continuo

Un SBOM firmato e archiviato non è il traguardo finale. Nuove vulnerabilità vengono divulgate contro componenti che erano puliti al momento della release. L'SBOM archiviato deve essere riscansionato periodicamente affinché quei CVE emergano.

Grype legge direttamente un SBOM esistente, quindi la riscansione non richiede l'ambiente di build originale:

name: Riscansione SBOM

on:
  schedule:
    - cron: "0 6 * * 1"  # Settimanale, lunedì ore 06:00 UTC

jobs:
  rescan:
    runs-on: ubuntu-latest
    steps:
      - name: Scarica l'SBOM archiviato
        env:
          SBOM_URL: ${{ vars.SBOM_URL }}
        run: |
          curl -sSfL -o sbom.cdx.json "$SBOM_URL"

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

      - name: Scansiona l'SBOM per nuovi CVE
        run: |
          grype sbom:./sbom.cdx.json

CRA Evidence esegue questa riscansione automaticamente per ogni SBOM caricato e invia un alert quando un nuovo CVE corrisponde a un componente, coprendo lo stesso obiettivo senza un job pianificato.

Qualità SBOM: rispettare TR-03183

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

Campi richiesti

Validare la qualità SBOM

Usare questi strumenti per verificare il proprio 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 allo SBOM mancano dati:

1. Usare i file di lock: package-lock.json, Pipfile.lock, go.sum contengono più metadati
2. Scansionare artefatti compilati: più completo delle sole scansioni del sorgente
3. Combinare gli strumenti: strumenti diversi trovano componenti diversi
4. Aggiungere voci manuali: per componenti commerciali o interni

Mantenere gli SBOM aggiornati

Uno 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 usare timestamp:

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

Conservazione

La conservazione degli artefatti CI (90 giorni negli esempi sopra) è per comodità degli sviluppatori, non per la conformità. Il requisito decennale richiede un sistema di archiviazione a lungo termine dedicato. CRA Evidence è progettato per questo scopo: archiviazione SBOM con versioning, riscansione delle vulnerabilità ed export dei file tecnici, collegati a ogni release del prodotto.

Se si preferisce gestire l'archiviazione internamente, qualsiasi object store di grandi dimensioni funziona con le impostazioni corrette:

Una lifecycle policy da sola non è sufficiente. Il sistema di archiviazione deve supportare il versioning, i controlli di accesso e, preferibilmente, l'immutabilità per soddisfare i requisiti di audit.

Errori comuni

Generazione SBOM una tantum

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

Soluzione: automatizzare la generazione SBOM in CI/CD. Ogni build deve produrre un SBOM aggiornato.

Dipendenze transitive mancanti

Problema: lo SBOM elenca solo le dipendenze dirette, omettendo i pacchetti annidati.

Soluzione: usare i file di lock, scansionare artefatti compilati, abilitare opzioni di scansione profonda.

Versione formato errata

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

Soluzione: verificare la versione di output dello strumento. Aggiornare gli strumenti regolarmente.

Nessun valore hash

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

Soluzione: assicurarsi che lo strumento includa gli hash. Syft e Trivy aggiungono hash SHA-256 quando possono leggere i file dei componenti.

Creazione manuale

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

Soluzione: automatizzare sempre. Voci manuali solo per i componenti che gli strumenti non riescono a rilevare.

Ignorare componenti interni

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

Soluzione: anche i componenti interni richiedono documentazione. Aggiungerli manualmente o configurare gli strumenti di conseguenza.

Checklist di implementazione SBOM

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

Qualità: validare il proprio SBOM rispetto allo standard BSI TR-03183.

VEX: aggiungere contesto di vulnerabilità allo 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.