# SBOM pre malé firmy: čo od vás CRA naozaj chce (a čo nie) Canonical: https://craguard.eu/sk/blog/sbom-pre-male-firmy-co-od-vas-cra-chce Language: sk Naposledy aktualizované: 2026-09-02 - [CRAguard](https://craguard.eu/sk)/ - [Blog](https://craguard.eu/sk/blog)/ - SBOM pre malé firmy: čo od vás CRA naozaj chce (a čo nie) 3. 9. 2026 · CRAguard Zhrnutie SBOM je strojovo čitateľný zoznam softvérových komponentov vášho produktu. CRA ho vyžaduje v Prílohe I ako súčasť procesu riešenia zraniteľností — stačia top-level závislosti v bežnom formáte (CycloneDX alebo SPDX). Nezverejňuje sa: je súčasťou technickej dokumentácie a predkladá sa na žiadosť orgánu dohľadu. Vyrobíte ho z buildu jedným príkazom nástrojmi Syft alebo Trivy. 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](https://craguard.eu/sk/blog/cra-reporting-11-9-2026) — 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. Scope-checker ### Zistite, či sa vás CRA týka Šesť otázok, dve minúty, bez účtu. Dostanete triedu produktu a prvé kroky. [Spustiť scope-checker](https://craguard.eu/sk/checker) ## 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ď: - **Verzujte SBOM s každým releasom.** Každá verzia produktu má svoj vlastný zoznam komponentov — inak neviete, ktorá dodaná verzia je zraniteľná. - **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. - **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](https://craguard.eu/sk/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](https://craguard.eu/sk/checker), alebo sa [zaraďte do waitlistu](https://craguard.eu/sk#waitlist) — 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.* Scope-checker ### Zistite, či sa vás CRA týka Šesť otázok, dve minúty, bez účtu. Dostanete triedu produktu a prvé kroky. [Spustiť scope-checker](https://craguard.eu/sk/checker) ## Zdroje - [EUR-Lex — Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) - [ENISA — Single Reporting Platform](https://www.enisa.europa.eu/) --- Zdroj: CRAguard — https://craguard.eu