Supply chain scanning

RingZero’s software composition analysis (SCA) matches your resolved dependency versions against advisory data and shows how vulnerable packages enter your build. Gradle scans also preserve module relationships, teams, and custom labels, so you can distinguish the module that introduces a dependency from the modules that consume it.

Large Gradle builds use multipart uploads automatically. Findings, module details, and dependency paths load as you need them.

Dependency paths describe the build graph. Runtime reachability analysis and using SCA findings to guide AI pentest agents are planned; a path does not prove that vulnerable code executes in your application. For the product overview, see supply chain security.

Ecosystem coverage

Ecosystem	Integration available today	Input and attribution
Gradle (Java / Kotlin)	Gradle plugin	Resolved configurations; snapshot v2 with modules, team metadata, and introducing dependencies
JavaScript / TypeScript	npm CLI	package-lock.json v2/v3, including workspaces; snapshot v1 with dependency paths
Python	REST API	A resolved dependency graph produced by your own tooling

Go, Rust, Ruby, .NET, a Maven build integration, and npm registry intelligence are on the roadmap. The API accepts resolved graphs; it does not parse manifests or lockfiles. The npm CLI does not yet read Yarn or pnpm lockfiles.

Two ways to integrate

1. First-party build integration. The Gradle plugin captures selected versions and variants inside the build. Apply it at the root for one aggregate scan, to modules for independent scans, or to both. The npm CLI reads the graph in package-lock.json. Both can write a local snapshot without an API key; advisory matching requires an upload.
2. Direct REST API. Any tool that can produce a resolved dependency graph can upload a snapshot. Schema v1 remains accepted; use schema v2 to include module metadata and resolution graphs for ownership attribution.

Either way, uploaded snapshots follow the same pipeline:

upload dependency snapshot → queued → running
  → match resolved versions against advisory data via OSV
  → completed: findings, fixed versions, dependency paths
     (or failed: investigate the reason and submit a new scan)

Build gating is coming soon

ringzeroScan returns after the upload is accepted. It does not wait for findings or fail the build on vulnerability thresholds. The ringzeroCheck task and failOn policy block are coming soon. Configuration, resolution, and upload failures can still fail ringzeroScan.

What a finding tells you

Each finding carries severity, package and installed version, the fixed version when one exists, the CVE or other advisory identifier, and dependency paths. Gradle findings identify the modules, configurations, and declarations that introduce a package. Expand attribution to see the evidence; large scans fetch these details in pages. The API reference shows the response fields and filtering options.

A finding remains unique per advisory, package, and installed version. If five modules use the same vulnerable package version, the finding counts once in the scan’s severity totals. A suppression removes a triaged finding from active counts while retaining its reason and optional expiry. Suppressed findings remain available in the app and API.

Review findings by module and team

After an uploaded Gradle scan completes, open its link or choose it from Scans in the app:

1. In Module ownership, choose a Team and/or Module. Team labels come from each module’s optional teamName.
2. Under Show dependencies, use Introduced by this selection to find the dependencies declared by that selection. Use Affecting this selection to include packages it consumes through other modules.
3. Expand a finding’s Module attribution to inspect configurations, direct/transitive relationships, paths, and introducing dependencies.
4. Search the module list and load more results as needed. Expand modules to inspect dependencies and custom attributes such as service or domain. Modules appear with dependencies before their consumers. Missing team labels display as Unassigned.

For example, if :core declares com.acme:json-client and :app consumes :core, a vulnerability pulled in by that library affects both modules. The introducing module is :core, even when the vulnerable package is transitive. Selecting :app under Affecting this selection includes the finding; selecting it under Introduced by this selection does not, unless :app also has an introducing declaration.

The app starts in Introduced by this selection mode. The REST findings endpoint defaults to attribution=affected; set attribution=introduced explicitly to request the introducing view. Team and module filters must match the same module. The filtered view still counts each finding once.

Team names and attributes are snapshot metadata. They do not grant access, change organization membership, or automatically assign a finding to a person.

Older scans and npm workspaces

Schema v1 scans retain dependency paths but have no module ownership metadata or attributions. This includes current npm CLI snapshots. Existing scans are not backfilled: run a new scan with the Gradle plugin’s v2 output to capture module ownership. Findings appear after processing completes.

Inspect a Gradle scan locally

Every Gradle scan writes snapshot.json and a readable dependencies.md in that project’s build/ringzero/ by default. Small scans retain a full snapshot and report. Large scans use an indexed bundle of upload parts and reports; keep the entire directory when archiving it. See report formats.

Without a key, or with --offline, the plugin writes the reports and skips the upload. These files describe dependencies, not vulnerability findings. See report-only mode and configuration cache support.

Next steps

Scan a large Gradle monorepo Keep one scan across the build and review findings by module and team.

Set up the Gradle plugin Scan a build or individual modules, attach team labels, and upload from CI.

Set up the npm CLI Scan package-lock.json — workspaces included — and upload snapshots.

Configuration reference Module metadata, exclusions, suppressions, configuration cache, and offline behavior.

REST API reference Upload v1/v2 snapshots and filter findings by module or team.