Skip to main content
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, 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. This is the state to fix.

​
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. Filter the warnings list by severity, type, or repository, and export a coverage report (CSV) for tracking.
WarningWhat it meansWhat to do
Transitive dependencies unresolvedDirect 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 lockfileAn 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 failedA manifest couldn’t be resolved at all (e.g. a Maven POM whose parent is unreachable). Sometimes transient.Fix the manifest/parent reference, or re-scan if it was transient.
Zero dependencies anomalyA 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 failedThe 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 unavailableThe KEV and EPSS exploit-intelligence feeds were unavailable at scan time.Usually transient; affects prioritization signal only.
License lookup failedLicense 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. 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, 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

Inventories, alerts, and SBOMs are generated from the same sorted dataset, so diffs and reviews stay stable scan to scan.
Every scan captures a point-in-time inventory, enabling scan-to-scan diffs, SBOM exports, and retroactive investigations.
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.
Scans resume after interruptions, repeated failures are throttled, stale jobs are cleaned up, and completed inventories are reused where possible.