> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Coverage & Warnings
> How completely ZeroPath scanned your supply chain, and how to clear the blind spots
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](/sca/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:
```bash theme={null}
# 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](/sca/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](/sca/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.