123% fler rapporterade CVE:er per dag 2026 än förra året.

SBOM-generering, registrerad under bygget

CRACI är ett verktyg för SBOM-generering som registrerar vad varje GitHub Actions-bygge faktiskt hämtade, i stället för att skanna filer i efterhand. Varje SBOM anger hur komplett den är.

Kort sagt: kör dina GitHub Actions-jobb på CRACI-runners så får varje jobb en SBOM över paketen det hämtade, inklusive transitiva beroenden och paket som återställs från CI-cachar, exporterad i CycloneDX eller SPDX. Varje SBOM har en fullständighetsstatus och bevakas för nya sårbarheter efter release. Skanningsverktyg som Syft och Trivy rekonstruerar en SBOM från filer; CRACI registrerar den från bygget. Varför SBOM:er från bygget skiljer sig.

Registrerad under bygget, inte skannad i efterhand

De flesta SBOM-generatorer läser filer efter bygget och rekonstruerar vad de tror att det innehöll. CRACI genererar SBOM:en i sin egen CI-runner. En paketmedveten proxy bevakar varje jobbs trafik till paketkällorna, så SBOM:en listar vad jobbet faktiskt hämtade, transitiva beroenden inräknade, i stället för vad ett manifest säger att det borde behöva. Det krävs ingen lockfile, inga installerade beroenden och inget extra skanningssteg för att registreringen ska finnas.

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

Transitiva beroenden i alla led

Det mesta ett bygge hämtar är inga direkta beroenden. Det är beroenden till beroenden, flera led ner, och en del av det syns aldrig i någon lockfile: förkompilerade binärer som ett byggskript laddar ner, paket som återställs från en cache, operativsystemspaket. CRACI registrerar varje paket som jobbet hämtade, i alla led, så att sårbarheter matchas mot hela beroendeträdet. I direkta jämförelser med andra SBOM-verktyg har den mer kompletta registreringen hittat sårbarheter som de andra verktygen inte rapporterade.

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

Paket som återställs från CI-cachar stannar i SBOM:en

Det är i cachar som registrering under bygget brukar fallera: ett paket som återställs från en cache når aldrig något register, så en proxy ensam skulle missa det. CRACI låter beroendebevisen följa med cachen, så paket som återställs från en CI-cache stannar i SBOM:en för det jobb som återställde dem.

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

En fullständighetsstatus för varje jobb

Sårbarhetsbevakning kan bara matcha de komponenter som din SBOM listar. Ett paket som saknas i SBOM:en är en sårbarhet som ingen får någon varning om. I stället för att presentera varje SBOM som komplett anger CRACI fullständigheten för varje jobb och varje cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Du vet vilka SBOM:er du kan lita på och vilka som behöver granskas närmare.

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.

De ekosystem och format du levererar

CRACI registrerar paket från npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningsförinställningar för Yocto och OpenEmbedded, och behandlar JFrog Artifactory-speglar för npm och PyPI som kända källor. Stöd för Maven och Java finns på roadmapen. SBOM:er exporteras i CycloneDX och SPDX, transitiva beroenden inräknade, redo att delas med kunder, partner och revisorer.

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

Deklarerade licenser för varje komponent

Varje registrerat paket tar med sin deklarerade licens in i SBOM:en. Du ser vilka beroenden som har en kommersiell eller på annat sätt restriktiv licens innan du levererar, och copyleft-licenser upptäcks innan de hamnar i din produkt.

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

Proveniens via API:t

SBOM:en är en del av det som CRACI registrerar för varje jobb. Det publika REST API:t returnerar SBOM:er, nätverksspårningar och proveniens, allt registrerat från samma bygge.

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

Bevakad efter release

En SBOM är hur ett företag vet vad som finns i programvaran det levererar, och kunder och tillsynsmyndigheter efterfrågar allt oftare en. Cyber Resilience Act kräver att tillverkare tar fram en för produkter som säljs i EU. CRACI omvärderar bevakade SBOM:er löpande när nya sårbarheter publiceras, sammanställer fynd över byggen och repon och har stöd för VEX. De SBOM:er du samlar in från dina egna leverantörer bevakas tillsammans med dina byggen.

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

En registrerad SBOM bredvid en skannad

Skannrar är rätt verktyg för programvara du inte har byggt. För dina egna releaser är det här vad registreringen av bygget förändrar. En skanner läser lockfilen eller byggresultatet och räknar ut vad som ingick. CRACI ser trafiken som kommer in i bygget, så de dolda beroenden som installationshookar, byggskript och basavbilder drar in hamnar också i SBOM:en.

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 Skannerbaserat SBOM-verktyg
Hur komponentlistan tas fram Registreras från byggets egen pakettrafik Rekonstrueras från filer i efterhand
Kräver en lockfile eller installerade beroenden Nej Oftast det ena eller det andra
Paket som återställs från CI-cachar Bevisen följer med cachen Bara om filerna finns där vid skanningen
Fullständighetsstatus per jobb Fem statusar, per jobb och per cache
Signerad koppling från artefakt till bygge Ingen signerad proveniens Med ett separat signeringssteg
Programvara du inte har byggt Lägg till leverantörens SBOM i stället
CI-system GitHub Actions i dag; andra CI-system på roadmapen Körs i vilken CI som helst
  • Ingår
  • Delvis
  • Ingår inte
  • På roadmapen

Jämför du specifika verktyg? Se SBOM-verktyg i jämförelse för Syft, Trivy, cdxgen, Microsoft SBOM Tool, Dependency-Track med flera. För den större bilden, se verktyg för säkerhet i leveranskedjan i jämförelse.

SBOM basics: SPDX, CycloneDX and OpenVEX

Vad en SBOM registrerar, hur formaten SPDX och CycloneDX skiljer sig åt i praktiken och vad OpenVEX tillför om huruvida en sårbarhet faktiskt påverkar en produkt.

Petteri Pulkkinen och Erika Marttinen på Kubernetes Community Days Helsinki 2026, 16:50 till 22:05 av SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

SBOM-generering: vanliga frågor

Vad är SBOM-generering?

SBOM-generering innebär att ta fram en software bill of materials, en programvaruförteckning: en maskinläsbar lista över komponenterna och beroendena i en programvara. Det kan göras från källfiler, under bygget eller genom att analysera en färdig artefakt som en containeravbild. CRACI genererar SBOM:en under bygget, utifrån vad bygget faktiskt hämtade.

Hur genererar CRACI en SBOM?

Dina GitHub Actions-jobb körs på CRACI-runners. Medan varje jobb körs bevakar en paketmedveten proxy dess trafik till paketkällorna och registrerar paketen det hämtar, inklusive transitiva beroenden och paket som återställs från CI-cachar. Varje jobb får en egen SBOM med en fullständighetsstatus.

Måste jag ändra mina arbetsflöden?

Du ändrar runs-on till craci. CRACI ersätter runnern, inte GitHub Actions, så dina arbetsflöden och deras körningar stannar i GitHub.

Vilka paketekosystem registrerar CRACI?

npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningsförinställningar för Yocto och OpenEmbedded. JFrog Artifactory-speglar för npm och PyPI behandlas som kända källor. Stöd för Maven och Java finns på roadmapen.

Vilka SBOM-format kan jag exportera?

CycloneDX och SPDX, inklusive transitiva beroenden och varje komponents deklarerade licens.

Vad betyder fullständighetsstatusen?

Complete betyder att CRACI observerade fullständiga bevis för jobbet och att varje återställd cache var komplett. Complete with connections betyder att jobbet dessutom använde egna nätverksanslutningar som är värda att granska. Incomplete betyder att något förhållande kan ha lämnat beroenden utanför. Unavailable betyder att bevisen inte kunde utvärderas, och Not recorded betyder att jobbet är äldre än fullständighetsrapporteringen.

Hittar CRACI sårbarheter i SBOM:en?

Ja. CRACI omvärderar bevakade SBOM:er löpande när nya sårbarheter publiceras, sammanställer fynd över byggen och repon och har stöd för VEX. Säkerhetsteamen triagerar fynden och skickar dem vidare till de team som äger åtgärden.

Kan CRACI generera en SBOM för programvara jag inte har byggt?

Nej. CRACI registrerar de byggen som körs på dess runners. För programvara du köper in lägger du till leverantörens SBOM, och CRACI bevakar den tillsammans med dina egna byggen. För en tredjepartsavbild som du inte har byggt är en skanner det praktiska valet; se SBOM-verktyg i jämförelse.

Se SBOM:en för ditt eget bygge

Boka en demo, kör ett av dina GitHub Actions-arbetsflöden på CRACI och se vad det faktiskt hämtade

Boka en demo