Skip to main content

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

Issue Validation

The ZeroPath SCA engine scores each vulnerable package, adds severity/impact context, and produces remediation notes (upgrade target, risk summary, exploit rationale).
7

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

Whenever you scan a repository, ZeroPath analyzes manifests and lockfiles, flags vulnerable packages, and surfaces dependency issues alongside your other findings.

​
Inventory & License Coverage

package-lock, requirements, go.mod, pom.xml, Podfile, Cargo.lock, and other manifests are deduplicated and versioned per scan.
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.
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.

​
Auto-remediation & Alerting

  • 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.
  • Score-based gating – each PR setting has its own minimum score, so critical CVEs can auto-remediate immediately while lower-risk fixes stay manual.
  • CVE alert toggle – enableCVEAlerting on the associated schedule lets you receive proactive notifications (email, Slack, or webhooks) whenever ZeroPath detects a new vulnerability in the packages tracked by that config.
  • 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.

​
Ecosystem Coverage

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

npm / Yarn

PyPI

Go modules

Maven / Gradle

https://mintcdn.com/zeropath/m2g7S38Ier9Tpvr-/icons/csharp.svg?fit=max&auto=format&n=m2g7S38Ier9Tpvr-&q=85&s=45d37f047f48e568c92b00a0383c8899

NuGet

https://mintcdn.com/zeropath/m2g7S38Ier9Tpvr-/icons/ruby.svg?fit=max&auto=format&n=m2g7S38Ier9Tpvr-&q=85&s=4c97571ab4bfc1ed7c4c714fe08840fe

RubyGems

crates.io (Cargo)

Packagist / Composer

https://mintcdn.com/zeropath/m2g7S38Ier9Tpvr-/icons/elixir.svg?fit=max&auto=format&n=m2g7S38Ier9Tpvr-&q=85&s=3805bb68956761932dcc30e616bde377

Hex (Elixir)

https://mintcdn.com/zeropath/m2g7S38Ier9Tpvr-/icons/dart.svg?fit=max&auto=format&n=m2g7S38Ier9Tpvr-&q=85&s=a91cacb3b1ec62c3d2a66bad55f5647d

Pub (Dart/Flutter)

Swift / CocoaPods

CRAN / Hackage

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.

​
Lockfile Requirement

ZeroPath requires lockfiles for accurate dependency analysis. Without a lockfile, ZeroPath can only parse version ranges from your manifest (e.g., ^1.2.3 in package.json or >=2.0.0 in requirements.txt), which 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.
Generate lockfiles before scanning to ensure ZeroPath captures your full dependency graph: 
# npm / Yarn
npm install          # creates package-lock.json
yarn install         # creates yarn.lock

# Python
pip freeze > requirements.txt           # if using pip directly
pipenv lock                             # creates Pipfile.lock
poetry lock                             # creates poetry.lock
uv lock                                 # creates uv.lock

# Go
go mod tidy                             # updates go.sum

# Maven
mvn dependency:tree                     # validates your pom.xml dependencies

# Gradle
./gradlew dependencies --write-locks   # creates gradle.lockfile

# Ruby
bundle lock                             # creates Gemfile.lock

# Rust
cargo build                             # creates Cargo.lock

# PHP
composer install                        # creates composer.lock

# Elixir
mix deps.get                            # creates mix.lock

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

# Swift
swift package resolve                   # creates Package.resolved

# CocoaPods
pod install                             # creates Podfile.lock
Commit these lockfiles to version control so every scan analyzes the exact dependency versions your application uses.

​
Adoption Checklist

1

Confirm SCA Is Enabled

Repository scanner settings include SCA by default; keep it enabled so every code 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.