Software Bill of Materials (SBOM)

En Software Bill of Materials (SBOM) er en komplet, formaliseret liste over alle softwarekomponenter, biblioteker og afhængigheder i et produkt. SBOM er et krav under Cyber Resilience Act (CRA) og et afgørende værktøj til sårbarhedshåndtering og forsyningskædesikkerhed.

Tilbage til ordbog

Hvad er en SBOM?

Tænk på en SBOM som en ingrediensliste for software. Ligesom en fødevareproducent skal oplyse, hvilke ingredienser der indgår i et produkt, kræver CRA, at softwareproducenter dokumenterer, hvilke komponenter deres produkt er bygget af.

Moderne software er sjældent bygget fra bunden. Et typisk produkt indeholder hundredvis af tredjepartsbiblioteker og open source-komponenter. Hver af disse komponenter kan have kendte sårbarheder, og uden en SBOM er det umuligt at holde styr på, hvad der faktisk kører i dit produkt.

Log4Shell-sårbarheden i december 2021 illustrerede problemet. Organisationer verden over brugte uger på at finde ud af, om de var berørt, fordi de ikke havde overblik over, hvor Log4j-biblioteket blev brugt. Med en opdateret SBOM kan du besvare det spørgsmål på minutter.

SBOM som lovkrav under CRA

Cyber Resilience Act kræver, at fabrikanter af produkter med digitale elementer udarbejder en SBOM. Kravet er forankret i CRA's bilag I om sårbarhedshåndtering og i kravene til teknisk dokumentation.

SBOM'en skal som minimum identificere topniveau-afhængigheder i produktet. Den skal inkluderes i den tekniske dokumentation, som fabrikanten skal opbevare i mindst ti år efter produktets markedsføring.

CRA er ikke den eneste regulering, der peger mod SBOM. I USA har Executive Order 14028 fra 2021 allerede gjort SBOM til et krav for software, der leveres til føderale myndigheder. NIS2 forudsætter forsyningskædesikkerhed, og en SBOM er det mest konkrete værktøj til at dokumentere softwareforsyningskæden. DORA stiller tilsvarende krav til IKT-tredjepartsstyring i den finansielle sektor.

Hvad skal en SBOM indeholde?

En brugbar SBOM indeholder som minimum følgende oplysninger for hver komponent:

Komponentnavn: Det officielle navn på biblioteket eller pakken
Version: Den specifikke version, der er inkluderet i produktet
Leverandør: Hvem der har udviklet komponenten
Unik identifikator: F.eks. CPE (Common Platform Enumeration) eller PURL (Package URL)
Afhængighedsrelationer: Hvordan komponenterne relaterer sig til hinanden
Licens: Hvilken open source-licens der gælder

CRA kræver som minimum topniveau-afhængigheder, men en SBOM med fuldt afhængighedstræ (inkl. transitive afhængigheder) giver langt bedre overblik. Mange sårbarheder findes i dybe afhængigheder, som du måske ikke engang ved, at dit produkt bruger.

Formater og værktøjer

To formater dominerer SBOM-landskabet:

SPDX (Software Package Data Exchange): Udviklet af Linux Foundation og standardiseret som ISO/IEC 5962:2021. SPDX er velegnet til licensstyring og er det ældste af de to formater.

CycloneDX: Udviklet af OWASP med et stærkere fokus på sikkerhed. CycloneDX understøtter sårbarhedsdata, tjenester og maskinlæsbar VEX (Vulnerability Exploitability eXchange).

Begge formater er maskinlæsbare (JSON, XML) og understøttes af de fleste værktøjer. Valget afhænger ofte af dit eksisterende økosystem og dine primære behov.

Til generering af SBOM findes en række værktøjer: Syft, Trivy, Microsoft SBOM Tool og GitHub's built-in dependency graph. De fleste CI/CD-pipelines kan konfigureres til automatisk at generere en SBOM ved hvert build.

SBOM i praksis

En SBOM har kun værdi, hvis den holdes opdateret og bruges aktivt. Sådan integrerer du SBOM i din udviklingsproces:

Automatisér generering: Generér SBOM automatisk som del af din build-pipeline. Manuelle SBOM'er bliver hurtigt forældede og upålidelige.

Kobl til sårbarhedsdatabaser: Brug værktøjer som Grype, Trivy eller Dependency-Track til automatisk at matche din SBOM mod kendte sårbarheder i NVD, OSV og andre databaser. Det er kernen i effektiv sårbarhedshåndtering.

Versionér og arkivér: CRA kræver dokumentation i ti år. Gem SBOM'en for hver release, så du kan dokumentere, hvilke komponenter der indgik i en given version af produktet.

Brug den til hændelsesrespons: Når en ny kritisk sårbarhed annonceres, skal du hurtigt kunne afgøre, om dit produkt er berørt. En opdateret SBOM gør det muligt inden for minutter.

For virksomheder, der arbejder med sikkerhed by design, er SBOM en naturlig del af den tekniske dokumentation. Den understøtter også GDPR's krav om tekniske og organisatoriske foranstaltninger, da den dokumenterer en bevidst tilgang til komponentvalg og risikostyring.

Ofte stillede spørgsmål om software bill of materials (sbom)

Hvad er en Software Bill of Materials (SBOM)?

En SBOM er en komplet, formaliseret liste over alle softwarekomponenter i et produkt, herunder tredjepartsbiblioteker, open source-komponenter og deres versioner. Tænk på det som en ingrediensliste for software, der gør det muligt at spore, hvilke komponenter der indgår i produktet.

Kræver CRA en SBOM?

Ja. Cyber Resilience Act kræver, at fabrikanter af produkter med digitale elementer udarbejder en SBOM, der som minimum identificerer alle topniveau-afhængigheder i produktet. SBOM'en skal inkluderes i den tekniske dokumentation.

Hvilke formater bruges til SBOM?

De to mest udbredte formater er SPDX (Software Package Data Exchange), som er en ISO-standard, og CycloneDX, som er udviklet af OWASP. Begge er maskinlæsbare og understøttes af de fleste SBOM-værktøjer.

Hvorfor er SBOM vigtig for cybersikkerhed?

En SBOM giver dig overblik over alle komponenter i dit produkt. Når en ny sårbarhed opdages i et bibliotek, kan du hurtigt identificere, om dit produkt er berørt. Uden SBOM er du blind over for risici i dine afhængigheder.

Skal SBOM deles med kunderne?

CRA kræver, at SBOM'en indgår i den tekniske dokumentation og stilles til rådighed for markedsovervågningsmyndigheder. CRA kræver ikke offentliggørelse til alle kunder, men mange brancher bevæger sig mod øget gennemsigtighed, og kunder kan kræve det som del af en indkøbsproces.