You already scan your dependencies. Here is what a scanner cannot see.

What your current stack does well

If you have SCA and SBOM generation configured, you have already done the hard organizational work: dependencies are tracked, advisories reach developers, and there is a file to hand over when someone asks. Keep that.

• GitHub's dependency graph and Dependabot are on by default for many teams. GitHub describes the dependency graph as "a summary of the manifest and lock files stored in a repository and any dependencies that are submitted for the repository using the dependency submission API." Dependabot alerts build on it and notify you when a new advisory is published or when your dependency graph changes.
• Commercial SCA such as Snyk also generates SBOMs. Its snyk sbom command reads manifest files and their lockfiles, and emits CycloneDX or SPDX. As of September 2026, Snyk documents it as "available only to customers on Snyk Enterprise plans."
• Open source generators such as Syft, Trivy and cdxgen are free, fast and easy to add to CI. Syft describes itself as a tool "for generating a Software Bill of Materials (SBOM) from container images and filesystems."

These tools are strongest at fast feedback on a pull request, broad ecosystem coverage and a remediation workflow developers already know. CRACI does not replace that today. Its vulnerability tracking aggregates findings across builds and repositories and re-evaluates monitored SBOMs as new vulnerabilities appear. Security teams can triage findings and send them to the right team. It does not yet block builds on thresholds or send vulnerability webhooks.

Scanner versus recorder

Every tool above is a scanner. You point it at a source tree, a lockfile or a container image, and it infers what went in. That works when the files tell the whole story. It gets harder when they do not:

• The repository has no lockfile, so versions are decided at install time.
• The build restores packages from a CI cache that no manifest mentions.
• A build step downloads a tool, an OS package or a binary directly.
• The thing you ship is a compiled binary, and the manifest next to it lists almost nothing.

CRACI is a recorder. It runs the build on its own GitHub Actions compatible runner, and a package-aware proxy observes the traffic to package sources while the job runs. Packages restored from a cache carry their evidence forward. There is no craci scan ./dir command, because scanning a directory after the fact is the step CRACI exists to avoid.

What a scan depends on

Scanner output depends on the tool and on what it is pointed at. Syft, Trivy, cdxgen, the Microsoft SBOM Tool, GitHub's dependency graph export and the Socket CLI each work out the list from what they can read. The patterns below come from how these tools are documented to work.

No component is found by every tool

Each generator decides for itself what counts as a component and which files to trust, so the same checkout gives each of them a different list. GitHub's dependency graph export works differently again: it is built from what GitHub knows about the repository rather than from files a scanner reads, and it reads the default branch rather than a pinned commit.

No lockfile, no dependencies

Express 5.2.1 commits no lockfile. Pointed at a clean checkout, a generator that resolves dependencies from lock files or an installed tree has neither in front of it, so none of the npm dependencies declared in package.json reach the document. No tool here is broken. The variable that decides whether the SBOM contains any dependencies at all is not the tool. It is whether anyone ran an install first.

One flag changes the answer

Syft's default directory scan reports what a project declares, not what is installed on disk. On an installed checkout of the same express release, one cataloger flag decides whether the installed npm packages appear in the list at all. Same tool, same version, same tree.

The product is a binary

The anthropics/claude-code repository at v2.1.259 has no dependency manifest or lockfile of any kind. Its published npm package declares zero runtime dependencies and wraps a prebuilt native binary through eight platform packages. @openai/codex 0.149.1 has the same shape. A manifest reader has almost nothing to describe, while the program that runs is a compiled binary, so what each tool returns says more about the tool than about the project.

Same package, different versions

Where two tools do find the same thing, they do not always agree on what it is. One may pin a GitHub Action to a commit SHA while another reports a release tag. A vulnerability lookup keyed on the wrong version returns a confident wrong answer.

Where CRACI fits alongside your SCA

Keep your SCA on pull requests. It is the right place to catch a vulnerable version before it merges. Add CRACI where the question is about the build rather than the diff:

• What did this release actually contain? The recorded SBOM covers npm, PyPI, RubyGems, Cargo, Go, Nix and OCI packages, plus OS and direct download sources, including transitive dependencies. JFrog Artifactory mirrors for npm and PyPI work too.
• Can we trust the list? Each job and cache has a completeness state, so an incomplete record is visible instead of silently thin.
• Is this the artifact the SBOM describes? Signed provenance (Ed25519 over SHA-512) links an artifact, including an OCI image, to the build that produced it.
• Are we affected by a new advisory? Monitored SBOMs are re-evaluated as new vulnerabilities are published, and findings are aggregated across builds and repositories.

The SBOM downloads as CycloneDX through the public REST API, along with the job's network trace and the artifact's provenance, so it can feed any tool that reads CycloneDX, including the SCA you already run. Setup is one line in the workflow: change runs-on to craci. GitHub Actions is the supported CI today.

Read more about build-time SBOM generation and vulnerability tracking.