Pažeidžiamumų analizė ir SBOM
CRA paverčia jūsų programinės įrangos medžiagų sąrašą nuolatine prievole: žinokite, kas yra jūsų produkte, stebėkite tuos komponentus dėl naujų pažeidžiamumų ir ištaisykite bei praneškite apie juos laikydamiesi 14 straipsnyje nustatytų terminų. Šiame puslapyje aptariamas šis ciklas ir nemokamas įrankis, kuris jį vykdo.
Sugeneruokite SBOM
Parenkite mašininiu būdu nuskaitomą programinės įrangos medžiagų sąrašą, apimantį bent jūsų aukščiausio lygmens priklausomybes. Tai griežtas reikalavimas, o ne geroji praktika.
Kaip jį sugeneruoti ↓Stebėkite pažeidžiamumus
Nuolat sutikrinkite kiekvieną komponentą su aktualiais pažeidžiamumų duomenimis (NVD, EUVD). Paketinės pranešimų santraukos neatitinka 24 valandų termino.
Kodėl santraukų nepakanka ↓Įvertinkite, ištaisykite ir praneškite
Dokumentuokite išnaudojamumą, pateikite pataisą ir praneškite apie aktyviai išnaudojamus pažeidžiamumus ENISA ir CSIRT laikydamiesi 24 val. / 72 val. / 14 dienų terminų.
Įrankis, kuris tai atlieka ↓CRA pažeidžiamumų analizatorius
Įkelkite savo SBOM ir aktyvių pažeidžiamumų sąrašą. Analizatorius sutikrina kiekvieną komponentą su Nacionaline pažeidžiamumų duomenų baze (NVD) ir ES pažeidžiamumų duomenų baze (EUVD), pažymi gyvavimo ciklo pabaigą pasiekusius komponentus ir sugeneruoja atitikties ataskaitą, kurią galite pridėti prie savo techninės bylos.
Praktiniai vadovai
Sugeneruokite reikalavimus atitinkantį SBOM
Programinės įrangos medžiagų sąrašas (SBOM) yra griežtas teisinis reikalavimas pagal I priedo II dalies 1 punktą. Šiame vadove aptariama privaloma aprėptis ir formatas, kaip jį sugeneruoti ir kaip jis maitina stebėsenos ciklą.
1 · Teisinis pagrindas
I priedo II dalies („Pažeidžiamumų valdymo reikalavimai“) 1 punkte gamintojai įpareigojami „nustatyti ir dokumentuoti pažeidžiamumus ir komponentus … be kita ko, parengiant programinės įrangos medžiagų sąrašą (SBOM) plačiai naudojamu ir mašininiu būdu nuskaitomu formatu, apimančiu bent aukščiausio lygmens produkto priklausomybes.“
Kitaip nei kai kurios CRA nuostatos, leidžiančios aiškinimo lankstumą, prievolė parengti mašininiu būdu nuskaitomą SBOM, apimantį bent aukščiausio lygmens priklausomybes, neleidžia alternatyvių požiūrių.
2 · Privaloma aprėptis ir formatas
Komponentų aprėptis. SBOM turi dokumentuoti visas aukščiausio lygmens priklausomybes – tai teisinis minimumas, o ne rekomenduojamas tikslas. Kai įmanoma, susiekite tranzityvines (netiesiogines) priklausomybes; paviršutiniškas SBOM atitinka įstatymo raidę, bet dažnai nepakankamas veiksmingam pažeidžiamumų valdymui.
Formatas. CRA reikalauja „plačiai naudojamo, mašininiu būdu nuskaitomo formato“. Priimtini formatai apima:
- SPDX (ISO/IEC 5962:2021): plačiai taikomas, orientuotas į licencijas, tinkamas atitikties dokumentacijai.
- CycloneDX: orientuotas į saugumą, gerai tinkamas pažeidžiamumų valdymo darbo procesams.
- Kiti struktūruoti formatai (JSON, XML), gauti iš pripažintų įrankių, paprastai priimtini pagal bazinį reikalavimą.
Nesaugokite SBOM PDF formatu. Rinkos priežiūros institucijos gali užginčyti PDF kaip nenuskaitomą mašininiu būdu. Saugokite originalų JSON, XML arba tag-value rezultatą iš savo įrankių grandinės.
Privalomi metaduomenų laukai
| Laukas | Aprašymas |
|---|---|
| Komponento pavadinimas | Unikalus bibliotekos, paketo ar modulio identifikatorius |
| Versija | Tiksli versijos eilutė; versijų diapazonų nepakanka |
| Tiekėjas / kilmė | Leidėjo, tiekėjo arba atvirojo kodo projekto pavadinimas |
| Priklausomybių ryšiai | Tiesioginės ir tranzityvinės; priklausomybių grafikas, kai įmanoma |
| Kriptografinė maiša | SHA-256 arba stipresnė vientisumo patikra kiekvienam komponentui |
| Licencijos identifikatorius | SPDX licencijos išraiška (pvz., Apache-2.0, MIT) |
3 · SBOM generavimas
Dauguma šiuolaikinių platformų gali automatiškai sugeneruoti SBOM kūrimo metu be papildomų sąnaudų:
- GitHub / Actions: Priklausomybių grafikas → Eksportuoti SBOM (Nustatymai → Kodo saugumas). Pateikia SPDX JSON.
- GitLab: CycloneDX ataskaitas savaime generuoja priklausomybių skenavimo CI/CD užduotis.
- Syft (Anchore): atvirojo kodo komandinės eilutės įrankis, generuojantis SPDX ir CycloneDX konteinerių atvaizdams, failų sistemoms ir paketų manifestams.
- cdxgen: CycloneDX SBOM npm, Maven, pip, Go, Rust ir kitose aplinkose.
Pažeidžiamumų patikra. Prieš užbaigdami bet kokį SBOM, patikrinkite kiekvieną komponentą pagal žinomų pažeidžiamumų duomenų bazes. Tiek GitHub skaitytuvas, tiek Syft integruojami su Grype tam. Komponento su žinomu, jau pataisytu pažeidžiamumu įtraukimas yra tiesioginis I priedo pažeidimas ir nesuteikia jokio aiškinimo lankstumo.
Jei egzistuoja pataisyta komponento versija, privalote ją naudoti. CRA nenumato „prisiimtos rizikos“ kategorijos pašalintiems pažeidžiamumams. Prieš pateikdami produktą rinkai imkitės veiksmų dėl kiekvieno aptikto trūkumo.
4 · Gyvavimo ciklo priežiūra ir saugojimas
SBOM yra nuolat kintantis artefaktas, nuolat atnaujinamas per visą produkto palaikomą gyvavimo ciklą, kad atspindėtų pataisytus komponentus, naujas priklausomybes, pašalintus gyvavimo ciklo pabaigą pasiekusius komponentus ir tiekimo grandinės pokyčius. Visos techninės dokumentacijos versijos, įskaitant SBOM, turi būti saugomos bent 10 metų nuo pirmojo pateikimo rinkai…
4–9 skyriai: gyvavimo ciklas, sankcijos, BSI TR-03183-2 ir pasirengimo kontrolinis sąrašas
Likusioje vadovo dalyje aptariama 10 metų saugojimo prievolė, konfidencialumas ir tiekimo grandinės atskleidimas, integracija su 14 straipsnyje numatytu pranešimu apie pažeidžiamumus, stebėsenos dažnumas, griežtesnės Vokietijos BSI taisyklės, baudos (iki 15 mln. € arba 2,5 % apyvartos) ir paruoštas naudoti pasirengimo kontrolinis sąrašas.
Susiję įrankiai ir analizė
Atitikties matrica
Kiekviena gyvavimo ciklo prievolė su nuoroda į straipsnį; stebėkite savo pažangą ir atsisiųskite visą kontrolinį sąrašą.
Esama padėtis
Kokia CRA padėtis šiandien: įgyvendinimo aktai, darnieji standartai ir kelias iki 2027 m. gruodžio.
Sąnaudų skaičiuoklė
Orientacinė sąmata, kiek tikėtina kainuos atitikties pasiekimas ir palaikymas.