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 Containers page under Assets in the sidebar. Enable it under Full scans → Full Scan Issue Types in
scanner settings.
How dependency data gets in
ZeroPath builds its inventory from your scans. There are three ways a dependency ends up analyzed:- Full scan with SCA
- Scheduled SCA scan
- Pull request scan
SCA is enabled in scanner settings by default, so every full scan also
parses manifests and lockfiles. Dependency findings appear on both the
Dependencies tab of 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 organization-wide view of your dependencies, and you can open it from its direct link. Its tabs are Posture, Risk, Inventory and Coverage, and they answer four questions that the deep-dive pages above map onto:- 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.
Patch PR and current issue workflow
The Patch PR filter offers Any, Not accepted, and Accepted. It tracks patch pull-request acceptance. Not accepted includes findings with no patch PR, even when their linked issue is resolved. The No accepted patch PR preset and Posture finding metrics use this same population; they are not totals of open linked issues. Each finding or grouped occurrence separately shows its Current workflow from its linked issue, such as Resolved, Reviewing, or Accepted Risk. No linked issue means the occurrence has no linked issue. Workflow unavailable means the current workflow cannot be displayed; it does not state why. Group headers have no combined workflow status. The scan and branch selection determine which occurrences appear. Their workflow is current when the page is loaded, including when viewing an older scan; it is not a historical status at that scan date. If the server returns unsupported or invalid workflow data, the page shows an error and removes the previous finding rows. 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, workspace team/tag filter, and branch selection). 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. The branch selector controls which scan generation is shown: selecting a branch shows only that branch’s latest inventory, so a scheduled scan on a feature branch does not displace the default branch’s data. 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.
CVSS scores and vulnerability classification labels are now sourced directly
from each advisory’s published data. When an advisory includes a CVSS vector
(version 3.x or 4.0), that vector is used as the authoritative score — no
model is asked to restate it. When an advisory publishes a CVSS 4.0 vector
alongside a 3.x vector, both are captured and displayed: the CVSS 4.0 score
drives prioritization, and the CVSS 3.1 panel shows the 3.x vector the
advisory actually published. Vulnerability class labels are derived from the
advisory’s CWE identifiers using MITRE’s official CWE titles, so each finding
is labeled with a descriptive weakness category (for example, “Improper Input
Validation”) rather than a raw advisory identifier.
The Supply Chain page is in Early Access, and its header shows an
Early Access badge. Its layout can change.
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 with the views Overview, Risk, Dependencies, Licenses and AI components for that one repository. Scan coverage is shown only on the Coverage tab of the Supply Chain page. The Inventory tab reads the latest finished scan on the repository’s default branch; the Branch picker lists every branch that has an inventory scan (each labeled with its last scan time), and the line beside it names the scan time and commit the page is describing. When no default branch has been recorded for a repository, the picker falls back to showing the newest scan across any branch rather than claiming a specific default. If only one branch has been scanned, the picker renders as a static label rather than a dropdown. Export SBOM produces CycloneDX, SPDX, VEX or ML-BOM for exactly that scan. The Export SBOM button opens immediately — no separate loading step is required, because the scan selection is derived from the inventory already on screen. The URL carries the selection (?tab=inventory&view=<view>&branch=<name>), so a
link to a branch’s inventory can be shared.
When the dependency graph for a particular scan generation has been retired as
part of inventory lifecycle management, the Dependency Paths section in the
package detail pane displays a notice — including the retirement date — instead
of an empty or incomplete path list. This makes it clear that the paths are
unavailable because the scan’s inventory was retired, not because the package
has no ancestors.
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. When resolution is partially
degraded — for example, a missing lockfile means direct dependencies were
resolved but the transitive closure was not — ZeroPath carries forward only
transitive findings on the affected manifest; direct-dependency findings can
still be resolved normally. A complete resolution failure carries forward all
findings on the manifest. In monorepos and workspaces where multiple
manifests share a single lockfile (for example, npm or pnpm workspaces),
the shared lockfile’s transitive closure is scanned once and attributed to
a single owner manifest — the manifest in the lockfile’s own directory, or
the shallowest one when none is co-located. This eliminates duplicate
findings that previously appeared once per workspace manifest and ensures
that all transitive advisories covered by the lockfile are reported even
when only one manifest in the workspace is resolved by the new engine.
Swift package names are now normalized to their canonical repository URL
form before advisory lookups, so packages referenced by SSH, HTTPS, or
git URLs are matched correctly against the vulnerability database. 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 Needs 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.
Scanning a container image
The Scan a container image dialog lets you submit an image for scanning without a full scan. It offers three source modes, all always visible:- Image reference — enter any public or private image reference directly
(e.g.
nginx:1.25). For private images, a collapsible Credentials for this image section lets you supply a username and token; those credentials are stored encrypted and reused on subsequent scans of the same image unless you clear them. A prompt in the same panel links organization admins directly to registry setup in Integrations so saved credentials can be used instead. - Connected registry — browse repositories and tags from a registry connection your organization has already configured. If no connections exist yet, the panel guides admins to add one in Settings → Integrations; members without admin access see instructions to ask an admin. If connections cannot be loaded due to a transient error, an inline retry button is shown.
- Upload archive — scan a
docker savetarball for images that cannot be pulled from any 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.