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. Policy gates can block a build; vulnerability webhooks are on the roadmap.

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.
• An npm install hook or a Rust build script fetches more code during the install, the route the Shai-Hulud worm used.
• A container build pulls a base image and its operating system layers, which no language lockfile lists.
• The thing you ship is a compiled binary, and the manifest next to it lists almost nothing.

CRACI is a recorder: it sees the traffic, and scanners do not. 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, so these hidden dependencies land in the SBOM. 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, OCI, apt, apk and Git sources, plus download presets, 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.
• 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 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; GitLab CI, Jenkins and other CI systems are on the roadmap.

An inventory of what is deployed where

CRACI's inventory view shows exactly which software versions are deployed to which products, globally. When a new vulnerability lands, you can see which products run the affected version instead of piecing it together from release notes and spreadsheets.

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