Příklady SBOM

Aplikace v těchto příkladech

Oba soubory popisují example-api 2.4.0, ilustrativní službu v Node.js s jednou přímou závislostí, express. Express dále závisí na accepts, takže příklady ukazují i jednu tranzitivní závislost. Skutečná SBOM aplikace v Expressu uvádí mnohem více komponent, ale struktura je stejná.

Příklad SBOM v 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]"] }
  ]
}

Pole	Co vám říká
specVersion	Jakou verzi formátu soubor používá, aby ho nástroje dokázaly zpracovat.
serialNumber, version	O kterou SBOM jde a o kterou její revizi.
metadata.lifecycles	Kdy SBOM vznikla. Zde během buildu.
metadata.tools	Který nástroj ji vytvořil. Dva nástroje mohou stejný commit popsat různě.
metadata.component	Produkt, který SBOM popisuje.
purl	Package URL, identifikátor, díky kterému nástroj spáruje komponentu s bezpečnostními upozorněními.
licenses	Deklarovaná licence komponenty.
dependencies	Kdo koho stahuje. Právě díky tomu je accepts vidět jako tranzitivní závislost.

Příklad SBOM v 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"
    }
  ]
}

Informace jsou stejné, jen jinak uspořádané. SPDX vede seznam packages a každou vazbu mezi položkami uvádí v relationships. licenseDeclared je to, co balíček uvádí sám o sobě, a downloadLocation může mít hodnotu NOASSERTION, když ji nástroj nezná. Jak se oba formáty liší nad rámec uspořádání, popisuje CycloneDX vs SPDX.

Jak vypadá slabá SBOM

Soubor může být platný, a přesto téměř nepoužitelný. Dávejte pozor na tyto znaky:

• Žádné vztahy mezi závislostmi. Plochý seznam vám řekne, že balíček je přítomen, ale ne, co ho stáhlo, a to potřebujete, abyste mohli opravit tranzitivní závislost.
• Žádné package URL. Bez identifikátoru, jako je purl, se párování komponenty s bezpečnostními upozorněními omezí na odhady podle názvů.
• Chybějící licence. Mnoho polí ponechaných jako NOASSERTION znamená, že SBOM nedokáže odpovědět na otázky k licencím.
• Podezřele málo komponent. Hrstka komponent u velké aplikace obvykle znamená jen přímé závislosti nebo jen to, co deklaroval jeden lockfile.
• Ani slovo o tom, kdy a jak. Bez nástroje a kontextu generování nepoznáte, čemu lze v SBOM věřit, že pokrývá.
• Mlčení o mezerách. Dobrá SBOM říká, co nemohla vidět. Většina souborů prostě skončí a čtenář předpokládá, že jsou úplné.

Jak zkontrolovat vlastní SBOM

1. Ověřte formát. Projděte soubor validátorem schématu pro jeho formát a verzi, protože nástroj, který soubor nedokáže zpracovat, ho nemůže použít.
2. Zkontrolujte pole. Porovnejte je s 2026 Minimum Elements nebo se seznamem, který požaduje váš zákazník.
3. Vyhledejte něco, co znáte. Vyberte tranzitivní závislost, balíček ze základního image a nástroj pro build a podívejte se, které z nich se objeví.
4. Porovnejte dva zdroje. Vygenerujte druhou SBOM jinou metodou a podívejte se na rozdíl. Každá komponenta navíc v jednom souboru je otázkou na ten druhý.

Všechny kontroly namapované na seznamy polí NTIA, CISA a BSI najdete v kontrolním seznamu kvality SBOM.

SBOM z doby buildu od CRACI

CRACI exportuje stejné formáty. Liší se to, odkud obsah pochází: zaznamenává, co každý job GitHub Actions stáhl, takže každá komponenta v SBOM byla do buildu skutečně stažena a balíčky obnovené z cache CI jsou tak označeny. GitHub Actions, které workflow spustil, se také objevují jako komponenty, připnuté na použitý commit. SBOM každého jobu navíc nese stav úplnosti, takže mezery jsou uvedené a nemusíte je hledat sami. Viz generování SBOM z doby buildu nebo srovnání nástrojů SBOM.

Příklady SBOM: časté dotazy

Jak vypadá SBOM?

Obvykle je to soubor JSON, někdy XML. Začíná údaji o samotné SBOM, například o nástroji a časovém razítku, pak uvádí každou komponentu s jejím názvem, verzí, identifikátorem a licencí a nakonec popisuje, jak na sobě komponenty závisejí.

Je SBOM soubor JSON?

Obvykle ano, protože JSON je nejpoužívanější kódování CycloneDX i SPDX. Oba formáty mají i jiná kódování a SPDX má navíc textovou podobu tag-value.

Co je purl v SBOM?

Purl neboli package URL je standardní identifikátor balíčku, například pkg:npm/[email protected]. V jednom řetězci pojmenovává ekosystém, balíček a verzi, což nástrojům umožňuje spolehlivě spárovat komponentu s daty o zranitelnostech.

Kolik komponent by měla SBOM mít?

Správné číslo neexistuje, ale měla by zahrnovat tranzitivní závislosti, kterých bývá obvykle mnohem víc než přímých. Velmi málo komponent u velké aplikace obvykle znamená, že nástroj viděl jen její část.

Můžete si prohlédnout SBOM open source projektu?

Někdy. Některé projekty zveřejňují SBOM spolu se svými vydáními a GitHub umí jednu exportovat z grafu závislostí repozitáře. Takový export odráží, co repozitář deklaruje, ne co použil konkrétní build.