SBOM pre malé firmy: čo od vás CRA naozaj chce (a čo nie)

Keď sa povie „splniť Cyber Resilience Act", väčšina malých softvérových firiem si predstaví hory papierov. V skutočnosti je jedna z prvých a najužitočnejších vecí veľmi konkrétna a dá sa vyrobiť za pár minút: SBOM — Software Bill of Materials, čiže zoznam softvérových komponentov, z ktorých sa váš produkt skladá. Tento článok vysvetľuje, čo od neho nariadenie (EÚ) 2024/2847 naozaj chce, čo je len mýtus, a ako si SBOM spravíte bez konzultanta.

Ak ešte nemáte prehľad o tom, čo všetko vás od 11. septembra 2026 čaká, začnite prvým článkom o reportingu — SBOM je jedna z piatich vecí, ktoré tam odporúčame spraviť hneď.

Čo je SBOM a prečo ho CRA chce

SBOM je jednoducho zoznam komponentov — knižníc, balíčkov a závislostí — ktoré sú vo vašom produkte, spolu s ich verziami. Predstavte si zloženie na obale potraviny, len pre softvér.

CRA ho vyžaduje v Prílohe I, časť II, bod 1 ako súčasť procesu riešenia zraniteľností: výrobca má „identifikovať a zdokumentovať komponenty produktu", a to vrátane vytvorenia SBOM. Nariadenie hovorí o minimálne top-level (priamych) závislostiach a o „bežne používanom, strojovo čitateľnom formáte". Nepredpisuje konkrétny štandard — v praxi to znamená CycloneDX alebo SPDX, dva zavedené strojovo čitateľné formáty. Komisia môže formát a povinné polia neskôr upresniť vykonávacím aktom, ale zatiaľ žiadny taký akt nevyšiel — takže dnes stačí ktorýkoľvek z tých dvoch formátov.

Čo presne zákon vyžaduje (a čo nie)

Tu sa oplatí byť presný, lebo okolo SBOM koluje veľa nedorozumení.

SBOM sa nezverejňuje. Nie je to verejný dokument ani niečo, čo by ste vešali na web. Je súčasťou vašej technickej dokumentácie a predkladáte ho na žiadosť orgánu dohľadu nad trhom. To je celý rozsah zákonnej povinnosti smerom von.

Niečo iné je obchodný tlak: veľkí odberatelia či verejní obstarávatelia si SBOM čoraz častejšie pýtajú zmluvne, ako podmienku dodávky. To ale nie je požiadavka CRA — je to požiadavka vášho zákazníka. Ak vám ju dá, splníte ju tým istým súborom, ktorý aj tak potrebujete pre dokumentáciu.

A do tretice: SBOM neposielate agentúre ENISA ani nikam „na sklad". Cez platformu ENISA sa hlásia len aktívne zneužívané zraniteľnosti a závažné incidenty — nie zoznamy komponentov.

Na čo vám SBOM v praxi je

Aj keby ho zákon nechcel, SBOM je vec, ktorá vám ušetrí najviac nervov v tom najhoršom momente. Od 11. septembra 2026 platí povinnosť hlásiť aktívne zneužívanú zraniteľnosť do 24 hodín (článok 14). Keď vyjde nová zraniteľnosť — nové CVE — musíte rýchlo vedieť odpovedať na jedinú otázku: týka sa nás to?

Bez zoznamu komponentov na to nemáte ako odpovedať inak než ručným prehrabávaním kódu pod časovým tlakom. So SBOM sa porovnanie dá zautomatizovať: zoznam vašich komponentov a verzií proti databázam zraniteľností — OSV.dev, NVD, CISA KEV — a odpoveď máte v priebehu chvíle namiesto hodín. Presne to je nadväznosť medzi SBOM a reportovacou povinnosťou z článku 14.

A nejde len o ten jeden incident. Keď máte zoznam komponentov pri každej verzii produktu, viete kedykoľvek povedať, ktoré dodané verzie treba opraviť a ktoré sú v poriadku — bez hádania a bez toho, aby ste otvárali starý kód. To je rozdiel medzi odpoveďou „preverujeme to" a odpoveďou „verzie 2.3 a 2.4 áno, staršie nie, oprava je vo verzii 2.5".

Ako ho vyrobiť za pár minút

Dobrá správa: SBOM sa nepíše ručne. Generuje sa z vášho buildu alebo lock súboru hotovými nástrojmi.

Najčastejšie sa používajú dva open-source nástroje s licenciou Apache-2.0: Syft a Trivy. Oba vedia prejsť váš projekt alebo build a vyrobiť SBOM jedným príkazom, s exportom do CycloneDX aj SPDX. Nemusíte sa rozhodovať medzi formátmi — vygenerujete si oba.

Pár praktických zásad, ktoré sa oplatí zaviesť hneď:

1. Verzujte SBOM s každým releasom. Každá verzia produktu má svoj vlastný zoznam komponentov — inak neviete, ktorá dodaná verzia je zraniteľná.
2. Uchovávajte ho s dokumentáciou. Technická dokumentácia sa podľa CRA uchováva 10 rokov od uvedenia produktu na trh (alebo počas support periódy, ak je dlhšia) — SBOM patrí k nej.
3. Nezabudnite na verzie a tranzitívne závislosti. Minimum je top-level, ale mať aspoň prehľad o tom, čo si vaše priame závislosti ťahajú so sebou, sa vám pri prvom incidente vráti.

Tri časté omyly

- „Sme SaaS, SBOM nepotrebujeme." Čistý cloudový SaaS je prevažne mimo pôsobnosti CRA. Ak ale k službe dodávate klientsku aplikáciu, agenta alebo zariadenie, ten kus produktom je — a SBOM preň platí. Ak si nie ste istí, náš scope-checker vám to povie za dve minúty. - „Stačí nám package.json." Manifest je dobrý začiatok, ale nie je to SBOM. Chýbajú v ňom presné vyriešené verzie a nezohľadňuje tranzitívne závislosti. Minimum sú top-level komponenty s verziami — a tie z holého manifestu spoľahlivo nevyčítate. - „SBOM musím poslať na ENISA." Nie. Cez platformu ENISA sa hlásia zraniteľnosti a incidenty, nie SBOM. Ten ostáva u vás v dokumentácii.

Ako pomáha CRAguard

Toto je presne tá časť, ktorú chceme malým firmám zobrať z rúk. CRAguard vygeneruje SBOM z vášho lock súboru (CycloneDX aj SPDX), drží ho verzovaný pri každom vydaní, a denne ho porovnáva s OSV, KEV a EPSS — takže keď vyjde nová zraniteľnosť, odpoveď „týka sa nás to?" máte hotovú skôr, než sa spustí 24-hodinová lehota. Termíny sú jasné: 11. 9. 2026 reporting a 11. 12. 2027 plná konformita a CE. Zistite, či sa vás CRA týka, alebo sa zaraďte do waitlistu — dáme vedieť pri spustení.

Tento článok je informatívny a nie je právnym poradenstvom. Vychádza z nariadenia (EÚ) 2024/2847 (Príloha I časť II, čl. 13, čl. 14), guidance Európskej komisie zo dňa 27. 7. 2026 a FAQ agentúry ENISA k Single Reporting Platform.