Product · Supply chain
Scan every dependency you ship
Most of the code an application ships is code your team didn't write: open-source dependencies pulled in through manifests and lockfiles, often several hops deep. That's where much of the real risk lives — and where teams have the least visibility. RingZero's software composition analysis (SCA) maps the open-source code your projects depend on and flags what's risky: vulnerable versions, known CVEs, and the exact path that pulled each one into your build.
How the scan works
SCA runs as part of a source-code scan. RingZero detects manifests and lockfiles in the
repo — build.gradle, pyproject.toml, poetry.lock,
package-lock.json, pnpm-lock.yaml, and friends — resolves the
full dependency graph, direct and transitive, and matches every version against CVE and
GHSA advisory data. Each finding carries severity, the installed and fixed versions, the
advisory id, and the dependency path: which manifest, through which direct dependency,
made this package reachable.
Gradle builds can feed the same pipeline from CI today via the
tech.ringzero.sca Gradle plugin, which snapshots the dependency graph at
build time and uploads it for analysis.
The differentiator: findings that steer the agents
In most stacks, SCA output is a standalone report that goes stale in a tab. In RingZero it's a context feed. Dependency findings are handed to the AI pentest agents, which concentrate their testing where a known-vulnerable package is actually exercised — probing deserialization endpoints when a vulnerable deserializer is in the graph, rather than testing uniformly. Projects with critical dependency findings rank higher in your org posture view, and a finding's fixed version gives automated remediation a concrete, verifiable change: bump, build, test.
Ecosystem coverage
Supported today: Gradle, Python, JavaScript, TypeScript.
Coming soon: Go, Rust, Ruby, .NET, Maven, and npm registry package
intelligence (typosquats and maintainer risk beyond version matching). MCP server
configuration — a supply chain surface of its own — is covered separately by
MCP security.
Frequently asked questions
Which ecosystems does RingZero scan?
Supported today: Gradle, Python, JavaScript, and TypeScript — detected automatically from manifests and lockfiles like build.gradle, pyproject.toml, and package-lock.json. Go, Rust, Ruby, .NET, Maven, and npm registry package intelligence are on the roadmap.
Does it catch transitive dependencies?
Yes. RingZero resolves the full dependency graph, direct and transitive, and every finding carries its path — which manifest and which direct dependency pulled the vulnerable package in — so you fix the root cause instead of chasing a leaf.
How is this different from Dependabot or a CVE scanner?
The scan itself covers similar ground: versions matched against CVE/GHSA advisory data. The difference is what happens next — RingZero’s dependency findings steer its AI pentest agents toward the attack surface where a vulnerable package is actually reachable, rank projects by supply-chain exposure in your org posture view, and feed fixed-version bumps into the automated remediation pipeline.
Is there a CI integration?
Yes — a Gradle plugin (tech.ringzero.sca) snapshots your dependency graph at build time and uploads it for analysis. Today it reports findings without gating your build; build-failing policy gates (the ringzeroCheck task) and further ecosystem plugins are coming soon.
What does a dependency finding contain?
Severity, package and installed version, the fixed version if one exists, the CVE or GHSA advisory id, and the dependency path that explains why it is in your build. Findings roll up into the same per-severity counts as the rest of your scans.