CRA SBOM-krav: format, omfattning, uppdateringar och lagring
CRA kräver att varje produkt med digitala element levereras med en maskinläsbar Software Bill of Materials (SBOM) som listar produktens programvarukomponenter och täcker minst deras top-level-beroenden. SBOM:en finns i din tekniska dokumentation och måste vara redo för en marknadskontrollmyndighet på begäran, inte inlämnad i förväg.
Sammanfattning
- Varje produkt med digitala element behöver en maskinläsbar SBOM som del av bevisen för sårbarhetshantering. Den är obligatorisk, utan undantag baserat på storlek.
- Den rättsliga miniminivån är top-level-beroenden. Täckning av transitiva beroenden är starkare praxis och det som de flesta SBOM-kvalitetsramverk förväntar sig.
- En produkt innebär en samling SBOM-bevis, även när produkten byggs av många kodförråd eller komponenter.
- Håll SBOM:en aktuell under stödperioden, särskilt efter releaser, komponentändringar och sårbarhetsbeslut.
- Spara SBOM:en tillsammans med den tekniska dokumentationen i minst 10 år, eller under stödperioden om den är längre.
- Skyldigheten att rapportera sårbarheter börjar 11 september 2026; full CRA-tillämpning är 11 december 2027.
Vad är en SBOM?
En Software Bill of Materials (SBOM) är en strukturerad inventering av programvaran inuti en produkt: bibliotek, ramverk, operativsystempaket och beroendena mellan dem. För CRA är det den post en marknadskontrollmyndighet skulle använda för att kontrollera vilka av dina komponenter som berörs av en rapporterad sårbarhet, så den måste vara maskinläsbar snarare än ett dokument i löptext.
Vad CRA kräver i en SBOM
SBOM-skyldigheten har två praktiska lager: vad inventeringen måste täcka och var beviset ska finnas i den tekniska dokumentationen.
Vilka komponenter måste SBOM:en täcka?
Tillverkare måste identifiera och dokumentera komponenterna och sårbarheterna i sina produkter med digitala element och upprätta en SBOM i ett allmänt använt och maskinläsbart format som åtminstone täcker produktens top-level-beroenden.
Det betyder:
- SBOM:en måste vara maskinläsbar och i ett allmänt använt format. En PDF eller ett kalkylblad kan hjälpa människor att granska inventeringen, men ersätter inte SBOM-filen.
- Den måste åtminstone täcka top-level-beroenden. Täckning av transitiva beroenden går utöver den rena miniminivån, och är en bättre bas för sårbarhetsövervakning.
Varje produkt med digitala element som släpps ut på EU-marknaden måste ha en maskinläsbar SBOM. Det finns inget undantag och ingen storleksgräns under vilken skyldigheten försvinner. Hur mycket detalj du dokumenterar skalar med produktens risk, men skyldigheten att upprätta en SBOM gör det inte.
Just nu kräver reglerna bara ett allmänt använt och maskinläsbart format som åtminstone täcker top-level-beroenden. De namnger inte ett specifikt format eller en fast fältlista. Den miniminivån kan höjas: CRA lämnar utrymme för kommissionen att senare fastställa ett exakt SBOM-format och en exakt fältuppsättning. Att välja ett välstött format nu, CycloneDX eller SPDX, och fånga mer än det absoluta minimum, är den säkraste gardering mot ett framtida föreskrivet format.
Var SBOM:en finns i den tekniska dokumentationen
SBOM:en är del av din tekniska dokumentation, arkiverad tillsammans med övriga bevis för sårbarhetshantering: policyn för samordnad delgivning av sårbarhetsinformation, en kontaktadress för rapportering och hur du distribuerar uppdateringar säkert. Du lämnar inte in den i förväg. Den måste finnas när produkten släpps ut på EU-marknaden och vara redo för en marknadskontrollmyndighet om den gör en motiverad begäran.
I praktiken bör SBOM:en låta dig göra sårbarhetsspårning på komponentnivå, kontroller av leverantör och ursprung, licensgranskning och planering för livscykelns slut.
Hur många SBOM:ar behöver en produkt?
En produkt byggs ofta av många kodförråd och komponenter, och var och en kan generera sin egen SBOM. CRA fastställer enheten för bevis till produkten, inte kodförrådet eller bygget.
CRA definierar en SBOM som en post över komponenterna i en produkts programvara och hur de förhåller sig till varandra, och förväntar sig att posten åtminstone täcker produktens top-level-beroenden. Bevisobjektet är produkten du släpper ut på EU-marknaden, identifierad med produkt och version. En produkt sammansatt av tio kodförråd täcks inte av tio lösa komponent-SBOM:ar som inget binder samman. Du är skyldig SBOM-bevis som representerar produkten så som den levereras.
CRA föreskriver ingen enskild fysisk fil, och förbjuder inte att man behåller komponent-SBOM:ar. Två vägar fungerar båda, så länge resultatet är maskinläsbart, sitter på produktnivå och åtminstone täcker top-level-beroenden:
- Sätta samman. Behåll komponent-SBOM:ar som separata dokument och länka dem till en produkt-SBOM, med CycloneDX-monteringskomponenter med BOM-Link-referenser, eller SPDX-relationer med externa dokumentreferenser.
- Slå samman. Platta ut varje komponent till ett enda CycloneDX- eller SPDX-dokument för produktversionen.
Eftersom SBOM:en är tänkt att fånga hur komponenter förhåller sig till varandra räcker en platt lista med paketnamn inte på egen hand. Oavsett vilken väg du väljer bör SBOM:en visa hur komponenter beror på och innehåller varandra, vilket både CycloneDX beroendegrafer och SPDX-relationer ger. För formatets mekanik, se CycloneDX vs SPDX.
Vem måste få SBOM:en?
SBOM:en är material i den tekniska dokumentationen, inte ett offentligt dokument. CRA kräver inte att du publicerar den, och den enda part som kan kräva ut den är en marknadskontrollmyndighet, som kan begära den genom en motiverad begäran när den behöver kontrollera din efterlevnad. Att dela SBOM:en med användare är frivilligt. Om du väljer att dela den med användare måste du sedan tala om för dem var den finns.
| Vem | Vad CRA förväntar sig |
|---|---|
| Marknadskontrollmyndighet | Kan begära SBOM:en genom en motiverad begäran, när den behövs för att kontrollera efterlevnad |
| Användare och allmänhet | Ingen skyldighet att publicera eller lämna ut den; att dela är ditt val |
| Importörer och distributörer | Ingen rätt till själva SBOM:en; de måste kunna förse myndigheter med din tekniska dokumentation på begäran |
| Integratörer som bygger på din produkt | Där din produkt är avsedd att integreras i deras ger du dem den information de behöver för att uppfylla sina egna skyldigheter, vilket inte automatiskt är hela SBOM:en |
Publicera inte SBOM:en och skicka den inte till användare som standard. En SBOM är en exakt karta över dina komponenter och versioner, vilket är just vad en angripare vill ha, och CRA ger dig ingen skyldighet att lämna ut den brett. Släpp den till en marknadskontrollmyndighet när den gör en motiverad begäran, och till företagskunder som bygger på din produkt, under ett sekretessavtal eller avtal, eftersom de behöver den för att sätta samman sin egen SBOM på produktnivå och uppfylla sina egna skyldigheter. För register över vem som fick vilken version.
Vad SBOM:en måste innehålla
Skilj CRA:s rättsliga miniminivå från fälten som gör SBOM:en användbar i verkliga sårbarhetsflöden. Förordningen sätter minimum. TR-03183, CycloneDX/SPDX-verktyg och kundförväntningar höjer normalt den operativa nivån.
| Område | CRA-minimum | Stark implementering |
|---|---|---|
| Format | Allmänt använt och maskinläsbart | CycloneDX JSON/XML eller SPDX JSON/tag-value, genererat av byggverktyg |
| Omfattning | Åtminstone top-level-beroenden | Direkta och transitiva beroenden, interna bibliotek, firmware och OS-paket där relevant |
| Komponenter | Komponenter i produkten | Komponentnamn, version, leverantör, PURL eller CPE, hash och relationsdata |
| Sårbarheter | Komponenter och sårbarheter identifierade och dokumenterade | Aktuell sårbarhetsstatus, VEX- eller exploaterbarhetsbeslut, åtgärdsreferens och granskningsdatum |
| Teknisk bevisning | SBOM inkluderad med bevis för sårbarhetshanteringsprocessen | Stabil filreferens per produktversion, genereringsverktyg, genereringsdatum och valideringsresultat |
| Myndighetsåtkomst | Tillgänglig där det behövs för en motiverad marknadskontrollbegäran | Säkert arkiv med ansvarig för hämtning, integritetskontroller och täckning under stödperioden |
CRA kräver att du identifierar och dokumenterar sårbarheter, men det betyder inte att sårbarhets- eller VEX-data måste finnas inuti själva SBOM-filen. Att bära det där är god praxis, inte en miniminivå. För fältkraven som går längre än denna checklista (PURL-identifierare, hashvärden, dokumentmetadata), se hur BSI TR-03183 utökar CRA. För en jämförelse av CycloneDX- och SPDX-verktyg, se CycloneDX vs SPDX.
Hur en SBOM-sammanfattning i den tekniska dokumentationen ser ut
En stark teknisk dokumentation parar den maskinläsbara SBOM:en med en kort sammanfattningspost. Sammanfattningen är ett försättsblad för mänsklig granskning. Den faktiska SBOM:en är den bifogade CycloneDX- eller SPDX-fil den pekar på.
SAMMANFATTNING AV SBOM I TEKNISK DOKUMENTATION
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.6
Generated: 2027-01-15
Tools: Syft (generering), Trivy (skanning)
SBOM-FIL:
sbom-ssp3000-v2.4.1.json (bifogad, maskinläsbar)
KOMPONENTSAMMANFATTNING:
-------------------------------------------------------------
Total Components: 127
Direct Dependencies: 23
Transitive Dependencies: 104
By Type:
Libraries: 98
Frameworks: 12
Operating System: 1 (FreeRTOS)
Firmware Modules: 16
SÅRBARHETSSTATUS VID BEDÖMNING:
-------------------------------------------------------------
Scan Date: 2027-01-17
Scanner: Trivy v0.48.0
Critical: 0
High: 0
Medium: 2 (accepterade - se nedan)
ACCEPTERADE SÅRBARHETER:
CVE-2026-15432 (Medium): libexpat 2.5.0
Status: Not exploitable in our configuration
Justification: Feature not enabled, code path not reachable
Review Date: 2027-04-15
-------------------------------------------------------------
När du behöver uppdatera din SBOM
SBOM:en är inte ett engångsdokument. Din tekniska dokumentation måste upprättas innan produkten släpps ut på marknaden och hållas aktuell, där det är lämpligt, åtminstone under stödperioden. Stödperioden återspeglar hur länge produkten förväntas vara i bruk, och den är minst fem år om produkten inte verkligen förväntas vara i bruk kortare tid.
Granska eller regenerera SBOM:en när:
| Trigger | Vad som förändras | Praktisk åtgärd |
|---|---|---|
| Ny firmware- eller programvaruversion | Ny byggartefakt | Regenerera SBOM:en för den produktversionen |
| Säkerhetskorrigering | Komponentversion ändras | Uppdatera berörda komponenter och arkivera ny SBOM |
| Sårbarhet upptäcks och bedöms | VEX- eller exploaterbarhetsstatus ändras | Uppdatera sårbarhetsstatus och beslutsbevis |
| Komponent läggs till, tas bort eller ersätts | Beroendegraf ändras | Regenerera och validera SBOM:en |
| Säkerhetsrelevant designändring | Komponenter eller arkitektur ändras | Regenerera SBOM:en och uppdatera tekniska referenser |
| Tillämpade standarder eller specifikationer ändras | Efterlevnadsmetadata ändras | Granska metadata och länkade bevis |
Periodiska granskningar. CRA sätter inget fast granskningsintervall. Dessa intervall är en praktisk utgångspunkt:
| Intervall | Omfattning |
|---|---|
| Kvartalsvis | SBOM och sårbarhetsstatus |
| Årligen | Fullständig granskning av teknisk dokumentation |
| Innan stödperioden avslutas | Slutlig dokumentationsfrysning |
Varje bygge bör producera en aktuell SBOM-artefakt, så att beviset hålls i takt med det du levererar. Se vanliga SBOM-misstag för vad som går fel när team hoppar över automatisering.
Hur länge SBOM-bevis ska sparas
Spara SBOM:en tillsammans med den tekniska dokumentationen i minst 10 år efter att produkten med digitala element har släppts ut på marknaden, eller under stödperioden om den är längre. Samma lagringsregel gäller för den tekniska dokumentationen och EU-försäkran om överensstämmelse. Detta handlar om att bevara dokumentationen. Det är skilt från skyldigheten att hålla själva säkerhetsuppdateringarna tillgängliga, som löper sina egna tio år från det att varje uppdatering släpps.
För en produktlinje som säljs över tid, spara bevis för de versioner och enheter som släppts ut på marknaden. Behandla inte första lanseringsdatumet som den praktiska slutpunkten för beviskravet medan senare enheter eller versioner fortfarande levereras.
| Milstolpe | Exempeldatum |
|---|---|
| Produkt första gången på marknaden | mars 2027 |
| Sista enhet på marknaden | december 2030 |
| Praktisk bevistäckning | Till december 2040 eller längre om stödperioden kräver det |
Klockan startar från den sista enheten som släpps ut på marknaden, så december 2030 plus tio år når minst december 2040, längre om stödperioden sträcker sig förbi det. Förvara SBOM:en någonstans säkert och säkerhetskopierat, med integritetsskydd, så att du kan hämta och lämna ut rätt version på en motiverad begäran.
Datum och tillämpning
Full CRA-tillämpning är 11 december 2027. Skyldigheten att rapportera sårbarheter börjar tidigare, 11 september 2026. Det tidigare datumet är inte en separat tidsfrist för att lämna in SBOM, men det kräver att du snabbt kan avgöra vilka produktversioner och komponenter som berörs av en rapporteringspliktig sårbarhet eller incident. För produkter som släpps ut på EU-marknaden efter full tillämpning är SBOM:en del av bevisbasen bakom bedömning av överensstämmelse, EU-försäkran om överensstämmelse och CE-märkning. För rapporteringsflödet, se CRA-rapportering av sårbarheter och incidenter. För CRA:s allmänna tidslinje, se vad CRA är; för påföljdstabellen, se CRA-påföljder och tillsyn.
Vanliga frågor
Kräver CRA en maskinläsbar SBOM eller är en PDF godtagbar?
SBOM:en måste vara i ett allmänt använt och maskinläsbart format. En PDF eller ett kalkylblad kan följa med filen för mänsklig granskning, men ersätter inte SBOM:en. CycloneDX eller SPDX serialiserat som JSON eller XML är den praktiska vägen.
Kräver CRA en SBOM för komponenter med öppen källkod?
Ja. Komponenter med öppen källkod är fortfarande komponenter i produkten, så de hör hemma i SBOM:en med version och identifierare. CRA förväntar sig också att du visar tillbörlig aktsamhet med de tredjepartskomponenter du integrerar, inklusive programvara med öppen källkod som inte tillhandahållits dig kommersiellt, och att du rapporterar varje sårbarhet du hittar i en integrerad komponent, även en med öppen källkod, till den som underhåller den.
När ska en SBOM lämnas in: vid marknadsplacering eller på begäran?
SBOM:en lämnas normalt inte in proaktivt. Den måste ingå i den tekniska dokumentationen, vara redo och tillgänglig för marknadskontrollmyndigheter vid motiverad begäran, och finnas när produkten släpps ut på EU-marknaden.
Vad är NTIA:s minimielement och uppfyller de CRA-kraven?
NTIA:s minimielement (leverantörsnamn, komponentnamn, version, unika identifierare, beroendeförhållanden, SBOM-författare och tidsstämpel) är en rimlig startpunkt. De besvarar inte i sig varje bevisfråga enligt CRA eller varje kvalitetsförväntan enligt TR-03183. För CRA-arbete bör den genererade filen valideras mot valt format, sårbarhetsstatus registreras och rikare fält som PURL/CPE, hashvärden och relationsdata fyllas i när kvalitetsramverket kräver det.
Kan jag återanvända SBOM:ar från leverantörer för att uppfylla CRA?
Delvis. Leverantörers SBOM:ar är giltiga ingångar för de delar de levererar, men du är fortfarande skyldig en SBOM för produkten så som den släpps ut på marknaden. Det innebär att konsolidera leverantörers SBOM:ar med dina egna komponenter och byggberoenden till bevis på produktnivå, som beskrivs ovan i hur många SBOM:ar en produkt behöver. Behandla leverantörers SBOM:ar som råmaterial, inte som den färdiga efterlevnadsartefakten.
Vad du gör härnäst
- Välj ett format: CycloneDX för säkerhetsfokus och inbyggt VEX-stöd, SPDX för licensefterlevnad och bredare spridning. Se CycloneDX vs SPDX.
- Automatisera generering i CI/CD med Syft, Trivy, cdxgen eller verktyg för analys av programvarusammansättning (SCA). En engångsexport uppfyller inte den löpande skyldigheten.
- Validera fältkvalitet mot BSI TR-03183 eller din interna SBOM-kvalitetsgrind: namn och version, leverantör, PURL/CPE, beroenden, hashvärden och licenser.
- Koppla SBOM:ar till sårbarhetsövervakning (NVD, OSV, GitHub Advisory Database, CISA KEV) inför de rapporteringsskyldigheter som börjar 11 september 2026.
- Placera SBOM:en i din tekniska dokumentation. Guiden för teknisk dokumentation går igenom var den placeras. Om du hellre inte bygger SBOM-inmatning från grunden hanterar CRA Evidence CycloneDX/SPDX-inmatning och TR-03183-kvalitetsbedömning över produktversioner.