> ## 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.
# SCA Overview
> How ZeroPath discovers, inventories, and alerts on vulnerable packages
## 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
Choose a repo/branch (or rely on the default) and ensure SCA is enabled in its scanner settings.
The SCA pipeline clones the repo, pins the commit, and normalizes paths so results stay consistent across environments.
An AI-assisted analyzer maps services/modules (e.g., `/apps/payments`) so each dependency can be tied back to its owning surface area.
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.
ZeroPath augments manifest-declared licenses with external data (e.g., deps.dev) and records the final SPDX-style license sets per package.
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.
If you have configured a **threat model** or **application context** for your repository, SCA reachability analysis and transitive dependency triage incorporate that context. Out-of-scope areas, trust-zone boundaries, and assumptions you define are factored into reachability verdicts and the transitive risk guard's decisions, so dependencies in subtrees you have explicitly marked as out of scope are less likely to generate noise.
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.
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.
Configure SCA scans to run daily, weekly, or on any cron schedule — independently of full scans. These scans focus exclusively on dependency analysis and keep your inventory fresh between full scans. Results appear on the **Supply Chain** page only, which is why you may see more SCA findings there than on the Issues page.
## 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 is the dedicated SCA dashboard. It shows **all** SCA vulnerabilities, including:
* Findings from full scans (the same ones visible on the Issues page)
* Findings from **SCA scans** that run on their own schedule, independent of full scans
Each tab on the Supply Chain page draws from different data:
* **Issues** — dependency vulnerabilities from full scans and SCA scans. Each issue links directly to its advisory source (GHSA advisories link to deps.dev, CVE advisories link to the NVD vulnerability page) and displays any associated CVE identifier alongside the primary advisory ID, so you can cross-reference findings across databases.
* **Alerts** — CVE alerts for repositories with alerting enabled in scanner settings, with a Repositories column showing which repos are affected by each alert
* **Inventory** — dependencies found across all full scans with SCA enabled and SCA scans. You can filter the inventory by ecosystem, package reachability, and source type (manifest vs. compiled).
* **Licenses** — licenses detected for each manifest and package found in SCA scans
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
| Source | Trigger | Where Results Appear |
| ------------------------------ | --------------------------------------------------------------------------------- | ------------------------------- |
| **Full scan with SCA enabled** | Runs as part of a full scan when SCA is enabled in scanner settings | Issues page + Supply Chain page |
| **SCA scan** | Runs on a schedule you configure (daily, weekly, etc.), independent of full scans | Supply 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 `` (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 `` 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
Dependency issues appear in the same ZeroPath findings stream as your other scan data so remediation stays in one workflow.
Identifies which service/module (e.g., `/apps/payments`) owns the vulnerable package, not just the manifest file.
Every issue spells out whether you declared the package yourself or pulled it in indirectly, plus the chain of packages that introduced it.
Inventories capture manifest-declared licenses and enrich them with external sources so legal/compliance reviews see the same data the scanners used.
Manifests and packages are deduplicated and sorted, producing repeatable SBOMs, audit reports, and diff views.
The same reasoning engine that powers ZeroPath validation explains SCA impact, suggests upgrade paths, and prioritizes issues based on severity + exploitability.
ZeroPath determines whether vulnerable code paths are actually reachable in your application, reducing noise from vulnerabilities that are imported but never invoked.
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:
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.
| Ecosystem | Without 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 / pnpm | **Direct deps only** — commit `package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml` for transitive coverage |
| Go modules | **Direct deps only** — `go.sum` is auto-generated by `go mod tidy` |
| Ruby | **Direct deps only** — commit `Gemfile.lock` |
| PHP | **Direct deps only** — commit `composer.lock` |
| Elixir | **Direct deps only** — commit `mix.lock` |
| Dart / Flutter | **Direct deps only** — commit `pubspec.lock` |
| Swift | **Direct 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
Generate lockfiles for the ecosystems that need them. The commands below produce the lockfiles ZeroPath looks for:
```bash theme={null}
# 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:
```bash theme={null}
# 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..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:
* **`build.sbt.lock`** — generated by the [sbt-dependency-lock](https://github.com/stringbean/sbt-dependency-lock) plugin
* **`lock.sbt`** — generated by the [sbt-lock](https://github.com/tkawachi/sbt-lock) plugin
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:
* **`.mvn/maven.lockfile`** / **`maven.lockfile`** — generated by the [maven-lockfile](https://github.com/chains-project/maven-lockfile) plugin
* **`.flattened-pom.xml.lock`** — generated by the [flatten-maven-plugin](https://www.mojohaus.org/flatten-maven-plugin/)
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](https://docs.gradle.org/current/userguide/dependency_locking.html) 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
Repository scanner settings include SCA by default; keep it enabled so every full scan collects dependency findings.
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.
Point schedules at the branches that matter (release, staging, services) so SCA always reflects the code you deploy.
Flip `enableCVEAlerting` on schedules that should raise proactive notifications; keep it off for test repos.
Turn on direct and/or transitive auto-PRs with thresholds aligned to your risk tolerance.
Once inventories exist, request CycloneDX/SPDX/VEX exports and wire them into procurement, compliance, or downstream tooling.
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.