104% more reported CVEs per day in 2026 than last year.

Comparison

CRACI vs OX Security

OX Security assembles a picture of risk from your code, pipelines, registries and scanners, and records it in a Pipeline Bill of Materials. CRACI is the runner your builds execute on, so it records what each build fetched and controls what it can reach.

Updated

The short answer

OX Security is an application security posture management (ASPM) platform with its own scanners (SAST, SCA, secrets, IaC and containers), aggregation of third-party findings, CI/CD posture policies, and runtime and cloud context. For supply chain security it offers the Pipeline Bill of Materials (PBOM): a signed record of how each artifact was built, from commit through CI/CD to production.

CRACI competes for the same supply chain budget. The difference is the vantage point. OX connects to the source control, CI systems and registries you already use and builds its picture from them. CRACI is the build runner for GitHub Actions: it records what each job actually pulled in, enforces an egress policy while it runs, monitors what shipped and produces CRA evidence. OX is much broader; CRACI is the build itself.

At a glance

Capability CRACI OX Security
Runs your builds Jobs run on CRACI runners Connects to the CI systems you run
Where the SBOM comes from Recorded by the runner from what each job fetches, including CI cache restores, with a completeness state per job. Collected from connected sources: source control, CI/CD pipelines, container images and imported files.
Build network egress policy Default deny or allow, fails closed Posture policies check workflow configuration instead
Signed build record No signed provenance PBOM signed per build
Continuous dependency monitoring Monitored SBOMs re-evaluated continuously Continuously updated inventory, exploitability-based prioritization
Block builds on security policy Policy gates block the build Scan step fails the workflow on blocking issues
CI/CD posture policies Unpinned actions, permissions, webhooks, secrets handling
SAST, secrets, IaC and containers OX Code, plus third-party scanner aggregation
CI systems covered GitHub Actions today; GitLab CI and Jenkins on the roadmap GitHub Actions, GitLab, Jenkins, Azure Pipelines, CircleCI
Pricing $0.002 per vCPU-minute ($0.004 for 2 vCPU), metered per second; no monthly fee and no per-SBOM charge OX Code priced per contributing developer; no list prices published (as of September 2026).
  • Included
  • Not included
  • On the roadmap

What OX Security does well

The OX Security homepage
ox.security
  • A build record beyond the SBOM. OX's PBOM captures pipeline definitions, runner identity, build arguments, artifact signatures and version lineage, and OX says it contains every open-source component resolved into each build. It is signed per build. OX also generates SBOMs in SPDX and CycloneDX.
  • CI/CD posture. OX policies flag insecure workflow files, unpinned third-party actions, deprecated GitHub Actions commands, excessive workflow permissions, plaintext secrets and risky webhooks, and can flag CI systems that are not approved for builds.
  • Enforcement in the pipeline. The OX Security Scan GitHub Action runs secrets, SAST, SCA and IaC scans and fails the workflow when it finds a blocking issue under your OX policies.
  • Aggregation. OX pulls in findings from scanners such as Checkmarx, Veracode, SonarQube, Snyk, Black Duck and JFrog Xray, alongside its own.
  • Wide integration coverage. On the CI side it lists GitHub Actions, GitLab CI/CD, Jenkins, Azure Pipelines, CircleCI and Drone CI, plus eight source control systems and ten container registries.
  • AI-era features. OX VibeSec covers AI-generated code and dependencies with an AI Bill of Materials, and AI remediation suggests code fixes in pull requests and the IDE.

Where CRACI is different

Recorded by the runner, not collected from connected tools

OX's documentation says its SBOM collects data from connected sources, including source control, CI/CD pipelines, container images and imported files. That gives a wide view across your estate. CRACI takes a narrower and deeper view of each build: a package-aware proxy observes traffic to package sources while the job runs, across npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk and Git sources, plus download presets. Dependency evidence travels with CI caches, so a package restored from a cache is still accounted for.

Every CRACI SBOM carries a completeness state per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded. When the record has a gap, it says so.

Control while the build runs

OX's posture policies check how a pipeline is configured. CRACI limits what the build can reach. Egress policies are default deny or default allow, with 24 built-in software-source presets, typed custom sources for npm, PyPI, apt, apk, the Go proxy, Nix, Cargo, OCI registries and Git, and explicit TLS, TCP, UDP and ICMP rules. Policies are validated before the job starts and fail closed, and CRACI can alert you on a violation.

Provenance and monitoring from one record

The API returns SBOMs, network traces and provenance. CRACI does not sign provenance and claims no SLSA level. It keeps re-evaluating the SBOMs of what you shipped as new vulnerabilities are published.

An inventory of what is deployed where

CRACI's inventory view shows exactly which software versions are deployed to which products, globally. When a new vulnerability lands, you can see which products run the affected version instead of piecing it together from release notes and spreadsheets.

Where OX is ahead

To be plain about it: CRACI has no SAST, secrets, IaC or container scanning, no CI/CD posture checks, no third-party scanner aggregation, and no runtime or cloud context. CRACI's policy gates can block a build on findings, but CRACI supports GitHub Actions only today, with GitLab CI and Jenkins on the roadmap. If you need one platform that spans every pipeline and scanner you run, OX covers much more.

Which one fits

OX Security is the better fit when

  • You want one ASPM platform that aggregates many scanners and prioritizes across them.
  • You need CI/CD posture policies across GitLab, Jenkins, Azure Pipelines or CircleCI.
  • You want pull request gating on code, secrets and IaC findings today.

CRACI is the better fit when

  • You build on GitHub Actions and want the runner, egress policy and dependency record in one place.
  • You need an SBOM of what each build fetched, with a completeness state you can show an auditor.
  • You want monitoring of what shipped and CRA evidence from the same record.

Using both

CRACI replaces the runner, not GitHub Actions, so the OX Security Scan action runs on a CRACI runner like any other step. OX can import SBOMs in CycloneDX format, so CRACI can supply the SBOM recorded from the build for OX to work from.

For the Cyber Resilience Act

The Cyber Resilience Act asks manufacturers to know the components in each product, handle vulnerabilities in them, and keep evidence. OX's SBOMs, PBOM and posture policies support secure development and an inventory across your estate. CRACI automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process: build-time SBOMs exported as CycloneDX or SPDX, vulnerability tracking, and provenance through the API. Neither tool makes you compliant on its own. See CRA evidence and CRA compliance.

Adding CRACI

Install the CRACI GitHub App on your organization, then change the runner label on a job to runs-on: craci. Runs still appear in the GitHub UI. Start with one workflow that produces a release artifact and compare CRACI's SBOM with the one OX shows for the same repository. Read more about CI/CD integration, build-time SBOM generation and pricing.

Weighing more than two tools? OX Security alternatives compares nine options side by side.

Run one real build and compare

Point one GitHub Actions workflow at CRACI and compare its SBOM and network trace with the inventory you have today.

Book a demo