Softwarestykliste (SBOM)

Det moderne SBOM-arbejde begyndte med den amerikanske NTIA's multistakeholder-proces i 2018 og fik regulatorisk vægt med Executive Order 14028 (maj 2021), hvorefter NTIA udgav The Minimum Elements for an SBOM (juli 2021). Den definerer tre grupper: datafelter (leverandørnavn, komponentnavn, version, andre unikke identifikatorer, afhængighedsforhold, forfatter til SBOM-data og tidsstempel), understøttelse af automatisering (et maskinlæsbart format - SPDX, CycloneDX eller SWID-tags) samt praksis og processer (hvor ofte den gendannes, dybde, håndtering af kendte ubekendte, distribution og adgangskontrol).

To formater dominerer. SPDX fra Linux Foundation blev standardiseret som ISO/IEC 5962:2021 (SPDX 2.2.1); SPDX 3.0 (2024) omstrukturerede modellen i profiler for sikkerhed, licenser, AI og datasæt. CycloneDX fra OWASP er standardiseret af Ecma som ECMA-424 (første udgave juni 2024, anden udgave december 2025) og dækker også tjenester, hardware, maskinlæringsmodeller (ML-BOM), kryptografiske aktiver (CBOM) og indlejrede sårbarheds- eller VEX-data. Komponenter identificeres med Package URLs (purl, fx pkg:npm/lodash@4.17.21) og undertiden CPE-navne; præcise identifikatorer er det, der gør automatisk matchning af sårbarheder mulig, og inkonsistente CPE'er er en almindelig årsag til både falske positiver og oversete fund.

SBOM'er adskiller sig efter, hvornår de laves; CISA's taksonomi skelner mellem design-, kilde-, build-, analyserede, udrullede og runtime-SBOM'er. En build-SBOM, som pakkehåndteringen eller byggeværktøjet genererer under kompileringen, er som regel den mest komplette; en analyseret SBOM, lavet ved at scanne en færdig binær eller et container-image (Syft, Trivy, cdxgen), kan overse statisk linket, vendoreret eller shadet kode. Dybden betyder noget: mange afhængigheder er transitive, og en SBOM med kun direkte afhængigheder ville have skjult det meste af Log4j-eksponeringen i 2021. SBOM'er vedhæftes ofte udgivelser eller container-images som signerede in-toto-attestationer, så modtagerne kan verificere deres oprindelse.

En SBOM er en fortegnelse, ikke en vurdering. Værdien viser sig, når den indlæses i værktøjer (fx OWASP Dependency-Track) og løbende sammenholdes med sårbarhedsdata, og når den kombineres med VEX (Vulnerability Exploitability eXchange i CSAF- eller OpenVEX-form), hvor leverandøren oplyser, om en listet sårbarhed faktisk rammer produktet. I EU kræver Cyberrobusthedsforordningen (forordning (EU) 2024/2847), bilag I, del II, punkt 1, at producenter identificerer og dokumenterer komponenter, bl.a. ved at udarbejde en SBOM i et almindeligt anvendt, maskinlæsbart format, der som minimum dækker de øverste afhængigheder; SBOM'en er en del af den tekniske dokumentation og skal ikke offentliggøres. Forordningens hovedforpligtelser gælder fra 11. december 2027, mens pligten til at indberette sårbarheder har gældt siden 11. september 2026. SBOM adskiller sig fra software composition analysis, som er den proces, der bruger eller producerer sådanne fortegnelser for at finde sårbare og ikke-kompatible komponenter.