V roce 2026 o 131% více nahlášených CVE denně než loni.

Generování SBOM zaznamenané během buildu

CRACI je nástroj pro generování SBOM, který zaznamenává, co každý build v GitHub Actions skutečně stáhl, místo aby soubory skenoval až potom. Každá SBOM uvádí, jak je úplná.

Ve zkratce: spouštějte své joby GitHub Actions na runnerech CRACI a každý job dostane SBOM balíčků, které stáhl, včetně tranzitivních závislostí a balíčků obnovených z cache CI, exportovanou ve formátu CycloneDX nebo SPDX. Každá SBOM nese stav úplnosti a po vydání se monitoruje kvůli novým zranitelnostem. Skenovací nástroje jako Syft a Trivy rekonstruují SBOM ze souborů; CRACI ji zaznamenává z buildu. Proč se SBOM z doby buildu liší.

Zaznamenáno během buildu, ne naskenováno potom

Většina generátorů SBOM čte soubory až po buildu a rekonstruuje, co do něj podle nich vstoupilo. CRACI generuje SBOM uvnitř vlastního runneru CI. Proxy, která rozumí balíčkům, sleduje provoz každého jobu ke zdrojům balíčků, takže SBOM uvádí, co job skutečně stáhl, včetně tranzitivních závislostí, a ne to, co by podle manifestu měl potřebovat. Aby záznam vznikl, není potřeba lockfile, nainstalovaný strom závislostí ani další krok skenování.

Recorded during the build, not scanned afterwards A scanner reads a lockfile or manifest after the fact and reconstructs what it thinks went in. CRACI observes the job's traffic to package sources while the build runs, including packages restored from CI caches, so the SBOM lists what the job actually pulled in. A scanner, after the build Lockfile Scanner SBOM Reconstructs what it thinks went in, from the files it can read Nothing tells you what it missed CRACI, during the build Job fetches Proxy records Job SBOM Lists what the job actually pulled in, including packages restored from CI caches Completeness stated for every job

Každá úroveň tranzitivních závislostí

Většina toho, co build stáhne, není přímá závislost. Je to závislost závislosti o několik úrovní níž a část z toho se v lockfilu vůbec neobjeví: předpřipravené binárky, které stáhne skript buildu, balíčky obnovené z cache, balíčky operačního systému. CRACI zaznamená každý balíček, který job stáhl, v jakékoli hloubce, takže se zranitelnosti porovnávají s celým stromem. Při přímém srovnání s jinými nástroji SBOM odhalil tento úplnější záznam zranitelnosti, které ostatní nástroje nenahlásily.

Every layer of transitive dependencies A dependency tree three layers deep. The app depends directly on express, pg and a build script. Express pulls in body-parser and router, which pull in raw-body and path-to-regexp; pg pulls in pg-protocol. The build script fetches a prebuilt library during the build, which bundles a native codec that matches a vulnerability advisory. A lockfile scanner sees the packages the lockfile lists; CRACI records every package the job fetched, at every depth, including the ones only the build pulls in. Your app Direct Layer 2 Layer 3 your-app express pg build script body-parser router pg-protocol prebuilt lib raw-body path-to-regexp native-codec advisory match In the lockfile and the build record Only in the build record: fetched while the job ran Matched an advisory, so it is tracked like any other

Balíčky obnovené z cache CI zůstávají v SBOM

Právě u cache se záznam v době buildu obvykle rozbije: balíček obnovený z cache se nikdy nedotkne registru, takže samotná proxy by ho přehlédla. CRACI přenáší důkazy o závislostech spolu s cache, takže balíčky obnovené z cache CI zůstávají v SBOM jobu, který je obnovil.

Packages restored from CI caches stay in the SBOM A first job fetches packages from a registry through CRACI's proxy and saves a cache. The dependency evidence travels with the cache, so when a later job restores it, those packages stay in that job's SBOM even though they never touched a registry. First run: cache miss npm registry Job 1 fetches Cache + evidence Packages recorded through the proxy Later run: cache hit Job 2 restores Cache + evidence No registry request, packages still recorded Job 2 SBOM express 5.2.1 (from cache) lodash 4.17.21 (from cache) Cache-restored packages stay in the SBOM

Stav úplnosti pro každý job

Sledování zranitelností dokáže porovnat jen komponenty, které vaše SBOM uvádí. Balíček, který v SBOM chybí, je zranitelnost, na kterou nikoho nic neupozorní. Proto CRACI nevydává každou SBOM za úplnou, ale uvádí úplnost pro každý job a každou cache: Complete, Complete with connections, Incomplete, Unavailable nebo Not recorded. Víte tak, na které SBOM se můžete spolehnout a které je potřeba prověřit.

A completeness state for every job Instead of presenting every SBOM as complete, CRACI states completeness for each job and each cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded. Workflow run: SBOM completeness Job Completeness build Complete test Complete with connections integration Incomplete docs Not recorded Why it matters Vulnerability tracking can only match listed components. A package missing from the SBOM is a vulnerability nobody is alerted about, so CRACI says when a list is partial.

Ekosystémy a formáty, které dodáváte

CRACI zaznamenává balíčky ze zdrojů npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk a Git a k tomu předvolby pro stahování Yocto a OpenEmbedded, a zrcadla npm a PyPI v JFrog Artifactory považuje za známé zdroje. Podpora Mavenu a Javy je v plánu vývoje. SBOM se exportují ve formátech CycloneDX a SPDX včetně tranzitivních závislostí, připravené ke sdílení se zákazníky, partnery a auditory.

Ecosystems and formats CRACI records packages from npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk and Git sources, plus Yocto and OpenEmbedded download presets, and treats JFrog Artifactory npm and PyPI mirrors as known sources. Maven and Java are on the roadmap. SBOMs export as CycloneDX or SPDX. Recorded today npm PyPI RubyGems Cargo Go Nix OCI apt · apk Git sources, Yocto presets Artifactory npm, PyPI mirrors On the roadmap Maven and Java Export CycloneDX SPDX With transitive dependencies and declared licenses

Deklarované licence u každé komponenty

Každý zaznamenaný balíček přenáší svou deklarovanou licenci do SBOM. Ještě před dodáním vidíte, které závislosti jsou pod komerční nebo jinak omezující licencí, a copyleftové licence zachytíte dříve, než skončí ve vašem produktu.

Declared licenses on every component Every recorded package carries its declared license into the SBOM, so restrictive and copyleft licenses show up before you ship. License policy rules can block a build on a license. Job SBOM: components and licenses Component Declared license express 5.2.1 MIT requests 2.32.3 Apache-2.0 serde 1.0.219 MIT OR Apache example-lib 1.4.0 GPL-3.0 copyleft License policy Build blocked: GPL-3.0 is not allowed Caught before it ends up in your product

Údaje o původu přes API

SBOM je jednou částí toho, co CRACI u každého jobu zaznamenává. Veřejné REST API vrací SBOM, síťové záznamy a údaje o původu, vše zaznamenané ze stejného buildu.

Provenance data from every build Every job on CRACI records the packages it fetched and its network trace. The public REST API returns the job's SBOMs, network trace and provenance. Build release job on CRACI Recorded packages fetched network trace Provenance build data, via the API Ask the API about any job Job → SBOM, trace, provenance Returned by the API Job Packages CycloneDX SBOM Network trace Recorded on every CRACI job, no extra step

Monitorováno i po vydání

SBOM je způsob, jak firma ví, co je uvnitř softwaru, který dodává, a zákazníci i regulátoři ji stále častěji požadují: Cyber Resilience Act ukládá výrobcům povinnost vypracovat ji pro produkty prodávané v EU. CRACI průběžně znovu vyhodnocuje monitorované SBOM, jakmile se zveřejní nové zranitelnosti, agreguje nálezy napříč buildy a repozitáři a podporuje VEX. SBOM, které získáte od vlastních dodavatelů, se monitorují spolu s vašimi buildy.

Vulnerability tracking after release After a release ships, its SBOM stays monitored. When a new vulnerability is published, CRACI re-evaluates the monitored SBOMs, finds the affected releases, and the security team triages the finding and routes it to the team that owns the fix. The inventory view shows which software versions are deployed to which products. Release shipped SBOM monitored Later New advisory published Re-evaluated automatically Finding: critical, in 2 releases 1. Triage 2. Route to owner 3. Team fixes Policy gates can block a build on findings · VEX supported Inventory: deployed versions Product Version Web app v4.12.0 Mobile API v2.3.1

Zaznamenaná SBOM vedle naskenované

Skenery jsou správným nástrojem pro software, který jste nesestavili sami. U vašich vlastních vydání mění záznam buildu toto. Skener přečte lockfile nebo výstup a odvodí, co do buildu vstoupilo. CRACI vidí provoz přicházející do buildu, takže se do SBOM dostanou i skryté závislosti, které stahují instalační hooky, skripty buildu a základní image.

How a scanned SBOM and a recorded SBOM are made Left, a scanner: it reads the lockfile after the build, which lists packages A to E, so its SBOM contains A to E. The build also fetched code through an install hook, a build script download and a base image, which are in no lockfile, so the scanned SBOM is missing them. Right, CRACI: it sees the traffic coming into the build, so all eight packages, including the three hidden dependencies, land in the recorded SBOM. Scanner reads files after the build package-lock.json A B C D E the build also fetched install hook download build script download base image layers in no lockfile, so the scan never sees them Scanned SBOM A B C D E missing missing missing CRACI sees the traffic into the build the network build job on CRACI every package that comes in Recorded SBOM A B C D E install hook build script base image hidden ones too
A scanner can only list what the lockfile or the output declares. CRACI sees what actually came into the build, including the hidden dependencies.
CRACI Nástroj SBOM založený na skeneru
Jak vzniká seznam komponent Zaznamenán z vlastního provozu balíčků buildu Zpětně rekonstruován ze souborů
Potřebuje lockfile nebo nainstalované závislosti Ne Obvykle jedno nebo druhé
Balíčky obnovené z cache CI Důkazy putují spolu s cache Jen pokud jsou soubory v době skenování na místě
Stav úplnosti pro každý job Pět stavů, pro každý job a každou cache
Podepsané propojení artefaktu s buildem Bez podepsaných údajů o původu S odděleným krokem podepisování
Software, který jste nesestavili sami Místo toho přidejte SBOM dodavatele
Systémy CI Dnes GitHub Actions; další systémy CI v plánu vývoje Běží v jakémkoli CI
  • Součástí
  • Částečně
  • Není součástí
  • V plánu vývoje

Srovnáváte konkrétní nástroje? Srovnání nástrojů SBOM zahrnuje Syft, Trivy, cdxgen, Microsoft SBOM Tool, Dependency-Track a další. Širší obrázek nabízí srovnání nástrojů pro bezpečnost softwarového dodavatelského řetězce. Zavádíte SBOM v mnoha týmech? Viz generování SBOM napříč vývojářskými týmy.

SBOM basics: SPDX, CycloneDX and OpenVEX

Co SBOM zaznamenává, jak se formáty SPDX a CycloneDX liší v praxi a co přidává OpenVEX k otázce, zda zranitelnost produkt skutečně ovlivňuje.

Petteri Pulkkinen a Erika Marttinen na akci Kubernetes Community Days Helsinki 2026, od 16:50 do 22:05 záznamu SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

Generování SBOM: časté dotazy

Co je generování SBOM?

Generování SBOM je vytvoření softwarového kusovníku: strojově čitelného seznamu komponent a závislostí v daném softwaru. Lze ho provést ze zdrojových souborů, během buildu nebo analýzou hotového artefaktu, například image kontejneru. CRACI generuje SBOM během buildu, z toho, co build skutečně stáhl.

Jak CRACI generuje SBOM?

Vaše joby GitHub Actions běží na runnerech CRACI. Během každého jobu sleduje proxy, která rozumí balíčkům, jeho provoz ke zdrojům balíčků a zaznamenává balíčky, které stahuje, včetně tranzitivních závislostí a balíčků obnovených z cache CI. Každý job dostane vlastní SBOM se stavem úplnosti.

Musím měnit svá workflow?

Změníte runs-on na craci. CRACI nahrazuje runner, ne GitHub Actions, takže vaše workflow i jejich běhy zůstávají na GitHubu.

Které ekosystémy balíčků CRACI zaznamenává?

Zdroje npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk a Git a k tomu předvolby pro stahování Yocto a OpenEmbedded. Zrcadla npm a PyPI v JFrog Artifactory se považují za známé zdroje. Podpora Mavenu a Javy je v plánu vývoje.

Které formáty SBOM mohu exportovat?

CycloneDX a SPDX, včetně tranzitivních závislostí a deklarované licence každé komponenty.

Co znamená stav úplnosti?

Complete znamená, že CRACI zaznamenalo úplné důkazy z jobu a každá obnovená cache byla úplná. Complete with connections znamená, že job navíc použil vlastní síťová spojení, která stojí za kontrolu. Incomplete znamená, že nějaká podmínka mohla závislosti vynechat. Unavailable znamená, že důkazy nebylo možné vyhodnotit, a Not recorded znamená, že job vznikl dříve, než se úplnost začala vykazovat. Viz úplnost SBOM.

Najde CRACI zranitelnosti v SBOM?

Ano. CRACI průběžně znovu vyhodnocuje monitorované SBOM, jakmile se zveřejní nové zranitelnosti, agreguje nálezy napříč buildy a repozitáři a podporuje VEX. Bezpečnostní týmy provádějí triáž toho, co najde, a předávají to týmům, které odpovídají za opravu.

Dokáže CRACI vygenerovat SBOM pro software, který jsem nesestavil?

Ne. CRACI zaznamenává buildy, které běží na jeho runnerech. U softwaru, který kupujete, přidejte SBOM dodavatele a CRACI ji bude monitorovat spolu s vašimi vlastními buildy. Pro image třetí strany, které jste nesestavili, je praktickou volbou skener; viz srovnání nástrojů SBOM.

Podívejte se na SBOM svého vlastního buildu

Rezervujte si demo, spusťte jedno ze svých workflow GitHub Actions na CRACI a podívejte se, co skutečně stáhlo

Rezervujte si demo