CRA-compliance: krav til SBOM'en og værktøjer sammenlignet

Hver sammenligning fortæller, hvad det andet produkt gør godt, hvor CRACI er anderledes, og hvornår du ville bruge begge. Se alle sammenligninger for alle kategorier.

Hvad CRA kræver af en SBOM

Cyber Resilience Act, forordning (EU) 2024/2847, placerer SBOM'en i sine krav til sårbarhedshåndtering. Den kræver mindre, end mange tror: en maskinlæsbar registrering af som minimum afhængighederne på øverste niveau, opbevaret i den tekniske dokumentation og vist til en myndighed på anmodning. Her er, hvad forordningen siger, spørgsmål for spørgsmål.

CRA's krav til SBOM'er i forordning (EU) 2024/2847
Funktion	Hvad CRA siger	Hvor
Er en SBOM obligatorisk?	Ja. Producenter skal identificere og dokumentere komponenterne i deres produkter, "herunder ved at udarbejde en softwarestykliste"	Bilag I, del II, punkt 1
Hvad er en SBOM?	"En formel registrering, der indeholder oplysninger om og forsyningskæderelationer for komponenter, der indgår i softwareelementerne i et produkt med digitale elementer"	Artikel 3, nr. 39
Hvilket format?	"Et almindeligt anvendt og maskinlæsbart format". Kommissionen kan fastlægge formatet og elementerne ved gennemførelsesretsakter	Bilag I, del II, punkt 1; artikel 13, stk. 24
Hvor dybt?	"Som minimum produkternes afhængigheder på øverste niveau"	Bilag I, del II, punkt 1
Hvor skal den ligge?	I den tekniske dokumentation, som en del af oplysningerne om sårbarhedshåndtering	Bilag VII, punkt 2, litra b
Skal den være offentlig?	Nej. "Producenter bør ikke være forpligtet til at offentliggøre SBOM'en." Deler du den med brugerne, skal brugeroplysningerne angive, hvor den findes	Betragtning 77; bilag II, punkt 9
Hvem kan bede om den?	En markedsovervågningsmyndighed, efter en begrundet anmodning, for at kontrollere overholdelsen. Myndigheder kan også anmode om SBOM'er til en EU-dækkende vurdering af afhængigheder	Bilag VII, punkt 8; artikel 13, stk. 25
Hvor længe skal den opbevares?	Den tekniske dokumentation opbevares i mindst 10 år efter, at produktet er bragt i omsætning, eller i supportperioden, hvis den er længere	Artikel 13, stk. 13

Forordningen gælder fuldt ud fra 11. december 2027, og dens rapporteringsforpligtelser gælder fra 11. september 2026. Resten af forordningen finder du under hvad CRA kræver.

Ud over minimum: BSI TR-03183-2

Indtil Kommissionen fastlægger formatet ved gennemførelsesretsakt, kommer den mest detaljerede offentlige vejledning fra Tysklands forbundskontor for informationssikkerhed (BSI). Dets tekniske retningslinje TR-03183-2, version 2.1.0 fra august 2025, er vejledning og ikke en del af forordningen, men den viser, hvor forventningerne er på vej hen:

Format: JSON eller XML, gyldigt i forhold til CycloneDX 1.6 eller nyere eller SPDX 3.0.1 eller nyere.
Dybde: rekursiv resolving af afhængigheder for hver komponent i leveranceomfanget, ned til og med den første komponent uden for det.
Sandhedskilde: SBOM'en skal indeholde "de samme oplysninger, som er tilgængelige under build-processen", eller tilsvarende oplysninger, hvor der ikke er nogen build-proces.

Retningslinjen navngiver også typerne af SBOM. En Build SBOM "oprettes som en del af build-processen". En Analysed SBOM "oprettes efter build-processen ved at analysere artefakter som eksekverbare filer, pakker, containere og images til virtuelle maskiner". Den skelnen er den vigtigste forskel mellem værktøjerne på denne side.

Afhængigheder på øverste niveau eller transitive afhængigheder

Afhængigheder på øverste niveau er bunden, ikke målet. En sårbarhed i en transitiv pakke er stadig i dit produkt, og CRA kræver, at producenter håndterer og afhjælper sårbarheder i de komponenter, de leverer. En SBOM, der stopper ved første niveau, udelader de pakker fra din sårbarhedshåndtering. Det praktiske spørgsmål er ikke, om transitive afhængigheder skal registreres, men hvordan du sikrer, at registreringen svarer til det, der blev leveret. Se transitive afhængigheder for, hvordan du lister dem og retter de sårbare.

Build SBOM eller analyseret SBOM

De fleste SBOM-værktøjer genererer en analyseret SBOM efter buildet eller administrerer SBOM'er, som andre værktøjer producerer. CRACI registrerer en build-SBOM, mens buildet kører. En sammenligning af SBOM-generatorer og -administrationsværktøjer finder du under SBOM-administration og SBOM-værktøjer sammenlignet. Værktøjer bygget op omkring CRA finder du under CRA-compliance-værktøjer sammenlignet.

Hvor CRACI passer ind

CRACI registrerer SBOM'en, mens dit GitHub Actions-build kører. En pakkebevidst proxy på runneren registrerer hver pakke, jobbet hentede, inklusive pakker gendannet fra CI-caches, så SBOM'en beskriver det build, der producerede artefaktet, og ikke en scanning, der kørte et sted i nærheden. Hvert jobs SBOM har en fuldstændighedsstatus, og eksporter i CycloneDX og SPDX indeholder transitive afhængigheder og hver komponents deklarerede licens.

Efter release genvurderer CRACI løbende overvågede SBOM'er, efterhånden som nye sårbarheder dukker op, og indsender CRA-underretningerne (tidlig varsling, underretning og endelig rapport) på dine vegne. API'et returnerer SBOM'er, netværkstraces og provenance. CRACI opbevarer build-data i 180 dage som standard, med tilpasset opbevaring på Enterprise, så eksportér det, der hører hjemme i din tekniske dokumentation, som skal opbevares i 10 år. CRACI automatiserer en væsentlig del af den synlighed i og dokumentation for forsyningskæden, som din CRA-proces har brug for; overensstemmelsesvurderingen og den tekniske dokumentation forbliver producentens ansvar. Alle CRA-krav som en trin-for-trin-køreplan finder du i CRA-guiden. Læs mere om SBOM-generering under buildet, eller book en demo for at se en SBOM registreret fra et af dine builds.

CRACI sammenlignet med hvert værktøj

Side om side

Flere værktøjer på én side, til når du vælger en kategori og ikke ét produkt.

Værktøjer til CRA-overholdelse sammenlignet Værktøjer, der hjælper producenter med at opfylde Cyber Resilience Act.

Spørgsmål om CRA-SBOM'er, besvaret

Kræver CRA transitive afhængigheder i SBOM'en?

Forordningen sætter bunden ved "som minimum produkternes afhængigheder på øverste niveau" (bilag I, del II, punkt 1). Transitive afhængigheder nævnes ikke, men en sårbar transitiv pakke er stadig i dit produkt, og CRA kræver, at du håndterer sårbarheder i de komponenter, du leverer. Tysklands BSI-retningslinje TR-03183-2 går videre og kræver rekursiv resolving af afhængigheder.

Skal CRA-SBOM'en være offentlig?

Nej. Betragtning 77 siger, at producenter ikke bør være forpligtet til at offentliggøre SBOM'en. Den hører hjemme i den tekniske dokumentation, og en markedsovervågningsmyndighed kan anmode om den med en begrundet anmodning. Vælger du at dele den med brugerne, skal de oplysninger, der følger med produktet, angive, hvor den findes (bilag II, punkt 9).

Skal en CRA-SBOM være i CycloneDX eller SPDX?

CRA kræver "et almindeligt anvendt og maskinlæsbart format" og nævner ikke noget bestemt; Kommissionen kan fastlægge formatet ved gennemførelsesretsakt (artikel 13, stk. 24). CycloneDX og SPDX er de to almindelige valg. BSI TR-03183-2 v2.1.0 accepterer CycloneDX 1.6 eller nyere og SPDX 3.0.1 eller nyere, i JSON eller XML.

Hvor længe skal jeg opbevare SBOM'en?

SBOM'en er en del af den tekniske dokumentation, som producenter skal stille til rådighed for markedsovervågningsmyndighederne i mindst 10 år efter, at produktet er bragt i omsætning, eller i supportperioden, hvis den er længere (artikel 13, stk. 13).

Hvornår gælder CRA's krav til SBOM'er?

CRA's rapporteringsforpligtelser gælder fra 11. september 2026, og forordningen gælder fuldt ud, inklusive SBOM-kravet i bilag I, fra 11. december 2027.

CRA-compliance: krav til SBOM'en og værktøjer