> ## 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, prioritizes, and remediates risk in your software supply chain

ZeroPath's Software Composition Analysis (SCA) maps every dependency your code
pulls in — direct and transitive — matches it against known vulnerabilities and
license data, and assesses whether the vulnerable code is actually reachable in
your application — invoked, not just imported. Reachability and exploitability are
AI-assisted signals that help you triage the findings most likely to matter first.
Dependency findings, license exposure, an AI component inventory, and
scan-coverage health all live together on the **Supply Chain** page.

This overview explains the moving parts at a high level and points you to a
dedicated page for each capability.

## What ZeroPath SCA gives you

<Columns cols={2}>
  <Card title="Supported ecosystems & coverage" icon="boxes-stacked" href="/docs/sca/ecosystems">
    Dependency resolution across 13 ecosystems, and exactly what each one needs
    for full transitive coverage.
  </Card>

  <Card title="Reachability & exploit signals" icon="route" href="/docs/sca/reachability">
    Whether the vulnerable code path is really invoked, plus CISA KEV and FIRST
    EPSS exploit intelligence for prioritization.
  </Card>

  <Card title="Coverage & warnings" icon="gauge-high" href="/docs/sca/coverage">
    How completely your supply chain was scanned, and how to clear remaining
    gaps.
  </Card>

  <Card title="License compliance" icon="scale-balanced" href="/docs/sca/licenses">
    Per-package SPDX licenses, enriched and grouped into informational
    obligation categories, so legal and compliance reviews start from the same
    data the scanners used.
  </Card>

  <Card title="AI Inventory (AI-BOM)" icon="robot" href="/docs/sca/ai-inventory">
    A bill of materials for the AI in your codebase: SDKs, agent frameworks, MCP
    servers, model files, and agent configs.
  </Card>

  <Card title="Auto-remediation & alerts" icon="code-pull-request" href="/docs/sca/remediation">
    Automatic upgrade PRs with safe-version selection, plus proactive CVE alerts
    for packages you already depend on.
  </Card>

  <Card title="Blast radius" icon="explosion" href="/docs/sca/blast-radius">
    Which call sites in your code an upgrade actually touches, classified by
    risk, attached to each patch.
  </Card>

  <Card title="SBOM exports" icon="file-export" href="/docs/sca/sbom-exports">
    CycloneDX, SPDX, VEX, and ML-BOM artifacts generated from the same inventory
    the UI shows.
  </Card>

  <Card title="Container scanning" icon="box" href="/docs/scanning/container-scanning">
    Scan built container images for OS-package and bundled-dependency
    vulnerabilities, with per-layer findings, base-image upgrade guidance, and a
    dedicated dashboard.
  </Card>
</Columns>

## How dependency data gets in

ZeroPath builds its inventory from your scans. There are three ways a dependency
ends up analyzed:

<Tabs>
  <Tab title="Full scan with SCA">
    SCA is enabled in scanner settings by default, so every full scan also
    parses manifests and lockfiles. Dependency findings appear on both the
    **Issues** page and the **Supply Chain** page, alongside your SAST and other
    results.
  </Tab>

  <Tab title="Scheduled SCA scan">
    Configure a dependency-only scan on any cron cadence, independent of full
    scans, to keep your inventory fresh between code pushes. Scheduled scans are
    incremental: when your code has not changed since the last run, ZeroPath
    reuses prior resolution and focuses on what is new. A newly published
    advisory can still surface a finding on unchanged code. Results appear on
    the **Supply Chain** page.
  </Tab>

  <Tab title="Pull request scan">
    PR scans analyze the dependencies touched by a diff, so a risky new package
    or version bump is caught at review time.
  </Tab>
</Tabs>

<Info>
  The Supply Chain page can show **more** dependency findings than the Issues
  page. That is expected: scheduled SCA scans run on their own cadence and may
  surface issues a full scan hasn't picked up yet. For the most complete view of
  your dependency posture, use the Supply Chain page.
</Info>

## The Supply Chain page

The Supply Chain page is the dedicated SCA dashboard. It is organized around four
questions, and the deep-dive pages above map onto them:

* **Where do I stand?** — a posture summary: scan coverage, exploitability, and
  what to fix first.
* **What should I fix?** — dependency findings, viewable as individual
  occurrences or grouped per CVE across every affected repository. Filter by
  severity, ecosystem, and [reachability](/docs/sca/reachability). When a Wiz
  integration is connected, you can also filter by cloud exposure to prioritize
  packages in internet-facing applications.
* **What's in my supply chain?** — the inventory: [dependencies](/docs/sca/ecosystems),
  [licenses](/docs/sca/licenses), and [AI components](/docs/sca/ai-inventory). Transitive
  packages show a dependency-path icon so you can see which parent dependencies
  pull them in.
* **How complete was the scan?** — [coverage](/docs/sca/coverage): which manifests
  resolved, which didn't, and the warnings that explain any gaps. Secrets scan
  incomplete notices are surfaced separately and no longer contribute to the
  SCA warnings banner count.

Repository scope selections are saved in the URL so they survive tab switches and
can be shared as deep links. When you switch organizations, any scope from the
previous organization is automatically cleared so the page does not start with
stale filters that resolve to nothing. Data such as SCA settings status,
coverage metrics, and warning counts is always tied to the exact population
on screen (organization, repository scope, and workspace team/tag filter). When
you change any of these dimensions, stale data from the previous scope is
cleared and refreshed, so counts and badges never show numbers from a
population that is no longer displayed.

Each finding is enriched with real-world [exploit intelligence](/docs/sca/reachability):
CISA KEV (known-exploited) and FIRST EPSS (exploit probability), so you can
prioritize what is actively being exploited. The issue detail API response now
includes these signals directly on each SCA vulnerability: `isKnownExploited`,
`kevDateAdded`, `kevKnownRansomware`, `epssScore`, and `epssPercentile` — so
integrations and automations can consume exploit intelligence without a separate
lookup. Findings link to their upstream advisory and show the associated CVE.
When an advisory carries neither a CVSS score nor a recognized severity label,
the finding's severity is left empty rather than assigned an artificial default.
Findings with unknown severity are ranked below scored findings in
prioritization, so they do not displace advisories with real severity data.
When a dependency finding is linked to a SAST finding, that finding's score sets
its severity, so the Issues and Supply Chain pages stay consistent.

<Note>
  The Supply Chain dashboard is in **Early Access** and its layout is still
  evolving; this guide refers to capabilities rather than specific tab names.
</Note>

<Info>
  For very large organizations, Supply Chain queries that scan an extremely
  broad scope may time out on the server and show a message directing you to
  narrow your scope using the repository selector, team, or tag controls at the
  top of the page. Narrowing the scope reloads the page automatically. When the
  findings query times out, follow-on queries (the total count and the posture
  preset badges) are skipped automatically, since they cover the same population
  and would reach the same conclusion. Once you narrow the scope and findings
  load successfully, those follow-on queries resume. You can always retry by
  changing the scope or navigating back — each attempt is allowed to run again.
  Findings load first for faster time-to-screen; the total count appears in the
  paginator once it is ready. If the total cannot be computed, pagination still
  works — you can page forward and backward normally.
</Info>

### Per-repository Inventory tab

Every repository's detail page has an **Inventory** tab that shows the same
Supply Chain views — Overview (posture and KEV exposure), Risk, Dependencies,
Licenses and AI components — for that one repository. The tab reads the latest
finished scan on the repository's default branch; the **Branch** picker lists
every branch that has an inventory scan, and the line beside it names the scan
time and commit the page is describing. **Export SBOM** produces CycloneDX,
SPDX, VEX or ML-BOM for exactly that scan.

The URL carries the selection (`?tab=inventory&view=<view>&branch=<name>`), so a
link to a branch's inventory can be shared.

## End to end, per scan

<Steps>
  <Step title="Checkout">
    ZeroPath clones the repo and pins the commit so results are consistent
    across scans.
  </Step>

  <Step title="Application discovery">
    An AI-assisted analyzer maps your services and modules (e.g.
    `/apps/payments`) so each dependency is attributed to the application that
    uses it.
  </Step>

  <Step title="Dependency resolution">
    Manifests and lockfiles are parsed into a graph of direct and transitive
    packages, with versions, dependency paths, and license signals. Maven
    projects now include full transitive dependency-path chains, so you can
    trace how a vulnerable transitive package enters your build through its
    parent dependencies. A fully `==`-pinned `requirements.txt` is treated as a
    lockfile-equivalent and resolves deterministically without requiring a
    separate lockfile. When a package-manager resolution refines a version that
    the static manifest parser previously recorded, the stale version is
    retracted so you no longer see phantom duplicate findings for the same
    package at an outdated version. Maven and Gradle resolution includes
    protection against registry rate limiting: the scanner fetches each POM
    coordinate at most once per scan and uses a fleet-wide request budget to
    pace egress. If the registry begins refusing requests for an IP, the scanner
    halts JVM resolution immediately and surfaces a transient warning on the
    affected manifests rather than silently returning an incomplete dependency
    tree. Rerunning the scan once the condition clears restores full coverage;
    no changes to your manifests are needed. See [Supported
    ecosystems](/docs/sca/ecosystems) for what each ecosystem needs.
  </Step>

  <Step title="License enrichment">
    Manifest-declared licenses are enriched and recorded as a normalized SPDX
    license string per package. See [License compliance](/docs/sca/licenses).
  </Step>

  <Step title="Reachability analysis">
    For each vulnerable package, ZeroPath assesses whether the vulnerable code
    path is actually reachable. Full scans use a deeper reasoning model for
    exploitability assessment, improving accuracy on complex multi-step
    vulnerability investigations. When an assessment cannot complete, the
    finding is surfaced as **Pending Review** rather than silently dropped, so
    no investigated advisory goes unreported. See
    [Reachability](/docs/sca/reachability).
  </Step>

  <Step title="Inventory, findings & exports">
    The normalized inventory, application map, and validated findings are stored
    once, so the UI, APIs, [SBOM exports](/docs/sca/sbom-exports), and alerts all
    draw from a single source of truth.
  </Step>
</Steps>

## Private package registries

If your organization hosts packages on a private npm or Maven registry (for
example, a corporate Artifactory or Nexus instance), you can connect it so
ZeroPath resolves your internal dependencies during SCA scans.

Once a registry connection is saved, ZeroPath authenticates against it when
resolving lockfile-less manifests for that ecosystem. Both basic
(username + password/token) and bearer token auth modes are supported.
Resolution falls back to the public registry configuration when no private
registry is configured for an ecosystem, so existing behavior is unchanged for
ecosystems with no connection.

<Note>
  Maven resolution routes ZeroPath's own POM and BOM fetcher through the private
  registry. Trivy's own transitive POM-walk uses its built-in fetcher and does
  not use the private registry credential; packages whose metadata exists only
  on the private registry may still resolve with degraded transitive coverage on
  that path. ZeroPath's resolver handles parent chains and imported BOMs through
  the configured private registry.
</Note>

## Getting started

<Steps>
  <Step title="Keep SCA enabled">
    Scanner settings include SCA by default — leave it on so every full scan
    collects dependency findings.
  </Step>

  <Step title="Add a recurring SCA scan">
    Schedule a dependency-only scan (daily/weekly) so your inventory stays
    current between full scans, and point it at the branches you actually
    deploy.
  </Step>

  <Step title="Close coverage gaps">
    Check the [coverage](/docs/sca/coverage) view and commit any missing lockfiles so
    transitive dependencies are fully resolved.
  </Step>

  <Step title="Connect private registries (if applicable)">
    If your organization uses a private npm or Maven registry, add a registry
    connection in organization settings so SCA scans can resolve internal
    packages.
  </Step>

  <Step title="Turn on remediation where it fits">
    Enable [auto-remediation and CVE alerting](/docs/sca/remediation) with thresholds
    aligned to your risk tolerance.
  </Step>

  <Step title="Wire up SBOMs">
    Once inventories exist, generate [CycloneDX/SPDX/VEX/ML-BOM
    exports](/docs/sca/sbom-exports) for procurement, compliance, or downstream
    tooling.
  </Step>
</Steps>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.