CRACI vs a DIY SBOM stack

The short answer

A DIY stack built from Syft or Trivy, Grype, Dependency-Track, Cosign and Renovate is free to license, runs anywhere, and gives a capable platform team full control. CRACI is a managed GitHub Actions runner that records what each build fetched, controls where it can connect, signs provenance, monitors what shipped and exports the evidence. The difference is less about features and more about where the SBOM comes from and who maintains the seams. If you build on GitLab, Jenkins or Windows, or everything must run on your own infrastructure, DIY is the honest recommendation today.

What the stack looks like

A complete build-your-own setup usually has seven layers. Each one is a real project with its own upkeep.

1. Generation. Syft ("generating a Software Bill of Materials (SBOM) from container images and filesystems"), Trivy, cdxgen (an OWASP project that creates CycloneDX BOMs "from source and container images") or the Microsoft SBOM Tool, which writes SPDX and expects a build drop folder, a package name, a version and a supplier on the command line.
2. Matching. Grype scans images, filesystems and SBOMs, with EPSS, KEV and risk scoring. OSV-Scanner matches lockfiles, SBOMs and container images against OSV.dev.
3. Management. OWASP Dependency-Track ingests CycloneDX SBOMs and monitors them over time. Its API server needs at least 2 GB of RAM and 2 CPU cores (8 GB and 4 cores recommended), and its docs point production deployments to Docker Compose with a separate database.
4. Signing. Cosign signs images, blobs and SBOM attestations, with keyless signing through Fulcio and a Rekor transparency log. GitHub artifact attestations build on Sigstore and provide SLSA v1.0 Build Level 2 provenance.
5. Updates. Renovate or Dependabot open pull requests to keep dependencies current.
6. Egress control. StepSecurity Harden-Runner can audit or block outbound connections from GitHub Actions jobs. Its Community tier is free for public repositories on GitHub-hosted runners; private repositories and self-hosted runners need the Enterprise tier. The alternative is your own proxy and firewall rules around self-hosted runners.
7. Reporting. Someone turns the output of all of the above into the documents an auditor, a customer or a CRA technical file needs.

The cost is in the seams

Choosing a generator is choosing its blind spots

Point several SBOM generators at the same repository and they will not agree on what it contains. Each reads a different set of files and resolves them differently, so the component list you get is a property of the tool you picked as much as of the project. The NTIA supplier field shows the same thing from the other side: most generators have no source for it, so it comes out empty whatever the repository holds.

None of these tools is broken. Each makes a different, documented decision about what counts as a component and which files to trust. But a DIY stack inherits whichever decisions you picked, and the rest of the pipeline (matching, monitoring, reporting) can only be as complete as that first step.

The glue is yours

Each tool has its own release cadence, vulnerability database, output format and configuration. Someone pins the versions, updates the databases, keeps Dependency-Track and its database patched, rotates signing identities, decides which SBOM goes where, and notices when a step silently starts producing less. That is ongoing platform work, not a one-time setup.

The tools are dependencies too

Security tools run inside your builds with access to your secrets, so they belong in your threat model. In March 2026, Aqua Security published an advisory describing how compromised credentials were used to publish a malicious Trivy release and to force-push most trivy-action tags to credential-stealing code for about 12 hours. Aqua documented it publicly, and it could have happened to any widely used project. It shows why egress control on the runner matters: a default-deny policy limits where a compromised step can send data, though not every channel (the advisory also describes a fallback that created repositories on the victim's GitHub account).

When DIY is the right call

• Your CI is not GitHub Actions. CRACI supports GitHub Actions only today. GitLab, Jenkins and CircleCI teams can run every open-source tool above.
• You build on Windows or macOS. CRACI runners are Linux (x86-64 and ARM64).
• Everything must run on your infrastructure. CRACI is a managed service, and customer-hosted runners are not offered.
• You have a platform team that wants to own it. If maintaining the stack is a deliberate investment and you already run Dependency-Track well, keep it.
• You need one SBOM for one questionnaire. For a low-stakes, occasional request, a generator run by hand may be enough.

What CRACI replaces, and what it does not

CRACI covers several layers in one place, starting from the build. You change runs-on to craci, and runs still appear in the GitHub UI. A package-aware proxy records what each job pulls from npm, PyPI, RubyGems, Cargo, Go, Nix and OCI sources, plus OS and download sources, and dependency evidence travels with CI caches. Every job and cache gets a completeness state: Complete, Complete with connections, Incomplete, Unavailable or Not recorded.

• Generation: CycloneDX and SPDX from the recorded build, including transitive dependencies.
• Monitoring: findings aggregated across builds and repositories, with monitored SBOMs re-evaluated continuously.
• Signing: signed provenance (Ed25519 over SHA-512) links an artifact, including an OCI artifact, to its build. CRACI does not claim a SLSA level.
• Egress: per-job policy with 24 built-in software-source presets, validated before the job starts, failing closed, with email alerts on violations.
• Reporting: export in PDF, HTML, CSV, Excel and JSON.

It does not replace everything. License policy and package blocklists are on the roadmap. Renovate or Dependabot still make sense for keeping every dependency current, not only vulnerable ones. If Dependency-Track is where your security team works, the CycloneDX SBOM downloads through CRACI's REST API and can feed it.

For the Cyber Resilience Act

The CRA asks manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials" (Annex I, Part II). Reporting of actively exploited vulnerabilities applies from September 2026, with 24 hours for the first notification. A DIY stack can support that, as long as someone owns the evidence trail from each release back to its SBOM. CRACI automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process. Whichever route you take, deciding what is actively exploited and filing the notification stays with your team. See CRA compliance and build-time SBOM generation.