SCA Overview

​

How It Works

• 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

​

Running Scans

​

Where SCA Findings Appear

​

Two Sources of SCA Data

​

Filtering & Sorting

• 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: Confirmed Exploitable, Needs Review, or No Path Detected.
• 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.

​

Inventory & License Coverage

​

CVE Alerting

• 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).
• Exploitability breakdown – each alert shows reachability counts (Confirmed Exploitable, Needs Review, No Path Detected) 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.

​

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.
• 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

​

Ecosystem Coverage

npm / Yarn

PyPI

Go modules

Maven / Gradle

NuGet

RubyGems

crates.io (Cargo)

Packagist / Composer

Hex (Elixir)

Pub (Dart/Flutter)

Swift

Haskell (Hackage)

R (CRAN)

​

Lockfile Requirement

# npm / Yarn
npm install          # creates package-lock.json
yarn install         # creates yarn.lock

# Python (all formats supported: requirements.txt, Pipfile, pyproject.toml)
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

​

Python Manifest 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.

​

Gradle Version Catalogs

​

Adoption Checklist

​

Operational Notes