Supply chain scanning

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. RingZero’s software composition analysis (SCA) maps the open-source code your projects pull in and flags what’s risky — vulnerable versions, known CVEs, and packages reachable from your code.

Unlike a standalone SCA report, RingZero feeds dependency findings to its AI pentest agents as targeting context: if a project transitively pulls a deserialization-vulnerable library, the agents concentrate their probing on the paths where that library is actually exercised. (For the non-technical pitch, see the supply chain security product overview.)

Ecosystem coverage

Tier	Ecosystems
Supported today	Gradle, Python, JavaScript, TypeScript
Coming soon	Go, Rust, Ruby, .NET, Maven, npm registry intelligence

Ecosystems are detected from the manifests and lockfiles in your snapshot (these map to the ecosystem field of the snapshot upload):

Manifest / lockfile	Ecosystem
build.gradle, build.gradle.kts, gradle.lockfile	Gradle
requirements.txt, pyproject.toml, poetry.lock, Pipfile.lock	Python
package.json + package-lock.json / yarn.lock / pnpm-lock.yaml	JavaScript / TypeScript

Two ways to integrate

1. Build tool plugin (recommended where available). The Gradle plugin resolves your real dependency graph — including transitive versions after conflict resolution — inside the build and uploads it as a snapshot: nodes and edges, not a flat list, so the server can compute every path to a vulnerable package. Build gating on policy arrives with the upcoming ringzeroCheck task.
2. Direct REST API. Any tool that can produce its resolved dependency graph can upload a snapshot directly. This is how you integrate ecosystems without a first-party plugin — the snapshot shape is identical across ecosystems.

Either way, the pipeline is the same:

upload dependency snapshot ─▶ scan queued ─▶ running
  ─▶ match versions against advisory data (CVE / GHSA)
  ─▶ completed: findings with severity, fixed version, and dependency path
     (or failed: re-upload — failed is terminal, don't re-poll)

What a finding tells you

Each dependency finding carries the severity, the package and installed version, the fixed version (if one exists), the CVE/GHSA advisory id, and the path — which manifest and which direct dependency pulled it in. The path is what turns a wall of CVEs into an actionable fix: it tells you which direct dependency to bump.

{
  "id": "fnd_9b4c",
  "scanId": "scn_7g8h",
  "packageRef": "dep_7f2e",
  "severity": "high",
  "cve": "CVE-2025-4410",
  "installedVersion": "1.2.68",
  "fixedVersion": "1.2.83",
  "reachable": true,
  "path": ["build.gradle", "acme-web-core", "fastjson"],
  "summary": "fastjson deserialization of untrusted input can lead to remote code execution."
}

reachable is present only when reachability analysis ran for the ecosystem — absence means unknown, not unreachable.

Findings roll up into the scan’s per-severity counts (findings: { critical, high, medium, low }) that you see on the scan detail page and in the scans API. Triaged findings can be suppressed with a required reason and optional expiry — suppressed findings leave the counts and the build gate but stay visible.

Next steps

Set up the Gradle plugin Install, provide the API key securely, and gate builds on policy.

Configuration reference Exclusions, suppressions, failOn policy, offline behavior.

REST API reference Upload snapshots and read findings from your own tooling.