Wat de verordening vraagt
Bijlage I, deel II, punt 1, van Verordening (EU) 2024/2847: fabrikanten moeten de kwetsbaarheden en componenten in producten met digitale elementen identificeren en documenteren, onder meer door een softwarestuklijst op te stellen in een gangbaar en machineleesbaar formaat, die ten minste de afhankelijkheden op het hoogste niveau van de producten dekt. Dit geldt vanaf 11 december 2027 (artikel 71).
- De SBOM hoort bij de technische documentatie, met de processen voor de behandeling van kwetsbaarheden (bijlage VII, punt 2, b)).
- U geeft haar op een met redenen omkleed verzoek aan een markttoezichtautoriteit (bijlage VII, punt 8). U hoeft haar niet openbaar te maken (overweging 77).
- Als u ervoor kiest haar beschikbaar te stellen aan gebruikers, zegt de gebruikersinformatie waar (bijlage II, punt 9).
- De Commissie kan het formaat en de elementen bij uitvoeringshandeling vaststellen (artikel 13, lid 24). CycloneDX en SPDX zijn gangbare formaten.
Wat deze pagina schrijft
Een CycloneDX 1.6-JSON-bestand met uw product als hoofdcomponent, elk pakket met de exacte versie en pakket-URL (purl), en de afhankelijkheden op het hoogste niveau van het product waar het lockbestand zegt welke dat zijn. Het leest:
- npm package-lock.json (lockfileVersion 2 of 3), Yarn yarn.lock (Yarn 1, 2 en later) en pnpm-lock.yaml (lockfileVersion 9.0); pakketten die alleen voor ontwikkeling zijn, worden weggelaten waar het bestand zegt welke dat zijn;
- Python requirements.txt met elk pakket vastgepind (naam==versie), zoals pip freeze of pip-compile het schrijft;
- Rust Cargo.lock, versie 3 of 4, en Go go.mod, met de indirecte modules;
- de Maven-afhankelijkheidsboom die mvn dependency:tree -DoutputFile schrijft, en Gradle gradle.lockfile; pakketten met test-scope worden weggelaten;
- PHP Composer composer.lock, zonder packages-dev, en NuGet packages.lock.json.
Een bestand dat zijn formaat niet volgt, wordt niet gelezen, met de regel en de reden, in plaats van geraden. Een pakket uit een andere bron dan het openbare register wordt zonder pakket-URL vermeld, zodat het bestand nooit verwijst naar een pakket dat u niet hebt gebruikt.
Hebt u al een SBOM uit een ander hulpmiddel? Open die als CycloneDX-JSON-bestand, of als SPDX-JSON-bestand zoals het bestand dat de afhankelijkheidsgrafiek van GitHub exporteert (Export SBOM), om de componenten op OSV.dev en aan de hand van de KEV-catalogus te controleren. Het wordt alleen voor de controle gelezen: open de lockbestanden om een nieuwe SBOM te maken. Waar geen lockbestand een versie vastpint, geeft het bestand van GitHub een bereik zoals ^4.17.0: die componenten worden als niet gecontroleerd vermeld, dus open het lockbestand om ze te controleren.
Bekende uitgebuite kwetsbaarheden
De controle markeert elke op OSV.dev gevonden kwetsbaarheid waarvan het CVE-nummer in de catalogus van bekende uitgebuite kwetsbaarheden (KEV) van het Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) staat, met de datum waarop CISA haar toevoegde. CISA neemt een kwetsbaarheid op zodra er betrouwbaar bewijs is dat ze is uitgebuit. Vanaf 11 september 2026 vraagt artikel 14 van de CRA u een actief uitgebuite kwetsbaarheid in uw product (artikel 3, punt 42) te melden binnen 24 uur nadat u er kennis van hebt gekregen. Een KEV-vermelding beslist dat niet voor uw product, maar het is de eerste plek om te kijken; de pagina over de meldingstermijnen telt de uren.
Wat het niet dekt
De SBOM vermeldt wat de lockbestanden vermelden. Code die u in het product hebt gekopieerd, pakketten van het besturingssysteem, firmware en bibliotheken in andere talen staan er niet in: voeg die zelf aan het bestand toe. De controle op kwetsbaarheden gebruikt OSV.dev, dat alleen gepubliceerde kwetsbaarheden vermeldt; ze vervangt niet de beoordeling van kwetsbaarheden die bijlage I, deel II, vraagt.
Voor de rest van de CRA-bestanden schrijft het CRA-documentenpakket de technische documentatie en de EU-conformiteitsverklaring. De CRA-check vertelt u de klasse van uw product.