123% flere rapporterede CVE'er pr. dag i 2026 end sidste år.

SBOM-generering, registreret under buildet

CRACI er et værktøj til SBOM-generering, der registrerer, hvad hvert GitHub Actions-build faktisk hentede, i stedet for at scanne filer bagefter. Hver SBOM fortæller, hvor komplet den er.

Kort sagt: Kør dine GitHub Actions-jobs på CRACI-runnere, og hvert job får en SBOM over de pakker, det hentede, inklusive transitive afhængigheder og pakker gendannet fra CI-caches, eksporteret i CycloneDX eller SPDX. Hver SBOM har en fuldstændighedsstatus og overvåges for nye sårbarheder efter release. Scanningsværktøjer som Syft og Trivy rekonstruerer en SBOM ud fra filer; CRACI registrerer den fra buildet. Derfor er build-time SBOM'er anderledes.

Registreret under buildet, ikke scannet bagefter

De fleste SBOM-generatorer læser filer efter buildet og rekonstruerer, hvad de tror, der gik ind i det. CRACI genererer SBOM'en i sin egen CI-runner. En pakkebevidst proxy overvåger hvert jobs trafik til pakkekilderne, så SBOM'en viser, hvad jobbet faktisk hentede, inklusive transitive afhængigheder, og ikke hvad et manifest siger, det burde have brug for. Registreringen kræver hverken en lockfile, installerede afhængigheder eller et ekstra scanningstrin.

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 afhængigheder i alle lag

Det meste af det, et build henter, er ikke en direkte afhængighed. Det er en afhængighed af en afhængighed, flere lag nede, og noget af det optræder slet ikke i en lockfile: færdigbyggede binærfiler, som et build-script downloader, pakker gendannet fra en cache, styresystempakker. CRACI registrerer hver eneste pakke, jobbet hentede, i alle lag, så sårbarheder matches mod hele træet. I direkte sammenligninger med andre SBOM-værktøjer har den mere komplette registrering afdækket sårbarheder, som de andre værktøjer ikke rapporterede.

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 gendannet fra CI-caches bliver i SBOM'en

Det er typisk ved caches, at registrering under buildet bryder sammen: En pakke gendannet fra en cache rører aldrig et registry, så en proxy alene ville overse den. CRACI sender dokumentationen for afhængighederne med cachen, så pakker gendannet fra en CI-cache bliver i SBOM'en for det job, der gendannede 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 fuldstændighedsstatus for hvert job

Sårbarhedssporing kan kun matche de komponenter, din SBOM indeholder. En pakke, der mangler i SBOM'en, er en sårbarhed, ingen bliver advaret om. Derfor præsenterer CRACI ikke hver SBOM som komplet, men angiver fuldstændigheden for hvert job og hver cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Du ved, hvilke SBOM'er du kan stole på, og hvilke der skal kigges nærmere på.

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 økosystemer og formater, du leverer

CRACI registrerer pakker fra npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt download-presets til Yocto og OpenEmbedded, og behandler JFrog Artifactory-spejle til npm og PyPI som kendte kilder. Understøttelse af Maven og Java er på roadmappen. SBOM'er eksporteres i CycloneDX og SPDX, inklusive transitive afhængigheder, klar til at dele 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

Deklarerede licenser på hver komponent

Hver registreret pakke tager sin deklarerede licens med ind i SBOM'en. Du kan se, hvilke afhængigheder der er under en kommerciel eller på anden måde restriktiv licens, før du leverer, og copyleft-licenser bliver fanget, før de ender i dit 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

Provenance via API'et

SBOM'en er én del af det, CRACI registrerer for hvert job. Det offentlige REST API returnerer SBOM'er, netværkstraces og provenance, alt sammen registreret fra det samme build.

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åget efter release

En SBOM er måden, en virksomhed ved, hvad der er i den software, den leverer, og kunder og myndigheder beder i stigende grad om en: Cyber Resilience Act kræver, at producenter udarbejder en for produkter, der sælges i EU. CRACI genvurderer løbende overvågede SBOM'er, efterhånden som nye sårbarheder offentliggøres, samler fund på tværs af builds og repositories og understøtter VEX. De SBOM'er, du indsamler fra dine egne leverandører, overvåges side om side med dine builds.

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 registreret SBOM ved siden af en scannet

Scannere er det rigtige værktøj til software, du ikke selv har bygget. For dine egne releases er det her, hvad registrering af buildet ændrer. En scanner læser lockfilen eller outputtet og udleder, hvad der gik ind. CRACI ser trafikken, der kommer ind i buildet, så de skjulte afhængigheder, som install-hooks, build-scripts og base-images trækker ind, også ender 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 Scannerbaseret SBOM-værktøj
Hvordan komponentlisten bliver til Registreret fra buildets egen pakketrafik Rekonstrueret fra filer bagefter
Kræver en lockfile eller installerede afhængigheder Nej Som regel det ene eller det andet
Pakker gendannet fra CI-caches Dokumentationen følger med cachen Kun hvis filerne er der, når der scannes
Fuldstændighedsstatus pr. job Fem statusser, pr. job og pr. cache
Signeret kobling fra artefakt til build Ingen signeret provenance Med et separat signeringstrin
Software, du ikke selv har bygget Tilføj leverandørens SBOM i stedet
CI-systemer GitHub Actions i dag; andre CI-systemer på roadmappen Kører i ethvert CI
  • Inkluderet
  • Delvist
  • Ikke inkluderet
  • På roadmappen

Sammenligner du bestemte værktøjer? Se SBOM-værktøjer sammenlignet for Syft, Trivy, cdxgen, Microsoft SBOM Tool, Dependency-Track og flere. For det store billede, se værktøjer til forsyningskædesikkerhed for software sammenlignet.

SBOM basics: SPDX, CycloneDX and OpenVEX

Hvad en SBOM registrerer, hvordan formaterne SPDX og CycloneDX adskiller sig i praksis, og hvad OpenVEX tilføjer om, hvorvidt en sårbarhed faktisk påvirker et produkt.

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

SBOM-generering: ofte stillede spørgsmål

Hvad er SBOM-generering?

SBOM-generering er at producere en software bill of materials, en softwarestykliste: en maskinlæsbar liste over komponenterne og afhængighederne i et stykke software. Det kan ske ud fra kildefiler, under buildet eller ved at analysere et færdigt artefakt som et container-image. CRACI genererer SBOM'en under buildet, ud fra hvad buildet faktisk hentede.

Hvordan genererer CRACI en SBOM?

Dine GitHub Actions-jobs kører på CRACI-runnere. Mens hvert job kører, overvåger en pakkebevidst proxy dets trafik til pakkekilderne og registrerer de pakker, det henter, inklusive transitive afhængigheder og pakker gendannet fra CI-caches. Hvert job får sin egen SBOM med en fuldstændighedsstatus.

Skal jeg ændre mine workflows?

Du ændrer runs-on til craci. CRACI erstatter runneren, ikke GitHub Actions, så dine workflows og deres kørsler bliver i GitHub.

Hvilke pakkeøkosystemer registrerer CRACI?

npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt download-presets til Yocto og OpenEmbedded. JFrog Artifactory-spejle til npm og PyPI behandles som kendte kilder. Understøttelse af Maven og Java er på roadmappen.

Hvilke SBOM-formater kan jeg eksportere?

CycloneDX og SPDX, inklusive transitive afhængigheder og hver komponents deklarerede licens.

Hvad betyder fuldstændighedsstatussen?

Complete betyder, at CRACI observerede fuldstændig dokumentation for jobbet, og at hver gendannet cache var komplet. Complete with connections betyder, at jobbet også brugte brugerdefinerede netværksforbindelser, som er værd at gennemgå. Incomplete betyder, at et forhold kan have udeladt afhængigheder. Unavailable betyder, at dokumentationen ikke kunne evalueres, og Not recorded betyder, at jobbet er ældre end rapporteringen af fuldstændighed.

Finder CRACI sårbarheder i SBOM'en?

Ja. CRACI genvurderer løbende overvågede SBOM'er, efterhånden som nye sårbarheder offentliggøres, samler fund på tværs af builds og repositories og understøtter VEX. Sikkerhedsteams triagerer fundene og sender dem videre til de teams, der ejer rettelsen.

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

Nej. CRACI registrerer de builds, der kører på dets runnere. For software, du køber, tilføjer du leverandørens SBOM, og CRACI overvåger den side om side med dine egne builds. For et tredjeparts-image, du ikke selv har bygget, er en scanner det praktiske valg; se SBOM-værktøjer sammenlignet.

Se SBOM'en for dit eget build

Book en demo, kør et af dine GitHub Actions-workflows på CRACI, og se, hvad det faktisk hentede

Book en demo