Risolvere "Supplier is a minimum element and must not be empty" nei SBOM CycloneDX

Se hai mai verificato un SBOM CycloneDX con il FOSSA NTIA SBOM Validator o uno strumento simile, potresti aver visto errori come questi:

Questi errori significano che il tuo SBOM è tecnicamente un CycloneDX valido — supera la validazione dello schema — ma non soddisfa gli elementi minimi NTIA per un Software Bill of Materials. Se vendi software nell'UE ai sensi del Cyber Resilience Act (CRA), o lo fornisci a un'agenzia federale statunitense, la conformità NTIA generalmente non è opzionale.

Analizziamo cosa succede e come risolvere.

Cosa richiedono gli elementi minimi NTIA

L'NTIA ha pubblicato i suoi "Minimum Elements for a Software Bill of Materials" nel 2021. Tra i campi obbligatori per ogni SBOM ci sono:

Il Nome del Supplier è richiesto in tre punti distinti in un SBOM CycloneDX:

1. metadata.supplier — l'organizzazione che fornisce il software descritto
2. metadata.component.supplier — il supplier del componente di livello superiore
3. components[].supplier — il supplier di ogni dipendenza elencata

La maggior parte dei generatori di SBOM, inclusi strumenti popolari come Syft e Trivy, storicamente omettevano questi campi. La validazione dello schema CycloneDX non li richiede — sono opzionali nella specifica. Ma la validazione NTIA sì, ed è questo che conta per la conformità.

La causa principale

Quando esegui npm install o pip install, il lockfile risultante (package-lock.json, requirements.txt, ecc.) registra nomi dei pacchetti, versioni e relazioni di dipendenza. Quello che non registra è chi ha pubblicato ogni pacchetto. Quei metadati risiedono nel registro dei pacchetti (npmjs.org, PyPI, ecc.), non nel tuo lockfile.

La maggior parte dei generatori di SBOM analizza solo il lockfile. Risultato: ogni componente ottiene un nome e una versione, ma nessun supplier. Lo SBOM è valido per lo schema ma non conforme NTIA.

La soluzione: popolare i campi supplier a ogni livello

1. Supplier nei metadata

La sezione metadata del tuo SBOM ha bisogno di un oggetto supplier con almeno un name:

{
  "metadata": {
    "supplier": {
      "name": "nome-del-tuo-progetto"
    },
    "component": {
      "type": "application",
      "name": "nome-del-tuo-progetto",
      "version": "1.0.0",
      "supplier": {
        "name": "nome-del-tuo-progetto"
      }
    }
  }
}

Il metadata.supplier rappresenta l'organizzazione che fornisce il software descritto da questo SBOM. Per la maggior parte dei team, è il nome del progetto o dell'azienda.

2. Supplier dello strumento

Se il tuo SBOM elenca lo strumento di generazione sotto metadata.tools, ogni strumento dovrebbe anch'esso avere un supplier:

{
  "tools": [
    {
      "name": "il-tuo-strumento-sbom",
      "version": "1.0.0",
      "supplier": {
        "name": "Il Tuo Fornitore di Strumenti"
      }
    }
  ]
}

3. Supplier dei componenti — la parte complicata

Ogni voce nell'array components necessita di un supplier.name. Ma da dove vengono quei dati se il lockfile non li contiene?

Ci sono due approcci:

Opzione A: Arricchimento dal registro (ideale, più lento)

Chiamare l'API del registro npm (https://registry.npmjs.org/{package}) per ogni dipendenza, estrarre l'autore o il pubblicatore e popolare il supplier. Questo fornisce i dati più accurati ma aggiunge chiamate di rete e latenza alla pipeline di generazione SBOM.

Opzione B: Euristica dallo scope del pacchetto (pratica, veloce)

Per i pacchetti npm, lo scope (il prefisso @org/) è un proxy ragionevole per il supplier. Ad esempio:

• @angular/core → supplier: @angular
• @types/node → supplier: @types
• express → supplier: express

Questo è l'approccio usato da strumenti come Syft e Trivy. Non è perfetto — un pacchetto senza scope come express viene attribuito a se stesso — ma soddisfa il requisito NTIA ed è una scelta difendibile per strumenti automatizzati. Lo scope rappresenta genuinamente l'entità organizzativa che ha pubblicato il pacchetto.

Aggiornamento a CycloneDX 1.7

Mentre correggi i campi supplier, vale la pena aggiornare la versione della specifica. CycloneDX 1.7 (rilasciato a ottobre 2025) è la versione più recente ed è completamente retrocompatibile. Le modifiche sono minime:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "$schema": "http://cyclonedx.org/schema/bom-1.7.schema.json"
}

Dopo la correzione

Con i campi supplier popolati a ogni livello, il tuo SBOM dovrebbe superare tutte le verifiche degli elementi minimi NTIA:

Come Verimu gestisce questo

Ogni SBOM generato da Verimu include già i campi supplier a tutti e tre i livelli — metadata.supplier, metadata.component.supplier e supplier per componente — utilizzando euristiche basate sullo scope per i pacchetti npm (con arricchimento dal registro previsto per una release futura).

I nostri SBOM sono generati secondo la specifica CycloneDX 1.7 e validati rispetto agli elementi minimi NTIA prima della consegna. Se stai lavorando alla conformità CRA per l'accesso al mercato europeo entro settembre 2026, è un problema in meno di cui preoccuparti.

Inizia gratis → o prenota una demo per vedere come Verimu gestisce la generazione SBOM per il tuo stack.