CRACI vs OX Security

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, signs provenance, monitors what shipped and produces CRA evidence. OX is much broader; CRACI is the build itself.

At a glance

What OX Security does well

• 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 and OCI, plus OS packages and source or 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 email you on a violation.

Provenance and monitoring from one record

Signed provenance links each artifact, including OCI artifacts, to the build that produced it (Ed25519 over SHA-512; no SLSA level is claimed). Through the API you can go from an artifact to its build, its CycloneDX SBOM and the job's network trace. CRACI keeps re-evaluating the SBOMs of what you shipped as new vulnerabilities are published.

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. Build blocking on vulnerability thresholds is on CRACI's roadmap, and CRACI supports GitHub Actions only. 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 reports 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, vulnerability tracking, provenance and reports in PDF, HTML, CSV, Excel and JSON. Neither tool makes you compliant on its own. See 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.