Coverage & Warnings

Dependency findings are only as complete as the graph they’re matched against. If a manifest can’t be fully resolved, usually because of a missing lockfile, its transitive packages stay invisible and a vulnerability could hide there. ZeroPath measures this directly and surfaces it as coverage, so resolution gaps are visible and trackable.

Resolution coverage

Every scan reports, per ecosystem, how many manifests it discovered versus how many it fully resolved. The Supply Chain page rolls this up into:

Scan coverage — the overall share of discovered manifests that resolved, across all measured repositories.
Coverage by ecosystem — resolved-manifest share for each ecosystem, so you can spot a uniformly weak ecosystem (e.g. “no Gradle lockfiles anywhere”).
Coverage by repository — least-covered repositories first.
Coverage blind spots — active warnings, split by severity (blocker / warning / info).

Repositories whose latest scan predates coverage measurement are omitted from the rollups, so an unmeasured repository is never shown as fully covered.

Resolution fidelity

Coverage also reports the fidelity ZeroPath achieved per ecosystem, the kind of resolution behind the numbers:

Deterministic — resolved from a committed lockfile (or a fully ==-pinned requirements.txt, which is treated as a lockfile-equivalent), so the inventory reflects the exact pinned versions your build is locked to.
Build-less — full transitive graph resolved directly from the manifest, no lockfile required. See Supported ecosystems for the per-ecosystem matrix.
Degraded (direct-only) — only your direct dependencies were resolved, because a required lockfile is missing. Direct-dependency findings still surface; only the transitive tail is absent. This is the state to fix.

The Resolution fidelity by ecosystem panel groups degraded ecosystems into a collapsible summary. Each ecosystem row shows its coverage tier, the number of affected manifests, and a chevron to expand the breakdown. Expanding a row lists the affected manifest files grouped by warning type, so you can see exactly which manifests need attention. For ecosystems with many affected manifests, the panel previews the first several files and points you to the full warnings table below for the rest.

Coverage warnings

Manifests that couldn’t be fully analyzed are flagged with a specific warning, so you can see exactly which part of the graph may be incomplete and why. You can click any warning row to expand it and see the full warning message, type, repository, and file path inline. Filter the warnings list by severity, type, or repository, and export a coverage report (CSV) for tracking.

Warning	What it means	What to do
Transitive dependencies unresolved	Direct dependencies resolved, but their transitive packages couldn’t be — almost always a missing lockfile. Direct findings still surface.	Commit the ecosystem’s lockfile (see below).
Missing lockfile	An ecosystem that requires a committed lockfile was found without one — most often Ruby or PHP, though JavaScript and Go manifests can also raise it when scanned without their lockfile.	Commit the ecosystem’s lockfile — `Gemfile.lock`, `composer.lock`, `package-lock.json`/`yarn.lock`/`pnpm-lock.yaml`, or `go.sum` (see below).
Dependency resolution failed	A manifest couldn’t be resolved at all (e.g. a Maven POM whose parent is unreachable). Direct-dependency findings are still preserved; only the transitive tail is affected.	Fix the manifest/parent reference, commit a lockfile, or re-scan if it was transient.
Dependency resolution failed (infrastructure)	A manifest couldn’t be resolved because of a transient infrastructure issue during the scan — not a problem with your project. Direct-dependency findings are preserved.	No action needed; the issue is usually transient and the next scan will re-check.
Zero dependencies anomaly	A manifest resolved zero packages despite substantial code nearby — a likely silent resolution failure. (Full scans only.)	Check the manifest is valid and committed; re-scan.
Vulnerability lookup failed	The vulnerability advisory data couldn’t be reached after retries, so a package’s status is unknown for this scan.	Usually transient; the next scan re-checks.
Exploit intelligence unavailable	The KEV and EPSS exploit-intelligence feeds were unavailable at scan time.	Usually transient; affects prioritization signal only.
License lookup failed	License enrichment couldn’t be reached after retries.	Usually transient; the next scan re-enriches.

The first three warnings concern dependency resolution and clear when you commit a lockfile or fix the manifest. The infrastructure variant of dependency resolution failure requires no action on your part — it is a transient platform-side issue that resolves on the next scan. A zero dependencies anomaly is an advisory signal to re-check and re-scan, not necessarily a lockfile fix. The last three are transient data-source warnings that generally clear on the next scan on their own.

Why findings don’t vanish on a failed scan

When a manifest can’t be resolved during a scan, ZeroPath carries forward the existing SCA findings for it instead of marking them resolved. This keeps a confirmed vulnerability from silently disappearing because of a transient resolution failure. A finding is auto-resolved only when its manifest was successfully analyzed and the vulnerability is genuinely gone.

Generate lockfiles before scanning

Closing a Transitive dependencies unresolved or Missing lockfile warning almost always means committing the lockfile for that ecosystem. The commands below produce the file ZeroPath looks for:

# Go — commit go.sum
go mod tidy

# Python (Pipenv / Poetry / uv) — commit a lockfile, or fully pin requirements.txt
pipenv lock          # Pipfile.lock
poetry lock          # poetry.lock
uv lock              # uv.lock

# Gradle — commit gradle.lockfile (Gradle dependency locking)
./gradlew dependencies --write-locks

# SBT — commit build.sbt.lock (sbt-dependency-lock plugin)
sbt dependencyLock

# NuGet — commit packages.lock.json (NuGet 4.9+)
dotnet restore --use-lock-file --force-evaluate

# Cargo — commit Cargo.lock
cargo generate-lockfile

# Ruby — commit Gemfile.lock
bundle lock

# PHP — commit composer.lock
composer install

# Elixir — commit mix.lock
mix deps.get

# Dart / Flutter — commit pubspec.lock
flutter pub get      # or: dart pub get

# Swift — commit Package.resolved
swift package resolve

For npm/Yarn/pnpm, Maven, and a fully ==-pinned requirements.txt (which ZeroPath treats as a lockfile-equivalent for deterministic resolution), no lockfile is required for full coverage — see Supported ecosystems.

The ZeroPath Agent platform includes a Coverage Autopilot playbook that reads your recorded coverage warnings after each scan, posts per-manifest guidance, and can open lockfile-generating pull requests.

Operational notes

Deterministic output

Inventories, alerts, and SBOMs are generated from the same sorted dataset, so diffs and reviews stay stable scan to scan.

Historical snapshots

Every scan captures a point-in-time inventory, enabling scan-to-scan diffs, SBOM exports, and retroactive investigations.

Exposure dating

SCA captures the earliest git commit that introduced an affected manifest entry, so you can see how long a vulnerability has lived in your history.

Automatic recovery

Scans resume after interruptions, repeated failures are throttled, stale jobs are cleaned up, and completed inventories are reused where possible.

Getting Started

Scanning

SCA

Platform

Developer Tools

Integrations

Authentication

Resolution coverage

Resolution fidelity

Coverage warnings

Why findings don’t vanish on a failed scan

Generate lockfiles before scanning

Operational notes

​Resolution coverage

​Resolution fidelity

​Coverage warnings

​Why findings don’t vanish on a failed scan

​Generate lockfiles before scanning

​Operational notes

Resolution coverage

Resolution fidelity

Coverage warnings

Why findings don’t vanish on a failed scan

Generate lockfiles before scanning

Operational notes