CRACI vs Harness

The short answer

Harness, founded in 2017 and based in San Francisco, sells a platform for everything after the code is written: continuous integration, continuous delivery, feature flags, cloud cost management, chaos engineering and security testing. Its Supply Chain Security (SCS) module adds SBOM generation, SLSA provenance, OPA policy gates and posture checks for repositories and pipelines. If you want one vendor for the whole delivery pipeline, across several Git providers, Harness is built for that.

CRACI is narrower and goes deeper into the build. It is a GitHub Actions runner: while each job runs, it records every external dependency the build pulls in, enforces an egress policy on the build network, and produces SBOMs, provenance data and vulnerability monitoring from that record. Harness adds supply chain steps to a pipeline; CRACI makes the runner itself the security record.

One practical point comes first. CRACI supports GitHub Actions only today, with GitLab CI and Jenkins on the roadmap. Harness CI pipelines would need to move to GitHub Actions to run on CRACI.

At a glance

What Harness does well

One platform for delivery. Harness covers CI, CD, GitOps, feature flags, infrastructure as code, chaos engineering and cloud cost management, with OPA-based policy enforcement across them. It works with GitHub, GitLab, Bitbucket, Azure Repos and its own Harness Code repositories, and says it serves more than 1,000 enterprise customers with more than 1,200 employees.

Build infrastructure choice. Harness Cloud runs builds on Harness-managed Linux, Windows and macOS machines: Linux AMD64 from 2 to 96 cores, ARM64 from 2 to 64 cores at the same rate, and macOS on Apple M4. Nested virtualization is available on Linux AMD64. You can also run builds on your own Kubernetes clusters, VMs or bare metal. Test Intelligence runs only the tests a change affects, and Build Intelligence and cache features reuse unchanged outputs and dependencies.

Supply chain features in the pipeline. The SCS module's SBOM Orchestration step generates an SBOM for a container image or a code repository with Syft or cdxgen, in SPDX or CycloneDX, and can ingest SBOMs from other tools. Harness says it generates and updates SBOMs on every build. OPA policies can block builds and deployments on components, licenses or provenance, and a remediation tracker follows vulnerable artifacts.

SLSA provenance. Harness documents SLSA Build Level 1, 2 and 3 under SLSA v1.0, with provenance signed through in-toto attestations and cosign. Its docs say Level 3 needs hardened build infrastructure or Harness Cloud, which isolates build processes from each other.

Posture and pipeline checks. SCS audits repositories and pipelines against the OWASP Top 10 CI/CD Security Risks and CIS benchmarks, and flags unpinned, unverified and over-permissioned GitHub Actions. Harness also offers its SCS steps as GitHub Actions and GitLab CI/CD components, so the module is not tied to Harness CI; those steps need a Harness account with an SCS license.

Where CRACI is different

The SBOM comes from the build, not a scan of its output

Syft and cdxgen are scanners: they read an image or a repository after the fact and infer what is in it from lockfiles, manifests and package databases. That works well when those files tell the whole story. Builds often do more: install scripts download code, Rust build scripts fetch at build time, and caches restore packages that no lockfile mentions.

CRACI sees that traffic because it is the runner. A package-aware proxy records what each job fetches from package sources, across npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk and Git sources, plus download presets, and dependency evidence travels with CI caches. It records the hidden dependencies that lockfile-based tools miss, and each SBOM states how complete it is, per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded.

A policy on the build network, not detection after it

Harness says its module detects anomalous CI runner behavior, including network calls and privilege escalation. CRACI takes the other route: an egress policy at the runner decides which hosts a job may reach. Policies are default deny or default allow, with 24 built-in software-source presets and typed custom sources, validated before the job starts, and they fail closed. Because a default-deny policy allows only what the build needs rather than looking for known-bad hosts, it blocks exfiltration to an attacker's server even for an attack nobody has seen before. Violations send an alert.

Provenance and monitoring from the same record

The API returns SBOMs, network traces and provenance. CRACI does not sign provenance and claims no SLSA level; Harness signs its provenance and documents Levels 1 to 3, and if signed provenance or a SLSA level is a procurement requirement, that counts for Harness. CRACI aggregates vulnerabilities across builds and repositories, keeps re-evaluating monitored SBOMs as advisories appear, and shows which past builds contained a vulnerable dependency, so you know the period you were affected.

Pricing you can read

CRACI charges only for build minutes: $0.002 per vCPU-minute ($0.004 for a default 2 vCPU runner), metered per second, with no monthly fee and no per-SBOM charge. Harness publishes its Harness Cloud rates, $0.005 per minute for a 2-core Linux machine with 7 GB and $0.080 for 32 cores, billed to the nearest minute, while its paid plans and the SCS module are priced through sales. CRACI's list price is 20% lower per minute at both sizes ($0.004 against $0.005, $0.064 against $0.080); Harness machines carry more memory per core.

Which one fits

• Stay with Harness if you want CI, CD, feature flags and cost management from one vendor, if your code lives on GitLab, Bitbucket or Azure Repos, if you need Windows, macOS or your own build hardware, or if a documented SLSA Build Level 3 is a requirement.
• Choose CRACI if your code is on GitHub and you run or plan to run GitHub Actions, and you want the SBOM, the network policy and the provenance to come from the runner that did the build, priced by the build minute.

Be clear about what you give up by choosing CRACI. It does not deploy software, run feature flags or manage cloud costs, and it does not check repositories and pipelines against posture benchmarks or scan source code. It runs Linux jobs only today, with Windows and macOS on the roadmap, and customer-hosted runners are on the roadmap for Enterprise.

For regulated products

Frameworks such as the EU Cyber Resilience Act expect manufacturers to know what is in each release and to handle its vulnerabilities, with reporting obligations from September 2026. Harness supplies SBOMs, provenance and policy results from its pipeline steps. CRACI produces the evidence from the build record and exports SBOMs as CycloneDX or SPDX. It automates a significant part of the software supply chain visibility and evidence a company needs for its wider CRA process; neither tool makes a product compliant on its own.

Moving a pipeline to CRACI

CRACI replaces the runner, not GitHub Actions, and runs still appear in the GitHub UI. Once a pipeline runs as a GitHub Actions workflow, it runs on CRACI with one line:

runs-on: craci

Read more about build-time SBOM generation, compare CI/CD platforms, see Harness alternatives, or see pricing.