CRACI vs GitLab CI

The short answer

GitLab is a complete DevSecOps platform: source control, merge requests, planning and CI/CD in one product, with a broad set of security scanners and vulnerability management in its Ultimate tier. If you want one vendor for the whole software lifecycle, GitLab is built for that.

CRACI is narrower. It is a GitHub Actions-compatible runner that records every external dependency a build fetches, controls what the build can reach, and turns that record into SBOMs, signed provenance and CRA evidence. The core difference is traditional CI with scanners attached versus CI where the runner itself is the security record.

One practical point comes first. CRACI supports GitHub Actions only today, and GitLab CI is not yet supported. If your pipelines live in GitLab CI, you would need to move them to GitHub Actions to use CRACI runners, or wait for GitLab CI support, which is on the roadmap.

What GitLab does well

One platform. Code, reviews, pipelines, security findings and planning live in the same place, with one permission model. For many organizations that alone decides the question.

Security scanning, by tier. Be precise about what each tier includes. According to GitLab, basic SAST, secret detection and container scanning run in all tiers, including Free. In Free and Premium, those scans produce JSON report artifacts. Ultimate adds the workflow around them: findings in merge requests, the vulnerability report, the dependency list, security approvals, and GitLab Advanced SAST. Dependency scanning, continuous vulnerability scanning and DAST are Ultimate features. Container scanning can also produce a CycloneDX SBOM report in every tier.

Provenance. GitLab Runner can generate an artifact provenance statement in the SLSA 1.0 format in all tiers. Signed SLSA Level 3 attestations exist too, but GitLab lists them as an experiment on GitLab.com for Ultimate, behind a feature flag that is disabled by default.

Runner choice. GitLab-hosted runners cover Linux on x86-64 (2 to 32 vCPUs) and arm64, with Windows and macOS in beta. You can also run your own runners anywhere, and GitLab states that jobs on your own runners do not use compute minutes. GitLab Dedicated adds data residency in a region of your choice.

Where CRACI is different

The SBOM comes from the build, not the lockfile

GitLab's SBOM-based dependency scanning detects dependencies from supported lockfiles or dependency graph exports. That is a solid approach when the lockfile tells the whole story. Builds often do more: they run install scripts, download toolchains, restore caches and pull base images.

CRACI sees that activity because it is the runner. 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 job produces an SBOM in CycloneDX or SPDX.

Completeness is stated, not assumed

Each 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, you can see it.

The build network is a policy

CRACI egress 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. Policies are validated before the job starts, fail closed, and send an email alert on a violation. On GitLab, network control for builds is whatever you configure around your own runners.

Provenance signed by the runner that built it

CRACI signs provenance that links each artifact, including OCI artifacts, to the build that produced it, using Ed25519 over SHA-512. Through the API you can trace an artifact to its build, its CycloneDX SBOM and the job network trace. CRACI does not claim a SLSA level.

Monitoring what shipped

CRACI aggregates vulnerabilities across builds and repositories and keeps re-evaluating monitored SBOMs as new advisories appear.

Which one fits

• Stay with GitLab if your code and pipelines are on GitLab and you want one platform, or if you need SAST, DAST and secret detection in the same product.
• Choose CRACI if your code is on GitHub and you run GitHub Actions, and you need evidence of what went into each release, control over what builds can reach, and SBOMs you can defend in an audit.
• Use both if your organization runs both platforms. GitLab keeps covering its projects and scanners; CRACI runs the GitHub Actions side and records those builds.

For the Cyber Resilience Act

Under the EU Cyber Resilience Act, manufacturers need to know what is in each product release and handle vulnerabilities in it. Vulnerability reporting obligations apply from September 2026, and the regulation applies in full from December 2027. GitLab Ultimate helps with finding and managing vulnerabilities across your projects. CRACI records what each release was built from, keeps monitoring it, 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. Neither tool makes you compliant on its own.

Adding CRACI

For a repository on GitHub, install the CRACI GitHub App on your organization, for all repositories or a selected set, and change the runner label:

runs-on: craci

Workflows, actions and the GitHub UI stay the same. CRACI replaces the runner, not GitHub Actions. Read more about build-time SBOM generation and compliance reports, or see pricing.