SBOM-esimerkit: CycloneDX- ja SPDX-tiedostot selitettyinä

Esimerkkien sovellus

Molemmat tiedostot kuvaavat sovellusta example-api 2.4.0, kuvitteellista Node.js-palvelua, jolla on yksi suora riippuvuus, express. Express puolestaan riippuu paketista accepts, joten esimerkeissä näkyy myös yksi transitiivinen riippuvuus. Todellinen Express-sovelluksen SBOM luettelee paljon enemmän komponentteja, mutta rakenne on sama.

CycloneDX-SBOM-esimerkki

{
  "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]"] }
  ]
}

Kenttä	Mitä se kertoo
`specVersion`	Mitä formaatin versiota tiedosto käyttää, jotta työkalut osaavat jäsentää sen.
`serialNumber`, `version`	Mikä SBOM tämä on ja mikä sen revisio.
`metadata.lifecycles`	Milloin SBOM tehtiin. Tässä buildin aikana.
`metadata.tools`	Mikä työkalu sen tuotti. Kaksi työkalua voi raportoida saman commitin eri tavoin.
`metadata.component`	Tuote, jota SBOM kuvaa.
`purl`	Package URL, tunniste, jonka avulla työkalu voi yhdistää komponentin tietoturvatiedotteisiin.
`licenses`	Komponentin ilmoitettu lisenssi.
`dependencies`	Mikä tuo mukanaan minkäkin. Tämän ansiosta `accepts` näkyy transitiivisena riippuvuutena.

SPDX-SBOM-esimerkki

{
  "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"
    }
  ]
}

Tiedot ovat samat, eri tavalla järjestettyinä. SPDX pitää packages-luetteloa ja ilmoittaa jokaisen kohteiden välisen yhteyden kentässä relationships. licenseDeclared on se, mitä paketti kertoo itsestään, ja downloadLocation voi olla NOASSERTION, kun työkalu ei tiedä sitä. Siitä, miten formaatit eroavat muutenkin kuin rakenteeltaan, kerrotaan sivulla CycloneDX vs. SPDX.

Miltä heikko SBOM näyttää

Tiedosto voi olla validi ja silti lähes hyödytön. Kiinnitä huomiota näihin:

Ei riippuvuussuhteita. Litteä luettelo kertoo, että paketti on mukana, mutta ei sitä, mikä toi sen mukaan, ja juuri sitä tarvitset transitiivisen riippuvuuden korjaamiseen.
Ei package URL -tunnisteita. Ilman purlin kaltaista tunnistetta komponentin yhdistäminen tietoturvatiedotteisiin perustuu nimistä arvailuun.
Puuttuvat lisenssit. Kun moni kenttä on jätetty arvoon NOASSERTION, SBOM ei pysty vastaamaan lisenssikysymyksiin.
Epäilyttävän vähän komponentteja. Kourallinen komponentteja suuressa sovelluksessa tarkoittaa yleensä vain suoria riippuvuuksia tai vain sitä, mitä yksi lukitustiedosto ilmoitti.
Ei tietoa siitä, milloin tai miten. Ilman työkalua ja generointikontekstia et voi tietää, minkä kattavuuteen SBOM:ssa voi luottaa.
Vaikeneminen aukoista. Hyvä SBOM kertoo, mitä se ei nähnyt. Useimmat tiedostot vain loppuvat, ja lukija olettaa niiden olevan kattavia.

Miten tarkistat oman SBOM:si

Validoi formaatti. Aja se formaatin ja version skeemavalidaattorin läpi, koska työkalu, joka ei pysty jäsentämään tiedostoa, ei voi käyttää sitä.
Tarkista kentät. Vertaa sitä 2026 Minimum Elements -vaatimuksiin tai asiakkaasi pyytämään luetteloon.
Etsi jotain, minkä tunnet. Valitse transitiivinen riippuvuus, paketti pohjakuvastasi ja build-työkalu, ja katso, mitkä niistä näkyvät.
Vertaa kahta lähdettä. Generoi toinen SBOM eri menetelmällä ja katso eroa. Jokainen ylimääräinen komponentti yhdessä tiedostossa on kysymys toisesta.

Kaikki tarkistukset NTIA:n, CISA:n ja BSI:n kenttäluetteloihin yhdistettyinä löydät SBOM:n laadun tarkistuslistasta.

Buildin aikana tallennettu SBOM CRACI:lta

CRACI vie samoissa formaateissa. Ero on siinä, mistä sisältö tulee: CRACI tallentaa, mitä kukin GitHub Actions -jobi haki, joten jokainen SBOM:n komponentti todella tuotiin buildiin, ja CI-välimuisteista palautetut paketit merkitään sellaisiksi. Työnkulun ajamat GitHub Actionsit näkyvät myös komponentteina, kiinnitettyinä käytettyyn committiin. Jokaisen jobin SBOM:ssa on myös kattavuustila, joten aukot kerrotaan sen sijaan, että ne jäisivät sinun löydettäviksesi. Katso SBOM-generointi buildin aikana tai SBOM-työkalut vertailussa.

SBOM-esimerkit: usein kysytyt kysymykset

Miltä SBOM näyttää?

Se on yleensä JSON-tiedosto, joskus XML. Se alkaa tiedoilla itse SBOM:sta, kuten työkalusta ja aikaleimasta, luettelee sitten jokaisen komponentin nimen, version, tunnisteen ja lisenssin ja kuvaa lopuksi, miten komponentit riippuvat toisistaan.

Onko SBOM JSON-tiedosto?

Yleensä, koska JSON on sekä CycloneDX:n että SPDX:n yleisimmin käytetty koodaus. Molemmilla formaateilla on myös muita koodauksia, ja SPDX:llä on lisäksi tag-value-tekstimuoto.

Mikä on purl SBOM:ssa?

Purl eli package URL on paketin standarditunniste, kuten pkg:npm/[email protected]. Se nimeää ekosysteemin, paketin ja version yhdessä merkkijonossa, minkä ansiosta työkalut voivat yhdistää komponentin haavoittuvuustietoihin luotettavasti.

Kuinka monta komponenttia SBOM:ssa pitäisi olla?

Oikeaa määrää ei ole, mutta siinä pitäisi olla transitiiviset riippuvuudet, joita on yleensä paljon enemmän kuin suoria. Hyvin vähän komponentteja suuressa sovelluksessa tarkoittaa yleensä, että työkalu näki siitä vain osan.

Voiko avoimen lähdekoodin projektin SBOM:n nähdä?

Joskus. Jotkin projektit julkaisevat SBOM:t julkaisujensa mukana, ja GitHub voi viedä sellaisen repositorion riippuvuusgraafista. Tuo vienti kuvastaa sitä, mitä repositorio ilmoittaa, eikä sitä, mitä tietty buildi käytti.