Sårbarhetsanalys och SBOM
CRA gör din programvaruförteckning (SBOM) till en löpande skyldighet: vet vad som finns i din produkt, bevaka dessa komponenter för nya sårbarheter och åtgärda och rapportera dem inom tidsfristerna i artikel 14. Den här sidan går igenom slingan och det gratis verktyg som driver den.
Generera en SBOM
Ta fram en maskinläsbar programvaruförteckning (SBOM) som omfattar åtminstone era beroenden på översta nivån. Detta är ett tvingande krav, inte en rekommenderad praxis.
Så genererar du den ↓Övervaka för sårbarheter
Korsreferera fortlöpande varje komponent mot aktuella sårbarhetsdata (NVD, EUVD). Buntade aviseringssammanställningar uppfyller inte tidsfristen på 24 timmar.
Varför sammandrag inte räcker till ↓Bedöm, åtgärda och rapportera
Dokumentera utnyttjbarheten, leverera en åtgärd och rapportera aktivt utnyttjade sårbarheter till ENISA och CSIRT enligt tidsplanen 24 tim / 72 tim / 14 dagar.
Verktyget som gör detta ↓CRA Vulnerability Analyzer
Ladda upp er SBOM och er lista över aktiva sårbarheter. Analysverktyget korsrefererar varje komponent mot National Vulnerability Database (NVD) och EU:s sårbarhetsdatabas (EUVD), flaggar komponenter som nått slutet av sin livscykel (End-of-Life) och genererar en rapport om överensstämmelse som ni kan bifoga till er tekniska dokumentation.
Instruktionsguider
Generera en regelefterlevande SBOM
En programvaruförteckning är ett tvingande rättsligt krav enligt bilaga I, del II, punkt 1. Denna vägledning behandlar det obligatoriska innehållet och formatet, hur man tar fram en och hur den matar in i övervakningsslingan.
1 · Rättslig grund
Bilaga I, Del II ("Krav för hantering av sårbarheter"), punkt (1) kräver att tillverkare "identifiera och dokumentera sårbarheter och komponenter … bland annat genom att upprätta en programvaruförteckning i ett allmänt använt och maskinläsbart format som omfattar åtminstone produktens beroenden på högsta nivå."
Till skillnad från vissa bestämmelser i CRA som tillåter tolkningsutrymme medger skyldigheten att ta fram en maskinläsbar SBOM som åtminstone omfattar beroenden på översta nivån inga alternativa tillvägagångssätt.
2 · Obligatoriskt tillämpningsområde och format
Komponenttäckning. Programvaruförteckningen (SBOM) ska dokumentera alla beroenden på högsta nivå, vilket är det rättsliga minimikravet snarare än den rekommenderade målnivån. Kartlägg transitiva (indirekta) beroenden där det är möjligt; en ytlig programvaruförteckning uppfyller lagens bokstav men är ofta otillräcklig för effektiv sårbarhetshantering.
Format. CRA föreskriver ett "allmänt använt, maskinläsbart format". Godtagna format omfattar:
- SPDX (ISO/IEC 5962:2021): allmänt använt, licensinriktat och lämpat för efterlevnadsdokumentation.
- CycloneDX: säkerhetsinriktad, väl lämpad för arbetsflöden för hantering av sårbarheter.
- Andra strukturerade format (JSON, XML) från erkända verktyg är i allmänhet godtagbara enligt grundkravet.
Lagra inte SBOM:er som PDF. PDF kan ifrågasättas som icke maskinläsbar av marknadskontrollmyndigheter. Lagra det ursprungliga JSON-, XML- eller tag-value-resultatet från din verktygskedja.
Obligatoriska metadatafält
| Fält | Beskrivning |
|---|---|
| Komponentnamn | Unik identifierare för biblioteket, paketet eller modulen |
| Version | Exakt versionssträng; versionsintervall är inte tillräckligt |
| Leverantör/ursprung | Namn på utgivare, leverantör eller projekt med öppen källkod |
| Beroenderelationer | Direkta kontra transitiva; beroendegraf där det är möjligt |
| Kryptografisk hash | SHA-256 eller starkare integritetskontroll per komponent |
| Licensidentifierare | SPDX-licensuttryck (t.ex. Apache-2.0, MIT) |
3 · Generera er SBOM
De flesta moderna plattformar kan generera SBOM:er automatiskt vid byggtillfället utan extra kostnad:
- GitHub / Actions: Dependency Graph → Export SBOM (Settings → Code security). Genererar SPDX JSON.
- GitLab: CycloneDX-rapporter genereras direkt av CI/CD-jobbet för beroendeskanning.
- Syft (Anchore): ett CLI-verktyg med öppen källkod som genererar SPDX och CycloneDX för containeravbildningar, filsystem och paketmanifest.
- cdxgen: CycloneDX-SBOM:er för npm, Maven, pip, Go, Rust med flera.
Sårbarhetsgranskning. Innan en SBOM färdigställs ska varje komponent granskas mot databaser över kända sårbarheter. Både GitHubs skanner och Syft integreras med Grype för detta. Att inkludera en komponent med en känd, redan åtgärdad sårbarhet är en direkt överträdelse av bilaga I och lämnar inget tolkningsutrymme.
Om det finns en uppdaterad version av en komponent måste du använda den. Det finns ingen kategori med ”accepterad risk” enligt CRA för åtgärdade sårbarheter. Agera på varje upptäckt innan du släpper ut produkten på marknaden.
4 · Underhåll och bevarande under livscykeln
En SBOM är ett levande dokument som uppdateras kontinuerligt under produktens livscykel med stöd för att återspegla uppdaterade komponenter, nya beroenden, borttagna komponenter som nått end-of-life och förändringar i leveranskedjan. Alla versioner av den tekniska dokumentationen, inklusive SBOM:er, måste bevaras i minst 10 år från det att produkten först släpptes ut på marknaden…
Avsnitt 4–9: livscykel, sanktioner, BSI TR-03183-2 och beredskapschecklistan
Resten av vägledningen behandlar den 10-åriga bevarandeskyldigheten, konfidentialitet och utlämnande i leveranskedjan, integrering med sårbarhetsrapportering enligt artikel 14, övervakningsfrekvens, Tysklands strängare BSI-regler, böterna (upp till €15M eller 2,5 % av omsättningen) och en färdig beredskapschecklista.
Närliggande verktyg och analys
Efterlevnadsmatris
Varje skyldighet under livscykeln med sin artikelhänvisning; följ dina framsteg och ladda ner hela checklistan.
Nuläge
Var CRA står idag: genomförandeakter, harmoniserade standarder och vägen mot december 2027.
Kostnadskalkylator
En vägledande uppskattning av vad det sannolikt kommer att kosta att uppnå och upprätthålla efterlevnad.