CRACI vs Harness

Det korta svaret

Harness, grundat 2017 och baserat i San Francisco, säljer en plattform för allt som händer efter att koden har skrivits: kontinuerlig integration, kontinuerlig leverans, funktionsflaggor, hantering av molnkostnader, chaos engineering och säkerhetstestning. Dess modul Supply Chain Security (SCS) lägger till SBOM-generering, SLSA-proveniens, OPA-policyspärrar och kontroller av säkerhetsläget för repon och pipelines. Om du vill ha en leverantör för hela leveranspipelinen, över flera Git-leverantörer, är Harness byggt för det.

CRACI är smalare och går djupare in i bygget. Det är en GitHub Actions-runner: medan varje jobb körs registrerar det varje externt beroende som bygget drar in, upprätthåller en egress-policy för byggets nätverk och tar fram SBOM:er, proveniensdata och sårbarhetsbevakning från den registreringen. Harness lägger till steg för leveranskedjan i en pipeline; CRACI gör runnern själv till säkerhetsregistreringen.

En praktisk sak först. CRACI har i dag stöd för enbart GitHub Actions, med GitLab CI och Jenkins på roadmapen. Pipelines i Harness CI skulle behöva flyttas till GitHub Actions för att köras på CRACI.

I korthet

Vad Harness gör bra

En plattform för leverans. Harness täcker CI, CD, GitOps, funktionsflaggor, infrastruktur som kod, chaos engineering och hantering av molnkostnader, med OPA-baserad policytillämpning över alltihop. Det fungerar med GitHub, GitLab, Bitbucket, Azure Repos och sina egna Harness Code-repon, och säger att det betjänar fler än 1 000 företagskunder med fler än 1 200 anställda.

Val av bygginfrastruktur. Harness Cloud kör byggen på Harness-hanterade Linux-, Windows- och macOS-maskiner: Linux AMD64 från 2 till 96 kärnor, ARM64 från 2 till 64 kärnor till samma pris och macOS på Apple M4. Nästlad virtualisering finns på Linux AMD64. Du kan också köra byggen på dina egna Kubernetes-kluster, VM:ar eller bare metal. Test Intelligence kör bara de tester som en ändring påverkar, och Build Intelligence och cachefunktioner återanvänder oförändrade resultat och beroenden.

Funktioner för leveranskedjan i pipelinen. SCS-modulens steg SBOM Orchestration genererar en SBOM för en containeravbild eller ett kodrepo med Syft eller cdxgen, i SPDX eller CycloneDX, och kan ta in SBOM:er från andra verktyg. Harness säger att det genererar och uppdaterar SBOM:er vid varje bygge. OPA-policyer kan blockera byggen och driftsättningar på grund av komponenter, licenser eller proveniens, och en åtgärdsspårare följer sårbara artefakter.

SLSA-proveniens. Harness dokumenterar SLSA Build Level 1, 2 och 3 under SLSA v1.0, med proveniens signerad via in-toto-attesteringar och cosign. Enligt dess dokumentation kräver Level 3 härdad bygginfrastruktur eller Harness Cloud, som isolerar byggprocesser från varandra.

Kontroller av säkerhetsläge och pipelines. SCS granskar repon och pipelines mot OWASP Top 10 CI/CD Security Risks och CIS-riktmärken, och flaggar olåsta, overifierade och överbehöriga GitHub Actions. Harness erbjuder också sina SCS-steg som GitHub Actions och GitLab CI/CD-komponenter, så modulen är inte knuten till Harness CI; de stegen kräver ett Harness-konto med en SCS-licens.

Där CRACI skiljer sig

SBOM:en kommer från bygget, inte från en skanning av resultatet

Syft och cdxgen är skannrar: de läser en avbild eller ett repo i efterhand och härleder vad som finns i det från lockfiler, manifest och paketdatabaser. Det fungerar bra när de filerna berättar hela historien. Byggen gör ofta mer: installationsskript laddar ner kod, Rust-byggskript hämtar saker under bygget och cachar återställer paket som ingen lockfil nämner.

CRACI ser den trafiken eftersom det är runnern. En paketmedveten proxy registrerar vad varje jobb hämtar från paketkällor, för npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningsförinställningar, och beroendebevisen följer med CI-cachar. Det registrerar de dolda beroenden som lockfilsbaserade verktyg missar, och varje SBOM anger hur komplett den är, per jobb och per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.

En policy för byggets nätverk, inte upptäckt i efterhand

Harness säger att dess modul upptäcker avvikande beteende hos CI-runners, bland annat nätverksanrop och rättighetseskalering. CRACI går den andra vägen: en egress-policy på runnern avgör vilka värdar ett jobb får nå. Policyer nekar eller tillåter som standard, med 24 inbyggda förinställningar för programvarukällor och typade egna källor, valideras innan jobbet startar och blockerar vid fel. Eftersom en policy som nekar som standard bara tillåter det bygget behöver i stället för att leta efter kända skadliga värdar blockerar den exfiltrering till en angripares server även vid en attack som ingen har sett tidigare. Vid överträdelser skickas en varning.

Proveniens och bevakning från samma registrering

API:t returnerar SBOM:er, nätverksspårningar och proveniens. CRACI signerar inte proveniens och gör inte anspråk på någon SLSA-nivå; Harness signerar sin proveniens och dokumenterar Level 1 till 3, och om signerad proveniens eller en SLSA-nivå är ett krav vid upphandling talar det för Harness. CRACI sammanställer sårbarheter över byggen och repon, fortsätter att omvärdera bevakade SBOM:er när nya säkerhetsmeddelanden dyker upp och visar vilka tidigare byggen som innehöll ett sårbart beroende, så att du vet under vilken period du var berörd.

Priser du kan läsa

CRACI tar bara betalt för byggminuter: $0.002 per vCPU-minut ($0.004 för en standardrunner med 2 vCPU), mätt per sekund, utan månadsavgift och utan avgift per SBOM. Harness publicerar sina priser för Harness Cloud, $0.005 per minut för en Linux-maskin med 2 kärnor och 7 GB och $0.080 för 32 kärnor, debiterat till närmaste minut, medan dess betalda planer och SCS-modulen prissätts via säljteamet. CRACI:s listpris är 20 % lägre per minut i båda storlekarna ($0.004 mot $0.005, $0.064 mot $0.080); Harness-maskiner har mer minne per kärna.

Vilken som passar

• Stanna kvar på Harness om du vill ha CI, CD, funktionsflaggor och kostnadshantering från en leverantör, om din kod finns på GitLab, Bitbucket eller Azure Repos, om du behöver Windows, macOS eller din egen bygghårdvara, eller om en dokumenterad SLSA Build Level 3 är ett krav.
• Välj CRACI om din kod finns på GitHub och du kör eller planerar att köra GitHub Actions, och du vill att SBOM:en, nätverkspolicyn och proveniensen ska komma från runnern som gjorde bygget, prissatt per byggminut.

Var tydlig med vad du avstår från när du väljer CRACI. Det driftsätter inte programvara, kör inte funktionsflaggor och hanterar inte molnkostnader, och det kontrollerar inte repon och pipelines mot riktmärken för säkerhetsläge och skannar inte källkod. Det kör bara Linux-jobb i dag, med Windows och macOS på roadmapen, och kundhostade runners finns på roadmapen för Enterprise.

För reglerade produkter

Ramverk som EU:s Cyber Resilience Act förväntar sig att tillverkare vet vad som finns i varje release och hanterar dess sårbarheter, med rapporteringsskyldigheter från september 2026. Harness levererar SBOM:er, proveniens och policyresultat från sina pipelinesteg. CRACI tar fram bevisen från registreringen av bygget och exporterar SBOM:er som CycloneDX eller SPDX. Det automatiserar en betydande del av den insyn i och de bevis om programvarans leveranskedja som ett företag behöver för sitt bredare CRA-arbete; inget av verktygen gör en produkt regelefterlevande på egen hand.

Flytta en pipeline till CRACI

CRACI ersätter runnern, inte GitHub Actions, och körningarna syns fortfarande i GitHubs gränssnitt. När en pipeline väl körs som ett GitHub Actions-arbetsflöde körs den på CRACI med en enda rad:

runs-on: craci

Läs mer om SBOM-generering under bygget, jämför CI/CD-plattformar, se alternativ till Harness eller se priser.