123% meer gemelde CVE's per dag in 2026 dan vorig jaar.

SBOM-generatie, vastgelegd tijdens de build

CRACI is een tool voor SBOM-generatie die vastlegt wat elke GitHub Actions-build daadwerkelijk heeft binnengehaald, in plaats van achteraf bestanden te scannen. Elke SBOM vermeldt hoe volledig hij is.

In het kort: laat uw GitHub Actions-jobs draaien op CRACI-runners en elke job krijgt een SBOM van de pakketten die hij heeft opgehaald, inclusief transitieve afhankelijkheden en pakketten die uit CI-caches zijn teruggezet, geëxporteerd in CycloneDX of SPDX. Elke SBOM heeft een volledigheidsstatus en wordt na de release gemonitord op nieuwe kwetsbaarheden. Scantools zoals Syft en Trivy reconstrueren een SBOM uit bestanden; CRACI legt hem vast vanuit de build. Waarom build-time SBOM's verschillen.

Vastgelegd tijdens de build, niet achteraf gescand

De meeste SBOM-generatoren lezen na de build bestanden uit en reconstrueren wat er vermoedelijk in is gegaan. CRACI genereert de SBOM in zijn eigen CI-runner. Een proxy die pakketten herkent, observeert het verkeer van elke job naar pakketbronnen. De SBOM vermeldt dus wat de job daadwerkelijk heeft binnengehaald, inclusief transitieve afhankelijkheden, en niet wat een manifest zegt dat er nodig zou moeten zijn. Er is geen lockfile, geen geïnstalleerde afhankelijkheden en geen extra scanstap nodig om die vastlegging te laten ontstaan.

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

Transitieve afhankelijkheden op elk niveau

Het meeste wat een build binnenhaalt, is geen directe afhankelijkheid. Het is een afhankelijkheid van een afhankelijkheid, een aantal lagen diep, en een deel ervan staat zelfs nooit in een lockfile: voorgecompileerde binaries die een buildscript downloadt, pakketten die uit een cache worden teruggezet, pakketten van het besturingssysteem. CRACI legt elk pakket vast dat de job heeft opgehaald, op elk niveau, zodat kwetsbaarheden tegen de volledige boom worden gematcht. In directe vergelijkingen met andere SBOM-tools bracht die completere vastlegging kwetsbaarheden aan het licht die de andere tools niet rapporteerden.

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

Pakketten uit CI-caches blijven in de SBOM

Bij caches gaat vastleggen tijdens de build meestal mis: een pakket dat uit een cache wordt teruggezet, komt nooit bij een registry, dus een proxy alleen zou het missen. CRACI geeft het bewijs van afhankelijkheden mee met de cache, zodat pakketten die uit een CI-cache worden teruggezet in de SBOM blijven van de job die ze heeft teruggezet.

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

Een volledigheidsstatus voor elke job

Kwetsbaarheidsmonitoring kan alleen de componenten matchen die uw SBOM vermeldt. Een pakket dat in de SBOM ontbreekt, is een kwetsbaarheid waarvoor niemand een melding krijgt. Daarom presenteert CRACI niet elke SBOM als volledig, maar geeft het de volledigheid aan voor elke job en elke cache: Complete, Complete with connections, Incomplete, Unavailable of Not recorded. Zo weet u op welke SBOM's u kunt vertrouwen en welke een tweede blik verdienen.

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 ecosystemen en formaten die u levert

CRACI legt pakketten vast uit npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk en Git-bronnen, plus downloadpresets voor Yocto en OpenEmbedded, en behandelt JFrog Artifactory-mirrors voor npm en PyPI als bekende bronnen. Ondersteuning voor Maven en Java staat op de roadmap. SBOM's worden geëxporteerd in CycloneDX en SPDX, inclusief transitieve afhankelijkheden, klaar om te delen met klanten, partners en auditors.

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

Gedeclareerde licenties bij elk component

Elk vastgelegd pakket neemt zijn gedeclareerde licentie mee in de SBOM. U ziet vóór de release welke afhankelijkheden onder een commerciële of anderszins beperkende licentie vallen, en copyleftlicenties worden opgemerkt voordat ze in uw product belanden.

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

Herkomst via de API

De SBOM is één onderdeel van wat CRACI voor elke job vastlegt. De openbare REST API levert SBOM's, netwerktraces en herkomstgegevens, allemaal vastgelegd uit dezelfde 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

Gemonitord na de release

Met een SBOM weet een bedrijf wat er in de software zit die het levert, en klanten en toezichthouders vragen er steeds vaker om: de Cyber Resilience Act verplicht fabrikanten er een op te stellen voor producten die in de EU worden verkocht. CRACI blijft gemonitorde SBOM's opnieuw beoordelen zodra nieuwe kwetsbaarheden worden gepubliceerd, bundelt bevindingen over builds en repositories heen en ondersteunt VEX. De SBOM's die u van uw eigen leveranciers ontvangt, worden samen met uw builds gemonitord.

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

Een vastgelegde SBOM naast een gescande

Voor software die u niet zelf bouwt, zijn scanners het juiste gereedschap. Voor uw eigen releases verandert het vastleggen van de build het volgende. Een scanner leest de lockfile of de output en leidt af wat erin is gegaan. CRACI ziet het verkeer dat de build binnenkomt, zodat ook de verborgen afhankelijkheden die install-hooks, buildscripts en base images binnenhalen in de SBOM terechtkomen.

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 SBOM-tool op basis van scannen
Hoe de componentenlijst tot stand komt Vastgelegd uit het pakketverkeer van de build zelf Achteraf gereconstrueerd uit bestanden
Vereist een lockfile of geïnstalleerde afhankelijkheden Nee Meestal het een of het ander
Pakketten uit CI-caches Het bewijs reist mee met de cache Alleen als de bestanden er zijn tijdens de scan
Volledigheidsstatus per job Vijf statussen, per job en per cache
Ondertekende koppeling van artefact naar build Geen ondertekende herkomst Met een aparte ondertekeningsstap
Software die u niet zelf bouwt Voeg in plaats daarvan de SBOM van de leverancier toe
CI-systemen Vandaag GitHub Actions; andere CI-systemen staan op de roadmap Draait in elke CI
  • Inbegrepen
  • Gedeeltelijk
  • Niet inbegrepen
  • Op de roadmap

Vergelijkt u specifieke tools? Zie SBOM-tools vergeleken voor Syft, Trivy, cdxgen, de Microsoft SBOM Tool, Dependency-Track en meer. Voor het bredere plaatje, zie tools voor ketenbeveiliging van software vergeleken.

SBOM basics: SPDX, CycloneDX and OpenVEX

Wat een SBOM vastlegt, hoe de formaten SPDX en CycloneDX in de praktijk verschillen en wat OpenVEX toevoegt over de vraag of een kwetsbaarheid een product echt raakt.

Petteri Pulkkinen en Erika Marttinen op Kubernetes Community Days Helsinki 2026, 16:50 tot 22:05 van SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

SBOM-generatie: veelgestelde vragen

Wat is SBOM-generatie?

SBOM-generatie is het opstellen van een software bill of materials: een machineleesbare lijst van de componenten en afhankelijkheden in een stuk software. Dat kan op basis van bronbestanden, tijdens de build, of door een afgerond artefact zoals een containerimage te analyseren. CRACI genereert de SBOM tijdens de build, op basis van wat de build daadwerkelijk heeft opgehaald.

Hoe genereert CRACI een SBOM?

Uw GitHub Actions-jobs draaien op CRACI-runners. Terwijl elke job draait, observeert een proxy die pakketten herkent het verkeer naar pakketbronnen en legt hij de pakketten vast die de job binnenhaalt, inclusief transitieve afhankelijkheden en pakketten die uit CI-caches worden teruggezet. Elke job krijgt een eigen SBOM met een volledigheidsstatus.

Moet ik mijn workflows aanpassen?

U wijzigt runs-on in craci. CRACI vervangt de runner, niet GitHub Actions, dus uw workflows en hun runs blijven in GitHub.

Welke pakketecosystemen legt CRACI vast?

npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk en Git-bronnen, plus downloadpresets voor Yocto en OpenEmbedded. JFrog Artifactory-mirrors voor npm en PyPI worden als bekende bronnen behandeld. Ondersteuning voor Maven en Java staat op de roadmap.

Naar welke SBOM-formaten kan ik exporteren?

CycloneDX en SPDX, inclusief transitieve afhankelijkheden en de gedeclareerde licentie van elk component.

Wat betekent de volledigheidsstatus?

Complete betekent dat CRACI volledig bewijs voor de job heeft waargenomen en dat elke teruggezette cache volledig was. Complete with connections betekent dat de job daarnaast eigen netwerkverbindingen gebruikte die het bekijken waard zijn. Incomplete betekent dat een omstandigheid ertoe kan leiden dat afhankelijkheden ontbreken. Unavailable betekent dat het bewijs niet kon worden beoordeeld, en Not recorded betekent dat de job ouder is dan de volledigheidsrapportage.

Vindt CRACI kwetsbaarheden in de SBOM?

Ja. CRACI blijft gemonitorde SBOM's opnieuw beoordelen zodra nieuwe kwetsbaarheden worden gepubliceerd, bundelt bevindingen over builds en repositories heen en ondersteunt VEX. Securityteams beoordelen wat het vindt en sturen het door naar de teams die verantwoordelijk zijn voor de oplossing.

Kan CRACI een SBOM genereren voor software die ik niet zelf heb gebouwd?

Nee. CRACI legt de builds vast die op zijn runners draaien. Voor software die u inkoopt, voegt u de SBOM van de leverancier toe en CRACI monitort die samen met uw eigen builds. Voor een image van een derde partij dat u niet zelf hebt gebouwd, is een scanner de praktische keuze; zie SBOM-tools vergeleken.

Bekijk de SBOM van uw eigen build

Boek een demo, laat een van uw GitHub Actions-workflows op CRACI draaien en zie wat hij daadwerkelijk heeft binnengehaald

Demo boeken