Sårbarhedsanalyse og SBOM
CRA gør din softwarestykliste til en løbende forpligtelse: vid, hvad der er i dit produkt, overvåg disse komponenter for nye sårbarheder, og afhjælp og indberet dem inden for fristerne i artikel 14. Denne side gennemgår løkken og det gratis værktøj, der kører den.
Generér en SBOM
Udarbejd en maskinlæsbar softwarestykliste, der mindst dækker dine afhængigheder på øverste niveau. Dette er et ufravigeligt krav, ikke en best practice.
Sådan genererer du den ↓Overvåg for sårbarheder
Krydsrefer løbende hver komponent mod aktive sårbarhedsdata (NVD, EUVD). Samlede notifikationsoversigter opfylder ikke kravet om 24-timersfristen.
Hvorfor oversigter ikke er tilstrækkelige ↓Vurdér, afhjælp og rapportér
Dokumentér udnyttelsesmuligheden, lever en rettelse, og indberet aktivt udnyttede sårbarheder til ENISA og CSIRT efter tidslinjen på 24 t / 72 t / 14 dage.
Værktøjet, der gør dette ↓CRA Vulnerability Analyzer
Upload din SBOM og liste over aktive sårbarheder. Analyzer krydsreferer hver komponent mod National Vulnerability Database (NVD) og EU Vulnerability Database (EUVD), markerer End-of-Life-komponenter og genererer en overensstemmelsesrapport, du kan vedlægge din tekniske dokumentation.
Vejledninger
Generér en overensstemmende SBOM
En softwarestykliste er et ufravigeligt lovkrav i henhold til bilag I, del II, punkt 1. Denne vejledning omhandler det obligatoriske omfang og format, hvordan man genererer en, og hvordan den indgår i overvågningsløkken.
1 · Retsgrundlag
Bilag I, del II ("Krav til sårbarhedshåndtering"), punkt 1, kræver, at fabrikanter "identificere og dokumentere sårbarheder og komponenter … herunder ved at udarbejde en softwarestykliste i et almindeligt anvendt og maskinlæsbart format, der mindst omfatter produktets afhængigheder på øverste niveau."
I modsætning til visse CRA-bestemmelser, der giver fortolkningsmæssig fleksibilitet, tillader forpligtelsen til at frembringe en maskinlæsbar SBOM, der mindst dækker afhængigheder på øverste niveau, ikke alternative tilgange.
2 · Obligatorisk omfang og format
Komponentdækning. SBOM'en skal dokumentere alle afhængigheder på øverste niveau, hvilket er det lovmæssige minimum frem for det anbefalede mål. Kortlæg transitive (indirekte) afhængigheder, hvor det er muligt; en overfladisk SBOM opfylder lovens bogstav, men er ofte utilstrækkelig til effektiv sårbarhedshåndtering.
Format. CRA kræver et "almindeligt anvendt, maskinlæsbart format". Accepterede formater omfatter:
- SPDX (ISO/IEC 5962:2021): bredt udbredt, licensorienteret og velegnet til overensstemmelsesdokumentation.
- CycloneDX: sikkerhedsfokuseret og velegnet til arbejdsgange for sårbarhedshåndtering.
- Andre strukturerede formater (JSON, XML) fra anerkendte værktøjer er generelt acceptable under grundkravet.
Opbevar ikke SBOM'er som PDF. PDF kan af markedsovervågningsmyndighederne anfægtes som ikke-maskinlæsbar. Opbevar det oprindelige JSON-, XML- eller tag-value-output fra din værktøjskæde.
Påkrævede metadatafelter
| Felt | Beskrivelse |
|---|---|
| Komponentnavn | Unik identifikator for biblioteket, pakken eller modulet |
| Version | Præcis versionsstreng; versionsintervaller er utilstrækkelige |
| Leverandør / oprindelse | Udgiver-, leverandør- eller open source-projektnavn |
| Afhængighedsforhold | Direkte vs. transitive; afhængighedsgraf hvor det er muligt |
| Kryptografisk hash | SHA-256 eller stærkere integritetskontrol pr. komponent |
| Licensidentifikator | SPDX-licensudtryk (f.eks. Apache-2.0, MIT) |
3 · Generering af din SBOM
De fleste moderne platforme kan generere SBOM'er automatisk ved build-tidspunktet uden ekstra omkostninger:
- GitHub / Actions: Dependency Graph → Export SBOM (Settings → Code security). Udsender SPDX JSON.
- GitLab: CycloneDX-rapporter genereres direkte af afhængighedsscanningsjobbet i CI/CD.
- Syft (Anchore): open source-CLI, der genererer SPDX og CycloneDX for containerbilleder, filsystemer og pakkemanifester.
- cdxgen: CycloneDX-SBOM'er på tværs af npm, Maven, pip, Go, Rust m.fl.
Sårbarhedsscreening. Inden du færdiggør en SBOM, skal du screene hver komponent mod databaser over kendte sårbarheder. Både GitHubs scanner og Syft integrerer med Grype til dette. At inkludere en komponent med en kendt, allerede patchet sårbarhed er en direkte overtrædelse af bilag I og giver ingen fortolkningsmæssig fleksibilitet.
Hvis der findes en patchet version af en komponent, skal du bruge den. Der findes ingen kategori for "accepteret risiko" under CRA for afhjulpne sårbarheder. Handl på ethvert fund, inden produktet bringes i omsætning.
4 · Vedligeholdelse i livscyklussen og opbevaring
En SBOM er et levende dokument, der opdateres løbende gennem produktets understøttede livscyklus for at afspejle patchede komponenter, nye afhængigheder, fjernede end-of-life-komponenter og ændringer i forsyningskæden. Alle versioner af den tekniske dokumentation, herunder SBOM'er, skal opbevares i mindst 10 år fra den første markedsføring…
Afsnit 4-9: livscyklus, sanktioner, BSI TR-03183-2 og parathedstjeklisten
Resten af vejledningen omhandler den 10-årige opbevaringspligt, fortrolighed og oplysning i forsyningskæden, integration med sårbarhedsrapportering efter artikel 14, overvågningsfrekvens, Tysklands strengere BSI-regler, bøderne (op til 15 mio. € eller 2,5 % af omsætningen) og en klar-til-brug-parathedstjekliste.
Tilknyttede værktøjer og analyse
Overensstemmelsesmatrix
Hver forpligtelse i livscyklussen med sin artikelhenvisning; spor dine fremskridt, og download hele tjeklisten.
Aktuel status
Hvor CRA står i dag: gennemførelsesretsakter, harmoniserede standarder og vejen til december 2027.
Omkostningsberegner
Et vejledende overslag over, hvad det sandsynligvis vil koste at opnå og opretholde overholdelse.