SBOM under Cyber Resilience Act: Fra komponentliste til sårbarhedshåndtering

Du får en klar forklaring på, hvad en SBOM er, og hvad Cyber Resilience Act kræver.
Du ser, hvorfor en komponentliste først skaber værdi, når den kobles til produkter og risici.
Du får fem arbejdsspor til generation, kvalitet, overvågning, ansvar og dokumentation.
Du kan bruge modellen til at prioritere en realistisk indsats frem mod fuld CRA-compliance.

En moderne softwareløsning består sjældent kun af virksomhedens egen kode. Biblioteker, open source-komponenter, pakker og indlejrede tjenester kan tilsammen udgøre en lang forsyningskæde. Hvis en sårbarhed bliver offentliggjort, skal producenten hurtigt kunne afgøre, hvilke produkter og versioner der er berørt. Her er en SBOM, en Software Bill of Materials, blevet et centralt arbejdsredskab.

Aktualiteten er tydelig. ENISA offentliggjorde i juni 2026 sin europæiske status for SBOM-anvendelse og vurderer, at Cyber Resilience Act accelererer indførelsen. Den 27. juli fulgte Europa-Kommissionen med ny, ikke-bindende vejledning om CRA. For danske softwareproducenter er opgaven derfor at få komponentdata ind i udvikling, vedligeholdelse og dokumentation, før den fulde forordning finder anvendelse 11. december 2027.

Hvad kræver Cyber Resilience Act af en SBOM?

Cyber Resilience Act, CRA, kræver, at producenter identificerer og dokumenterer sårbarheder og komponenter i produkter med digitale elementer. Bilag I, del II, angiver, at dette blandt andet skal ske gennem en SBOM i et almindeligt anvendt, maskinlæsbart format, som mindst dækker produktets direkte afhængigheder. Kravet indgår i den samlede sårbarhedshåndtering og bør ikke læses som et isoleret krav om at eksportere en fil.

Forordningen giver EU-Kommissionen mulighed for senere at specificere format og elementer nærmere. Det taler for en løsning, der kan tilpasses. Et værktøjsvalg bør derfor vurderes på datakvalitet, sporbarhed og integration, ikke kun på hvilket format der kan genereres i dag.

SBOM-kravene gælder som del af CRA’s fulde anvendelse fra december 2027. De må ikke forveksles med rapporteringspligten for aktivt udnyttede sårbarheder og alvorlige sikkerhedshændelser, som begynder 11. september 2026. En brugbar SBOM kan støtte rapporteringsprocessen, men den ændrer ikke fristerne eller kriterierne for rapportering.

En komponentliste er kun begyndelsen

En SBOM kan vise, at et produkt indeholder en bestemt komponent og version. Den kan ikke alene afgøre, om sårbar kode faktisk kan nås, om komponenten er eksponeret, eller hvad et angreb betyder for kundens drift. Derfor skal komponentdata forbindes med produktversioner, byggeprocesser, supportperioder, sikkerhedsvarsler og en dokumenteret risikovurdering.

Datakvaliteten er afgørende. Dubletter, manglende versionsnumre og uklare komponentnavne kan skabe falske alarmer eller skjule reel eksponering. Samtidig skal virksomheden kende de begrænsninger, der følger med automatiske scannere. Resultatet bør kunne efterprøves mod kildekode, build-filer og de binære komponenter, der faktisk leveres.

Arbejdet hænger naturligt sammen med Secure SDLC og med den eksisterende CRA-compliance. SBOM’en giver komponentoverblik; udviklings- og sårbarhedsprocessen afgør, om overblikket fører til rettidige beslutninger.

Fastlæg omfang og ejerskab

Kortlæg de produkter og versioner, som virksomheden gør tilgængelige på EU-markedet. Udpeg en ansvarlig for SBOM-processen og en teknisk ejer for hvert produkt.

Generér SBOM som del af build-processen

Automatisér generationen, så komponentlisten følger den konkrete produktversion. Gem den sammen med versions- og releasebeviser, så det senere kan dokumenteres, hvad der blev leveret.

Kontrollér kvalitet og dækning

Test om direkte afhængigheder, versionsnumre og leverandørnavne er korrekte. Aftal hvordan transitive afhængigheder og proprietære komponenter håndteres, selv hvor minimumskravet er smallere.

Kobl listen til sårbarhedshåndtering

Overvåg relevante advisories og forbind et nyt sårbarheds-ID med berørte produkter, eksponering og forretningskonsekvens. Dokumentér beslutningen om rettelse, afværgning, overvågning eller begrundet risikoaccept.

Stil krav gennem leverandørkæden

Aftal, hvilke komponentdata leverandører skal levere, hvor hurtigt de varsler om sårbarheder, og hvordan rettelser og supportperioder dokumenteres. En SBOM uden opdaterede leverandørdata bliver hurtigt historisk.

Ledelsen behøver ikke måle succes på antallet af registrerede komponenter. Mere anvendelige mål er, hvor stor en del af produktporteføljen der har en versionsbundet SBOM, hvor hurtigt en ny sårbarhed kan matches til produkter og kunder, hvor mange kritiske fund der mangler en ejer, og om beslutninger kan genfindes.

Start med ét aktivt produkt med flere tredjepartsafhængigheder. Generér en SBOM, kontrollér den mod det leverede produkt og gennemfør en øvelse med en kendt sårbarhed i en direkte afhængighed. Øvelsen bør ende med et spor af data, ansvar, risikovurdering, beslutning og kundekommunikation. Det er denne sammenhæng, der gør SBOM til sårbarhedshåndtering i praksis og samtidig skaber dokumentation, som kan bruges i arbejdet med Cyber Resilience Act, CRA.