Ievainojamību analīze un SBOM
CRA pārvērš jūsu programmatūras sastāva specifikāciju par dzīvu pienākumu: ziniet, kas ir jūsu produktā, uzraugiet šos komponentus attiecībā uz jaunām ievainojamībām un novērsiet un ziņojiet par tām 14. panta termiņos. Šī lapa apraksta šo ciklu un bezmaksas rīku, kas to īsteno.
Izveidot SBOM
Izveidojiet mašīnlasāmu programmatūras komplektācijas sarakstu, kas aptver vismaz jūsu augstākā līmeņa atkarības. Šī ir stingra prasība, nevis labākā prakse.
Kā to izveidot ↓Uzraudzīt ievainojamības
Nepārtraukti salīdziniet katru komponentu ar reāllaika ievainojamību datiem (NVD, EUVD). Sagrupēti paziņojumu apkopojumi neatbilst 24 stundu logam.
Kāpēc kopsavilkumi ir nepietiekami ↓Novērtēt, novērst un ziņot
Dokumentējiet izmantojamību, piegādājiet labojumu un paziņojiet ENISA un CSIRT par aktīvi izmantotām ievainojamībām saskaņā ar 24 h / 72 h / 14 dienu grafiku.
Rīks, kas to dara ↓CRA ievainojamību analizators
Augšupielādējiet savu SBOM un aktīvo ievainojamību sarakstu. Analizators salīdzina katru komponentu ar Nacionālo ievainojamību datubāzi (NVD) un ES ievainojamību datubāzi (EUVD), atzīmē komponentus, kuru aprites cikls ir beidzies, un ģenerē atbilstības ziņojumu, ko varat pievienot savai tehniskajai dokumentācijai.
Praktiskās rokasgrāmatas
Izveidot atbilstošu SBOM
Programmatūras komplektācijas saraksts ir stingra juridiska prasība saskaņā ar I pielikuma II daļas 1. punktu. Šajā rokasgrāmatā aplūkots obligātais tvērums un formāts, kā to izveidot un kā tas iekļaujas uzraudzības ciklā.
1 · Juridiskais pamats
I pielikuma II daļa ("Ievainojamību apstrādes prasības"), 1. punkts prasa ražotājiem "apzināt un dokumentēt ievainojamības un komponentus … tostarp sagatavojot programmatūras komplektācijas sarakstu plaši izmantotā un mašīnlasāmā formātā, kas aptver vismaz produkta augstākā līmeņa atkarības."
Atšķirībā no dažiem CRA noteikumiem, kas pieļauj interpretācijas elastību, pienākums sagatavot mašīnlasāmu SBOM, kas aptver vismaz augstākā līmeņa atkarības, nepieļauj alternatīvas pieejas.
2 · Obligātais tvērums un formāts
Komponentu pārklājums. SBOM jādokumentē visas augstākā līmeņa atkarības — tas ir juridiskais minimums, nevis ieteicamais mērķis. Kartējiet pārejošās (netiešās) atkarības, kur vien iespējams; sekla SBOM atbilst likuma burtam, taču bieži vien nav pietiekama efektīvai ievainojamību pārvaldībai.
Formāts. CRA pieprasa "plaši lietotu, mašīnlasāmu formātu". Pieņemtie formāti ietver:
- SPDX (ISO/IEC 5962:2021): plaši pieņemts, vērsts uz licencēm, piemērots atbilstības dokumentācijai.
- CycloneDX: vērsts uz drošību, labi piemērots ievainojamību pārvaldības darbplūsmām.
- Citi strukturēti formāti (JSON, XML) no atzītiem rīkiem parasti ir pieņemami saskaņā ar pamatprasību.
Neglabājiet SBOM kā PDF. Tirgus uzraudzības iestādes PDF var apstrīdēt kā mašīnneilasāmu. Glabājiet nesapstrādātu JSON, XML vai atzīmju vērtību izvadi no jūsu rīkķēdes.
Obligātie metadatu lauki
| Lauks | Apraksts |
|---|---|
| Komponenta nosaukums | Unikāls bibliotēkas, pakotnes vai moduļa identifikators |
| Versija | Precīza versijas virkne; versiju diapazoni ir nepietiekami |
| Piegādātājs / izcelsme | Izdevēja, piegādātāja vai atvērtā pirmkoda projekta nosaukums |
| Atkarību attiecības | Tiešās pret tranzitīvajām; atkarību grafs, kur iespējams |
| Kriptogrāfiskā jaucējvērtība | SHA-256 vai stiprāka integritātes pārbaude katram komponentam |
| Licences identifikators | SPDX licences izteiksme (piemēram, Apache-2.0, MIT) |
3 · SBOM izveide
Lielākā daļa mūsdienu platformu var automātiski izveidot SBOM būvēšanas laikā bez papildu izmaksām:
- GitHub / Actions: Atkarību grafs → Eksportēt SBOM (Iestatījumi → Koda drošība). Izvada SPDX JSON.
- GitLab: CycloneDX ziņojumus iebūvēti ģenerē atkarību skenēšanas CI/CD uzdevums.
- Syft (Anchore): atvērtā pirmkoda komandrindas rīks, kas izveido SPDX un CycloneDX konteineru attēliem, failu sistēmām un pakotņu manifestiem.
- cdxgen: CycloneDX SBOM npm, Maven, pip, Go, Rust un citām vidēm.
Ievainojamību pārbaude. Pirms jebkura SBOM pabeigšanas pārbaudiet katru komponentu attiecībā pret zināmo ievainojamību datubāzēm. Gan GitHub skeneris, gan Syft integrējas ar Grype šim nolūkam. Tāda komponenta iekļaušana, kuram ir zināma, jau izlabota ievainojamība, ir tiešs I pielikuma pārkāpums un nepieļauj nekādu interpretācijas elastību.
Ja pastāv izlabota komponenta versija, jums tā jāizmanto. Saskaņā ar CRA novērstajām ievainojamībām nav "riska pieņemšanas" kategorijas. Rīkojieties saistībā ar katru konstatējumu pirms produkta laišanas tirgū.
4 · Dzīves cikla uzturēšana un glabāšana
SBOM ir dzīvs artefakts, kas tiek nepārtraukti atjaunināts visā produkta atbalstītajā dzīves ciklā, lai atspoguļotu izlabotos komponentus, jaunas atkarības, noņemtos aprites cikla beigu komponentus un piegādes ķēdes izmaiņas. Visas tehniskās dokumentācijas versijas, tostarp SBOM, jāglabā vismaz 10 gadus no pirmās laišanas tirgū…
4.–9. sadaļa: dzīves cikls, sodi, BSI TR-03183-2 un gatavības kontrolsaraksts
Pārējā rokasgrāmatas daļa aptver 10 gadu glabāšanas pienākumu, konfidencialitāti un piegādes ķēdes izpaušanu, integrāciju ar 14. panta ievainojamību ziņošanu, uzraudzības biežumu, Vācijas stingrākos BSI noteikumus, naudas sodus (līdz €15M vai 2,5% no apgrozījuma) un lietošanai gatavu gatavības kontrolsarakstu.
Saistītie rīki un analīze
Atbilstības matrica
Katrs dzīves cikla pienākums ar tā panta atsauci; izsekojiet savu progresu un lejupielādējiet pilnu kontrolsarakstu.
Pašreizējā situācija
Kāda ir CRA pašreizējā situācija: īstenošanas akti, saskaņotie standarti un ceļš uz 2027. gada decembri.
Izmaksu kalkulators
Orientējošs aprēķins par to, cik, visticamāk, izmaksās atbilstības sasniegšana un uzturēšana.