Esempi di SBOM: file CycloneDX e SPDX spiegati in dettaglio

L'applicazione di questi esempi

Entrambi i file descrivono example-api 2.4.0, un servizio Node.js illustrativo con una dipendenza diretta, express. Express dipende a sua volta da accepts, quindi gli esempi mostrano anche una dipendenza transitiva. Una SBOM reale di un'applicazione Express elenca molti più componenti, ma la struttura è la stessa.

Esempio di SBOM CycloneDX

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-30T09:00:00Z",
    "lifecycles": [{ "phase": "build" }],
    "tools": {
      "components": [
        { "type": "application", "name": "example-sbom-tool", "version": "1.0.0" }
      ]
    },
    "component": {
      "type": "application",
      "bom-ref": "example-api",
      "name": "example-api",
      "version": "2.4.0"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/[email protected]",
      "name": "express",
      "version": "4.21.2",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }]
    },
    {
      "type": "library",
      "bom-ref": "pkg:npm/[email protected]",
      "name": "accepts",
      "version": "1.3.8",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ],
  "dependencies": [
    { "ref": "example-api", "dependsOn": ["pkg:npm/[email protected]"] },
    { "ref": "pkg:npm/[email protected]", "dependsOn": ["pkg:npm/[email protected]"] }
  ]
}

Campo	Che cosa indica
`specVersion`	Quale versione del formato usa il file, così gli strumenti possono interpretarlo.
`serialNumber`, `version`	Di quale SBOM si tratta e di quale sua revisione.
`metadata.lifecycles`	Quando è stata creata la SBOM. In questo caso, durante la build.
`metadata.tools`	Quale strumento l'ha prodotta. Due strumenti possono riportare lo stesso commit in modo diverso.
`metadata.component`	Il prodotto descritto dalla SBOM.
`purl`	Il package URL, l'identificatore che permette a uno strumento di associare il componente agli advisory.
`licenses`	La licenza dichiarata del componente.
`dependencies`	Chi introduce chi. È ciò che rende `accepts` visibile come dipendenza transitiva.

Esempio di SBOM SPDX

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "example-api-2.4.0",
  "documentNamespace": "https://example.com/spdx/example-api-2.4.0",
  "creationInfo": {
    "created": "2026-10-30T09:00:00Z",
    "creators": ["Tool: example-sbom-tool-1.0.0"]
  },
  "packages": [
    {
      "name": "example-api",
      "SPDXID": "SPDXRef-Package-example-api",
      "versionInfo": "2.4.0",
      "downloadLocation": "NOASSERTION"
    },
    {
      "name": "express",
      "SPDXID": "SPDXRef-Package-express",
      "versionInfo": "4.21.2",
      "downloadLocation": "NOASSERTION",
      "licenseDeclared": "MIT",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/[email protected]"
        }
      ]
    },
    {
      "name": "accepts",
      "SPDXID": "SPDXRef-Package-accepts",
      "versionInfo": "1.3.8",
      "downloadLocation": "NOASSERTION",
      "licenseDeclared": "MIT",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/[email protected]"
        }
      ]
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relationshipType": "DESCRIBES",
      "relatedSpdxElement": "SPDXRef-Package-example-api"
    },
    {
      "spdxElementId": "SPDXRef-Package-example-api",
      "relationshipType": "DEPENDS_ON",
      "relatedSpdxElement": "SPDXRef-Package-express"
    },
    {
      "spdxElementId": "SPDXRef-Package-express",
      "relationshipType": "DEPENDS_ON",
      "relatedSpdxElement": "SPDXRef-Package-accepts"
    }
  ]
}

Le informazioni sono le stesse, organizzate in modo diverso. SPDX mantiene un elenco packages e dichiara ogni collegamento tra gli elementi in relationships. licenseDeclared è ciò che il pacchetto dichiara di sé, e downloadLocation può valere NOASSERTION quando lo strumento non lo conosce. Per le differenze tra i due formati oltre alla struttura, veda CycloneDX vs SPDX.

Com'è fatta una SBOM debole

Un file può essere valido e tuttavia quasi inutile. Faccia attenzione a questi segnali:

Nessuna relazione di dipendenza. Un elenco piatto dice che un pacchetto è presente, non che cosa lo ha introdotto, ed è questo che serve per correggere una dipendenza transitiva.
Nessun package URL. Senza un identificatore come un purl, l'associazione di un componente agli advisory si riduce a un'ipotesi basata sui nomi.
Licenze mancanti. Molti campi lasciati a NOASSERTION significano che la SBOM non può rispondere alle domande sulle licenze.
Troppo pochi componenti. Pochi componenti per una grande applicazione di solito significano solo dipendenze dirette, o solo ciò che un lockfile ha dichiarato.
Nessuna indicazione su quando o come. Senza uno strumento e un contesto di generazione, non si può capire che cosa la SBOM copra in modo affidabile.
Silenzio sulle lacune. Una buona SBOM dice ciò che non ha potuto vedere. La maggior parte dei file semplicemente si ferma, e chi legge li presume completi.

Come controllare la Sua SBOM

Convalidi il formato. La sottoponga a un validatore di schema per il suo formato e la sua versione, perché uno strumento che non riesce a interpretare il file non può usarlo.
Controlli i campi. La confronti con i 2026 Minimum Elements o con l'elenco richiesto dal Suo cliente.
Cerchi qualcosa che conosce. Scelga una dipendenza transitiva, un pacchetto della Sua immagine base e uno strumento di build, e veda quali compaiono.
Confronti due fonti. Generi una seconda SBOM con un metodo diverso e osservi la differenza. Ogni componente in più in un file è una domanda sull'altro.

Una SBOM in fase di build da CRACI

CRACI esporta gli stessi formati. La differenza sta nella provenienza del contenuto: registra ciò che ogni job GitHub Actions ha scaricato, quindi ogni componente della SBOM è stato davvero introdotto nella build, e i pacchetti ripristinati dalle cache CI sono contrassegnati come tali. Anche le GitHub Actions eseguite dal workflow compaiono come componenti, fissate al commit utilizzato. La SBOM di ogni job riporta inoltre uno stato di completezza, così le lacune vengono dichiarate invece di essere lasciate da scoprire a Lei. Veda la generazione di SBOM in fase di build, oppure il confronto tra gli strumenti SBOM.

Esempi di SBOM: domande frequenti

Che aspetto ha una SBOM?

Di solito è un file JSON, a volte XML. Inizia con i dati sulla SBOM stessa, come lo strumento e la marca temporale, poi elenca ogni componente con nome, versione, identificatore e licenza, e infine descrive come i componenti dipendono l'uno dall'altro.

Una SBOM è un file JSON?

Di solito sì, perché JSON è la codifica più diffusa sia di CycloneDX sia di SPDX. Entrambi i formati hanno anche altre codifiche, e SPDX ha anche una forma testuale tag-value.

Che cos'è un purl in una SBOM?

Un purl, o package URL, è un identificatore standard di un pacchetto, come pkg:npm/[email protected]. Indica ecosistema, pacchetto e versione in un'unica stringa, il che consente agli strumenti di associare in modo affidabile il componente ai dati sulle vulnerabilità.

Quanti componenti dovrebbe avere una SBOM?

Non esiste un numero giusto, ma deve includere le dipendenze transitive, che di solito superano di gran lunga quelle dirette. Pochissimi componenti per una grande applicazione di solito significano che lo strumento ne ha visto solo una parte.

Si può vedere la SBOM di un progetto open source?

A volte. Alcuni progetti pubblicano le SBOM insieme alle release, e GitHub può esportarne una dal grafo delle dipendenze di un repository. Quell'esportazione riflette ciò che il repository dichiara, non ciò che una build specifica ha usato.