Vergelijken
CRA-compliance: SBOM-eisen en tools
De Cyber Resilience Act maakt een software bill of materials verplicht voor producten met digitale elementen. Dit is wat de verordening ervan vraagt, wat de Duitse BSI-richtlijn toevoegt en hoe tools voor CRA-compliance zich tot elkaar verhouden.
Bijgewerkt op
Elke vergelijking laat zien waar het andere product goed in is, waarin CRACI verschilt en wanneer u beide zou gebruiken. Zie alle vergelijkingen voor elke categorie.
Wat de CRA van een SBOM vraagt
De Cyber Resilience Act, Verordening (EU) 2024/2847, plaatst de SBOM in de eisen voor de behandeling van kwetsbaarheden. De verordening vraagt minder dan veel mensen denken: een machineleesbare registratie van ten minste de afhankelijkheden op het hoogste niveau, opgenomen in de technische documentatie en op verzoek getoond aan een autoriteit. Hieronder staat per vraag wat de verordening zegt.
| Functie | Wat de CRA zegt | Waar |
|---|---|---|
| Is een SBOM verplicht? | Ja. Fabrikanten moeten de componenten in hun producten identificeren en documenteren, "onder meer door een softwarestuklijst op te stellen" | Bijlage I, deel II, punt 1 |
| Wat is een SBOM? | "Een formele registratie met details en toeleveringsketenrelaties van componenten die zijn opgenomen in de software-elementen van een product met digitale elementen" | Artikel 3, punt 39 |
| Welk formaat? | "Een algemeen gebruikt en machineleesbaar formaat". De Commissie kan het formaat en de elementen bij uitvoeringshandelingen specificeren | Bijlage I, deel II, punt 1; artikel 13, lid 24 |
| Hoe diep? | "Ten minste de afhankelijkheden op het hoogste niveau van de producten" | Bijlage I, deel II, punt 1 |
| Waar hoort hij thuis? | In de technische documentatie, als onderdeel van de informatie over de behandeling van kwetsbaarheden | Bijlage VII, punt 2, b) |
| Moet hij openbaar zijn? | Nee. "Fabrikanten mogen niet worden verplicht de SBOM openbaar te maken." Deelt u hem met gebruikers, dan staat in de gebruikersinformatie waar hij te vinden is | Overweging 77; bijlage II, punt 9 |
| Wie kan erom vragen? | Een markttoezichtautoriteit, op een met redenen omkleed verzoek, om de naleving te controleren. Autoriteiten kunnen ook SBOM's opvragen voor een EU-brede beoordeling van afhankelijkheden | Bijlage VII, punt 8; artikel 13, lid 25 |
| Hoe lang bewaren? | De technische documentatie wordt ten minste 10 jaar bewaard nadat het product in de handel is gebracht, of gedurende de ondersteuningsperiode als die langer is | Artikel 13, lid 13 |
De verordening is volledig van toepassing vanaf 11 december 2027, en de meldplichten gelden vanaf 11 september 2026. Voor de rest van de verordening, zie wat de CRA vereist.
Verder dan het minimum: BSI TR-03183-2
Zolang de Commissie het formaat niet bij uitvoeringshandeling heeft vastgelegd, komt de meest gedetailleerde openbare richtlijn van het Duitse Bundesamt für Sicherheit in der Informationstechnik (BSI). De technische richtlijn TR-03183-2, versie 2.1.0 van augustus 2025, is een richtlijn en geen onderdeel van de verordening, maar laat zien waar de verwachtingen naartoe gaan:
- Formaat: JSON of XML, geldig volgens CycloneDX 1.6 of hoger, of SPDX 3.0.1 of hoger.
- Diepgang: recursieve resolutie van afhankelijkheden voor elk component binnen de leveringsomvang, tot en met het eerste component daarbuiten.
- Bron van waarheid: de SBOM moet "dezelfde informatie bevatten als tijdens het buildproces beschikbaar is", of gelijkwaardige informatie als er geen buildproces is.
De richtlijn benoemt ook de soorten SBOM. Een Build SBOM "wordt aangemaakt als onderdeel van het buildproces". Een Analysed SBOM "wordt na het buildproces aangemaakt door artefacten te analyseren, zoals uitvoerbare bestanden, pakketten, containers en images van virtuele machines". Dat onderscheid is het belangrijkste verschil tussen de tools op deze pagina.
Afhankelijkheden op het hoogste niveau of transitieve
Afhankelijkheden op het hoogste niveau zijn de ondergrens, niet het doel. Een kwetsbaarheid in een transitief pakket zit nog steeds in uw product, en de CRA vraagt fabrikanten kwetsbaarheden aan te pakken en te verhelpen in de componenten die ze leveren. Een SBOM die bij het eerste niveau stopt, laat die pakketten buiten uw kwetsbaarheidsafhandeling. De praktische vraag is niet of u transitieve afhankelijkheden vastlegt, maar hoe u zeker weet dat de vastlegging overeenkomt met wat er is geleverd. Zie transitieve afhankelijkheden voor hoe u ze opsomt en kwetsbare versies oplost.
Build SBOM of analysed SBOM
De meeste SBOM-tools genereren na de build een analysed SBOM, of beheren SBOM's die andere tools maken. CRACI legt een build SBOM vast terwijl de build draait. Voor een vergelijking van SBOM-generatoren en -beheertools, zie SBOM-beheer en SBOM-tools vergeleken. Voor tools die rond de CRA zijn gebouwd, zie tools voor CRA-compliance vergeleken.
Waar CRACI past
CRACI legt de SBOM vast terwijl uw GitHub Actions-build draait. Een proxy op de runner die pakketten herkent, legt elk pakket vast dat de job heeft opgehaald, inclusief pakketten die uit CI-caches worden teruggezet, zodat de SBOM de build beschrijft die het artefact heeft gemaakt en niet een scan die ergens in de buurt draaide. De SBOM van elke job heeft een volledigheidsstatus, en exports in CycloneDX en SPDX bevatten transitieve afhankelijkheden en de gedeclareerde licentie van elk component.
Na de release blijft CRACI gemonitorde SBOM's opnieuw beoordelen zodra er nieuwe kwetsbaarheden verschijnen, en het dient de CRA-meldingen (vroegtijdige waarschuwing, melding en eindrapport) namens u in. De API levert SBOM's, netwerktraces en herkomstgegevens. CRACI bewaart buildgegevens standaard 180 dagen, met een aangepaste bewaartermijn bij Enterprise, dus exporteer wat in uw technisch dossier van 10 jaar hoort. CRACI automatiseert een aanzienlijk deel van het inzicht in de keten en het bewijs dat uw CRA-proces nodig heeft; de conformiteitsbeoordeling en het technisch dossier blijven de verantwoordelijkheid van de fabrikant. Voor alle CRA-eisen als stappenplan, zie de CRA-gids. Lees meer over SBOM-generatie tijdens de build, of boek een demo om een SBOM te zien die uit een van uw eigen builds is vastgelegd.
CRACI vergeleken met elke tool
- CRACI vs Cybeats Een system of record voor SBOM's tegenover vastgelegde en gemonitorde SBOM's.
- CRACI vs FOSSA SBOM-beheer tegenover build, SBOM en monitoring in één.
- CRACI vs Anchore Images scannen tegenover builds vastleggen en monitoren.
- CRACI vs Black Duck Scannen van code, snippets en binaries tegenover bewijs uit de build.
- CRACI vs Sonatype Repository-poortwachter en SCA tegenover bewijs uit de build.
- CRACI vs ONEKEY Binaire firmwareanalyse tegenover bewijs uit de build.
- CRACI vs Finite State Analyse van binaries en leveranciers-SBOM's tegenover een vastlegging van de build.
- CRACI vs Exein Runtimebeveiliging op het apparaat tegenover bewijs uit de build.
Naast elkaar
Meerdere tools op één pagina, voor als u een categorie kiest en niet één product.
Vragen over de CRA-SBOM, beantwoord
Vereist de CRA transitieve afhankelijkheden in de SBOM?
De verordening legt de ondergrens bij "ten minste de afhankelijkheden op het hoogste niveau van de producten" (bijlage I, deel II, punt 1). Transitieve afhankelijkheden worden niet genoemd, maar een kwetsbaar transitief pakket zit nog steeds in uw product, en de CRA vraagt u kwetsbaarheden af te handelen in de componenten die u levert. De Duitse BSI-richtlijn TR-03183-2 gaat verder en vraagt om recursieve resolutie van afhankelijkheden.
Moet de CRA-SBOM openbaar zijn?
Nee. Volgens overweging 77 mogen fabrikanten niet worden verplicht de SBOM openbaar te maken. Hij hoort in de technische documentatie, en een markttoezichtautoriteit kan hem met een met redenen omkleed verzoek opvragen. Kiest u ervoor hem met gebruikers te delen, dan moet de informatie bij het product vermelden waar hij te vinden is (bijlage II, punt 9).
Moet een CRA-SBOM in CycloneDX of SPDX zijn?
De CRA vraagt om "een algemeen gebruikt en machineleesbaar formaat" en noemt er geen; de Commissie kan het formaat bij uitvoeringshandeling specificeren (artikel 13, lid 24). CycloneDX en SPDX zijn de twee gangbare keuzes. BSI TR-03183-2 v2.1.0 accepteert CycloneDX 1.6 of hoger en SPDX 3.0.1 of hoger, in JSON of XML.
Hoe lang moet ik de SBOM bewaren?
De SBOM maakt deel uit van de technische documentatie, die fabrikanten ten minste 10 jaar nadat het product in de handel is gebracht ter beschikking houden van markttoezichtautoriteiten, of gedurende de ondersteuningsperiode als die langer is (artikel 13, lid 13).
Wanneer gaan de SBOM-eisen van de CRA gelden?
De meldplichten van de CRA gelden vanaf 11 september 2026, en de verordening is volledig van toepassing, inclusief de SBOM-eis in bijlage I, vanaf 11 december 2027.
Andere categorieën
Bekijk CRACI in uw eigen pipeline
Boek een demo en we lopen samen uw builds, uw SBOM's en uw nalevingsbewijs door.
Demo boeken