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

Plattform

Slik fungerer CRACI

CRACI kjører GitHub Actions-byggene dine og registrerer hva hvert av dem henter inn. Alt annet, fra sårbarhetssporing til CRA-dokumentasjon, bygger på den registreringen.

Oppdatert

Oversikt over CRACI-plattformen. Kildekode på GitHub går gjennom GitHub Actions inn i CRACI Secure Build Service. Bygget mater CRACI Package Analytics og deretter 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. Bygget mater også CRACI Attack Prevention. Både Attack Prevention og Digital Inventory leder videre til utrulling i staging og produksjon.
CRACI-plattformen, fra venstre mot høyre. Åpne diagrammet i full størrelse.

Kortversjonen

De fleste sikkerhetsverktøy ser på koden eller manifestene dine i etterkant og utleder hva et bygg sannsynligvis inneholdt. CRACI er bygge-runneren, så den ser hva bygget faktisk hentet, i det øyeblikket det ble hentet. Den registreringen er input til alt i diagrammet: pakkeanalyse, angrepsforebygging, sårbarhetsanalyse, sporbarhet og samsvarsrapportering.

Du beholder GitHub og GitHub Actions. Endringen er én linje i hver 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.

Steg for steg

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

Koden din blir værende på GitHub. Du kobler til organisasjonen din ved å installere CRACIs GitHub-app, på alle repositorier eller bare dem du velger. Workflows kjører fortsatt fra GitHub Actions, og kjøringene vises fortsatt i GitHub. GitHub Actions er den støttede CI-integrasjonen i dag; støtte for andre CI/CD-systemer står på veikartet.

2. Bygg: CRACI Secure Build Service

Jobber kjører på CRACI-runnere i isolerte virtuelle maskiner. Runnerne skalerer fra 1 til 32 beregningsenheter (hver med 1 vCPU og 3 GB RAM), på native x86-64 og ARM64, med et GitHub-kompatibelt Ubuntu-image eller CRACIs slanke images. Bruken måles per sekund.

Bygg på CRACI kjører omtrent dobbelt så raskt som på GitHubs standard hostede runnere. Hvert minutt koster også mindre: En standard Linux-runner med 2 vCPU koster $0.004 per minutt, mot GitHubs $0.006 (omtrent 33 % mindre). Til sammen blir et bygg som tar 10 minutter på GitHub, ferdig på omtrent 5 på CRACI og koster omtrent 67 % mindre. CRACI fakturerer også per sekund i stedet for å runde hver jobb opp til et helt minutt, så pipelines med mange korte jobber sparer enda mer. Se den fullstendige sammenligningen 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. Kartlegging av leverandørkjeden: CRACI Package Analytics

Mens jobben kjører, observerer en pakkebevisst proxy trafikken til pakkekildene og registrerer hver eksterne avhengighet bygget henter inn, på tvers av npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder, i tillegg til download-presets for Yocto og OpenEmbedded. Dokumentasjonen følger med CI-cacher, så pakker gjenopprettet fra en cache blir fortsatt regnet med.

Dette er forskjellen fra andre SBOM-verktøy. De leser lockfilen eller resultatet av bygget og utleder hva som gikk inn. CRACI ser trafikken, så den registrerer også de skjulte avhengighetene ingen lockfile oppgir: kode som npm install-hooks laster ned, filer som Rust-byggeskript henter under bygget, og base-image-lagene i et containerbygg.

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.

Hver jobb og hver cache får en fullstendighetsstatus, fra Complete til Not recorded, så du vet hvor mye du kan stole på SBOM-en den produserte. SBOM-er eksporteres som CycloneDX eller SPDX, transitive avhengigheter inkludert.

4. Kontinuerlig leverandørkjedesikkerhet: CRACI Attack Prevention

Det samme laget som registrerer trafikken, styrer den også. En egress-policy bestemmer hvilke verter en jobb kan nå, med default deny eller default allow, innebygde presets for vanlige programvarekilder og egendefinerte regler for dine egne. Policyer valideres før jobben starter og blokkerer ved feil, og CRACI varsler deg ved brudd. En kompromittert avhengighet eller et byggeverktøy som prøver å ringe hjem, stoppes ved runneren.

Fordi policyen bare tillater det bygget trenger, i stedet for å lete etter kjente ondsinnede verter, virker den også mot et angrep ingen har sett før. Hvis en orm som Shai-Hulud når bygget ditt først, blir forsøket på å sende hemmelighetene dine ut blokkert likevel.

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. Kontinuerlig respons i leverandørkjeden: CRACI Vulnerability Analysis

Registrerte pakker matches mot kjente sårbarheter, og overvåkede SBOM-er vurderes kontinuerlig på nytt, så en sårbarhet som blir offentliggjort etter at du leverte, fortsatt når deg. Visninger på organisasjonsnivå viser hvilke bygg og repositorier som deler en sårbar avhengighet, og sikkerhetsteamene kan prioritere hvert funn og sende det videre til teamet som eier rettingen. Du kan også legge til SBOM-er fra tredjepartsleverandørene dine, så komponentene du kjøper inn, overvåkes side om side med dem dine egne bygg henter inn.

Using SBOMs for improved cybersecurity

Hvordan en SBOM fra bygget blir til sårbarhetsovervåking etter utgivelse, som er nettopp jobben CRACIs SBOM-generering og sårbarhetssporing gjør.

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

6. Sporing i leverandørkjeden: CRACI Digital Inventory

Hvert bygg har sin SBOM og nettverkssporet over hva det koblet seg til, og CRACIs API returnerer SBOM-er, nettverksspor og provenance. Når en ny sårbarhet eller en kompromittert pakke havner i nyhetene, kan du fra ett sted svare på hvilke av byggene dine som er berørt.

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 leverandørkjeden: CRACI Compliance Reporting

Dokumentasjonen som samles inn underveis, går til dem som ber om den: kunder, leverandører og myndigheter. SBOM-er eksporteres som CycloneDX eller SPDX, inkludert sårbarhetene som er funnet i komponentene, API-et returnerer SBOM-er, nettverksspor og provenance, og CRACI sender inn CRA-sårbarhetsvarsler på dine vegne.

Cyber Resilience Act er den mest kjente regelen bak dette, men ikke den eneste. På tvers av rammeverk er kravet det samme: Vit hva som finnes i programvaren din, og ha en prosess for å finne og håndtere sårbarhetene i den.

  • EUs Cyber Resilience Act: en SBOM og håndtering av sårbarheter for produkter med digitale elementer som selges i EU, med rapporteringsplikter fra september 2026.
  • NIS2: leverandørkjedesikkerhet samt håndtering og offentliggjøring av sårbarheter for vesentlige og viktige enheter.
  • ISO/IEC 27001: nevner ikke SBOM-er, men kontrollene i Annex A krever en oversikt over eiendeler (5.9), sikkerhet i IKT-leverandørkjeden (5.21) og håndtering av tekniske sårbarheter (8.8). SBOM-er fra bygget og kontinuerlig overvåking er dokumentasjon for alle tre.
  • US FDA: en SBOM i søknader før markedsføring av tilkoblet medisinsk utstyr, i tillegg til en plan for å overvåke og håndtere sårbarheter etter utgivelse.
  • US Executive Order 14028: SBOM-er for hvert produkt og en prosess for offentliggjøring av sårbarheter i veiledningen om programvareleverandørkjeden for leverandører som selger til føderale myndigheter.

CRACI gir deg SBOM-ene og den kontinuerlige sårbarhetsovervåkingen disse rammeverkene forventer, og dokumentasjonen bak samsvarspåstandene dine. Å oppfylle hvert rammeverk er fortsatt din prosess; CRACI gjør dokumentasjonsdelen automatisk.

8. Utrulling: staging og produksjon

Det som når staging og produksjon, er bygget under nettverkspolicyen din, med en SBOM som er registrert under bygget og overvåkes for nye sårbarheter etter utgivelse.

Gå i dybden

Se CRACI i din egen pipeline

Book en demo, så går vi gjennom byggene dine, SBOM-ene dine og samsvarsdokumentasjonen din.

Book en demo