CRACI and GitHub Advanced Security

The short answer

GitHub Advanced Security is now sold as two products. GitHub Secret Protection covers secret scanning and push protection. GitHub Code Security covers code scanning with CodeQL, Copilot Autofix, dependency review and premium Dependabot features. Both sit on top of platform features every GitHub team knows: the dependency graph, Dependabot and, in GitHub Actions, artifact attestations.

CRACI is a GitHub Actions-compatible runner. You keep GitHub, your workflows and your security tooling, and change runs-on to craci. While jobs run, CRACI records every external dependency they fetch, enforces an egress policy and signs provenance. GitHub tells you what your repository contains and declares. CRACI tells you what your build did. Most teams on GitHub should use both.

At a glance

The table mixes GitHub Advanced Security with the GitHub platform features it builds on (dependency graph, Dependabot, artifact attestations and hosted runners), because that is how teams experience them.

What GitHub does well

Code scanning with CodeQL is semantic static analysis built into pull requests, and Copilot Autofix proposes fixes for the alerts it raises. Secret scanning covers git history, pull requests, issues and wikis, and push protection blocks a secret before it lands. Validity checks tell you whether a leaked credential is still live. CRACI does none of this, and nothing on this page suggests replacing it.

On dependencies, the dependency graph parses the manifests and lock files in your repository, and Dependabot alerts you when one matches an advisory in the GitHub Advisory Database. Both are included in all GitHub plans. Security updates try to open a pull request for every open alert that has a patch, and dependency review (part of Code Security) shows what a pull request changes before merge. Automatic dependency submission can add build-resolved data for Maven, Gradle and Python. You can export the graph as an SPDX SBOM from the UI or the REST API.

Artifact attestations use Sigstore to sign build provenance for binaries and container images, and can attest SBOMs in SPDX or CycloneDX. GitHub documents that attestations alone provide SLSA v1.0 Build Level 2, and Level 3 with reusable workflows. For public repositories, code scanning and secret scanning are enabled by default; private repositories need the paid products, which require a Team or Enterprise plan.

Where CRACI is different

A record of the build, not the repository

The dependency graph describes the repository, and updates when a commit changes a manifest or lock file on the default branch. That is useful, but it is not the same as a record of the job that produced a release. CRACI observes the build itself: a package-aware proxy sees traffic to package sources, across npm, PyPI, RubyGems, Cargo, Go, Nix and OCI plus OS packages. Evidence travels with CI caches, and each SBOM states its completeness per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded.

The gap is structural. GitHub's dependency graph export is built from what GitHub knows about the repository rather than from the files a scanner reads, so it can list components no file-based tool finds and miss things they do find. It also reflects the default branch rather than the commit you built. CRACI cannot be compared that way, because it records builds rather than scanning a directory.

Control over what the job can reach

CRACI enforces an egress policy per job: default deny or default allow, with 24 built-in software-source presets and typed custom sources for registries and Git. Policies are validated before the job starts and fail closed, and CRACI can email you on a violation. This is a runtime control on the build, which scanning the repository cannot provide.

Provenance with the evidence attached

GitHub's attestations are a workflow step you add, and GitHub itself notes that an attestation is not a guarantee that an artifact is secure. CRACI's provenance comes from the runner that observed the job, so the artifact, its CycloneDX SBOM and the job's network trace link together through the API. Signatures are Ed25519 over SHA-512 and cover OCI artifacts. CRACI claims no SLSA level; if you need a documented SLSA level today, GitHub's attestations provide one.

Monitoring what shipped

CRACI aggregates vulnerabilities across builds and repositories, and keeps re-evaluating monitored SBOMs. Reports export in PDF, HTML, CSV, Excel and JSON.

How they fit together

• GitHub Advanced Security on every pull request: CodeQL, secret scanning, push protection and dependency review.
• Dependabot keeping declared dependencies patched.
• CRACI as the runner: recording each build, enforcing egress policy, signing provenance and holding the evidence.

Runs on CRACI still appear in the GitHub UI, and your workflows keep their steps.

Stay on GitHub-hosted runners for Windows and macOS jobs: CRACI runs Linux only, on x86-64 and ARM64.

For the Cyber Resilience Act

GitHub's tools help you find and fix vulnerabilities before release, which a manufacturer needs to do. CRACI automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process: what went into each release, proof that the artifact came from that build, and ongoing vulnerability tracking. Neither makes a product compliant by itself. See what the CRA is and compliance reports.

Adding CRACI

Install the CRACI GitHub App on your organization, for all repositories or a selected set, then change runs-on to craci in the workflows you want recorded. Read more on CI/CD integration and build-time SBOM generation, or check pricing.