Ako vygenerovať SBOM z package-lock.json alebo NuGet za 10 minút

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; 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):

1. 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.
2. 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.
3. 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í.

.NET / NuGet projekt

Pre .NET je najpriamejší oficiálny nástroj CycloneDX:

1. Inštalácia: dotnet tool install --global CycloneDX (raz).
2. Generovanie: dotnet CycloneDX MyApp.sln -j -o . — prejde solution alebo projekt a vytvorí CycloneDX (-j = JSON) do aktuálneho priečinka.
3. 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ý:

1. Verzujte SBOM s každým releasom. Každá verzia produktu má vlastný zoznam komponentov — inak neviete, ktorá dodaná verzia je zraniteľná.
2. Zaraďte generovanie do CI. Jeden krok v pipeline, ktorý pri builde vypľuje sbom.cdx.json ako artefakt, znamená, že nikdy nezabudnete.
3. 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.
4. 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ý:

1. Docker image: syft scan <image>:<tag> -o cyclonedx-json=sbom.cdx.json alebo trivy image --format cyclonedx --output sbom.cdx.json <image>:<tag> — zachytí OS balíčky aj aplikačné závislosti vnútri image.
2. 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.
3. 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.

Časté otázky

1. 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.
2. Stačí package.json / .csproj? Nie — manifest nemá presné vyriešené verzie ani tranzitívne závislosti. Generujte z lock súboru alebo buildu.
3. Ako často SBOM regenerovať? Pri každom release; ideálne automaticky v CI, aby ste nezabudli.
4. 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, 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) 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.