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

Platform

Sådan virker CRACI

CRACI kører dine GitHub Actions-builds og registrerer, hvad hvert enkelt henter. Alt andet, fra sårbarhedssporing til CRA-dokumentation, bygger på den registrering.

Opdateret

Oversigt over CRACI-platformen. Kildekode på GitHub løber gennem GitHub Actions ind i CRACI Secure Build Service. Buildet fodrer CRACI Package Analytics og derefter Vulnerability Analysis (som også får input fra tredjepartsleverandører), Digital Inventory og Compliance Reporting, som rapporterer til tredjeparter som kunder, leverandører og ENISA. Buildet fodrer også CRACI Attack Prevention. Både Attack Prevention og Digital Inventory fører videre til deployment i staging og produktion.
CRACI-platformen, fra venstre mod højre. Åbn diagrammet i fuld størrelse.

Kort fortalt

De fleste sikkerhedsværktøjer ser på din kode eller dine manifester bagefter og udleder, hvad et build sandsynligvis indeholdt. CRACI er build-runneren, så det ser, hvad buildet faktisk hentede, i det øjeblik det blev hentet. Den registrering er input til alt i diagrammet: pakkeanalyse, angrebsforebyggelse, sårbarhedsanalyse, sporbarhed og compliance-rapportering.

Du beholder GitHub og GitHub Actions. Ændringen er én linje i hvert 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.

Trin for trin

1. Kildekode og CI/CD: GitHub og GitHub Actions

Din kode bliver på GitHub. Du forbinder din organisation ved at installere CRACI's GitHub-app på alle repositories eller kun dem, du vælger. Workflows kører fortsat fra GitHub Actions, og deres kørsler vises stadig i GitHub. GitHub Actions er den understøttede CI-integration i dag; understøttelse af andre CI/CD-systemer er på roadmappen.

2. Build: CRACI Secure Build Service

Jobs kører på CRACI-runnere i isolerede virtuelle maskiner. Runnerne skalerer fra 1 til 32 compute units (hver med 1 vCPU og 3 GB RAM) på native x86-64 og ARM64 med et GitHub-kompatibelt Ubuntu-image eller CRACI's slanke images. Forbruget måles pr. sekund.

Builds på CRACI kører cirka dobbelt så hurtigt som på GitHubs hostede standardrunnere. Hvert minut koster også mindre: En standard Linux-runner med 2 vCPU koster $0.004 pr. minut mod GitHubs $0.006 (cirka 33 % mindre). Samlet set bliver et build, der tager 10 minutter på GitHub, færdigt på cirka 5 på CRACI og koster cirka 67 % mindre. CRACI afregner også pr. sekund i stedet for at runde hvert job op til et helt minut, så pipelines med mange korte jobs sparer endnu mere. Se den fulde sammenligning med GitHub-hostede runnere.

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. Afdækning af forsyningskæden: CRACI Package Analytics

Mens jobbet kører, overvåger en pakkebevidst proxy trafikken til pakkekilderne og registrerer hver ekstern afhængighed, buildet henter, på tværs af npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt download-presets til Yocto og OpenEmbedded. Dokumentationen følger med CI-caches, så pakker gendannet fra en cache stadig medregnes.

Det er forskellen fra andre SBOM-værktøjer. De læser lockfilen eller buildets output og udleder, hvad der gik ind. CRACI ser trafikken, så det registrerer også de skjulte afhængigheder, som ingen lockfile angiver: kode, som npm install-hooks downloader, filer, som Rust-build-scripts henter under buildet, og base-image-lagene i et container-build.

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.

Hvert job og hver cache får en fuldstændighedsstatus, fra Complete til Not recorded, så du ved, hvor meget du kan stole på den SBOM, der blev produceret. SBOM'er eksporteres som CycloneDX eller SPDX, inklusive transitive afhængigheder.

4. Løbende forsyningskædesikkerhed: CRACI Attack Prevention

Det samme lag, der registrerer trafikken, styrer den også. En egress-politik afgør, hvilke hosts et job må nå, med default deny eller default allow, indbyggede presets for almindelige softwarekilder og brugerdefinerede regler for dine egne. Politikker valideres, før jobbet starter, og blokerer ved fejl, og CRACI advarer dig ved brud. En kompromitteret afhængighed eller et build-værktøj, der forsøger at ringe hjem, bliver stoppet ved runneren.

Fordi politikken kun tillader det, buildet har brug for, i stedet for at lede efter kendte ondsindede hosts, virker den også mod et angreb, ingen har set før. Hvis en orm som Shai-Hulud når dit build først, bliver dens forsøg på at sende dine secrets ud blokeret alligevel.

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. Løbende håndtering i forsyningskæden: CRACI Vulnerability Analysis

Registrerede pakker matches mod kendte sårbarheder, og overvågede SBOM'er genvurderes løbende, så en sårbarhed, der offentliggøres, efter du har leveret, stadig når frem til dig. Visninger på organisationsniveau viser, hvilke builds og repositories der deler en sårbar afhængighed, og sikkerhedsteams kan triagere hvert fund og sende det videre til det team, der ejer rettelsen. Du kan også tilføje SBOM'er fra dine tredjepartsleverandører, så de komponenter, du køber ind, overvåges side om side med dem, dine egne builds henter.

Using SBOMs for improved cybersecurity

Hvordan en SBOM fra buildet bliver til sårbarhedsovervågning efter release, hvilket netop er opgaven for CRACI's SBOM-generering og sårbarhedssporing.

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

6. Sporing i forsyningskæden: CRACI Digital Inventory

Hvert build har sin SBOM og netværkstracen over det, det forbandt sig til, og CRACI's API returnerer SBOM'er, netværkstraces og provenance. Når en ny sårbarhed eller en kompromitteret pakke kommer i nyhederne, kan du fra ét sted svare på, hvilke af dine builds der er ramt.

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. Rapportering om forsyningskæden: CRACI Compliance Reporting

Den dokumentation, der indsamles undervejs, går til dem, der beder om den: kunder, leverandører og myndigheder. SBOM'er eksporteres som CycloneDX eller SPDX, inklusive de sårbarheder, der er fundet i deres komponenter, API'et returnerer SBOM'er, netværkstraces og provenance, og CRACI indsender CRA-sårbarhedsunderretninger på dine vegne.

Cyber Resilience Act er den mest kendte regel bag dette, men ikke den eneste. På tværs af rammeværker er kravet det samme: Vid, hvad der er i din software, og hav en proces for at finde og håndtere dens sårbarheder.

  • EU's Cyber Resilience Act: en SBOM og håndtering af sårbarheder for produkter med digitale elementer, der sælges i EU, med rapporteringsforpligtelser fra september 2026.
  • NIS2: forsyningskædesikkerhed samt håndtering og offentliggørelse af sårbarheder for væsentlige og vigtige enheder.
  • ISO/IEC 27001: nævner ikke SBOM'er, men kontrollerne i Annex A kræver en fortegnelse over aktiver (5.9), sikkerhed i IKT-forsyningskæden (5.21) og styring af tekniske sårbarheder (8.8). Build-time SBOM'er og løbende overvågning er dokumentation for alle tre.
  • US FDA: en SBOM i ansøgninger før markedsføring af forbundet medicinsk udstyr samt en plan for at overvåge og håndtere sårbarheder efter release.
  • US Executive Order 14028: SBOM'er for hvert produkt og en proces for offentliggørelse af sårbarheder i vejledningen om softwareforsyningskæden for leverandører, der sælger til den føderale regering.

CRACI giver dig de SBOM'er og den løbende sårbarhedsovervågning, som disse rammeværker forventer, og dokumentationen bag dine compliance-påstande. At opfylde hvert rammeværk er stadig din proces; CRACI gør dokumentationsdelen automatisk.

8. Deployment: staging og produktion

Det, der når staging og produktion, er bygget under din netværkspolitik med en SBOM, der er registreret under buildet og overvåges for nye sårbarheder efter release.

Gå i dybden

Se CRACI i din egen pipeline

Book en demo, så gennemgår vi dine builds, dine SBOM'er og din compliance-dokumentation.

Book en demo