CRACI vs Harness

Det korte svar

Harness, grundlagt i 2017 og baseret i San Francisco, sælger en platform til alt, der sker, efter koden er skrevet: continuous integration, continuous delivery, feature flags, styring af cloudomkostninger, chaos engineering og sikkerhedstest. Dets Supply Chain Security-modul (SCS) tilføjer SBOM-generering, SLSA-provenance, OPA-policy-gates og posture-tjek af repositories og pipelines. Vil du have én leverandør til hele leveringspipelinen på tværs af flere Git-udbydere, er Harness bygget til det.

CRACI er smallere og går dybere ned i buildet. Det er en GitHub Actions-runner: Mens hvert job kører, registrerer den hver ekstern afhængighed, buildet trækker ind, håndhæver en egress-politik på buildets netværk og producerer SBOM'er, provenance-data og sårbarhedsovervågning ud fra den registrering. Harness tilføjer forsyningskædetrin til en pipeline; CRACI gør runneren selv til sikkerhedsregistreringen.

Én praktisk ting kommer først. CRACI understøtter kun GitHub Actions i dag, med GitLab CI og Jenkins på roadmappen. Harness CI-pipelines skal flyttes til GitHub Actions for at køre på CRACI.

Overblik

Hvad Harness gør godt

Én platform til levering. Harness dækker CI, CD, GitOps, feature flags, infrastructure as code, chaos engineering og styring af cloudomkostninger, med OPA-baseret håndhævelse af politikker på tværs af dem. Det arbejder med GitHub, GitLab, Bitbucket, Azure Repos og sine egne Harness Code-repositories og siger, at det betjener mere end 1.000 enterprise-kunder og har mere end 1.200 ansatte.

Valg af build-infrastruktur. Harness Cloud kører builds på Harness-administrerede Linux-, Windows- og macOS-maskiner: Linux AMD64 fra 2 til 96 kerner, ARM64 fra 2 til 64 kerner til samme takst og macOS på Apple M4. Nested virtualization er tilgængelig på Linux AMD64. Du kan også køre builds på dine egne Kubernetes-klynger, VM'er eller bare metal. Test Intelligence kører kun de test, en ændring berører, og Build Intelligence og cache-funktioner genbruger uændrede output og afhængigheder.

Forsyningskædefunktioner i pipelinen. SCS-modulets SBOM Orchestration-trin genererer en SBOM for et container-image eller et kode-repository med Syft eller cdxgen, i SPDX eller CycloneDX, og kan indlæse SBOM'er fra andre værktøjer. Harness siger, at det genererer og opdaterer SBOM'er ved hvert build. OPA-politikker kan blokere builds og udrulninger på baggrund af komponenter, licenser eller provenance, og en remediation tracker følger sårbare artefakter.

SLSA-provenance. Harness dokumenterer SLSA Build Level 1, 2 og 3 under SLSA v1.0, med provenance signeret via in-toto-attestationer og cosign. Dets dokumentation siger, at Level 3 kræver hærdet build-infrastruktur eller Harness Cloud, som isolerer build-processer fra hinanden.

Posture- og pipeline-tjek. SCS auditerer repositories og pipelines mod OWASP Top 10 CI/CD Security Risks og CIS-benchmarks og markerer ufastlåste, uverificerede og overprivilegerede GitHub Actions. Harness tilbyder også sine SCS-trin som GitHub Actions- og GitLab CI/CD-komponenter, så modulet ikke er bundet til Harness CI; de trin kræver en Harness-konto med en SCS-licens.

Hvor CRACI er anderledes

SBOM'en kommer fra buildet, ikke fra en scanning af dets output

Syft og cdxgen er scannere: De læser et image eller et repository bagefter og udleder, hvad der er i det, ud fra lockfiles, manifester og pakkedatabaser. Det fungerer godt, når de filer fortæller hele historien. Builds gør ofte mere: Install-scripts downloader kode, Rust-build-scripts henter under buildet, og caches gendanner pakker, som ingen lockfile nævner.

CRACI ser den trafik, fordi det er runneren. En pakkebevidst proxy registrerer, hvad hvert job henter fra pakkekilder, på tværs af npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt download-presets, og dokumentationen for afhængighederne følger med CI-caches. Den registrerer de skjulte afhængigheder, som lockfile-baserede værktøjer overser, og hver SBOM angiver, hvor komplet den er, pr. job og pr. cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.

En politik på buildets netværk, ikke opdagelse bagefter

Harness siger, at dets modul opdager unormal adfærd på CI-runnere, herunder netværkskald og privilegieeskalering. CRACI går den anden vej: En egress-politik på runneren afgør, hvilke værter et job må nå. Politikker er default deny eller default allow, med 24 indbyggede presets for softwarekilder og typede brugerdefinerede kilder, valideres, før jobbet starter, og blokerer ved fejl (fail closed). Fordi en default deny-politik kun tillader det, buildet har brug for, i stedet for at lede efter kendte ondsindede værter, blokerer den eksfiltrering til en angribers server, selv ved et angreb, ingen har set før. Overtrædelser sender en advarsel.

Provenance og overvågning fra den samme registrering

API'et returnerer SBOM'er, netværkstraces og provenance. CRACI signerer ikke provenance og gør ikke krav på noget SLSA-niveau; Harness signerer sin provenance og dokumenterer Level 1 til 3, og er signeret provenance eller et SLSA-niveau et indkøbskrav, tæller det til Harness' fordel. CRACI samler sårbarheder på tværs af builds og repositories, genvurderer løbende overvågede SBOM'er, efterhånden som advisories dukker op, og viser, hvilke tidligere builds der indeholdt en sårbar afhængighed, så du ved, i hvilken periode du var berørt.

Priser, du kan læse

CRACI tager kun betaling for build-minutter: $0.002 pr. vCPU-minut ($0.004 for en standardrunner med 2 vCPU), målt pr. sekund, uden månedligt gebyr og uden betaling pr. SBOM. Harness offentliggør sine Harness Cloud-takster, $0.005 pr. minut for en Linux-maskine med 2 kerner og 7 GB og $0.080 for 32 kerner, faktureret til nærmeste minut, mens betalte planer og SCS-modulet prissættes via salg. CRACI's listepris er 20 % lavere pr. minut ved begge størrelser ($0.004 mod $0.005, $0.064 mod $0.080); Harness' maskiner har mere hukommelse pr. kerne.

Hvilken passer bedst

• Bliv på Harness, hvis du vil have CI, CD, feature flags og omkostningsstyring fra én leverandør, hvis din kode ligger på GitLab, Bitbucket eller Azure Repos, hvis du har brug for Windows, macOS eller din egen build-hardware, eller hvis en dokumenteret SLSA Build Level 3 er et krav.
• Vælg CRACI, hvis din kode ligger på GitHub, og du kører eller planlægger at køre GitHub Actions, og du vil have SBOM'en, netværkspolitikken og provenance fra den runner, der udførte buildet, til en pris pr. build-minut.

Vær klar over, hvad du giver afkald på ved at vælge CRACI. Det udruller ikke software, kører ikke feature flags og styrer ikke cloudomkostninger, og det tjekker ikke repositories og pipelines mod posture-benchmarks og scanner ikke kildekode. Det kører kun Linux-jobs i dag, med Windows og macOS på roadmappen, og kundehostede runnere er på roadmappen for Enterprise.

Til regulerede produkter

Rammeværker som EU's Cyber Resilience Act forventer, at producenter ved, hvad der er i hver release, og håndterer dens sårbarheder, med rapporteringsforpligtelser fra september 2026. Harness leverer SBOM'er, provenance og politikresultater fra sine pipeline-trin. CRACI producerer dokumentationen ud fra build-registreringen og eksporterer SBOM'er som CycloneDX eller SPDX. Det automatiserer en væsentlig del af den synlighed i og dokumentation for softwareforsyningskæden, som en virksomhed har brug for i sin bredere CRA-proces; ingen af værktøjerne gør et produkt compliant alene.

Flyt en pipeline til CRACI

CRACI erstatter runneren, ikke GitHub Actions, og kørsler vises stadig i GitHubs brugerflade. Når en pipeline kører som et GitHub Actions-workflow, kører den på CRACI med én linje:

runs-on: craci

Læs mere om SBOM-generering under buildet, sammenlign CI/CD-platforme, se alternativer til Harness, eller se priser.