> ## 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).

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

### 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](/sca/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.

| 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). Sometimes transient.                                                                               | Fix the manifest/parent reference, or re-scan if it was transient.                                                                            |
| **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.                                                                                                 |

<Info>
  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.
</Info>

### 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`**,
no lockfile is required for full coverage — see [Supported ecosystems](/sca/ecosystems).

<Tip>
  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.
</Tip>

## Operational notes

<AccordionGroup>
  <Accordion title="Deterministic output">
    Inventories, alerts, and SBOMs are generated from the same sorted dataset, so
    diffs and reviews stay stable scan to scan.
  </Accordion>

  <Accordion title="Historical snapshots">
    Every scan captures a point-in-time inventory, enabling scan-to-scan diffs,
    [SBOM exports](/sca/sbom-exports), and retroactive investigations.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="Automatic recovery">
    Scans resume after interruptions, repeated failures are throttled, stale jobs
    are cleaned up, and completed inventories are reused where possible.
  </Accordion>
</AccordionGroup>