# Ako vygenerovať SBOM z package-lock.json alebo NuGet za 10 minút Canonical: https://craguard.eu/sk/blog/ako-vygenerovat-sbom-za-10-minut Language: sk Naposledy aktualizované: 2026-09-02 - [CRAguard](https://craguard.eu/sk)/ - [Blog](https://craguard.eu/sk/blog)/ - Ako vygenerovať SBOM z package-lock.json alebo NuGet za 10 minút 18. 8. 2026 · CRAguard Zhrnutie SBOM sa negeneruje ručne — vytvoríte ho z lock súboru jedným príkazom. Ukazujeme konkrétne príkazy pre Syft, Trivy, `npm sbom` a CycloneDX .NET, výstup v CycloneDX aj SPDX, a čo z toho CRA (Príloha I časť II) skutočne požaduje: aspoň top-level závislosti v bežnom strojovo čitateľnom formáte. Nie je to raketová veda a nepotrebujete konzultanta. SBOM znie ako veľká compliance úloha, ale v praxi je to jeden príkaz a pár minút. Cyber Resilience Act ho vyžaduje v **Prílohe I, časť II, bod 1** ako súčasť procesu riešenia zraniteľností — a nepredpisuje pri tom žiadny drahý nástroj. Tento návod je čisto praktický: čo presne spustiť pri Node.js aj .NET projekte, aby ste mali SBOM v oboch bežných formátoch. ## Čo z SBOM žiada CRA (v skratke) Aby ste vedeli, kedy je hotovo: nariadenie (EÚ) 2024/2847 hovorí o **minimálne top-level (priamych) závislostiach** v *bežne používanom, strojovo čitateľnom formáte*. Konkrétny štandard nepredpisuje — v praxi to znamená **CycloneDX alebo SPDX**, dva zavedené formáty. SBOM **nezverejňujete**: je súčasťou technickej dokumentácie a predkladá sa orgánu dohľadu nad trhom na žiadosť. Detailne to rozoberá [SBOM pre malé firmy](https://craguard.eu/sk/blog/sbom-pre-male-firmy-co-od-vas-cra-chce); tu ideme rovno na príkazy. ## Node.js / npm projekt Ak máte `package-lock.json`, máte tri jednoduché cesty. Najrýchlejšia je vstavaný príkaz npm (od npm 10): - **Vstavané v npm:** `npm sbom --sbom-format cyclonedx > sbom.cdx.json` — vyrobí CycloneDX priamo z lock súboru, bez inštalácie čohokoľvek navyše. Pre SPDX použite `--sbom-format spdx`. - **Syft** (open source, Apache-2.0): `syft scan dir:. -o cyclonedx-json=sbom.cdx.json -o spdx-json=sbom.spdx.json` — jedným behom vyrobí oba formáty naraz. Vie čítať aj priamo lock súbor: `syft scan file:package-lock.json -o cyclonedx-json`. - **Trivy** (open source, Apache-2.0): `trivy fs --format cyclonedx --output sbom.cdx.json .` — Trivy navyše vie ten istý sken hneď porovnať proti databázam zraniteľností. 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) ## .NET / NuGet projekt Pre .NET je najpriamejší oficiálny nástroj CycloneDX: - **Inštalácia:** `dotnet tool install --global CycloneDX` (raz). - **Generovanie:** `dotnet CycloneDX MyApp.sln -j -o .` — prejde solution alebo projekt a vytvorí CycloneDX (`-j` = JSON) do aktuálneho priečinka. - **Alternatíva Syft:** `syft scan dir:. -o cyclonedx-json=sbom.cdx.json` funguje aj nad `packages.lock.json` (ak máte zapnutý `RestorePackagesWithLockFile`). Ak lock súbor ešte nemáte, pri .NET ho zapnete cez `RestorePackagesWithLockFile` v `.csproj` a `dotnet restore` ho vytvorí — vďaka nemu bude SBOM obsahovať presné vyriešené verzie, nielen rozsahy z manifestu. ## Pár zásad, aby vám SBOM naozaj slúžil Vygenerovať súbor je začiatok; hodnotu má, keď je aktuálny a dohľadateľný: - **Verzujte SBOM s každým releasom.** Každá verzia produktu má vlastný zoznam komponentov — inak neviete, ktorá dodaná verzia je zraniteľná. - **Zaraďte generovanie do CI.** Jeden krok v pipeline, ktorý pri builde vypľuje `sbom.cdx.json` ako artefakt, znamená, že nikdy nezabudnete. - **Uchovávajte ho s dokumentáciou.** Technická dokumentácia sa podľa CRA uchováva aspoň 10 rokov od uvedenia na trh (alebo počas support periódy, ak je dlhšia) — SBOM patrí k nej. - **Nezastavte sa pri top-level.** Minimum sú priame závislosti, ale Syft aj Trivy zachytia aj tranzitívne — a práve tie vás pri prvom incidente najčastejšie prekvapia. ## Kontajnery, monorepá a viac jazykov Ak nedodávate holý kód, ale **kontajner** alebo aplikáciu z viacerých jazykov, princíp je rovnaký, len cieľ skenu je iný: - **Docker image:** `syft scan : -o cyclonedx-json=sbom.cdx.json` alebo `trivy image --format cyclonedx --output sbom.cdx.json :` — zachytí OS balíčky aj aplikačné závislosti vnútri image. - **Monorepo s viacerými ekosystémami** (napr. Node front-end + .NET back-end): oba nástroje prejdú celý strom a poskladajú jeden SBOM naprieč jazykmi. Alebo vygenerujte SBOM per komponent a zlúčte ich pri release. - **Priradenie k verzii produktu:** SBOM pomenujte a ulož s číslom verzie, ktorú dodávate — `sbom-2.5.0.cdx.json`. To je to, čo neskôr umožní odpovedať „ktoré vydané verzie sú zraniteľné". ## Čo SBOM sám osebe nerieši SBOM je zoznam, nie strážca. Sám vám nepovie, že v komponente pribudla nová zraniteľnosť — to zistíte, až keď ho **porovnáte proti databázam** (OSV.dev, NVD, CISA KEV). A práve to porovnávanie je opakovaná, nie jednorazová robota: nové CVE vychádzajú denne. Ako skratky (CVE, CVSS, EPSS, KEV) čítať, rozoberáme v [samostatnom článku](https://craguard.eu/sk/blog/cve-cvss-epss-kev-vysvetlene). ## Časté otázky - **CycloneDX alebo SPDX?** CRA nepredpisuje; oba sú „bežne používané, strojovo čitateľné". Syft aj Trivy vedia vyrobiť oba naraz, tak si spravte oba. - **Stačí package.json / .csproj?** Nie — manifest nemá presné vyriešené verzie ani tranzitívne závislosti. Generujte z lock súboru alebo buildu. - **Ako často SBOM regenerovať?** Pri každom release; ideálne automaticky v CI, aby ste nezabudli. - **Musíme SBOM zverejniť?** Nie — je súčasťou technickej dokumentácie a predkladá sa orgánu na žiadosť. ## Na čo si dať pozor Dve chyby sa opakujú. Prvá: vygenerovať SBOM raz „na ukážku" a nechať ho zastarať — pri prvom incidente potom nesedí s dodanou verziou. Druhá: spoľahnúť sa na manifest namiesto lock súboru, takže SBOM nemá presné verzie a monitoring proti databázam je nespoľahlivý. Oboje rieši jeden návyk: generovať SBOM z lock súboru automaticky pri builde a verzovať ho s vydaním. Potom je SBOM vždy aktuálny a použiteľný na to najdôležitejšie — rýchle „týka sa nás nové CVE?". ## Kľúčový bod SBOM nie je hory papierov, ale jeden príkaz a pár minút. **Príloha I časť II** ho žiada ako súčasť riešenia zraniteľností — minimálne top-level závislosti v bežnom strojovo čitateľnom formáte (CycloneDX alebo SPDX). Node.js projekt: `npm sbom`, Syft alebo Trivy z lock súboru. .NET: `dotnet CycloneDX` alebo Syft nad `packages.lock.json`. Kontajner či monorepo? Rovnaké nástroje, iný cieľ skenu. Kľúčové návyky: generujte z **lock súboru** (nie z manifestu), zaraďte to do CI a **verzujte SBOM s každým releasom**. SBOM je ale len zoznam, nie strážca — hodnotu má, až keď ho priebežne porovnávate proti databázam (OSV, KEV, EPSS). To je opakovaná robota, lebo nové CVE pribúdajú denne — a práve automatizácia toho porovnávania rozhoduje o tom, či odpoveď „týka sa nás?" máte za chvíľu alebo za hodiny. ## Ako pomáha CRAguard CRAguard vezme váš lock súbor, vygeneruje z neho SBOM (CycloneDX aj SPDX), drží ho verzovaný pri každom vydaní a **denne** ho porovnáva s OSV, KEV a EPSS — takže odpoveď „týka sa nás nové CVE?" máte hotovú skôr, než sa spustí 24-hodinová lehota z čl. 14. [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) a usmernenia Európskej komisie zo dňa 27. 7. 2026. Uvedené nástroje sú tretích strán; príkazy si overte podľa aktuálnej verzie nástroja.* 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