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

Platform

Zo werkt CRACI

CRACI draait uw GitHub Actions-builds en legt vast wat elke build binnenhaalt. Al het andere, van kwetsbaarheidstracking tot CRA-bewijs, is gebouwd op dat record.

Bijgewerkt op

Overzicht van het CRACI-platform. Broncode op GitHub stroomt via GitHub Actions naar de CRACI Secure Build Service. De build voedt CRACI Package Analytics, daarna Vulnerability Analysis (dat ook input van externe leveranciers krijgt), Digital Inventory en Compliance Reporting, dat rapporteert aan derden zoals klanten, leveranciers en ENISA. De build voedt ook CRACI Attack Prevention. Attack Prevention en Digital Inventory leiden allebei naar deployment in staging en productie.
Het CRACI-platform, van links naar rechts. Open het diagram op volledige grootte.

In het kort

De meeste beveiligingstools bekijken uw code of manifesten achteraf en leiden af wat een build vermoedelijk bevatte. CRACI is de buildrunner en ziet dus wat de build werkelijk heeft opgehaald, op het moment dat hij het ophaalde. Dat record is de input voor alles in het diagram: package analytics, aanvalspreventie, kwetsbaarheidsanalyse, traceerbaarheid en compliancerapportage.

U houdt GitHub en GitHub Actions. De wijziging is één regel in elke workflow:

Switching a GitHub Actions job to CRACI A workflow file with a build job. The line runs-on: ubuntu-latest changes to runs-on: craci. That is the only change, and the job's runs still show up in GitHub. .github/workflows/build.yml jobs: build: runs-on: ubuntu-latest ubuntu-lates ubuntu-late ubuntu-lat ubuntu-la ubuntu-l ubuntu- ubuntu ubunt ubun ubu ub u c cr cra crac craci ✓ One line per job. Runs still show up in GitHub.

Stap voor stap

1. Broncode en CI/CD: GitHub en GitHub Actions

Uw code blijft op GitHub. U koppelt uw organisatie door de CRACI GitHub App te installeren, op alle repositories of alleen op de repositories die u kiest. Workflows blijven draaien vanuit GitHub Actions en hun runs verschijnen nog steeds in GitHub. GitHub Actions is vandaag de ondersteunde CI-integratie; ondersteuning voor andere CI/CD-systemen staat op de roadmap.

2. Build: CRACI Secure Build Service

Jobs draaien op CRACI-runners in geïsoleerde virtuele machines. Runners schalen van 1 tot 32 rekeneenheden (elk 1 vCPU en 3 GB RAM), native op x86-64 en ARM64, met een GitHub-compatibel Ubuntu-image of de slanke images van CRACI. Het gebruik wordt per seconde gemeten.

Builds op CRACI draaien ongeveer twee keer zo snel als op de standaard gehoste runners van GitHub. Elke minuut kost ook minder: een standaard Linux-runner met 2 vCPU kost $0.004 per minuut, tegenover $0.006 bij GitHub (ongeveer 33% minder). Samen betekent dat: een build die op GitHub 10 minuten duurt, is op CRACI in ongeveer 5 minuten klaar en kost ongeveer 67% minder. CRACI rekent bovendien per seconde af in plaats van elke job naar een hele minuut af te ronden, dus pipelines met veel korte jobs besparen meer. Bekijk de volledige vergelijking met door GitHub gehoste runners.

One 10-minute build, GitHub-hosted runner versus CRACI On a GitHub-hosted 2-core Linux runner, a 10-minute build at $0.006 per minute costs $0.060, and each job is rounded up to a whole minute. On CRACI, the same build takes about 5 minutes at $0.004 per minute and costs $0.020, billed per second. That is about 67 percent less. GitHub-hosted runner standard 2-core Linux x64 build time 10 min per minute $0.006 cost of the build $0.060 CRACI size 2, Linux x64 build time about 5 min per minute $0.004 cost of the build $0.020 About 2x faster and about 67% less per build Billed per second; GitHub rounds jobs up to a minute.

3. Inzicht in de keten: CRACI Package Analytics

Terwijl de job draait, observeert een proxy die pakketten herkent het verkeer naar pakketbronnen en legt hij elke externe afhankelijkheid vast die de build binnenhaalt, uit npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk en Git-bronnen, plus downloadpresets voor Yocto en OpenEmbedded. Het bewijs reist mee met CI-caches, zodat ook pakketten die uit een cache worden teruggezet, worden meegeteld.

Dit is het verschil met andere SBOM-tools. Die lezen de lockfile of de output van de build en leiden af wat erin is gegaan. CRACI ziet het verkeer en legt dus ook de verborgen afhankelijkheden vast die in geen enkele lockfile staan: code die npm install-hooks downloaden, bestanden die Rust-buildscripts tijdens de build ophalen, en de base image-lagen van een containerbuild.

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.

Elke job en cache krijgt een volledigheidsstatus, van Complete tot Not recorded, zodat u weet hoeveel u kunt vertrouwen op de SBOM die eruit voortkwam. SBOM's worden geëxporteerd als CycloneDX of SPDX, inclusief transitieve afhankelijkheden.

4. Doorlopende ketenbeveiliging: CRACI Attack Prevention

Dezelfde laag die het verkeer vastlegt, regelt het ook. Een egressbeleid bepaalt welke hosts een job mag bereiken, met standaard weigeren of standaard toestaan, ingebouwde presets voor gangbare softwarebronnen en aangepaste regels voor uw eigen bronnen. Beleid wordt gevalideerd voordat de job start en werkt fail-closed, en CRACI waarschuwt u bij overtredingen. Een gecompromitteerde afhankelijkheid of buildtool die naar huis probeert te bellen, wordt op de runner tegengehouden.

Omdat het beleid alleen toestaat wat de build nodig heeft, in plaats van te zoeken naar bekende kwaadaardige hosts, werkt het ook tegen een aanval die nog niemand eerder heeft gezien. Bereikt een worm zoals Shai-Hulud als eerste uw build, dan wordt zijn poging om uw secrets naar buiten te sturen evengoed geblokkeerd.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

5. Doorlopende afhandeling in de keten: CRACI Vulnerability Analysis

Vastgelegde pakketten worden gematcht met bekende kwetsbaarheden, en gemonitorde SBOM's worden doorlopend opnieuw beoordeeld, zodat een kwetsbaarheid die na uw release wordt bekendgemaakt, u toch bereikt. Overzichten op organisatieniveau tonen welke builds en repositories een kwetsbare afhankelijkheid delen, en securityteams kunnen elke bevinding beoordelen en doorsturen naar het team dat verantwoordelijk is voor de oplossing. U kunt ook SBOM's van uw externe leveranciers toevoegen, zodat de componenten die u inkoopt worden gemonitord naast de componenten die uw eigen builds binnenhalen.

Using SBOMs for improved cybersecurity

Hoe een build-time SBOM na de release uitgroeit tot het monitoren van kwetsbaarheden, precies wat de SBOM-generatie en kwetsbaarheidstracking van CRACI doen.

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

6. Traceerbaarheid in de keten: CRACI Digital Inventory

Elke build heeft zijn SBOM en de netwerktrace van waarmee hij verbinding maakte, en de CRACI API levert SBOM's, netwerktraces en herkomstgegevens. Komt een nieuwe kwetsbaarheid of een gecompromitteerd pakket in het nieuws, dan beantwoordt u vanaf één plek welke van uw builds getroffen zijn.

A new vulnerability, traced back through build history Eight releases, v1.0 to v1.7, are built and recorded over time. Today a new advisory is published for example-lib 2.3.1. CRACI's build history shows that v1.2 and v1.3 contained it as a transitive dependency and v1.4 and v1.5 as a direct one, while v1.6 and v1.7 already shipped a fixed version. The exposure period is v1.2 to v1.5, answered from the recorded SBOMs without rescanning old code. Build history every build keeps its recorded SBOM New advisory today example-lib 2.3.1 today v1.0 v1.1 v1.2 v1.3 v1.4 v1.5 v1.6 v1.7 v1.2 transitive v1.3 transitive v1.4 direct v1.5 direct fixedfixed exposure period: v1.2 to v1.5 Answered from the recorded SBOMs, without rescanning old code
CRACI keeps re-evaluating the SBOMs of what you shipped. Build history follows your retention, 180 days by default.

7. Rapportage over de keten: CRACI Compliance Reporting

Het bewijs dat onderweg wordt verzameld, gaat naar wie erom vraagt: klanten, leveranciers en autoriteiten. SBOM's worden geëxporteerd als CycloneDX of SPDX, inclusief de kwetsbaarheden die in hun componenten zijn gevonden, de API levert SBOM's, netwerktraces en herkomstgegevens, en CRACI dient CRA-kwetsbaarheidsmeldingen namens u in.

De Cyber Resilience Act is de bekendste regel hierachter, maar niet de enige. In elk kader is de vraag dezelfde: weet wat er in uw software zit, en heb een proces om de kwetsbaarheden ervan te vinden en af te handelen.

  • EU Cyber Resilience Act: een SBOM en afhandeling van kwetsbaarheden voor producten met digitale elementen die in de EU worden verkocht, met meldingsplichten vanaf september 2026.
  • NIS2: ketenbeveiliging en de afhandeling en bekendmaking van kwetsbaarheden voor essentiële en belangrijke entiteiten.
  • ISO/IEC 27001: noemt SBOM's niet, maar de beheersmaatregelen in Annex A vragen om een inventaris van bedrijfsmiddelen (5.9), beveiliging in de ICT-toeleveringsketen (5.21) en beheer van technische kwetsbaarheden (8.8). Build-time SBOM's en doorlopende monitoring zijn bewijs voor alle drie.
  • US FDA: een SBOM in premarket submissions voor verbonden medische hulpmiddelen, plus een plan om kwetsbaarheden na de release te monitoren en aan te pakken.
  • US Executive Order 14028: SBOM's voor elk product en een proces voor het bekendmaken van kwetsbaarheden, in de richtlijnen voor de softwareketen voor leveranciers die aan de federale overheid verkopen.

CRACI geeft u de SBOM's en de doorlopende kwetsbaarheidsmonitoring die deze kaders verwachten, en het bewijs achter uw compliance-claims. Aan elk kader voldoen blijft uw eigen proces; CRACI automatiseert het bewijsdeel daarvan.

8. Deployment: staging en productie

Wat staging en productie bereikt, is gebouwd onder uw netwerkbeleid, met een SBOM die tijdens de build is vastgelegd en na de release wordt gemonitord op nieuwe kwetsbaarheden.

Verder lezen

Bekijk CRACI in uw eigen pipeline

Boek een demo en we lopen samen uw builds, uw SBOM's en uw nalevingsbewijs door.

Demo boeken