Skip to main content
ZeroPath’s Software Composition Analysis (SCA) maps every dependency your code pulls in — direct and transitive — matches it against known vulnerabilities and license data, and assesses whether the vulnerable code is actually reachable in your application — invoked, not just imported. Reachability and exploitability are AI-assisted signals that help you triage the findings most likely to matter first. Dependency findings, license exposure, an AI component inventory, and scan-coverage health all live together on the Supply Chain page. This overview explains the moving parts at a high level and points you to a dedicated page for each capability.

​
What ZeroPath SCA gives you

Supported ecosystems & coverage

Dependency resolution across 13 ecosystems, and exactly what each one needs for full transitive coverage.

Reachability & exploit signals

Whether the vulnerable code path is really invoked, plus CISA KEV and FIRST EPSS exploit intelligence for prioritization.

Coverage & warnings

How completely your supply chain was scanned, and how to clear remaining gaps.

License compliance

Per-package SPDX licenses, enriched and grouped into informational obligation categories, so legal and compliance reviews start from the same data the scanners used.

AI Inventory (AI-BOM)

A bill of materials for the AI in your codebase: SDKs, agent frameworks, MCP servers, model files, and agent configs.

Auto-remediation & alerts

Automatic upgrade PRs with safe-version selection, plus proactive CVE alerts for packages you already depend on.

Blast radius

Which call sites in your code an upgrade actually touches, classified by risk, attached to each patch.

SBOM exports

CycloneDX, SPDX, VEX, and ML-BOM artifacts generated from the same inventory the UI shows.

Container scanning

Scan built container images for OS-package and bundled-dependency vulnerabilities, with per-layer findings, base-image upgrade guidance, and a dedicated dashboard.

​
How dependency data gets in

ZeroPath builds its inventory from your scans. There are three ways a dependency ends up analyzed:
SCA is enabled in scanner settings by default, so every full scan also parses manifests and lockfiles. Dependency findings appear on both the Issues page and the Supply Chain page, alongside your SAST and other results.
The Supply Chain page can show more dependency findings than the Issues page. That is expected: scheduled SCA scans run on their own cadence and may surface issues a full scan hasn’t picked up yet. For the most complete view of your dependency posture, use the Supply Chain page.

​
The Supply Chain page

The Supply Chain page is the dedicated SCA dashboard. It is organized around four questions, and the deep-dive pages above map onto them:
  • Where do I stand? — a posture summary: scan coverage, exploitability, and what to fix first.
  • What should I fix? — dependency findings, viewable as individual occurrences or grouped per CVE across every affected repository. Filter by severity, ecosystem, and reachability. When a Wiz integration is connected, you can also filter by cloud exposure to prioritize packages in internet-facing applications.
  • What’s in my supply chain? — the inventory: dependencies, licenses, and AI components. Transitive packages show a dependency-path icon so you can see which parent dependencies pull them in.
  • How complete was the scan? — coverage: which manifests resolved, which didn’t, and the warnings that explain any gaps. Secrets scan incomplete notices are surfaced separately and no longer contribute to the SCA warnings banner count.
Repository scope selections are saved in the URL so they survive tab switches and can be shared as deep links. When you switch organizations, any scope from the previous organization is automatically cleared so the page does not start with stale filters that resolve to nothing. Data such as SCA settings status, coverage metrics, and warning counts is always tied to the exact population on screen (organization, repository scope, and workspace team/tag filter). When you change any of these dimensions, stale data from the previous scope is cleared and refreshed, so counts and badges never show numbers from a population that is no longer displayed. Each finding is enriched with real-world exploit intelligence: CISA KEV (known-exploited) and FIRST EPSS (exploit probability), so you can prioritize what is actively being exploited. The issue detail API response now includes these signals directly on each SCA vulnerability: isKnownExploited, kevDateAdded, kevKnownRansomware, epssScore, and epssPercentile — so integrations and automations can consume exploit intelligence without a separate lookup. Findings link to their upstream advisory and show the associated CVE. When an advisory carries neither a CVSS score nor a recognized severity label, the finding’s severity is left empty rather than assigned an artificial default. Findings with unknown severity are ranked below scored findings in prioritization, so they do not displace advisories with real severity data. When a dependency finding is linked to a SAST finding, that finding’s score sets its severity, so the Issues and Supply Chain pages stay consistent.
The Supply Chain dashboard is in Early Access and its layout is still evolving; this guide refers to capabilities rather than specific tab names.
For very large organizations, Supply Chain queries that scan an extremely broad scope may time out on the server and show a message directing you to narrow your scope using the repository selector, team, or tag controls at the top of the page. Narrowing the scope reloads the page automatically. When the findings query times out, follow-on queries (the total count and the posture preset badges) are skipped automatically, since they cover the same population and would reach the same conclusion. Once you narrow the scope and findings load successfully, those follow-on queries resume. You can always retry by changing the scope or navigating back — each attempt is allowed to run again. Findings load first for faster time-to-screen; the total count appears in the paginator once it is ready. If the total cannot be computed, pagination still works — you can page forward and backward normally.

​
Per-repository Inventory tab

Every repository’s detail page has an Inventory tab that shows the same Supply Chain views — Overview (posture and KEV exposure), Risk, Dependencies, Licenses and AI components — for that one repository. The tab reads the latest finished scan on the repository’s default branch; the Branch picker lists every branch that has an inventory scan, and the line beside it names the scan time and commit the page is describing. Export SBOM produces CycloneDX, SPDX, VEX or ML-BOM for exactly that scan. The URL carries the selection (?tab=inventory&view=<view>&branch=<name>), so a link to a branch’s inventory can be shared.

​
End to end, per scan

1

Checkout

ZeroPath clones the repo and pins the commit so results are consistent across scans.
2

Application discovery

An AI-assisted analyzer maps your services and modules (e.g. /apps/payments) so each dependency is attributed to the application that uses it.
3

Dependency resolution

Manifests and lockfiles are parsed into a graph of direct and transitive packages, with versions, dependency paths, and license signals. Maven projects now include full transitive dependency-path chains, so you can trace how a vulnerable transitive package enters your build through its parent dependencies. A fully ==-pinned requirements.txt is treated as a lockfile-equivalent and resolves deterministically without requiring a separate lockfile. When a package-manager resolution refines a version that the static manifest parser previously recorded, the stale version is retracted so you no longer see phantom duplicate findings for the same package at an outdated version. Maven and Gradle resolution includes protection against registry rate limiting: the scanner fetches each POM coordinate at most once per scan and uses a fleet-wide request budget to pace egress. If the registry begins refusing requests for an IP, the scanner halts JVM resolution immediately and surfaces a transient warning on the affected manifests rather than silently returning an incomplete dependency tree. Rerunning the scan once the condition clears restores full coverage; no changes to your manifests are needed. See Supported ecosystems for what each ecosystem needs.
4

License enrichment

Manifest-declared licenses are enriched and recorded as a normalized SPDX license string per package. See License compliance.
5

Reachability analysis

For each vulnerable package, ZeroPath assesses whether the vulnerable code path is actually reachable. Full scans use a deeper reasoning model for exploitability assessment, improving accuracy on complex multi-step vulnerability investigations. When an assessment cannot complete, the finding is surfaced as Pending Review rather than silently dropped, so no investigated advisory goes unreported. See Reachability.
6

Inventory, findings & exports

The normalized inventory, application map, and validated findings are stored once, so the UI, APIs, SBOM exports, and alerts all draw from a single source of truth.

​
Private package registries

If your organization hosts packages on a private npm or Maven registry (for example, a corporate Artifactory or Nexus instance), you can connect it so ZeroPath resolves your internal dependencies during SCA scans. Once a registry connection is saved, ZeroPath authenticates against it when resolving lockfile-less manifests for that ecosystem. Both basic (username + password/token) and bearer token auth modes are supported. Resolution falls back to the public registry configuration when no private registry is configured for an ecosystem, so existing behavior is unchanged for ecosystems with no connection.
Maven resolution routes ZeroPath’s own POM and BOM fetcher through the private registry. Trivy’s own transitive POM-walk uses its built-in fetcher and does not use the private registry credential; packages whose metadata exists only on the private registry may still resolve with degraded transitive coverage on that path. ZeroPath’s resolver handles parent chains and imported BOMs through the configured private registry.

​
Getting started

1

Keep SCA enabled

Scanner settings include SCA by default — leave it on so every full scan collects dependency findings.
2

Add a recurring SCA scan

Schedule a dependency-only scan (daily/weekly) so your inventory stays current between full scans, and point it at the branches you actually deploy.
3

Close coverage gaps

Check the coverage view and commit any missing lockfiles so transitive dependencies are fully resolved.
4

Connect private registries (if applicable)

If your organization uses a private npm or Maven registry, add a registry connection in organization settings so SCA scans can resolve internal packages.
5

Turn on remediation where it fits

Enable auto-remediation and CVE alerting with thresholds aligned to your risk tolerance.
6

Wire up SBOMs

Once inventories exist, generate CycloneDX/SPDX/VEX/ML-BOM exports for procurement, compliance, or downstream tooling.