Haavoittuvuusanalyysi ja SBOM
CRA tekee ohjelmistoluettelostasi elävän velvoitteen: tiedä, mitä tuotteessasi on, seuraa näiden komponenttien uusia haavoittuvuuksia sekä korjaa ja raportoi ne 14 artiklan määräaikojen sisällä. Tämä sivu käy läpi syklin ja sitä ajavan maksuttoman työkalun.
Luo SBOM
Tuota koneluettava ohjelmistoluettelo (SBOM), joka kattaa vähintään ylimmän tason riippuvuutesi. Tämä on ehdoton vaatimus, ei pelkkä paras käytäntö.
Miten se luodaan ↓Seuraa haavoittuvuuksia
Ristiintarkista jokainen komponentti jatkuvasti reaaliaikaista haavoittuvuusdataa vasten (NVD, EUVD). Eräkohtaiset ilmoituskoosteet eivät täytä 24 tunnin aikarajaa.
Miksi koosteet eivät riitä ↓Arvioi, korjaa ja raportoi
Dokumentoi hyväksikäytettävyys, toimita korjaus ja ilmoita aktiivisesti hyväksikäytetyistä haavoittuvuuksista ENISAlle ja CSIRT-yksikölle 24 h / 72 h / 14 vuorokauden aikataulun mukaisesti.
Työkalu, joka tekee tämän ↓CRA-haavoittuvuusanalysaattori
Lataa SBOM ja luettelo aktiivisista haavoittuvuuksista. Analysaattori ristiintarkistaa jokaisen komponentin National Vulnerability Database (NVD)- ja EU Vulnerability Database (EUVD) -tietokantoja vasten, merkitsee elinkaarensa päässä olevat komponentit ja luo vaatimustenmukaisuusraportin, jonka voit liittää tekniseen asiakirja-aineistoosi.
Käytännön oppaat
Luo vaatimustenmukainen SBOM
Ohjelmistoluettelo (SBOM) on ehdoton lakisääteinen vaatimus liitteen I osan II kohdan 1 nojalla. Tämä opas kattaa pakollisen laajuuden ja muodon, sen luomisen sekä sen, miten se syöttää tietoa seurantasykliin.
1 · Oikeusperusta
Liitteen I osan II ("Haavoittuvuuksien käsittelyä koskevat vaatimukset") kohta 1 edellyttää valmistajilta, että ne "yksilöitävä ja dokumentoitava haavoittuvuudet ja komponentit … muun muassa laatimalla yleisesti käytetyssä ja koneluettavassa muodossa oleva ohjelmistoluettelo (SBOM), joka kattaa vähintään tuotteen ylimmän tason riippuvuudet."
Toisin kuin jotkin CRA:n säännökset, jotka sallivat tulkinnallista joustavuutta, velvoite tuottaa koneluettava SBOM, joka kattaa vähintään ylimmän tason riippuvuudet, ei salli vaihtoehtoisia lähestymistapoja.
2 · Pakollinen laajuus ja muoto
Komponenttien kattavuus. SBOM:n on dokumentoitava kaikki ylimmän tason riippuvuudet, mikä on lakisääteinen vähimmäistaso, ei suositeltu tavoite. Kartoita transitiiviset (epäsuorat) riippuvuudet aina kun mahdollista; pinnallinen SBOM täyttää lain kirjaimen mutta on usein riittämätön tehokkaaseen haavoittuvuuksien hallintaan.
Muoto. CRA edellyttää "yleisesti käytettyä, koneluettavaa muotoa". Hyväksyttyjä muotoja ovat muun muassa:
- SPDX (ISO/IEC 5962:2021): laajasti käytössä, lisenssipainotteinen ja soveltuu vaatimustenmukaisuusdokumentaatioon.
- CycloneDX: tietoturvakeskeinen, hyvin soveltuva haavoittuvuuksien hallinnan työnkulkuihin.
- Muut tunnetuilla työkaluilla tuotetut jäsennellyt muodot (JSON, XML) ovat yleensä hyväksyttäviä perusvaatimuksen mukaisesti.
Älä tallenna SBOM-luetteloita PDF-muodossa. Markkinavalvontaviranomaiset voivat kyseenalaistaa PDF:n ei-koneluettavana. Tallenna työkaluketjusi tuottama natiivi JSON-, XML- tai tag-value-tuloste.
Vaaditut metatietokentät
| Kenttä | Kuvaus |
|---|---|
| Komponentin nimi | Kirjaston, paketin tai moduulin yksilöllinen tunniste |
| Versio | Tarkka versiomerkkijono; versioalueet eivät riitä |
| Toimittaja / alkuperä | Julkaisijan, toimittajan tai avoimen lähdekoodin projektin nimi |
| Riippuvuussuhteet | Suora vs. transitiivinen; riippuvuuskaavio aina kun mahdollista |
| Kryptografinen tiiviste | SHA-256 tai vahvempi eheystarkistus komponenttia kohden |
| Lisenssitunniste | SPDX-lisenssilauseke (esim. Apache-2.0, MIT) |
3 · SBOM-luettelon luominen
Useimmat nykyaikaiset alustat voivat luoda SBOM-luetteloita automaattisesti käännösvaiheessa ilman lisäkustannuksia:
- GitHub / Actions: Riippuvuuskaavio → Vie SBOM (Asetukset → Koodin tietoturva). Tuottaa SPDX JSON -muodon.
- GitLab: CycloneDX-raportit luodaan natiivisti riippuvuuksia skannaavalla CI/CD-työllä.
- Syft (Anchore): avoimen lähdekoodin komentorivityökalu, joka tuottaa SPDX- ja CycloneDX-muodot konttikuville, tiedostojärjestelmille ja pakettimanifesteille.
- cdxgen: CycloneDX-SBOM-luettelot npm-, Maven-, pip-, Go-, Rust- ja muille ekosysteemeille.
Haavoittuvuuksien seulonta. Ennen minkään SBOM-luettelon viimeistelyä tarkista jokainen komponentti tunnettujen haavoittuvuuksien tietokantoja vasten. Sekä GitHubin skanneri että Syft integroituvat Grype tähän. Sellaisen komponentin sisällyttäminen, jolla on tunnettu, jo korjattu haavoittuvuus, on suora liitteen I rikkomus eikä siihen liity tulkinnallista joustavuutta.
Jos komponentista on olemassa korjattu versio, sinun on käytettävä sitä. CRA:ssa ei ole "riski hyväksytty" -luokkaa ratkaistuille haavoittuvuuksille. Toimi jokaisen havainnon perusteella ennen tuotteen markkinoille saattamista.
4 · Elinkaaren ylläpito ja säilytys
SBOM on elävä asiakirja, jota päivitetään jatkuvasti koko tuotteen tuetun elinkaaren ajan, jotta se heijastaa korjattuja komponentteja, uusia riippuvuuksia, poistettuja elinkaarensa päässä olevia komponentteja ja toimitusketjun muutoksia. Kaikki teknisten asiakirjojen versiot, mukaan lukien SBOM-luettelot, on säilytettävä vähintään 10 vuotta ensimmäisestä markkinoille saattamisesta…
Osiot 4–9: elinkaari, seuraamukset, BSI TR-03183-2 ja valmiustarkistuslista
Oppaan loppuosa kattaa 10 vuoden säilytysvelvollisuuden, luottamuksellisuuden ja toimitusketjun julkistamisen, integroinnin 14 artiklan haavoittuvuusraportointiin, seurantatiheyden, Saksan tiukemmat BSI-säännöt, sakot (enintään 15 milj. € tai 2,5 % liikevaihdosta) ja valmiin valmiustarkistuslistan.
Liittyvät työkalut ja analyysit
Vaatimustenmukaisuusmatriisi
Jokainen elinkaaren velvoite artiklaviittauksineen; seuraa edistymistäsi ja lataa koko tarkistuslista.
Nykytilanne
Missä CRA on tänään: täytäntöönpanosäädökset, yhdenmukaistetut standardit ja tie kohti joulukuuta 2027.
Kustannuslaskuri
Suuntaa-antava arvio siitä, mitä vaatimustenmukaisuuden saavuttaminen ja ylläpitäminen todennäköisesti maksaa.