O 123% więcej zgłoszonych CVE dziennie w 2026 niż przed rokiem.

Generowanie SBOM rejestrowane w trakcie buildu

CRACI to narzędzie do generowania SBOM, które rejestruje, co każdy build GitHub Actions faktycznie pobrał, zamiast skanować pliki po fakcie. Każdy SBOM informuje, na ile jest kompletny.

W skrócie: wystarczy uruchamiać zadania GitHub Actions na runnerach CRACI, a każde zadanie otrzyma SBOM pobranych pakietów, w tym zależności przechodnich i pakietów przywróconych z cache CI, eksportowany w formacie CycloneDX lub SPDX. Każdy SBOM ma stan kompletności i jest monitorowany pod kątem nowych podatności po wydaniu. Narzędzia skanujące, takie jak Syft i Trivy, odtwarzają SBOM z plików; CRACI rejestruje go z buildu. Dlaczego SBOM-y z czasu buildu są inne.

Rejestrowany w trakcie buildu, a nie skanowany po fakcie

Większość generatorów SBOM odczytuje pliki po zakończeniu buildu i odtwarza, co prawdopodobnie do niego trafiło. CRACI generuje SBOM wewnątrz własnego runnera CI. Proxy rozpoznające pakiety obserwuje ruch każdego zadania do źródeł pakietów, dzięki czemu SBOM zawiera to, co zadanie faktycznie pobrało, łącznie z zależnościami przechodnimi, a nie to, czego według manifestu powinno potrzebować. Do powstania zapisu nie jest potrzebny lockfile, zainstalowane drzewo zależności ani dodatkowy krok skanowania.

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żdy poziom zależności przechodnich

Większość tego, co pobiera build, nie jest zależnością bezpośrednią. To zależność zależności, kilka poziomów niżej, a część z nich w ogóle nie pojawia się w lockfile: gotowe pliki binarne pobierane przez skrypt buildu, pakiety przywrócone z cache, pakiety systemu operacyjnego. CRACI rejestruje każdy pakiet pobrany przez zadanie, na każdym poziomie, więc podatności są dopasowywane do całego drzewa. W bezpośrednich porównaniach z innymi narzędziami SBOM ten pełniejszy zapis ujawnił podatności, których inne narzędzia nie zgłosiły.

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

Pakiety przywrócone z cache CI zostają w SBOM

To na cache rejestrowanie w trakcie buildu zwykle się załamuje: pakiet przywrócony z cache nigdy nie łączy się z rejestrem, więc samo proxy by go pominęło. CRACI przenosi dowody zależności razem z cache, dzięki czemu pakiety przywrócone z cache CI pozostają w SBOM zadania, które je przywróciło.

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

Stan kompletności dla każdego zadania

Śledzenie podatności może dopasować tylko te komponenty, które wymienia Państwa SBOM. Pakiet, którego brakuje w SBOM, to podatność, o której nikt nie zostanie ostrzeżony. Dlatego zamiast przedstawiać każdy SBOM jako kompletny, CRACI określa kompletność dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. Wiedzą Państwo, na których SBOM-ach można polegać, a które wymagają ponownej weryfikacji.

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.

Ekosystemy i formaty, w których Państwo dostarczają

CRACI rejestruje pakiety z npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródeł Git, a także z presetów pobierania Yocto i OpenEmbedded, i traktuje mirrory npm i PyPI w JFrog Artifactory jako znane źródła. Obsługa Maven i Javy jest w planach rozwoju. SBOM-y eksportuje się w formatach CycloneDX i SPDX, łącznie z zależnościami przechodnimi, gotowe do przekazania klientom, partnerom i audytorom.

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

Deklarowane licencje każdego komponentu

Każdy zarejestrowany pakiet przenosi do SBOM swoją deklarowaną licencję. Przed wydaniem widzą Państwo, które zależności są objęte licencją komercyjną lub w inny sposób restrykcyjną, a licencje copyleft zostają wychwycone, zanim trafią do Państwa 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

Pochodzenie (provenance) przez API

SBOM to jedna z rzeczy, które CRACI rejestruje dla każdego zadania. Publiczne REST API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu, wszystkie zarejestrowane z tego samego 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

Monitorowany po wydaniu

SBOM pozwala firmie wiedzieć, co znajduje się w oprogramowaniu, które dostarcza, a klienci i regulatorzy coraz częściej go wymagają: Cyber Resilience Act zobowiązuje producentów do sporządzenia SBOM dla produktów sprzedawanych w UE. CRACI na bieżąco ponownie ocenia monitorowane SBOM-y w miarę publikowania nowych podatności, agreguje wyniki z wielu buildów i repozytoriów oraz obsługuje VEX. SBOM-y, które otrzymują Państwo od własnych dostawców, są monitorowane razem z Państwa buildami.

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

SBOM zarejestrowany obok zeskanowanego

Skanery to właściwe narzędzie dla oprogramowania, którego nie budują Państwo sami. W przypadku własnych wydań rejestrowanie buildu zmienia następujące rzeczy. Skaner odczytuje lockfile lub wynik buildu i wnioskuje, co do niego trafiło. CRACI widzi ruch wchodzący do buildu, więc w SBOM trafiają też ukryte zależności, które pobierają hooki instalacyjne, skrypty buildu i obrazy bazowe.

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 Narzędzie SBOM oparte na skanerze
Jak powstaje lista komponentów Rejestrowana z ruchu pakietów samego buildu Odtwarzana z plików po fakcie
Wymaga lockfile lub zainstalowanych zależności Nie Zwykle jednego lub drugiego
Pakiety przywrócone z cache CI Dowody przenoszone są razem z cache Tylko jeśli pliki są obecne w chwili skanowania
Stan kompletności dla każdego zadania Pięć stanów, dla każdego zadania i cache
Podpisane powiązanie artefaktu z buildem Brak podpisanego pochodzenia Z osobnym krokiem podpisywania
Oprogramowanie, którego nie budują Państwo sami Zamiast tego proszę dodać SBOM dostawcy
Systemy CI Dziś GitHub Actions; inne systemy CI w planach rozwoju Działa w dowolnym CI
  • W zestawie
  • Częściowo
  • Brak
  • W planach rozwoju

Porównują Państwo konkretne narzędzia? Porównanie narzędzi SBOM obejmuje Syft, Trivy, cdxgen, Microsoft SBOM Tool, Dependency-Track i inne. Szerszy obraz przedstawia porównanie narzędzi bezpieczeństwa łańcucha dostaw oprogramowania.

SBOM basics: SPDX, CycloneDX and OpenVEX

Co zapisuje SBOM, czym w praktyce różnią się formaty SPDX i CycloneDX oraz co OpenVEX wnosi do pytania, czy podatność rzeczywiście dotyczy produktu.

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

Generowanie SBOM: najczęściej zadawane pytania

Czym jest generowanie SBOM?

Generowanie SBOM to tworzenie zestawienia komponentów oprogramowania (software bill of materials): czytelnej maszynowo listy komponentów i zależności danego oprogramowania. Może się odbywać na podstawie plików źródłowych, w trakcie buildu lub przez analizę gotowego artefaktu, na przykład obrazu kontenera. CRACI generuje SBOM w trakcie buildu, na podstawie tego, co build faktycznie pobrał.

Jak CRACI generuje SBOM?

Państwa zadania GitHub Actions działają na runnerach CRACI. W trakcie każdego zadania proxy rozpoznające pakiety obserwuje jego ruch do źródeł pakietów i rejestruje pobierane pakiety, w tym zależności przechodnie i pakiety przywrócone z cache CI. Każde zadanie otrzymuje własny SBOM ze stanem kompletności.

Czy muszę zmieniać swoje workflow?

Wystarczy zmienić runs-on na craci. CRACI zastępuje runner, a nie GitHub Actions, więc Państwa workflow i ich uruchomienia pozostają w GitHub.

Jakie ekosystemy pakietów rejestruje CRACI?

npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródła Git, a także presety pobierania Yocto i OpenEmbedded. Mirrory npm i PyPI w JFrog Artifactory są traktowane jako znane źródła. Obsługa Maven i Javy jest w planach rozwoju.

W jakich formatach mogę eksportować SBOM?

CycloneDX i SPDX, łącznie z zależnościami przechodnimi i deklarowaną licencją każdego komponentu.

Co oznacza stan kompletności?

Complete oznacza, że CRACI zaobserwował kompletne dowody zadania, a każdy przywrócony cache był kompletny. Complete with connections oznacza, że zadanie korzystało też z niestandardowych połączeń sieciowych, które warto przejrzeć. Incomplete oznacza, że pewien warunek mógł spowodować pominięcie zależności. Unavailable oznacza, że dowodów nie udało się ocenić, a Not recorded oznacza, że zadanie powstało, zanim wprowadzono raportowanie kompletności.

Czy CRACI znajduje podatności w SBOM?

Tak. CRACI na bieżąco ponownie ocenia monitorowane SBOM-y w miarę publikowania nowych podatności, agreguje wyniki z wielu buildów i repozytoriów oraz obsługuje VEX. Zespoły bezpieczeństwa analizują znaleziska i przekazują je zespołom odpowiedzialnym za poprawkę.

Czy CRACI wygeneruje SBOM dla oprogramowania, którego nie budujemy sami?

Nie. CRACI rejestruje buildy uruchamiane na jego runnerach. W przypadku kupowanego oprogramowania wystarczy dodać SBOM dostawcy, a CRACI monitoruje go razem z Państwa własnymi buildami. Dla obrazu zewnętrznego, którego Państwo nie zbudowali, praktycznym wyborem jest skaner; zob. porównanie narzędzi SBOM.

SBOM Państwa własnego buildu

Prosimy umówić demo, uruchomić jeden z workflow GitHub Actions na CRACI i zobaczyć, co faktycznie pobrał

Umów demo