Skip to main content

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.

​
How It Works

ZeroPath’s Software Composition Analysis (SCA) continuously analyzes your dependencies to understand your dependency graph, enrich it with application context, and keep inventories fresh:
  • Automated scanning runs whenever you push code or on a schedule you configure. Each scan parses manifests and lockfiles, builds the dependency graph, maps applications, and validates vulnerable packages with AI.
  • Scheduled inventory builder honors cron expressions you configure for each repository/tag/org. It only stages work when a branch’s head commit changes, so recurring scans track real code changes instead of reprocessing identical data.
  • Reporting layer converts any SCA inventory into CycloneDX, SPDX, or VEX artifacts on demand (see SBOM Exports). You can export SBOMs from any repository with SCA data, whether that data came from a dedicated SCA scan or a full scan with SCA enabled. Because SBOMs are generated from the same canonical inventory, exports match what the UI shows developers.

​
End-to-end Flow

1

Repository Selection

Choose a repo/branch (or rely on the default) and ensure SCA is enabled in its scanner settings.
2

Checkout & Normalization

The SCA pipeline clones the repo, pins the commit, and normalizes paths so results stay consistent across environments.
3

Application Discovery

An AI-assisted analyzer maps services/modules (e.g., /apps/payments) so each dependency can be tied back to its owning surface area.
4

Dependency Graphing

Manifests and lockfiles are parsed to build a graph containing direct and transitive packages, version ranges, dependency paths, and license signals. When a lockfile resolves dependencies declared in a manifest, findings link back to the original manifest file and line number rather than the lockfile, so you can navigate directly to where the dependency was declared.
5

License Enrichment

ZeroPath augments manifest-declared licenses with external data (e.g., deps.dev) and records the final SPDX-style license sets per package.
6

Reachability Analysis

For each vulnerable dependency, ZeroPath determines whether the vulnerable code paths are actually reachable in your application. This goes beyond checking if a package is imported — it analyzes whether the specific vulnerable functions or methods are called and whether user input can reach them. Transitive dependencies are triaged by an AI guard that evaluates whether the dependency chain exposes the vulnerability before committing investigation budget.Reachability status defaults to “unknown” until analysis completes, so you will never see a package incorrectly marked as reachable before ZeroPath has verified it. Each package receives a package-level reachability status indicating whether it is reachable, not reachable, or not yet tested, along with a summary explaining the assessment. You can view this status and summary in the package details panel, and filter the Inventory and Issues views by package reachability.When a vulnerability is reachable but depends on conditions that cannot be fully verified from code alone, ZeroPath surfaces preconditions — for example, “Vulnerable method is only called with server-controlled input” or “Requires specific runtime configuration to trigger.” These preconditions help you assess real-world exploitability and prioritize remediation accordingly.
7

Issue Validation

The ZeroPath SCA engine scores each vulnerable package, adds severity/impact context, and produces remediation notes (upgrade target, risk summary, exploit rationale). When a linked SAST finding exists, the AI-derived score from that finding is used to determine severity, ensuring consistency between the Issues and Supply Chain pages.
8

Inventory + Findings

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

​
Running Scans

When SCA is enabled in your scanner settings, every full scan also analyzes manifests and lockfiles. Dependency findings from these scans appear on both the Issues page and the Supply Chain page, alongside your SAST and other finding types.

​
Where SCA Findings Appear

SCA vulnerabilities can come from two different scan sources, and understanding where each appears helps avoid confusion:
The Issues page shows vulnerabilities found during full scans. When SCA is enabled in your scanner settings, full scans analyze dependencies alongside your source code. SCA findings from these scans appear as issues in the global Issues list, mixed in with SAST and other finding types.What you’ll see: SCA vulnerabilities discovered during full scans only.
The Supply Chain page may show more SCA findings than the Issues page. This is expected — SCA scans run on their own schedule and may detect vulnerabilities that haven’t been picked up by a full scan yet. If you want the most comprehensive view of your dependency security posture, use the Supply Chain page.

​
Two Sources of SCA Data

SourceTriggerWhere Results Appear
Full scan with SCA enabledRuns as part of a full scan when SCA is enabled in scanner settingsIssues page + Supply Chain page
SCA scanRuns on a schedule you configure (daily, weekly, etc.), independent of full scansSupply Chain page only
To ensure you catch vulnerabilities between full scans, enable a scheduled SCA scan. This keeps your dependency inventory fresh even when engineers aren’t actively pushing code.

​
Filtering & Sorting

The Issues and Inventory tabs on the Supply Chain page offer several filters to help you focus on what matters:
  • Severity — filter by Critical, High, Medium, Low, or Info severity levels.
  • Ecosystem — narrow results to specific package ecosystems (e.g., npm, PyPI, Go modules, Maven). The available ecosystems update dynamically based on your repository selection.
  • Reachability (vulnerability-level) — filter issues by exploitability status: Likely Exploitable, Needs Review, or Likely Non-Exploitable.
  • Package Reachability — filter by whether the package itself is reachable, not reachable, or not yet tested in your application.
  • Source Type — distinguish between dependencies declared in source manifests and those embedded in compiled assets (JARs, WARs, Python wheels).
  • Transitivity — show only direct dependencies, only transitive dependencies, or both.
  • Advisory search — search for vulnerabilities by advisory title, CVE identifier (e.g., CVE-2024-1234), or GHSA identifier (e.g., GHSA-xxxx-xxxx-xxxx).
On the Issues tab, a sort dropdown is always available. When grouping is active, you can sort by highest severity or most findings per group. When grouping is off, you can sort by highest severity or newest. All filters are reflected in the URL, so you can bookmark or share a filtered view with teammates.

​
Inventory & License Coverage

package-lock, requirements, go.mod, pom.xml, Podfile, Cargo.lock, and other manifests are deduplicated and versioned per scan. Maven parent POMs that declare dependencies exclusively in <dependencyManagement> (common in multi-module projects) are also captured, so version pins defined in a parent POM appear in your inventory even when the parent has no direct <dependencies> section.
Each dependency includes its role (declared vs inherited) plus the chain of packages that led to it, making blast-radius analysis simple.
ZeroPath normalizes manifest-declared terms, enriches them with authoritative sources, and records the final SPDX expression per package, enabling legal/compliance workflows.
The UI exposes filters for high/medium/low-risk license groups, plus quick toggles for common families (GPL, LGPL, AGPL, Apache, MIT, BSD, Proprietary). Compliance teams can combine these filters with allow/deny lists to focus on the licenses that matter most.
Search for any license identifier (e.g., GPL-3.0-only, SSPL, Polyform) to instantly highlight the packages and applications affected, making it easy to enforce custom policies.
Binary artifacts committed to your repository — such as JARs, WARs, and Python wheels — are scanned for embedded packages. These packages appear in your inventory alongside source-declared dependencies, giving you visibility into vendored or pre-built libraries that would otherwise be invisible to manifest-only analysis.You can filter the inventory and dependency views by compiled vs. source-declared manifests using the Source Type filter, making it easy to isolate findings from binary artifacts. Compiled manifests are visually distinguished with a badge showing the asset type (e.g., JAR, WAR).
Dependency findings are linked to the applications/services discovered in your repo so teams immediately know who owns remediation.
Every SCA scan captures a point-in-time inventory, enabling diffs, SBOM exports, and retroactive investigations.

​
CVE Alerting

CVE alerting proactively notifies you when new vulnerabilities are discovered in your tracked packages — without waiting for a scan to run.
  • Enable per repository – toggle enableCVEAlerting in your repository’s scanner settings to start receiving alerts.
  • Alerts tab – all CVE alerts appear on the Alerts tab of the Supply Chain page, where you can filter by repository, severity, ecosystem, exploitability, and status (new / acknowledged).
  • Affected repositories – each alert displays the repositories where the vulnerable package was detected. When an alert affects multiple repositories, the first repository is shown inline with a count badge (e.g., “+3”) indicating additional repositories. Expand the alert row to see the full list of affected repositories.
  • Exploitability breakdown – each alert shows reachability counts (Likely Exploitable, Needs Review, Likely Non-Exploitable) so you can prioritize triage. Exploitability is assessed by AI; for critical supply chain issues, human review is recommended.
  • Drill into findings – click an exploitability count on an alert to jump directly to the Issues tab filtered to that advisory and reachability status.
CVE alerting must be explicitly enabled in scanner settings for each repository. Repositories without alerting enabled will not generate alerts, even if SCA scanning is active.

​
Auto-remediation

  • Direct dependency PRs – opt into automatic upgrade pull requests for direct dependencies by enabling autoCreateDirectPackagePRs and defining the score threshold that must be met before a fix is proposed. ZeroPath opens the branch, applies the version bump, and links it to the original finding.
  • Transitive remediation – manage inherited dependencies separately via autoCreateTransitivePackagePRs. Use a different threshold (or disable entirely) when indirect upgrades require more review. ZeroPath walks the dependency chain to find the nearest direct parent that can be upgraded, even through multi-hop transitive chains.
  • Smarter upgrade selection – when suggesting an upgrade version, ZeroPath first looks for the nearest version with zero known CVEs. If no fully clean version exists within the same major version, it falls back to the nearest version that fixes the specific vulnerability being patched without introducing any new CVEs that don’t already affect your current version. This avoids impractical major-version jumps and ensures suggested upgrades never make your security posture worse.
  • Remediation guidance for unpatchable findings – when a vulnerability cannot be auto-patched (e.g., no safe version exists, or the fix requires architectural changes), ZeroPath provides step-by-step remediation instructions so developers know exactly what to do manually.
  • Score-based gating – each PR setting has its own minimum score, so critical CVEs can auto-remediate immediately while lower-risk fixes stay manual.
  • Per-branch targeting – every scheduled scan stores the branch it was staged for, letting you run auto-remediation and alerting on release branches without touching experimental ones.

​
Key Capabilities

Unified Findings

Dependency issues appear in the same ZeroPath findings stream as your other scan data so remediation stays in one workflow.

Precise Application Mapping

Identifies which service/module (e.g., /apps/payments) owns the vulnerable package, not just the manifest file.

Direct vs Transitive Clarity

Every issue spells out whether you declared the package yourself or pulled it in indirectly, plus the chain of packages that introduced it.

License Visibility

Inventories capture manifest-declared licenses and enrich them with external sources so legal/compliance reviews see the same data the scanners used.

Deterministic Inventories

Manifests and packages are deduplicated and sorted, producing repeatable SBOMs, audit reports, and diff views.

AI-Backed Validation

The same reasoning engine that powers ZeroPath validation explains SCA impact, suggests upgrade paths, and prioritizes issues based on severity + exploitability.

Reachability Analysis

ZeroPath determines whether vulnerable code paths are actually reachable in your application, reducing noise from vulnerabilities that are imported but never invoked.

Compiled Asset Scanning

Binary artifacts committed to your repository (JARs, WARs, Python wheels) are scanned for embedded packages, extending inventory coverage beyond source-level manifests.

​
Ecosystem Coverage

ZeroPath’s SCA analyzers recognize the following ecosystems out of the box:

npm / Yarn

PyPI

Go modules

Maven / Gradle / SBT

https://mintcdn.com/zeropath/3LQWG-DWQmf_zR2q/icons/csharp.svg?fit=max&auto=format&n=3LQWG-DWQmf_zR2q&q=85&s=a369b07fdfa85a098eef35c035d7c098

NuGet

https://mintcdn.com/zeropath/3LQWG-DWQmf_zR2q/icons/ruby.svg?fit=max&auto=format&n=3LQWG-DWQmf_zR2q&q=85&s=e98ed481966bcbb1508f8d69e680b60e

RubyGems

crates.io (Cargo)

Packagist / Composer

https://mintcdn.com/zeropath/3LQWG-DWQmf_zR2q/icons/elixir.svg?fit=max&auto=format&n=3LQWG-DWQmf_zR2q&q=85&s=1561f8905cfcc6ab231dbcb15aaf5db3

Hex (Elixir)

https://mintcdn.com/zeropath/3LQWG-DWQmf_zR2q/icons/dart.svg?fit=max&auto=format&n=3LQWG-DWQmf_zR2q&q=85&s=c3fa2a0a3350a59c4f7fcd10cbeff84b

Pub (Dart/Flutter)

Swift

Haskell (Hackage)

R (CRAN)

Each dependency record tracks whether ZeroPath saw it declared directly or discovered it through the transitive graph, enabling policies that treat vendor libraries differently from first-party choices.
Go modules: ZeroPath automatically handles the +incompatible version suffix used by pre-module Go packages (major version 2 and above). Vulnerabilities in packages tagged with versions like v3.2.0+incompatible in your go.sum or go.mod are correctly matched to known advisories, so you get accurate coverage without manual intervention. Go pseudo-versions (e.g., v0.0.0-20231215084216-abcdef123456) are also handled correctly — they are excluded from version comparisons to prevent false negatives when used as “fixed” markers in advisories.

​
Lockfile Handling

Lockfiles give ZeroPath the most accurate picture of your dependency graph because they pin every transitive package to a single resolved version. Where a lockfile is present, ZeroPath uses it directly — there is no extra resolution step to misbehave, the inventory matches what your tooling installs, and SBOM exports are complete. For ecosystems whose package manager exposes a graph-resolution command, ZeroPath automatically resolves the full transitive tree when no lockfile is committed, so you still get full transitive coverage for these manifests. The remaining ecosystems — npm/Yarn/pnpm, Go, Ruby, PHP, Elixir, Dart/Flutter, Swift — require a lockfile to surface transitives.
EcosystemWithout a lockfile
Maven (pom.xml)Resolves transitives via mvn dependency:list
Gradle (build.gradle, build.gradle.kts)Resolves transitives via gradle :module:dependencies
Python (requirements.txt, pyproject.toml)Resolves transitives via pip install --dry-run --report
NuGet (*.csproj, *.fsproj)Resolves transitives via dotnet restore && dotnet list package
Cargo (Cargo.toml)Resolves transitives via cargo metadata
SBT (build.sbt)Resolves transitives via sbt dependencyList
npm / Yarn / pnpmDirect deps only — commit package-lock.json, yarn.lock, or pnpm-lock.yaml for transitive coverage
Go modulesDirect deps only — go.sum is auto-generated by go mod tidy
RubyDirect deps only — commit Gemfile.lock
PHPDirect deps only — commit composer.lock
ElixirDirect deps only — commit mix.lock
Dart / FlutterDirect deps only — commit pubspec.lock
SwiftDirect deps only — commit Package.resolved
For ecosystems where ZeroPath cannot resolve transitives without a lockfile, missing a lockfile means:
  • Transitive dependencies are invisible — ZeroPath won’t see any packages your direct dependencies pull in.
  • Version resolution is ambiguous — range specifiers don’t tell us which exact version is installed, so vulnerability matching becomes unreliable.
  • Incomplete SBOM exports — CycloneDX and SPDX artifacts will be missing most of your actual dependency tree.
For these ecosystems, commit your lockfile to version control to ensure full transitive coverage.
Generate lockfiles before scanning for the ecosystems that need them. The commands below produce the lockfiles ZeroPath looks for: 
# npm / Yarn / pnpm — required for transitive coverage
npm install          # creates package-lock.json
yarn install         # creates yarn.lock
pnpm install         # creates pnpm-lock.yaml

# Go — required (auto-generated alongside go.mod)
go mod tidy          # updates go.sum

# Ruby — required
bundle lock          # creates Gemfile.lock

# PHP — required
composer install     # creates composer.lock

# Elixir — required
mix deps.get         # creates mix.lock

# Dart / Flutter — required
flutter pub get      # creates pubspec.lock
dart pub get         # creates pubspec.lock

# Swift — required
swift package resolve # creates Package.resolved
The ecosystems below resolve transitives automatically when no lockfile is present. Committing a lockfile is still a good idea — it makes scans deterministic and faster — but it is not required for accurate vulnerability matching: 
# Python (pip / Pipenv / Poetry / uv) — optional
pipenv lock          # creates Pipfile.lock
poetry lock          # creates poetry.lock
uv lock              # creates uv.lock

# Maven — optional (third-party plugins; rare in practice)
# .mvn/maven.lockfile via the maven-lockfile plugin, or
# .flattened-pom.xml.lock via the flatten-maven-plugin

# Gradle — optional (Gradle's dependency-locking feature)
./gradlew dependencies --write-locks  # creates gradle.lockfile

# SBT — optional
sbt dependencyLock   # creates build.sbt.lock (sbt-dependency-lock plugin)

# NuGet — optional (NuGet 4.9+)
dotnet restore --use-lock-file --force-evaluate  # creates packages.lock.json

# Cargo — optional for libraries; auto-created for binary crates
cargo generate-lockfile  # creates Cargo.lock
For ecosystems where a lockfile is required, commit it to version control so every scan analyzes the exact dependency versions your application uses.

​
Python Manifest Formats

ZeroPath supports all common Python dependency declaration formats:
  • requirements.txt — standard pip format
  • Pipfile — Pipenv format (with [packages] and [dev-packages] sections)
  • pyproject.toml (Poetry) — [tool.poetry.dependencies], [tool.poetry.dev-dependencies], and Poetry 1.2+ group dependencies ([tool.poetry.group.<name>.dependencies])
  • pyproject.toml (PEP 621) — the [project] table used by uv, hatch, flit, setuptools, pdm, and other modern build backends. Both dependencies and optional-dependencies are parsed.

​
SBT (Scala) Dependency Resolution

ZeroPath supports transitive dependency analysis for Scala projects using SBT. If your project uses a lockfile plugin, ZeroPath parses it automatically: For SBT projects that do not have a lockfile, ZeroPath automatically runs sbt dependencyList to resolve the full dependency tree, including all transitive dependencies. This means you get complete dependency coverage for Scala projects even without committing a lockfile.

​
Maven Dependency Resolution

ZeroPath supports transitive dependency analysis for Maven projects (pom.xml). If your repository commits one of the third-party Maven lockfiles, ZeroPath parses it automatically: For projects that do not commit a lockfile (the common case for Maven), ZeroPath automatically runs mvn dependency:list to enumerate the resolved dependency set. Multi-module reactor builds are handled by appending each module’s output, so every submodule’s transitives are captured. Classifier-bearing artifacts (e.g., Netty’s platform-specific transports, Bouncy Castle test JARs) are correctly attributed to the right (group:artifact, version) pair.

​
Gradle Dependency Resolution

ZeroPath supports transitive dependency analysis for Gradle projects (build.gradle, build.gradle.kts). If your repository commits Gradle’s opt-in dependency-locking output, ZeroPath parses it automatically:
  • gradle.lockfile — generated by ./gradlew dependencies --write-locks when dependency locking is enabled
For projects without gradle.lockfile, ZeroPath automatically runs gradle :module:dependencies --configuration runtimeClasspath. Multi-module repositories — the dominant Gradle layout (Spring Boot multi-module, Android, etc.) where gradlew lives at the repo root and each module’s build.gradle lives in a subdirectory — are detected by walking up to the project root, so the correct submodule is targeted from the correct working directory.

​
Gradle Version Catalogs

ZeroPath automatically resolves dependencies declared using Gradle version catalogs (libs.versions.toml). When your build.gradle or build.gradle.kts references dependencies via libs.foo.bar accessors, ZeroPath locates the corresponding version catalog file and resolves the package name and version from its [libraries] section. Findings are linked back to the exact line in your build file where the dependency is referenced, so you can navigate directly to the relevant code. Supported version catalog entry formats include string shorthand ("group:artifact:version"), module references with version.ref, group/name pairs with inline or referenced versions, and dict-style version constraints (strictly, require, prefer).

​
Python (pip) Dependency Resolution

For Python projects that commit a Pipenv, Poetry, or uv lockfile (Pipfile.lock, poetry.lock, uv.lock), ZeroPath uses the lockfile directly to enumerate transitives. For requirements.txt and bare pyproject.toml manifests where no lockfile is committed, ZeroPath automatically runs pip install --dry-run --ignore-installed --report to walk the full dependency graph without installing anything. Both PEP 621 pyproject.toml and Poetry-style pyproject.toml are recognized; for Poetry projects, pip uses the project’s declared build backend to extract the dependency set.

​
NuGet Dependency Resolution

ZeroPath supports transitive dependency analysis for .NET projects (*.csproj, *.fsproj, *.vbproj). If your repository commits NuGet’s opt-in lockfile, ZeroPath parses it automatically:
  • packages.lock.json — generated by dotnet restore --use-lock-file --force-evaluate (NuGet 4.9+)
For projects without packages.lock.json (common in legacy and enterprise codebases that have not opted into lockfile mode), ZeroPath automatically runs dotnet restore followed by dotnet list package --include-transitive --format json to enumerate every top-level and transitive package across each target framework. NuGet package ids are matched case-insensitively, so packages will not be missed because of casing differences between manifest and registry.

​
Cargo (Rust) Dependency Resolution

For Rust projects that commit Cargo.lock (the default for binary crates), ZeroPath uses the lockfile directly. For library crates that do not commit Cargo.lock (cargo’s own guidance is to omit it from libraries so version resolution defers to the consumer), ZeroPath automatically runs cargo metadata --format-version 1 to resolve the full dependency graph without compiling anything. Workspace members (the project itself) are filtered out, and crates that resolve to multiple versions in the same graph (e.g., when transitives disagree on requested versions, or when a workspace uses resolver = “2”) are reported as separate (name, version) pairs so each one reaches advisory matching.

​
Adoption Checklist

1

Confirm SCA Is Enabled

Repository scanner settings include SCA by default; keep it enabled so every full scan collects dependency findings.
2

Add Recurring Coverage

Create an SCA schedule with the cadence you need (daily, weekly, etc.) so inventory snapshots stay current even when engineers aren’t running full repo scans.
3

Set Branch Preferences

Point schedules at the branches that matter (release, staging, services) so SCA always reflects the code you deploy.
4

Enable Alerting Where Needed

Flip enableCVEAlerting on schedules that should raise proactive notifications; keep it off for test repos.
5

Decide on Auto-Remediation

Turn on direct and/or transitive auto-PRs with thresholds aligned to your risk tolerance.
6

Plan SBOM Consumption

Once inventories exist, request CycloneDX/SPDX/VEX exports and wire them into procurement, compliance, or downstream tooling.
7

Route Findings

Configure notifications, dashboards, or ticketing automations so dependency issues reach the right service owners.

​
Operational Notes

  • Deterministic output – inventories, alerts, and SBOMs are generated from the same sorted dataset, which keeps diffs and reviews stable.
  • 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 production.
  • Automatic recovery – scans are resilient to interruptions and automatically resume. Repeated failures are throttled, stale jobs are cleaned up, and completed inventories are reused whenever possible.
  • Smarter CVE alerting – the alerting pipeline skips metadata-only advisory updates (such as CVSS score or reference URL changes) and only re-processes a CVE when its affected packages or version ranges actually change. A built-in circuit breaker prevents repeated failures from blocking the rest of the alert queue, and automatic retry ensures transient errors resolve on their own.
  • Cross-package advisory filtering – when an OSV advisory covers multiple packages, ZeroPath verifies that each finding actually applies to the specific package in your dependency graph before raising an alert. This eliminates false positives caused by broad multi-package advisories.