SecurityVault
Request a demo

Know your dependencies.
Understand your exposure.

Connect software composition analysis (SCA) and software bills of materials (SBOMs) to the images and workloads they affect. Keep component risk in production context.

Request a demo View the platform
Dependency provenancemanifest
Application dependency tree
Application
Direct dependency
Transitive package
Investigation context
01 / Inventory

Know what the build contains.

  • Package version
  • Dependency relationship

Resolve package identity and version into a software bill of materials.

CycloneDX
and SPDX
Export per project and per image.
VEX
Exploitability
CycloneDX VEX, OpenVEX and CSAF.
EPSS · KEV
Exploit signals
Alongside CVSS when ranking.
Never drop
Reachability
Unreachable is deprioritised, not deleted.
The category

What are SCA and SBOM?

Most of the code in a modern application is someone else's. SCA tells you which of those packages have known vulnerabilities, which are actually called, and which licences come with them. An SBOM is what you keep: when an advisory lands next month, the question is not whether a repository depends on the package today but which builds and images shipped it, and where they run.

That is where SecurityVault differs. The vulnerable package, the image layer that carries it and the workload running that image sit on one graph, from code to artifact to cloud. Static reachability hints help prioritise advisories for investigation; they do not prove runtime execution. A configured release gate can block a policy-violating CVE. The result is a shorter upgrade list your engineers trust, and an SBOM you can hand to a customer with VEX statements that explain every exception.

Read the dependency chain

  1. Manifest

    Resolve the declared package and version.

  2. Transitive dependency

    Follow the package introduced by another dependency.

  3. SBOM record

    Retain the component identity with the build inventory.

Investigate the advisory in the context of the application that contains it.

How SecurityVault does it

How does SecurityVault run SCA?

Inventory
The native engine parses lockfiles and manifests inside the isolated scanner and emits an inventory only: package URL, version, direct or transitive, and the dependency edges. syft and grype run on every repository scan alongside it.
Match
Matching runs inside the platform against OSV and GitHub advisories, enriched with EPSS exploit probability and CISA's Known Exploited Vulnerabilities list. Language bundles add pip-audit, safety, govulncheck, cargo-audit and OWASP dependency-check.
Reach
Call-graph analysis for Go, Java, JavaScript and Python decides whether the vulnerable code is reachable from an entry point. The verdict is a reachability hint of reachable, not reachable or unknown, and it changes the priority of a finding, never whether it exists.
Supply chain
Every dependency is checked against a malicious-package feed and for typosquatted names. Static checks can still run if a feed is unavailable, but cannot replace the missing feed data. Review coverage before treating a result as complete.
Licences
Declared licences are classified as permissive, weak copyleft or strong copyleft, and per-organisation licence policies decide what is acceptable.
SBOM
Generate an SBOM per project version, diff two versions, download CycloneDX or SPDX, import one you already have, and attach VEX statements. Image SBOM exports are deterministic: the same components and timestamp produce a byte-identical document.
After the scan

What happens to a dependency finding?

The same vulnerable package in a repository and in the image built from it is one story on one graph, from the commit that introduced it to the workload running it.

Finding
affects
Package
depends_on
Repository
contains
Commit
triggered
Build
produces
ContainerImage
runs_image
Workload
01

A consistent identity for each package issue

The same CVE reported by grype, the native engine and an imported report resolves to one logical finding; agreement becomes a corroborating edge.

02

Ranked by reach

Reachability hints, exploit likelihood and exposure feed the risk score. Review the supporting path and analysis coverage; an import alone is not proof of exploitation.

03

Fixable

Upgrade pull requests can be generated for npm, pip, Maven, Go and Cargo manifests, and a successful rescan supplies verification evidence. Closure follows the lifecycle rules, with human-held dispositions preserved.

Gates

Can a vulnerable dependency block a release?

Yes. The CI gate evaluates dependency findings with everything else in the scan against your severity threshold and policies, and a denial lists the blocking package and CVE. A failed or timed-out scan is a deny. For images, registry promotion can be evaluated on blocking CVEs, signature and SLSA level before an image moves on. See deployment gates and container security.

Dependency release review

  1. Affected package

    Inspect the advisory and dependency context.

  2. Severity threshold

    Apply the organisation’s release policy.

  3. Gate outcome

    Keep policy failure distinct from scan or API failure.

A failed check must not be interpreted as a clean dependency scan.

Evidence

What can I show a customer or an auditor?

Two things. For a security questionnaire or procurement review, the SBOM for the project version or image you shipped, with VEX statements recording which advisories do not apply and why. For your own audit, dependency findings are recorded as dependency evidence when controls are evaluated, and the cross-walk maps that evidence across 6 seeded framework catalogues. See continuous compliance.

Software supply-chain record

  1. SBOM

    Identify components in the project or image.

  2. VEX context

    Retain the vulnerability applicability information.

  3. Audit cross-walk

    Link the supporting records to control evaluation.

Component identity is the anchor for downstream review.

FAQ

Frequently asked questions about SCA and SBOMs

What is the difference between SCA and an SBOM?
SCA is the analysis: which packages you depend on and which of them carry known vulnerabilities or licence obligations. An SBOM is the record: the component inventory of one build or image in a standard format. SCA answers what is wrong today; the SBOM lets you answer later whether a newly published advisory affects something you already shipped.
Which SBOM formats are supported?
Project SBOMs are generated as CycloneDX and can be downloaded as CycloneDX or SPDX. Image SBOMs export as CycloneDX or SPDX 2.3. Existing SBOM files can be imported, and VEX statements export as CycloneDX VEX, OpenVEX or CSAF.
Does SecurityVault drop findings it thinks are unreachable?
No. Reachability lowers priority; it never deletes a finding. An unknown verdict means the analysis did not run for that package, and it is not treated as not reachable.
Which package ecosystems are parsed?
npm, Yarn and pnpm; pip and Poetry; Maven and Gradle; Go modules; Cargo; and NuGet. syft also inventories operating-system and application packages inside container images.
How are dependencies matched to advisories?
The native inventory identifies components for advisory matching in the platform. Third-party scanners can also report vulnerability matches. Coverage depends on the package ecosystem, component identifiers and advisory data available to the enabled tools.

Dependency risk connects to the rest of the platform: SAST findings that prove reachability, image scanning for the packages inside each layer and risk-based vulnerability management across all of it. Built for security engineers who need to fix what is reachable first. See vulnerability management. Glossary: SCA, SBOM, SBOM component.

From the blog

Further reading

All SCA & SBOM articles →

See it on your stack

Bring one repository and one image.

See the same vulnerable package traced from lockfile to image layer to running workload, with an SBOM you can download.

Request a demo View the platform