123% flere rapporterte CVE-er per dag i 2026 enn i fjor.

SBOM-generering, registrert under bygget

CRACI er et verktøy for SBOM-generering som registrerer hva hvert GitHub Actions-bygg faktisk hentet inn, i stedet for å skanne filer etterpå. Hver SBOM forteller hvor fullstendig den er.

Kort fortalt: Kjør GitHub Actions-jobbene dine på CRACI-runnere, så får hver jobb en SBOM over pakkene den hentet, inkludert transitive avhengigheter og pakker gjenopprettet fra CI-cacher, eksportert i CycloneDX eller SPDX. Hver SBOM har en fullstendighetsstatus og overvåkes for nye sårbarheter etter utgivelse. Skanneverktøy som Syft og Trivy rekonstruerer en SBOM ut fra filer; CRACI registrerer den fra bygget. Derfor er SBOM-er fra bygget annerledes.

Registrert under bygget, ikke skannet etterpå

De fleste SBOM-generatorer leser filer etter bygget og rekonstruerer det de tror gikk inn i det. CRACI genererer SBOM-en i sin egen CI-runner. En pakkebevisst proxy observerer trafikken fra hver jobb til pakkekildene, så SBOM-en viser hva jobben faktisk hentet inn, transitive avhengigheter inkludert, og ikke hva et manifest sier at den burde trenge. Registreringen krever verken en lockfile, installerte avhengigheter eller et ekstra skanningssteg.

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

Transitive avhengigheter i alle lag

Det meste av det et bygg henter inn, er ikke en direkte avhengighet. Det er en avhengighet av en avhengighet, flere lag ned, og noe av det dukker aldri opp i en lockfile i det hele tatt: ferdigbygde binærfiler som et byggeskript laster ned, pakker gjenopprettet fra en cache, operativsystempakker. CRACI registrerer hver pakke jobben hentet, på alle nivåer, så sårbarheter matches mot hele treet. I direkte sammenligninger med andre SBOM-verktøy har denne mer fullstendige registreringen avdekket sårbarheter som de andre verktøyene ikke rapporterte.

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

Pakker gjenopprettet fra CI-cacher blir værende i SBOM-en

Det er gjerne ved cacher at registrering under bygget svikter: En pakke som gjenopprettes fra en cache, berører aldri et register, så en proxy alene ville gått glipp av den. CRACI tar med seg dokumentasjonen for avhengighetene i cachen, så pakker gjenopprettet fra en CI-cache blir værende i SBOM-en til jobben som gjenopprettet 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 fullstendighetsstatus for hver jobb

Sårbarhetssporing kan bare matche komponentene SBOM-en din inneholder. En pakke som mangler i SBOM-en, er en sårbarhet ingen blir varslet om. Derfor presenterer ikke CRACI hver SBOM som fullstendig, men angir fullstendigheten for hver jobb og hver cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Du vet hvilke SBOM-er du kan stole på, og hvilke som trenger en nærmere titt.

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.

Økosystemene og formatene du leverer

CRACI registrerer pakker fra npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder, i tillegg til download-presets for Yocto og OpenEmbedded, og behandler JFrog Artifactory-speil for npm og PyPI som kjente kilder. Støtte for Maven og Java står på veikartet. SBOM-er eksporteres i CycloneDX og SPDX, transitive avhengigheter inkludert, klare til å deles med kunder, partnere og 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

Deklarerte lisenser på hver komponent

Hver registrerte pakke tar med seg sin deklarerte lisens inn i SBOM-en. Du ser hvilke avhengigheter som har en kommersiell eller på annen måte restriktiv lisens før du leverer, og copyleft-lisenser fanges opp før de havner i produktet ditt.

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

Provenance via API-et

SBOM-en er én del av det CRACI registrerer for hver jobb. Det offentlige REST-API-et returnerer SBOM-er, nettverksspor og provenance, alt registrert fra det samme bygget.

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

Overvåket etter utgivelse

En SBOM er måten et selskap vet hva som finnes i programvaren det leverer, og kunder og myndigheter ber stadig oftere om en: Cyber Resilience Act krever at produsenter utarbeider en for produkter som selges i EU. CRACI vurderer overvåkede SBOM-er på nytt etter hvert som nye sårbarheter publiseres, samler funn på tvers av bygg og repositorier og støtter VEX. SBOM-ene du samler inn fra dine egne leverandører, overvåkes side om side med byggene dine.

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 registrert SBOM ved siden av en skannet

Skannere er riktig verktøy for programvare du ikke har bygget selv. For dine egne utgivelser er dette hva registrering av bygget endrer. En skanner leser lockfilen eller resultatet og utleder hva som gikk inn. CRACI ser trafikken som kommer inn i bygget, så de skjulte avhengighetene som installasjonshooks, byggeskript og base-images trekker inn, også havner 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 Skannerbasert SBOM-verktøy
Hvordan komponentlisten blir til Registrert fra byggets egen pakketrafikk Rekonstruert fra filer i etterkant
Krever en lockfile eller installerte avhengigheter Nei Som regel det ene eller det andre
Pakker gjenopprettet fra CI-cacher Dokumentasjonen følger med cachen Bare hvis filene finnes når det skannes
Fullstendighetsstatus per jobb Fem statuser, per jobb og per cache
Signert kobling fra artefakt til bygg Ingen signert provenance Med et separat signeringssteg
Programvare du ikke har bygget selv Legg til leverandørens SBOM i stedet
CI-systemer GitHub Actions i dag; andre CI-systemer på veikartet Kjører i alle CI-systemer
  • Inkludert
  • Delvis
  • Ikke inkludert
  • På veikartet

Sammenligner du bestemte verktøy? Se SBOM-verktøy sammenlignet for Syft, Trivy, cdxgen, Microsoft SBOM Tool, Dependency-Track med flere. For det store bildet, se verktøy for sikkerhet i programvareleverandørkjeden sammenlignet.

SBOM basics: SPDX, CycloneDX and OpenVEX

Hva en SBOM registrerer, hvordan formatene SPDX og CycloneDX skiller seg i praksis, og hva OpenVEX tilfører om hvorvidt en sårbarhet faktisk rammer et produkt.

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

SBOM-generering: ofte stilte spørsmål

Hva er SBOM-generering?

SBOM-generering er å lage en software bill of materials, en programvarestykkliste: en maskinlesbar liste over komponentene og avhengighetene i en programvare. Det kan gjøres ut fra kildefiler, under bygget eller ved å analysere en ferdig artefakt, for eksempel et container-image. CRACI genererer SBOM-en under bygget, ut fra det bygget faktisk hentet.

Hvordan genererer CRACI en SBOM?

GitHub Actions-jobbene dine kjører på CRACI-runnere. Mens hver jobb kjører, observerer en pakkebevisst proxy trafikken til pakkekildene og registrerer pakkene jobben henter inn, inkludert transitive avhengigheter og pakker gjenopprettet fra CI-cacher. Hver jobb får sin egen SBOM med en fullstendighetsstatus.

Må jeg endre workflowene mine?

Du endrer runs-on til craci. CRACI erstatter runneren, ikke GitHub Actions, så workflowene dine og kjøringene deres blir værende i GitHub.

Hvilke pakkeøkosystemer registrerer CRACI?

npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder, i tillegg til download-presets for Yocto og OpenEmbedded. JFrog Artifactory-speil for npm og PyPI behandles som kjente kilder. Støtte for Maven og Java står på veikartet.

Hvilke SBOM-formater kan jeg eksportere?

CycloneDX og SPDX, inkludert transitive avhengigheter og den deklarerte lisensen til hver komponent.

Hva betyr fullstendighetsstatusen?

Complete betyr at CRACI observerte fullstendig dokumentasjon for jobben, og at hver gjenopprettede cache var fullstendig. Complete with connections betyr at jobben også brukte egendefinerte nettverkstilkoblinger som er verdt å se gjennom. Incomplete betyr at et forhold kan ha utelatt avhengigheter. Unavailable betyr at dokumentasjonen ikke kunne vurderes, og Not recorded betyr at jobben er eldre enn rapporteringen av fullstendighet.

Finner CRACI sårbarheter i SBOM-en?

Ja. CRACI vurderer overvåkede SBOM-er på nytt etter hvert som nye sårbarheter publiseres, samler funn på tvers av bygg og repositorier og støtter VEX. Sikkerhetsteamene prioriterer funnene og sender dem videre til teamene som eier rettingen.

Kan CRACI generere en SBOM for programvare jeg ikke har bygget selv?

Nei. CRACI registrerer byggene som kjører på runnerne sine. For programvare du kjøper, legger du til leverandørens SBOM, og CRACI overvåker den side om side med dine egne bygg. For et tredjeparts-image du ikke har bygget selv, er en skanner det praktiske valget; se SBOM-verktøy sammenlignet.

Se SBOM-en for ditt eget bygg

Book en demo, kjør en av GitHub Actions-workflowene dine på CRACI, og se hva den faktisk hentet inn

Book en demo