CRACI vs Cycode

The short answer

Cycode calls itself an agentic development security platform, and grew out of application security posture management (ASPM). It sells code security (SAST, SCA, container and IaC scanning), software supply chain security (CI/CD security, build runtime protection, code leak detection, SBOM, secrets), posture management with more than 100 connectors, and AI governance for development. Its build runtime piece, Cimon, is an eBPF agent that runs inside your CI jobs.

CRACI competes for the same supply chain budget, and with Cimon the overlap is real: both observe builds, both can restrict build egress, and both produce an SBOM and signed provenance from the build. The difference is where that lives. Cycode adds an agent to the CI you already run, across many systems. CRACI is the runner for GitHub Actions, so the record, the policy and the provenance come with every job, and CRACI carries them forward into monitoring and CRA evidence. Cycode is far broader; CRACI goes deeper on the build and what shipped.

At a glance

What Cycode does well

Breadth across the SDLC

• Code security: SAST and AI SAST, SCA with reachability analysis and license compliance, container scanning and infrastructure as code security.
• Secrets and leaks: Cycode looks for exposed secrets in source code, pipelines and tools such as Jira, Slack and Confluence, and detects leaked code.
• CI/CD security: it monitors CI/CD security policies, configurations and governance, and uses policy enforcement to help teams meet standards such as NIST SSDF.
• Posture management: the Context Intelligence Graph traces vulnerabilities across code, tool configurations, cloud infrastructure and ownership, and ConnectorX brings in findings from other scanners.
• SBOMs: Cycode generates SBOMs in SPDX or CycloneDX, and its Posture Management plan lists SBOM ingestion.

Cimon, the build runtime agent

Cycode describes Cimon as runtime security, a runtime-observed SBOM and SLSA provenance in a single GitHub Actions or Azure Pipelines step. It monitors process execution, network egress and file access at the kernel level with eBPF. In detect mode it observes without blocking; once a pipeline's normal behavior is established, it enforces it, and the GitHub Action accepts allowed hosts and IPs. Cimon signs provenance to the SLSA Provenance v1.0 specification, which Cycode says satisfies SLSA Build Level 2 on a hosted runner signed through GitHub OIDC. It also runs on Jenkins, GitLab CI, Buildkite and Harness, and Cycode says it is free and open source.

Where CRACI is different

The runner, not an agent on it

Cimon is added to the runners you keep; on GitHub Actions it runs as a privileged container that joins the runner's process and network namespaces. That is what lets it work on hosted runners and many CI systems. CRACI takes the other route and replaces the runner. You change runs-on to craci, and the egress policy is part of the platform: validated before the job starts, rejecting unknown fields, and failing closed.

Packages and sources, not only hosts

CRACI's egress policy is typed by ecosystem. It has 24 built-in software-source presets, custom sources for npm, PyPI, apt, apk, the Go proxy, Nix, Cargo, OCI registries and Git over HTTPS and SSH, and explicit TLS, TCP, UDP and ICMP rules. A package-aware proxy records which packages each job fetched. Dependency evidence travels with CI caches, so a package restored from a cache is still in the record, and every SBOM carries a completeness state per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded.

From the build to what shipped

• Provenance: signed evidence links each artifact, including OCI artifacts, to its build. Through the API you can go from an artifact to its build, its CycloneDX SBOM and the job's network trace.
• Monitoring: CRACI keeps re-evaluating the SBOMs of what you shipped as new vulnerabilities appear, aggregated across builds and repositories.
• Reports: export in PDF, HTML, CSV, Excel and JSON.

Where Cycode is ahead

To be plain about it: CRACI has no SAST, secrets, IaC or container scanning, no ASPM connectors, no process or file monitoring, and no detect or monitor mode yet (it is on the roadmap). CRACI claims no SLSA level, and it runs GitHub Actions only. If you need one platform across all your code and every CI system, Cycode covers much more.

Which one fits

Cycode is the better fit when

• You want one ASPM platform for code scanning, secrets, CI/CD posture and prioritization.
• You run Azure Pipelines, Jenkins, GitLab CI or Buildkite and want build runtime protection there.
• You want to keep GitHub-hosted runners and add an agent to them.

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 a package-level SBOM from each build with a completeness state you can show an auditor.
• You want monitoring of what shipped and CRA reports from the same record.

Using both

Cycode's code scanning, secrets detection and posture management cover ground CRACI does not touch, so the two can sit side by side. Cimon is the exception: on a CRACI runner, build observation, egress control and provenance are already part of the runner, so CRACI replaces Cimon rather than running next to it.

For the Cyber Resilience Act

Cycode positions its platform for CRA conformity with automated SBOM generation, vulnerability tracking and evidence collection for technical files. CRACI automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process, starting from the build: SBOMs with completeness states, provenance, monitoring of what shipped and reports. Neither tool makes you compliant on its own. See what the CRA requires 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. Read more about CI/CD integration, build-time SBOM generation and pricing.