Vygenerujte vyhovujúci SBOM
Súpis softvérových komponentov je striktnou zákonnou požiadavkou podľa prílohy I, časti II, bodu (1). Táto časť pokrýva povinný rozsah a formát, nástroj vhodný podľa toho, ako je váš produkt zostavený, a úplného sprievodcu celým životným cyklom.
1 · Právny základ
Príloha I časť II („Požiadavky na riešenie zraniteľností“) bod 1 vyžaduje, aby výrobcovia „identifikovať a zdokumentovať zraniteľnosti a komponenty … vrátane vypracovania softvérového kusovníka v bežne používanom a strojovo čitateľnom formáte pokrývajúceho aspoň závislosti najvyššej úrovne produktu.“
Na rozdiel od niektorých ustanovení CRA, ktoré umožňujú výkladovú flexibilitu, povinnosť vytvoriť strojovo čitateľný SBOM pokrývajúci aspoň závislosti najvyššej úrovne neumožňuje alternatívne prístupy.
2 · Povinný rozsah a formát
Pokrytie komponentov. SBOM musí dokumentovať všetky závislosti najvyššej úrovne, čo je zákonné minimum, nie odporúčaný cieľ. Tam, kde je to realizovateľné, zmapujte tranzitívne (nepriame) závislosti; plytký SBOM spĺňa literu zákona, ale často nepostačuje pre účinnú správu zraniteľností.
Formát. CRA nariaďuje „bežne používaný, strojovo čitateľný formát“. Medzi prijaté formáty patria:
- SPDX (ISO/IEC 5962:2021): široko prijatý, zameraný na licencie, vhodný pre dokumentáciu súladu.
- CycloneDX: zameraný na bezpečnosť, vhodný pre pracovné postupy správy zraniteľností.
- Iné štruktúrované formáty (JSON, XML) z uznávaných nástrojov sú v rámci základnej požiadavky vo všeobecnosti prijateľné.
Neukladajte SBOM ako PDF. Orgány dohľadu nad trhom môžu PDF napadnúť ako strojovo nečitateľné. Ukladajte natívny výstup JSON, XML alebo tag-value z vášho reťazca nástrojov.
Povinné polia metaúdajov
| Pole | Opis |
|---|---|
| Názov komponentu | Jedinečný identifikátor knižnice, balíka alebo modulu |
| Verzia | Presný reťazec verzie; rozsahy verzií nepostačujú |
| Dodávateľ / pôvod | Názov vydavateľa, dodávateľa alebo open-source projektu |
| Vzťahy medzi závislosťami | Priame oproti tranzitívnym; graf závislostí tam, kde je to realizovateľné |
| Kryptografický odtlačok (hash) | Kontrola integrity SHA-256 alebo silnejšia na každý komponent |
| Identifikátor licencie | Licenčný výraz SPDX (napr. Apache-2.0, MIT) |
3 · Vygenerujte svoj SBOM: vyberte správny nástroj
Väčšina platforiem dokáže vygenerovať SBOM automaticky pri zostavení, bez ďalších nákladov. Správny nástroj závisí od toho, ako je váš produkt zostavený.
Aplikačné a balíčkové ekosystémy
- GitHub / Actions: Dependency graph → Export SBOM (Settings → Code security). Vytvára výstup SPDX JSON.
- GitLab: Správy CycloneDX sa natívne generujú úlohou CI/CD na skenovanie závislostí.
- Syft (Anchore): open-source CLI nástroj generujúci SPDX a CycloneDX pre obrazy kontajnerov, súborové systémy a manifesty balíkov.
- cdxgen: SBOM vo formáte CycloneDX naprieč npm, Maven, pip, Go, Rust a ďalšími.
Vstavaný firmvér v C/C++
Skenery balíčkových manifestov, ako sú syft a cdxgen, predpokladajú manifest závislostí, ktorý firmvér nemá: komponenty sú staticky linkované alebo premenované vnútri SDK výrobcu čipu. Pre tento prípad:
- Gangmu (github.com/GANGMU-SBOM/gangmu ↗): open-source generátor (Apache-2.0) pracujúci v čase zostavenia, vytvorený pre vstavané C/C++. Číta váš zdrojový strom, compile_commands.json, mapy linkera a firmvérové binárne súbory, identifikuje open-source komponenty, ktoré SDK výrobcu premenoval alebo staticky zlinkoval, a vytvára CycloneDX 1.6 a SPDX 3.0.1, ktoré priamo napájajú Analyzer v kroku 2. Beží výhradne na vašom stroji, bez telemetrie. Spravuje ho Suzhou Qilijie Technology.
Gangmu je najsilnejší, keď máte k dispozícii zdrojový strom; analýza len z binárnych súborov je čiastočná, najmä naprieč architektúrami CPU. Predkompilované knižnice výrobcu, ktoré nedokáže identifikovať, sú napriek tomu uvedené, vrátane ich cesty a odtlačku SHA-256, a označené ako neidentifikované, aby ste ich mohli vyriešiť sami.
Jeho SBOM obsahuje relatívne cesty k adresárom a odtlačky súborov z vášho stromu, preto ho pred nahraním sem alebo zdieľaním skontrolujte. Gangmu je jednou z viacerých možností medzi generátormi SBOM uvedenými tu a nie je prepojený s touto webovou stránkou; nástroj a jeho súbor pravidiel sme preverili a uvádzame ho na základe jeho kvalít, nie je sponzorom.
Preverenie zraniteľností. Pred dokončením akéhokoľvek SBOM preverte každý komponent voči databázam známych zraniteľností. Skener GitHubu aj Syft sa integrujú s Grype na to. Zahrnutie komponentu so známou, už opravenou zraniteľnosťou je priamym porušením prílohy I a nepripúšťa žiadnu výkladovú flexibilitu.
Ak existuje opravená verzia komponentu, musíte ju použiť. V rámci CRA neexistuje pri vyriešených zraniteľnostiach žiadna kategória „akceptované riziko“. Na každé zistenie reagujte pred uvedením produktu na trh.
4 · Údržba počas životného cyklu a uchovávanie
SBOM je živý artefakt, priebežne aktualizovaný počas podporovaného životného cyklu produktu, aby odrážal opravené komponenty, nové závislosti, odstránené komponenty na konci životnosti a zmeny v dodávateľskom reťazci. Všetky verzie technickej dokumentácie vrátane SBOM sa musia uchovávať aspoň 10 rokov od prvého uvedenia na trh…
Časti 4 – 9: životný cyklus, sankcie, BSI TR-03183-2 a kontrolný zoznam pripravenosti
Zvyšok sprievodcu pokrýva povinnosť uchovávania na 10 rokov, dôvernosť a zverejňovanie v dodávateľskom reťazci, integráciu s oznamovaním zraniteľností podľa článku 14, frekvenciu monitorovania, prísnejšie pravidlá nemeckého BSI, pokuty (až 15 mil. € alebo 2,5 % obratu) a kontrolný zoznam pripravenosti pripravený na použitie.
Posúďte svoj SBOM ešte dnes a opravte otvorené zraniteľnosti
Skôr než uvediete produkt na trh, porovnajte SBOM, ktorý ste práve vygenerovali, s aktuálnymi údajmi o zraniteľnostiach, aby ste našli všetko, čo je už otvorené, a opravte to. Bezplatný Vulnerability Analyzer robí presne toto.
Analyzátor zraniteľností CRA
Analyzer porovnáva každý komponent s databázou National Vulnerability Database (NVD) a EU Vulnerability Database (EUVD), označuje komponenty po skončení životnosti (End-of-Life) a generuje správu o zhode, ktorú môžete priložiť k svojej technickej dokumentácii.
Každý otvorený nález musí byť vyriešený predtým, než sa produkt uvedie na trh: neexistuje žiadna kategória "risk-accepted" pre zraniteľnosti, ktoré už majú záplatu. Použite správu na zdokumentovanie toho, čo ste zistili a čo ste urobili. Potom prejdite na krok 3 a pokračujte v sledovaní, pretože SBOM je živý artefakt, nie jednorazová kontrola.
Nastavte automatizovanú monitorovaciu pipeline
Čistý SBOM dnes nehovorí nič o zajtrajšku. Jeho komponenty musíte sledovať priebežne, aby bola novo zverejnená zraniteľnosť zachytená v rámci 24-hodinového okna podľa článku 14. Tu je opísané, ako sa nastaví natívne sledovanie v GitHube a prečo samotné súhrnné prehľady oznámení nespĺňajú zákon.
Aktivácia štandardných súhrnných prehľadov oznámení GitHubu nespĺňa vaše zákonné povinnosti podľa trhového práva EÚ. Článok 14 zaväzuje výrobcov k striktnému 24-hodinovému oknu na včasné oznámenie aktívne zneužívaných zraniteľností. Súhrnné prehľady sú funkciou pre informovanosť vývojárov a nemôžu nahradiť smerovanie regulačných incidentov v reálnom čase.
Časť 1 · Nastavenie repozitára (správcovia)
Aby GitHub zostavil dependency graph a označil známe zraniteľnosti oproti GitHub Advisory Database:
- Otvorte repozitár → Settings.
- V bočnom paneli, pod Security, vyberte Advanced Security.
- Nájdite Dependabot alerts a kliknite na Enable.
Časť 2 · Osobné súhrnné prehľady bezpečnostných upozornení
Sledujte repozitár. Na hlavnej stránke projektu otvorte ponuku Watch ponuka → All Activity, alebo Custom so zaškrtnutým Security alerts zaškrtnuté.
Nastavte frekvenciu svojho súhrnného prehľadu. Profile → Settings → Notifications → Dependabot alerts, potom upravte e-mailový súhrnný prehľad:
- Denný súhrn: otvorené upozornenia zlúčené do jedného balíčka každých 24 hodín.
- Týždenný súhrn: otvorené upozornenia zlúčené do jedného balíčka raz týždenne.
Časť 3 · Prevádzková realita a súlad s CRA
Spoliehanie sa na dávkové súhrnné prehľady vás vystavuje medzerám v zhode pri nasadení na trh EÚ. Ako konfigurácie GitHubu zodpovedajú očakávaniam CRA:
| Konfigurácia | Správanie | Stav podľa CRA |
|---|---|---|
| Týždenný súhrn | Agregovaný súhrn raz týždenne | ✕ V nesúlade; úplne premešká 24-hodinové okno. |
| Denný súhrn | Agregovaný súhrn každých 24 hodín | ⚠ Vysoké riziko; zero-day odhalený tesne po odoslaní súhrnu poruší lehotu skôr, než dorazí ďalší. |
| Webhooky v reálnom čase | JSON payload okamžite pri zverejnení | ● Umožňuje súlad; okamžité strojovo čitateľné údaje umožňujú tímom pre triedenie zdokumentovať zneužiteľnosť a včas kontaktovať ENISA. |
Signál v reálnom čase je nevyhnutný, no nie postačujúci; stále musíte posúdiť každý komponent a vytvoriť dôkazy. Každú zmenu premietnite späť do nástroja Vulnerability Analyzer ↗ aby ste svoj SBOM a údaje o zraniteľnostiach premenili na správu pripravenú pre CRA, a potom ohláste aktívne zneužívané zraniteľnosti agentúre ENISA a tímu CSIRT v časovom rámci 24h / 72h / 14 dní.