Your SOC 2 platform shows the control runs. CRACI records what the build contained.

The setup this page is about

Many SaaS teams end up with the same arrangement. A generator such as Syft or Trivy produces an SBOM in CI, a vulnerability scanner watches the repositories, and a compliance automation platform connects to GitHub and the cloud account to collect evidence for SOC 2. It works. Auditors accept it, and nobody spends the week before an audit taking screenshots.

Those platforms are good at this. Vanta says it "connects read-only to your cloud, identity, code, and device tools" and "automatically pulls evidence, maps it to controls," with more than 1,200 automated tests running hourly. Drata connects to "cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more" to collect and map evidence to SOC 2 controls. If the goal is a clean SOC 2 report, that is the right tool for the job.

This page is about a narrower question: what that evidence says about the SBOM itself.

What a SOC 2 check actually asks

SOC 2 examinations report against the AICPA Trust Services Criteria. The criterion closest to SBOMs is CC7.1:

"To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities."

AICPA, 2017 Trust Services Criteria, CC7.1

The criterion describes an outcome. It leaves the method, and the depth of the component inventory behind it, to you and your auditor. So an automated test usually asks whether the control is in place and operating: is a scanner connected, did it run, were findings handled within your policy. That is a fair question, and it is the checkbox.

What the check does not ask is whether the SBOM behind the scan listed everything the release contained. A vulnerability that sits in a component the SBOM never listed cannot be matched to anything, so the scan comes back clean and the control still reads as green.

Where a green check and a complete SBOM part ways

SBOM generators work from the files in front of them, and their own documentation shows where that leaves gaps:

• On expressjs/express 5.2.1, which commits no lockfile, a generator that resolves dependencies from lock files has nothing to resolve. It can still return a document, listing whatever else it recognizes, such as GitHub Actions and workflow files, and none of the npm dependencies declared in package.json.
• Different generators return different lists from the same checkout, because each decides for itself what counts as a component. GitHub's dependency graph export is further out still: it is built from what GitHub knows about the repository and reads the default branch rather than the pinned commit.
• The NTIA supplier field comes out empty in most documents, because most generators have no source for it.

None of those tools is broken. Each one read the files it was pointed at, and each produced a valid document in a standard format, on schedule. As far as a compliance test is concerned, the control operated. The SBOM still did not describe the software.

What CRACI adds to the evidence

CRACI replaces the GitHub Actions runner. You change runs-on to craci, and runs still appear in the GitHub UI. The SBOM is generated inside that runner while the build happens: a package-aware proxy observes traffic to package sources, so the record reflects what the job pulled rather than what a file says it should pull.

Completeness is stated, not assumed

Every job and every cache gets one of five completeness states: Complete, Complete with connections, Incomplete, Unavailable, or Not recorded. Dependency evidence travels with caches, so packages restored from a warm cache are carried forward instead of silently dropping out. When a record is incomplete, it says so.

That matches where the standards are going. The 2026 SBOM minimum elements from CISA and its partners ask SBOM authors to "explicitly state whether the information is unknown to the SBOM author" rather than leave fields quietly blank.

Provenance links the artifact to the build

CRACI signs evidence that links an artifact, including OCI images, to the build that produced it, using Ed25519 signatures over SHA-512. SLSA defines provenance as "the verifiable information about software artifacts describing where, when and how something was produced." We do not claim a SLSA level. The point is narrower and practical: you can show which build produced the thing you shipped, and which SBOM describes that build.

Evidence in formats auditors take

SBOMs export as CycloneDX or SPDX. Compliance reports export as PDF, HTML, CSV, Excel and JSON. The public REST API returns the SBOM, the job's network trace and the artifact's provenance, so the same records can go wherever your audit evidence lives.

Keep the SOC 2 platform

CRACI is not a compliance automation platform and does not replace one. It does not manage policies, access reviews, device checks or vendor questionnaires. The two answer different questions. Your compliance platform shows that a control exists and runs. CRACI records what the build pulled in and whether that record is complete.

The difference grows once you sell software into the EU. The Cyber Resilience Act requires manufacturers to identify and document components "by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products" (Annex I, Part II). Annex VII places the SBOM in the technical documentation and lets a market surveillance authority request it. A SOC 2 report attests to how your organization runs its controls. A CRA SBOM describes a specific product. Our overview of the CRA covers the timeline, and the CRA compliance page covers what CRACI automates. CRACI automates a significant part of the supply chain visibility and evidence that a wider CRA compliance process needs; it does not make you compliant on its own.

How to try it without touching your audit

1. Pick one repository whose SBOM already feeds your SOC 2 evidence.
2. Point its release workflow at CRACI by changing runs-on to craci.
3. Compare the recorded SBOM with the one you generate today, component by component, and check the completeness state of the job.
4. Decide whether the difference belongs in your evidence.

You can read more about build-time SBOM generation and compliance reports, or see how we document our own controls on our security page.