CRACI vs Aikido

Consolidation versus evidence

Teams usually look at Aikido because they want fewer security tools. Aikido covers open-source dependencies, first-party code, secrets, infrastructure as code, containers, cloud posture, dynamic testing and runtime protection in one product, with a single place to triage findings. For a small team that needs broad coverage quickly, that is a strong offer.

Teams look at CRACI for a narrower reason. They need to know what their builds actually did, control what the build can reach, and produce evidence about each release that holds up in front of a customer or an auditor. CRACI does that by being the CI runner itself.

What Aikido does well

Breadth is the headline. Every Aikido plan lists SCA, SAST, secrets detection, IaC, cloud posture, container scanning, DAST, license scanning and SBOM generation. Its SCA uses function-level reachability to reduce noise, and AutoFix opens pull requests with patched versions. In CI it can block pull requests with critical risks, and it works with GitHub, GitLab, Jenkins, Bitbucket, CircleCI and others. CRACI supports GitHub Actions only.

Aikido also ships Safe Chain, a free tool that runs a local proxy in front of npm and PyPI package managers and blocks packages with known malware before they install, locally and in CI. CRACI does not block individual packages today. Organization-wide package blocklisting is on the CRACI roadmap, not in the product.

On compliance, Aikido's higher plans include SOC 2 and ISO 27001 compliance reports and sync to compliance platforms such as Drata and Vanta. If your main goal is feeding a SOC 2 program with application security findings, Aikido is built for it.

Where CRACI differs

CRACI is the CI runtime

Aikido's runtime protection guards running applications. CRACI works at a different runtime: the build job. Your GitHub Actions jobs execute on CRACI in isolated virtual machines, on runners from 1 to 32 compute units, on x86-64 or ARM64. Setup is changing runs-on to craci. Your workflows stay the same, and runs still appear in the GitHub UI.

Because CRACI runs the job, it can enforce an egress policy while the job runs. Policies are default deny or default allow, with 24 built-in software-source presets and typed custom sources for npm, PyPI, apt, apk, the Go proxy, Nix, Cargo, OCI registries and Git. They are validated before the job starts and fail closed. A scanner can tell you a risky package exists. A network policy stops the build from reaching places it should not.

Deterministic build evidence

Aikido builds its dependency view from manifests and lockfiles and adds analysis on top, including AI-driven exploitability checks. That is a sensible way to prioritize work.

CRACI's SBOM is not inferred. A package-aware proxy records what the job fetched from package sources, and dependency evidence travels with CI caches, so packages restored from a cache are still counted. Each SBOM states its own completeness per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded. It is a record of what happened rather than an estimate, and it tells you where it has gaps.

This matters because static SBOM tools disagree more than most people expect, and the reason is structural. Each one reads a different set of files and resolves them differently, so what a repository is said to contain depends on which tool you asked and how it was configured. A project that commits no lockfile, as express 5.2.1 does not, gives a lockfile reader nothing to resolve at all. CRACI cannot be compared on those terms, because it records builds rather than scanning directories, which is the point: a build record does not depend on which files happen to be present.

Provenance for each artifact

CRACI generates the SBOM inside its own runner, so the artifact you ship is provably the artifact the SBOM describes. Signed provenance links each artifact, including OCI artifacts, to its build, using Ed25519 signatures over SHA-512. The API lets you trace an artifact to its producing build, its CycloneDX SBOM and the job network trace.

Compliance outcomes built on that record

For the EU Cyber Resilience Act, the hard part is showing what went into each release and how you track its vulnerabilities over time. CRACI aggregates vulnerabilities across builds and repositories, continuously re-evaluates monitored SBOMs, and exports reports in PDF, HTML, CSV, Excel and JSON. It automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process. See CRA compliance and compliance reports.

Where each fits

• Choose Aikido when you want one tool covering code, dependencies, cloud and running apps, you use CI systems other than GitHub Actions, or your compliance focus is SOC 2 or ISO 27001 reporting from application security findings.
• Choose CRACI when you build on GitHub Actions and need to know exactly what each build fetched, control build network access, sign provenance for each artifact, and keep release evidence for CRA and customer audits.
• Use both when you want Aikido's scanning and pull request gating plus CRACI's build runtime controls and evidence. Aikido's CI checks and Safe Chain run as steps in your workflow, and those steps can run on a CRACI runner like any other.