Software composition
Your dependencies, matched against public advisories.
SCA is derived from your SAST scans. While the engine analyses your code it also reads your manifests and lockfiles, inventories the packages it can read, matches each one against public advisories — and says plainly what it could not check, so an empty result is never mistaken for a clean one.
web-app · package-lock.json
The question it answers
“Is there a known vulnerability in code we imported?”
Capabilities
What SCA does
Your dependencies matched against public advisories — no second scan.
No separate scan
Run SAST and SCA is populated. The engine reads composer.json, package.json, requirements.txt and lockfiles while it parses your code.
Advisory matching
Packages are matched against GHSA and CVE advisories from public vulnerability databases. Every result shows the date of the advisory data it was matched against.
Fix available
Each advisory shows the fixed versions it publishes, and when one upgrade clears every advisory on a package the app names that version. When no fix is published yet, it says so.
What to fix first
Every package says whether your code imports and calls it, and where an advisory's fix names the functions it changed, whether your code calls one of them and where. Every advisory shows how likely it is to be exploited and whether it is known to be exploited — so you can judge which findings to fix first.
Multi-ecosystem
npm, Composer / Packagist, Maven / Gradle, Go, Python / PyPI, .NET / NuGet, Ruby / RubyGems, Rust / crates.io, Dart / Pub, Swift / SwiftURL, GitHub Actions and Elixir / Hex, with breakdowns by severity, package and ecosystem — and a plain list of any dependency file that was seen but not read.
Provenance you can trust
A Sources row on every view shows which projects and scans it was derived from, what each one checked, and the date of the advisory data.
How it works
From input to evidence
Scan
A SAST scan reads your dependency manifests alongside your code.
Match
Each package and version is matched against known advisories.
Prioritise
Sort by priority — known-exploited advisories first — filter by ecosystem, exploit likelihood or whether your code uses the package.
Fix and re-scan
Bump the package, upload again — resolved advisories drop off automatically.
Coverage
Ecosystems and advisory sources
What the dependency check reads and matches against today. Every result also lists what it could not check.
Ecosystems
Advisory sources
Records from public vulnerability databases. Every result shows the date of the advisory data it was matched against.
Available on
SCA is included on the plans below.
FAQ
SCA, in brief
Full walkthroughs live in the SCA documentation.
Do I have to run a separate SCA scan?
No. SCA reads the results of each project's latest completed SAST scan. If SCA is empty, run a SAST scan and it fills in.
Which advisory sources do you use?
GitHub Advisory Database, PyPA Advisory Database, OSS-Fuzz vulnerability database, Go Vulnerability Database, OpenSSF Malicious Packages, Drupal Advisory Database, RustSec Advisory Database and Erlang Ecosystem Foundation CNA advisories. Each advisory shows its identifiers (including its CVE), aliases and a link to its public page, and every result shows the date of the advisory data it was matched against.
Can you export an SBOM?
Yes. Each project's bill of materials downloads as CycloneDX or SPDX (JSON), with every package's identifier and its licence, from the lockfile or the package registry. The vulnerable-dependency list exports as CSV or JSON, and VEX statements as OpenVEX. Licence policy (allow, review and deny lists) is part of the Enterprise plan.
What does SCA not check?
The dependency check covers the packages your source declares in its manifests and lockfiles, the container images in your upload, and — when fetching is allowed — the base image a Dockerfile names: versions with a published vulnerability (an image's operating-system packages included), packages an advisory lists as malicious, your own package names that the public registry also publishes, look-alike names of popular packages, packages that run code when installed, packages marked unmaintained or past their end of life and — when fetching is allowed — major releases behind the latest, the versions of the CI workflow actions you use, and — with a license policy — licenses. Where the fix of an advisory names the functions it changed, the finding says whether your code calls one of them; no call found never clears a finding. It does not inspect what an install script does, judge how a CI workflow is configured, or read an image held only in a registry. This boundary is stated, not scored.
Do you scan container images?
Yes. Upload a container image (a docker save archive) with your code and its operating-system packages are checked against the distribution's own advisories — Debian, Ubuntu, Alpine, Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, SUSE, openSUSE and Azure Linux — along with the Java, Python, Node and Go packages installed in it. When the scan may reach the network, a Dockerfile's base image is pulled and checked the same way.
Will I hear about a new vulnerability in a package I already use?
Yes. Every hour each project's dependencies are checked again against the newest advisory data, with no new upload, and new findings are sent to the e-mail addresses and webhook you choose.
Ship software you can prove is secure.
See the platform on your own code, or talk to us about a dedicated Enterprise stack.