FISMA

Blog FISMA

SBOM a open-source závislosti v produktovej bezpečnosti

SBOM nie je iba zoznam knižníc. CRA mení spôsob, akým výrobcovia softvéru sledujú komponenty, zraniteľnosti a open-source závislosti počas životného cyklu produktu.

Publikované: September 5, 2026 · Aktualizované: September 5, 2026 · Autor:

Softvérový produkt zložený z viacerých komponentov a open-source závislostí, pričom jeden komponent obsahuje bezpečnostnú zraniteľnosť.

Vývojový tím dostane informáciu o novej kritickej zraniteľnosti populárnej open-source knižnice.

Prvá otázka znie:

Používame ju?

Druhá:

V ktorých produktoch a verziách?

A potom prídu ďalšie:

  • je zraniteľnosť v našej konfigurácii reálne zneužiteľná,
  • existuje opravená verzia,
  • dokážeme ju bezpečne aktualizovať,
  • ktorí zákazníci používajú dotknuté verzie,
  • kto rozhodne o náprave,
  • a môže vzniknúť aj oznamovacia povinnosť?

Ak firma začne tieto odpovede hľadať až po zverejnení zraniteľnosti, môže stratiť hodiny alebo dni iba zisťovaním, z čoho jej produkty vlastne pozostávajú.

Práve tu sa z obyčajného zoznamu knižníc stáva súčasť riadenia produktovej bezpečnosti.

Čo je SBOM

SBOM – Software Bill of Materials – možno zjednodušene prirovnať ku kusovníku softvérového produktu.

Zachytáva softvérové komponenty, z ktorých je produkt vytvorený, a informácie potrebné na ich identifikáciu. V praxi môžu ísť napríklad o:

  • open-source knižnice,
  • frameworky,
  • balíky tretích strán,
  • softvérové moduly,
  • komponenty dodávateľov,
  • konkrétne verzie použitých závislostí.

CRA požaduje, aby výrobca identifikoval a dokumentoval zraniteľnosti a komponenty obsiahnuté v produkte s digitálnymi prvkami. Súčasťou požiadaviek na vulnerability handling je vytvorenie SBOM v bežne používanom a strojovo spracovateľnom formáte, pričom minimálnym základom sú priame – top-level – závislosti produktu.

Dôležité je, že nejde o jednorazový dokument.

Produkt sa vyvíja, menia sa verzie knižníc, pribúdajú nové komponenty a staré sa odstraňujú. SBOM, ktorý nezodpovedá konkrétnemu buildu alebo releasu, rýchlo stráca svoju praktickú hodnotu.

CRA nerieši komponenty iba kvôli dokumentácii

Výrobca zodpovedá za bezpečnosť výsledného produktu.

Ak do neho integruje komponenty tretích strán, potrebuje pri ich výbere a použití postupovať s primeranou starostlivosťou tak, aby použité komponenty nenarušili bezpečnosť výsledného produktu. CRA zároveň prepája kybernetické riziká s plánovaním, návrhom, vývojom, výrobou, dodaním aj údržbou produktu.

To je zásadné pri open-source softvéri.

Veta:

„Tá chyba nie je v našom kóde, ale v cudzej knižnici.“

môže byť technicky pravdivá, ale z pohľadu bezpečnosti výsledného produktu nestačí.

Výrobca potrebuje vedieť:

  • akú verziu komponentu používa,
  • prečo je v produkte potrebný,
  • či je aktívne udržiavaný,
  • či sú dostupné bezpečnostné opravy,
  • akým spôsobom ho môže aktualizovať alebo nahradiť,
  • ktoré verzie vlastného produktu sú jeho zmenou ovplyvnené.

Open source neznamená automaticky „mimo CRA“

Pri open-source softvéri treba rozlišovať viacero situácií.

Free and open-source software poskytovaný mimo obchodnej činnosti nie je automaticky postavený do rovnakej pozície ako komerčný výrobca. CRA zároveň vytvára osobitný režim pre tzv. open-source software stewardov – právnické osoby, ktoré systematicky a dlhodobo podporujú vývoj určitých open-source produktov určených na komerčné aktivity.

Pre bežnú softvérovú firmu je však praktickejšia otázka:

Čo sa stane, keď open-source komponent vložíme do nášho komerčného produktu?

Vtedy sa stáva súčasťou výsledného produktu a výrobca musí vedieť riadiť riziko, ktoré z jeho použitia vzniká.

Licenčný model komponentu sám osebe neodstraňuje zodpovednosť za bezpečnosť produktu, ktorý sa dostáva k zákazníkovi.

SBOM nie je zoznam CVE

Toto je jeden z najčastejších omylov.

SBOM odpovedá na otázku:

Čo produkt obsahuje?

Databázy zraniteľností a bezpečnostné nástroje následne pomáhajú odpovedať:

Aké známe bezpečnostné problémy sa s týmito komponentmi spájajú?

A produktový alebo bezpečnostný tím ešte musí posúdiť:

Je konkrétna zraniteľnosť v našom produkte reálne zneužiteľná a aký má dopad?

Samotná existencia CVE pri jednej knižnici preto automaticky neznamená rovnaké riziko pre každý produkt, ktorý ju obsahuje.

Môže ísť o funkciu, ktorú konkrétny produkt:

  • vôbec nepoužíva,
  • nepoužíva v zraniteľnej konfigurácii,
  • izoluje ďalším opatrením,
  • alebo už opravil iným spôsobom.

SBOM je preto mapou komponentov. Vulnerability management je proces, ktorý nad touto mapou rozhoduje, čo je potrebné riešiť.

Priame závislosti sú iba začiatok

CRA stanovuje ako minimálny základ SBOM priame – top-level – závislosti. Z pohľadu praktickej produktovej bezpečnosti však môže byť potrebné poznať aj tranzitívne závislosti hlbšie v softvérovom reťazci. (

Vývojár môže napríklad pridať jednu knižnicu.

Tá používa ďalšie tri balíky.

Tie používajú ďalších desať.

Výsledkom je reťazec:

produkt → knižnica A → knižnica B → knižnica C → ďalšie balíky

A práve zraniteľnosť hlboko v tomto reťazci môže zasiahnuť veľké množstvo produktov bez toho, aby ju vývojár priamo deklaroval ako vlastnú závislosť.

ENISA preto vo svojom technickom odporúčaní k package managerom upozorňuje na riziká komponentov tretích strán a odporúča bezpečne riadiť ich výber, integráciu, monitoring a aktualizácie počas SDLC.

Package manager je dnes súčasťou bezpečnosti produktu

npm, pip, Maven, NuGet a ďalšie package managery sú pre vývojára predovšetkým nástrojom efektivity.

Z pohľadu bezpečnosti však zároveň predstavujú kanál, cez ktorý sa externý kód dostáva priamo do produktu.

Preto má význam riešiť napríklad:

  • kto môže pridávať nové závislosti,
  • z akých zdrojov alebo repozitárov,
  • či sa verzie závislostí riadia a fixujú,
  • ako sa sledujú bezpečnostné upozornenia,
  • čo sa deje s nepodporovanými komponentmi,
  • kto rozhoduje o aktualizácii alebo výmene kritickej knižnice.

Výber knižnice teda nie je iba technické rozhodnutie developera.

Môže byť aj dlhodobým produktovým záväzkom.

Čo ak open-source projekt prestane byť udržiavaný?

Predstavme si, že produkt používa knižnicu, ktorá:

  • už nemá aktívneho maintenera,
  • prestala vydávať aktualizácie,
  • nepodporuje novú verziu platformy,
  • alebo má rastúci počet nevyriešených bezpečnostných problémov.

Výrobca pritom môže svoj produkt podporovať ešte niekoľko rokov.

Má potom viacero možností:

  • komponent nahradiť,
  • prevziať časť jeho údržby,
  • vytvoriť vlastnú opravu,
  • zaviesť náhradné opatrenie,
  • alebo prehodnotiť architektúru produktu.

Preto sa produktová bezpečnosť nezačína až pri prvej zraniteľnosti.

Začína už pri rozhodnutí, aké závislosti do produktu pustíme a či ich budeme schopní bezpečne udržiavať počas celej doby podpory.

Od 11. septembra sa SBOM prepája aj s reportingom

Téma je aktuálna aj z iného dôvodu.

Od 11. septembra 2026 začínajú výrobcovia v rozsahu CRA povinne oznamovať:

  • aktívne zneužívané zraniteľnosti,
  • závažné incidenty s dopadom na bezpečnosť produktu.

Prvotné upozornenie sa podáva bez zbytočného odkladu, najneskôr do 24 hodín od zistenia udalosti, a následné oznámenie najneskôr do 72 hodín. Pri aktívne zneužívanej zraniteľnosti nasleduje záverečná správa najneskôr do 14 dní od sprístupnenia nápravného alebo zmierňujúceho opatrenia; pri závažnom incidente do jedného mesiaca od 72-hodinového oznámenia.

Pre produktový tím je preto aktuálny SBOM prakticky užitočný pri veľmi jednoduchej, ale časovo kritickej otázke:

Ktoré naše produkty a podporované verzie obsahujú komponent, ktorý sa práve aktívne zneužíva?

Ak na túto otázku firma nevie odpovedať rýchlo, významnú časť oznamovacej lehoty môže minúť iba interným zisťovaním.

Ako bude fungovať hlásenie podľa CRA

Tu je dôležité rozlíšiť komu je hlásenie určené a cez aký mechanizmus sa technicky podáva.

CRA vytvára jednotnú Single Reporting Platform – SRP, ktorú zriaďuje, prevádzkuje a udržiava ENISA. Výrobca cez SRP podáva jedno elektronické hlásenie a vyberá príslušný CSIRT designated as coordinator, spravidla podľa svojho hlavného miesta usadenia.

Hlásenie je teda určené príslušnému koordinujúcemu CSIRT. Za štandardných okolností sa zároveň sprístupní ENISA. CSIRT, ktorý ho prijme, následne zabezpečí distribúciu relevantným CSIRT v ďalších členských štátoch, kde bol produkt sprístupnený, a podľa potreby aj príslušným orgánom dohľadu nad trhom.

Architektúra SRP navyše umožňuje členským štátom a koordinujúcim CSIRT vytvoriť vlastné elektronické notifikačné endpointy napojené na spoločný európsky mechanizmus.

Pre slovenského výrobcu je preto prakticky najdôležitejšie vedieť, ktorý slovenský CSIRT bude určený ako koordinátor a aký národný spôsob podania bude NBÚ komunikovať pre slovenské subjekty. Európsky mechanizmus zostáva prepojený so SRP a ENISA.

Z pohľadu firmy však ešte pred prvým hlásením treba vyriešiť najmä:

  • kto posudzuje, či udalosť podlieha reportingu podľa CRA,
  • kto má oprávnenie hlásenie podať,
  • kto dodáva technické vstupy,
  • kto komunikuje s koordinujúcim CSIRT,
  • kto komunikuje so zákazníkmi,
  • kto sleduje nápravné opatrenia a ďalšie aktualizácie.

ENISA zároveň uvádza, že používateľské účty pre poverených zástupcov výrobcu využívajú EU Login a väzbu zástupcu na výrobcu následne overuje príslušný koordinujúci CSIRT. (

Viete, kam vám má niekto nahlásiť zraniteľnosť?

Reporting výrobcu smerom k CSIRT je iba jedna strana procesu.

Druhá otázka znie:

Ako sa o zraniteľnosti dozvie samotný výrobca?

CRA preto vyžaduje, aby výrobca poskytol jednotný kontaktný bod, prostredníctvom ktorého je možné s ním bezpečne komunikovať aj v súvislosti so zraniteľnosťami produktu. Informácie k produktu majú zároveň umožniť nájsť politiku coordinated vulnerability disclosure. (

Jedným z praktických spôsobov, ako takýto kontakt publikovať, je štandard security.txt podľa RFC 9116.

Typicky je dostupný na:

/.well-known/security.txt

a môže v strojovo spracovateľnej podobe uvádzať napríklad:

  • kontakt pre hlásenie zraniteľností,
  • odkaz na bezpečnostnú politiku,
  • preferovaný jazyk,
  • spôsob šifrovanej komunikácie.

Dôležité je však rozlišovať právnu povinnosť od spôsobu implementácie:

CRA nepredpisuje security.txt ako jediný povinný spôsob splnenia požiadavky na kontaktný bod.

Je to štandardizovaný a praktický spôsob, ako túto komunikáciu zjednodušiť.

SBOM sa presúva priamo do SDLC

SBOM nemá byť dokument vytvorený raz za rok.

ENISA v júni 2026 zverejnila výsledky európskeho prieskumu o zavádzaní SBOM. Výsledky podľa agentúry potvrdzujú, že CRA funguje ako akcelerátor adopcie SBOM a organizácie investujú do jeho generovania, automatizácie a integrácie priamo do Software Development Life Cycle.

Praktický posun možno zjednodušiť takto.

Starý model:

Pred auditom niekto vytvorí Excel so zoznamom knižníc.

Zrelší model:

Build alebo release automaticky vytvorí aktuálny strojovo spracovateľný obraz komponentov konkrétnej verzie produktu.

Takýto SBOM možno ďalej prepájať s:

  • databázami zraniteľností,
  • vulnerability managementom,
  • release managementom,
  • podporovanými verziami,
  • bezpečnostnou dokumentáciou,
  • incidentným procesom.

Hodnota potom nevzniká zo samotného súboru, ale zo schopnosti používať ho počas životného cyklu produktu.

SPDX alebo CycloneDX?

V praxi sa dnes často používajú strojovo spracovateľné formáty ako SPDX alebo CycloneDX.

Pre firmu však nemusí byť prvou otázkou:

SPDX alebo CycloneDX?

Najskôr potrebuje vyriešiť:

Dokážeme spoľahlivo vytvoriť aktuálny SBOM pre konkrétny produkt a konkrétnu verziu?

A až následne vybrať formát podľa:

  • existujúceho vývojového stacku,
  • CI/CD,
  • používaných bezpečnostných nástrojov,
  • požiadaviek zákazníkov,
  • spôsobu ďalšieho spracovania dát.

CRA pracuje s požiadavkou na bežne používaný a strojovo spracovateľný formát a zároveň vytvára priestor na ďalšie technické spresňovanie.

A čo HBOM, CBOM alebo AIBOM?

V odborných diskusiách možno naraziť aj na ďalšie typy „Bill of Materials“, napríklad:

  • HBOM pri hardvérových komponentoch,
  • CBOM pri kryptografických prvkoch,
  • AIBOM pri AI modeloch a komponentoch.

Tieto evidencie môžu byť podľa charakteru konkrétneho produktu veľmi užitočné.

Nie je však správne automaticky prezentovať ich ako univerzálnu povinnosť každého výrobcu podľa CRA.

CRA explicitne pracuje so Software Bill of Materials – SBOM.

Potrebu ďalších typov BOM treba posudzovať podľa konkrétneho produktu, jeho technológie, architektúry a ďalších relevantných požiadaviek.

Musí výrobca SBOM zverejniť?

Nie.

CRA neznamená, že výrobca musí automaticky publikovať kompletný SBOM svojho produktu na webovej stránke.

SBOM je predovšetkým súčasťou procesu identifikácie komponentov a riadenia zraniteľností a súvisí s technickou dokumentáciou produktu. CRA počíta aj s možnosťou, že relevantný SBOM bude požadovaný orgánom dohľadu pri posudzovaní softvérových závislostí produktu.

Pre výrobcu je preto podstatné, aby SBOM:

  • existoval,
  • bol aktuálny,
  • zodpovedal konkrétnej verzii produktu,
  • bol strojovo spracovateľný,
  • a dal sa reálne použiť pri posudzovaní zraniteľností.

Otázka jeho poskytovania zákazníkom môže byť následne súčasťou konkrétneho obchodného alebo zmluvného modelu.

Čo má dobrý SBOM proces vedieť

Nie konkrétny nástroj, ale celý proces by mal vedieť odpovedať aspoň na tieto otázky:

  1. Aké komponenty obsahuje konkrétny produkt a jeho verzia?
  2. Ktoré komponenty sú vlastné a ktoré pochádzajú od tretích strán?
  3. Aké open-source závislosti používame?
  4. Ktoré produkty obsahujú konkrétny zraniteľný komponent?
  5. Ktoré podporované verzie produktu sú dotknuté?
  6. Kto zodpovedá za vyhodnotenie a opravu?
  7. Je komponent stále podporovaný a aktualizovateľný?
  8. Vieme po oprave preukázať, v ktorých verziách už zraniteľnosť nie je prítomná?

Ak odpoveď na tieto otázky vyžaduje manuálne obvolávanie jednotlivých developerov, firma má síce informácie o svojich komponentoch, ale ešte nemá zrelý SBOM proces.

SBOM má zmysel iba v spojení s ďalšími procesmi

Najväčšia hodnota vzniká až vtedy, keď sa SBOM prepojí s:

  • produktovým managementom,
  • secure SDLC,
  • vulnerability managementom,
  • release managementom,
  • supportom,
  • incident response,
  • technickou dokumentáciou.

Vznikne tak sledovateľná väzba:

komponent → produkt → verzia → zraniteľnosť → posúdenie → rozhodnutie → oprava → dôkaz

Práve táto stopa je pre produktovú bezpečnosť omnoho cennejšia než samotný export zo skenera.

Kde začať

Softvérová firma nemusí hneď kupovať komplexnú supply-chain security platformu.

Dobrým začiatkom môže byť jedna produktová rodina.

Pri nej si skúste zodpovedať:

  • ktoré verzie stále podporujeme,
  • z čoho sú postavené,
  • ako dnes evidujeme priame a tranzitívne závislosti,
  • kde vzniká informácia o verzii komponentu,
  • ktoré nástroje už používajú development a DevOps tímy,
  • kto dostáva vulnerability alerts,
  • kto rozhoduje o aktualizáciách,
  • ako sa oprava dostane k zákazníkovi.

Až potom má zmysel riešiť automatizáciu, formát SBOM a integráciu do CI/CD.

Tým sa vyhneme situácii, keď firma síce generuje technicky správny súbor, ale nikto ho nepoužíva na rozhodovanie.

SBOM nie je cieľ. Je to mapa.

Samotný SBOM produkt neurobí bezpečným.

Je to mapa, ktorá výrobcovi umožňuje pochopiť, z čoho jeho produkt vznikol a ktoré časti môžu byť ovplyvnené novou zraniteľnosťou.

Bez tejto mapy sa vulnerability alert začína otázkou:

„Kto vie, kde tú knižnicu používame?“

So zrelším procesom môže firma začať otázkou:

„Ktoré produkty a podporované verzie musíme preveriť ako prvé?“

To je rozdiel medzi reaktívnym hasením jednotlivých zraniteľností a systematickým riadením produktovej bezpečnosti.

CRA preto neposúva SBOM do popredia preto, aby výrobcovia vytvorili ďalší dokument. Posúva ho tam preto, aby výrobca poznal svoj produkt, vedel reagovať na zraniteľnosti a dokázal túto zodpovednosť udržať počas jeho životného cyklu.

Zdroje a ďalšie informácie