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

• Automatic scans – whenever you scan a repository, ZeroPath analyzes manifests and lockfiles, flags vulnerable packages, and surfaces dependency issues alongside your other findings.
• Scheduled scans – configure daily/weekly/etc via cron expressions per repository, tag, or organization. The scheduler only creates new work when the branch head changes, minimizing redundant analysis. Automatic backoff prevents repeated failures from monopolizing capacity and purges stale staged jobs for you.

​

Inventory & License Coverage

• Full manifest capture – package-lock, requirements, go.mod, pom.xml, Podfile, Cargo.lock, and other manifests are deduplicated and versioned per scan.
• Direct vs transitive context – each dependency includes its role (declared vs inherited) plus the chain of packages that led to it, making blast-radius analysis simple.
• License intelligence – ZeroPath normalizes manifest-declared terms, enriches them with authoritative sources, and records the final SPDX expression per package, enabling legal/compliance workflows.
• License risk filters – 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.
• Specific license checks – 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.
• Application ownership – dependency findings are linked to the applications/services discovered in your repo so teams immediately know who owns remediation.
• Historical snapshots – 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

• npm / Yarn (including scoped packages)
• PyPI
• Go modules
• Maven / Gradle (groupId/artifactId)
• NuGet
• RubyGems
• crates.io (Cargo)
• Packagist / Composer
• Hex (Elixir)
• Pub (Dart/Flutter)
• CRAN (R)
• Hackage (Haskell)
• Swift Package Manager (SwiftURL)
• CocoaPods

​

Lockfile Requirement

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

# 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

# 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

​

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.
• Cost transparency – token usage for AI validation is aggregated per scan, so platform teams can budget and attribute spending.
• Automatic recovery – scans move through a staged → active lifecycle, so if a worker restarts ZeroPath resumes in-flight jobs, prunes stale staged entries, throttles repeated failures per cron window, and reuses completed inventories whenever possible.