Analiza ranljivosti in SBOM
CRA vaš seznam sestavin programske opreme spremeni v živo obveznost: vedite, kaj je v vašem izdelku, te komponente spremljajte glede novih ranljivosti ter jih odpravite in o njih poročajte v rokih iz člena 14. Ta stran vodi skozi cikel in brezplačno orodje, ki ga izvaja.
Ustvarite SBOM
Pripravite strojno berljiv seznam sestavin programske opreme, ki zajema vsaj vaše odvisnosti najvišje ravni. To je trdna zahteva, ne pa najboljša praksa.
Kako ga ustvariti ↓Spremljajte ranljivosti
Vsako komponento neprekinjeno navzkrižno primerjajte z aktualnimi podatki o ranljivostih (NVD, EUVD). Zbirna obvestila v paketih ne ustrezajo 24-urnemu roku.
Zakaj zbirna obvestila ne zadostujejo ↓Ocenite, odpravite in poročajte
Dokumentirajte izkoristljivost, dobavite popravek in o aktivno izkoriščenih ranljivostih poročajte ENISA in CSIRT po časovnici 24 ur / 72 ur / 14 dni.
Orodje, ki to opravi ↓Analizator ranljivosti CRA
Naložite svoj SBOM in seznam aktivnih ranljivosti. Analizator vsako komponento navzkrižno primerja z nacionalno zbirko ranljivosti (NVD) in zbirko ranljivosti EU (EUVD), označi komponente ob koncu življenjske dobe in ustvari poročilo o skladnosti, ki ga lahko priložite svoji tehnični dokumentaciji.
Navodila po korakih
Ustvarite skladen SBOM
Seznam sestavin programske opreme je trdna pravna zahteva v skladu s Prilogo I, del II, točka (1). Ta vodnik zajema obvezni obseg in obliko, kako ga ustvariti in kako se vključuje v cikel spremljanja.
1 · Pravna podlaga
Priloga I, del II ("Zahteve glede obravnavanja ranljivosti"), točka (1) od proizvajalcev zahteva, da "prepoznavanje in dokumentiranje ranljivosti in komponent … vključno s pripravo seznama sestavin programske opreme v splošno uporabljani in strojno berljivi obliki, ki zajema vsaj odvisnosti najvišje ravni izdelka."
Za razliko od nekaterih določb CRA, ki dopuščajo prožnost pri razlagi, obveznost priprave strojno berljivega SBOM, ki zajema vsaj odvisnosti najvišje ravni, ne dopušča drugačnih pristopov.
2 · Obvezni obseg in oblika
Pokritost komponent. SBOM mora dokumentirati vse odvisnosti najvišje ravni, kar je zakonski minimum, ne pa priporočeni cilj. Tranzitivne (posredne) odvisnosti preslikajte, kjer koli je izvedljivo; plitev SBOM zadošča črki zakona, vendar pogosto ne zadostuje za učinkovito upravljanje ranljivosti.
Oblika. CRA predpisuje "splošno uporabljano, strojno berljivo obliko". Sprejete oblike vključujejo:
- SPDX (ISO/IEC 5962:2021): široko uveljavljen, osredotočen na licence, primeren za dokumentacijo o skladnosti.
- CycloneDX: osredotočen na varnost, dobro primeren za delovne tokove upravljanja ranljivosti.
- Druge strukturirane oblike (JSON, XML) iz priznanih orodij so v okviru osnovne zahteve na splošno sprejemljive.
SBOM ne shranjujte v obliki PDF. Organi za nadzor trga lahko PDF izpodbijajo kot strojno neberljiv. Shranite domorodni izhod JSON, XML ali tag-value iz svoje verige orodij.
Obvezna polja metapodatkov
| Polje | Opis |
|---|---|
| Ime komponente | Enolični identifikator za knjižnico, paket ali modul |
| Različica | Natančna oznaka različice; razponi različic ne zadostujejo |
| Dobavitelj / izvor | Ime izdajatelja, dobavitelja ali odprtokodnega projekta |
| Razmerja med odvisnostmi | Neposredne v primerjavi s tranzitivnimi; graf odvisnosti, kjer je izvedljivo |
| Kriptografski izvleček | SHA-256 ali močnejše preverjanje celovitosti za vsako komponento |
| Identifikator licence | Licenčni izraz SPDX (npr. Apache-2.0, MIT) |
3 · Ustvarjanje vašega SBOM
Večina sodobnih platform lahko SBOM samodejno ustvari med gradnjo brez dodatnih stroškov:
- GitHub / Actions: Graf odvisnosti → Izvozi SBOM (Nastavitve → Varnost kode). Ustvari SPDX JSON.
- GitLab: Poročila CycloneDX domorodno ustvari opravilo CI/CD za pregledovanje odvisnosti.
- Syft (Anchore): odprtokodno orodje ukazne vrstice, ki ustvarja SPDX in CycloneDX za slike vsebnikov, datotečne sisteme in manifeste paketov.
- cdxgen: SBOM v obliki CycloneDX za npm, Maven, pip, Go, Rust in več.
Pregledovanje ranljivosti. Preden dokončate kateri koli SBOM, vsako komponento preverite v zbirkah znanih ranljivosti. Tako optični bralnik GitHub kot Syft se povezujeta z Grype za to. Vključitev komponente z znano, že popravljeno ranljivostjo je neposredna kršitev Priloge I in ne dopušča prožnosti pri razlagi.
Če obstaja popravljena različica komponente, jo morate uporabiti. Po CRA ni kategorije "sprejeto tveganje" za odpravljene ranljivosti. Pred dajanjem izdelka na trg ukrepajte ob vsaki ugotovitvi.
4 · Vzdrževanje življenjskega cikla in hramba
SBOM je živ dokument, ki se neprekinjeno posodablja skozi podprt življenjski cikel izdelka in odraža popravljene komponente, nove odvisnosti, odstranjene komponente ob koncu življenjske dobe in spremembe v dobavni verigi. Vse različice tehnične dokumentacije, vključno s SBOM, je treba hraniti vsaj 10 let od prvega dajanja na trg…
Razdelki 4–9: življenjski cikel, kazni, BSI TR-03183-2 in kontrolni seznam pripravljenosti
Preostanek vodnika zajema dolžnost hrambe za 10 let, zaupnost in razkrivanje v dobavni verigi, povezavo s poročanjem o ranljivostih iz člena 14, pogostost spremljanja, strožja nemška pravila BSI, globe (do 15 mio. € ali 2,5 % prometa) in kontrolni seznam pripravljenosti, pripravljen za uporabo.
Povezana orodja in analize
Matrika skladnosti
Vsaka obveznost življenjskega cikla s sklicem na člen; spremljajte svoj napredek in prenesite celoten kontrolni seznam.
Trenutno stanje
Kje je CRA danes: izvedbeni akti, harmonizirani standardi in pot do decembra 2027.
Kalkulator stroškov
Okvirna ocena tega, koliko bosta verjetno stala dosega in ohranjanje skladnosti.