Sebezhetőségelemzés és SBOM
A CRA a szoftvertermék-jegyzéket élő kötelezettséggé alakítja: tudja, mi van a termékében, figyelje ezeket az összetevőket az új sebezhetőségek szempontjából, valamint javítsa és jelentse őket a 14. cikk határidőin belül. Ez az oldal végigvezeti a hurkot, valamint az azt futtató ingyenes eszközt.
Készítsen SBOM-ot
Készítsen géppel olvasható szoftvertermék-jegyzéket, amely legalább a legfelső szintű függőségekre kiterjed. Ez szigorú követelmény, nem pedig bevált gyakorlat.
Hogyan állítható elő ↓Felügyelje a sebezhetőségeket
Folyamatosan vesse össze minden összetevőt az aktuális sebezhetőségi adatokkal (NVD, EUVD). A kötegelt értesítési összefoglalók nem felelnek meg a 24 órás időkeretnek.
Miért elégtelenek az összefoglalók ↓Értékelés, javítás és jelentés
Dokumentálja a kihasználhatóságot, adjon ki javítást, és jelentse az aktívan kihasznált sebezhetőségeket az ENISA-nak és a CSIRT-nek a 24 órás / 72 órás / 14 napos határidőkkel.
Az ezt elvégző eszköz ↓CRA sebezhetőségelemző
Töltse fel az SBOM-ot és az aktív sebezhetőségi listáját. Az elemző minden összetevőt összevet a nemzeti sebezhetőségi adatbázissal (NVD) és az EU sebezhetőségi adatbázisával (EUVD), megjelöli az életciklusvégi összetevőket, és olyan megfelelőségi jelentést készít, amelyet csatolhat a műszaki dokumentációjához.
Útmutatók
Készítsen megfelelő SBOM-ot
A szoftvertermék-jegyzék (SBOM) szigorú jogi követelmény az I. melléklet II. részének (1) pontja értelmében. Ez az útmutató bemutatja a kötelező hatályt és formátumot, az elkészítés módját, valamint azt, hogyan táplálja a felügyeleti hurkot.
1 · Jogalap
Az I. melléklet II. része („Sebezhetőségkezelési követelmények”), (1) pont előírja a gyártók számára, hogy „a sebezhetőségek és összetevők azonosítása és dokumentálása … többek között a szoftvertermék-jegyzék (SBOM) általánosan használt és géppel olvasható formátumban történő elkészítésével, amely legalább a termék legfelső szintű függőségeire kiterjed.”
Egyes CRA-rendelkezésekkel ellentétben, amelyek értelmezési rugalmasságot tesznek lehetővé, a legalább a legfelső szintű függőségekre kiterjedő, géppel olvasható SBOM elkészítésére vonatkozó kötelezettség nem enged meg alternatív megközelítéseket.
2 · Kötelező hatály és formátum
Összetevő-lefedettség. Az SBOM-nak dokumentálnia kell az összes legfelső szintű függőséget, ami a jogi minimum, nem pedig az ajánlott célérték. Térképezze fel a tranzitív (közvetett) függőségeket, ahol csak megvalósítható; egy felületes SBOM kielégíti a jogszabály betűjét, de gyakran elégtelen a hatékony sebezhetőségkezeléshez.
Formátum. A CRA „általánosan használt, géppel olvasható formátumot” ír elő. Az elfogadott formátumok közé tartozik:
- SPDX (ISO/IEC 5962:2021): széles körben elterjedt, licencközpontú, megfelelőségi dokumentációhoz alkalmas.
- CycloneDX: biztonságközpontú, jól illeszkedik a sebezhetőségkezelési munkafolyamatokhoz.
- Az elismert eszközökből származó egyéb strukturált formátumok (JSON, XML) általában elfogadhatók az alapkövetelmény szerint.
Ne tárolja az SBOM-okat PDF formátumban. A PDF-et a piacfelügyeleti hatóságok nem géppel olvashatóként megkérdőjelezhetik. Tárolja az eszközláncból származó natív JSON-, XML- vagy tag-value-kimenetet.
Kötelező metaadatmezők
| Mező | Leírás |
|---|---|
| Összetevő neve | A könyvtár, csomag vagy modul egyedi azonosítója |
| Verzió | Pontos verzióazonosító; a verziótartományok nem elegendők |
| Beszállító / eredet | A kiadó, a forgalmazó vagy a nyílt forráskódú projekt neve |
| Függőségi kapcsolatok | Közvetlen vs. tranzitív; függőségi gráf, ahol megvalósítható |
| Kriptográfiai hash | SHA-256 vagy erősebb sértetlenség-ellenőrzés összetevőnként |
| Licencazonosító | SPDX-licenckifejezés (pl. Apache-2.0, MIT) |
3 · Az SBOM előállítása
A legtöbb modern platform képes automatikusan SBOM-okat előállítani az összeállítás idején, további költség nélkül:
- GitHub / Actions: Függőségi gráf → SBOM exportálása (Beállítások → Kódbiztonság). SPDX JSON kimenetet ad.
- GitLab: A CycloneDX-jelentéseket natívan generálja a függőségvizsgáló CI/CD-feladat.
- Syft (Anchore): nyílt forráskódú parancssori eszköz, amely SPDX és CycloneDX formátumot állít elő konténerképekhez, fájlrendszerekhez és csomagjegyzékekhez.
- cdxgen: CycloneDX SBOM-ok npm, Maven, pip, Go, Rust és további platformokon.
Sebezhetőség-átvizsgálás. Bármely SBOM véglegesítése előtt vesse össze minden összetevőt az ismert sebezhetőségi adatbázisokkal. Mind a GitHub szkennere, mind a Syft integrálódik a következővel: Grype ehhez. Egy ismert, már javított sebezhetőséget tartalmazó összetevő feltüntetése az I. melléklet közvetlen megsértése, és nem ad helyt értelmezési rugalmasságnak.
Ha egy összetevő javított verziója létezik, azt kell használnia. A CRA értelmében nincs „kockázatelfogadott” kategória az orvosolt sebezhetőségekre. A termék forgalomba hozatala előtt minden megállapítás alapján intézkedjen.
4 · Életciklus-karbantartás és megőrzés
Az SBOM egy élő dokumentum, amelyet a termék támogatott életciklusa során folyamatosan frissíteni kell, hogy tükrözze a javított összetevőket, az új függőségeket, az eltávolított életciklusvégi összetevőket és az ellátási lánc változásait. A műszaki dokumentáció minden változatát, beleértve az SBOM-okat is, az első forgalomba hozataltól számított legalább 10 évig meg kell őrizni…
4–9. szakasz: életciklus, szankciók, BSI TR-03183-2 és a felkészültségi ellenőrzőlista
Az útmutató további része a 10 éves megőrzési kötelezettséget, a bizalmasságot és az ellátási láncban való közzétételt, a 14. cikk szerinti sebezhetőség-bejelentéssel való integrációt, a felügyelet gyakoriságát, Németország szigorúbb BSI-szabályait, a bírságokat (legfeljebb 15 millió € vagy az árbevétel 2,5%-a), valamint egy azonnal használható felkészültségi ellenőrzőlistát tárgyalja.
Kapcsolódó eszközök és elemzések
Megfelelőségi mátrix
Minden életciklus-kötelezettség a cikkhivatkozásával; kövesse nyomon az előrehaladását, és töltse le a teljes ellenőrzőlistát.
A jelenlegi állás
Hol tart ma a CRA: végrehajtási jogi aktusok, harmonizált szabványok és a 2027 decemberéig vezető út.
Költségkalkulátor
Tájékoztató becslés arról, hogy a megfelelés elérése és fenntartása várhatóan mennyibe kerül.