Does it tell us whether the vulnerable function is actually called?

No. Onam ranks by exploitation signals — EPSS and CISA KEV — and fix availability, not by call-graph reachability. A package is reported if it is present at an affected version.

Which lockfiles are not supported yet?

poetry.lock, pnpm-lock.yaml, go.sum, Gradle lockfiles and a Pipfile without its lock. If your stack relies on one of these, generate an SBOM with your build tool and upload it instead.

What does the license check need?

License data. SBOMs you upload usually carry it; components found by parsing lockfiles often do not, so license policy is most useful on uploaded SBOMs.

Can we export the SBOM in SPDX?

Not today. Onam exports CycloneDX 1.5 JSON, and accepts both CycloneDX and SPDX JSON as input.

Does it scan container images?

Not in Code Security today — it works from source manifests and SBOM files. Image vulnerabilities in running workloads are covered by Onam's vulnerability and agentless workload scanning.

Dependencies & SBOM (SCA)

Which of our dependencies are actually being exploited, and can we prove what we ship?

Know what you ship, and which of it attackers are using right now.

Onam reads your manifests and lockfiles, matches every component against OSV and NVD, ranks each vulnerability by exploitation signals as well as severity, and gives you a CycloneDX SBOM with license, VEX and NTIA checks on top.

See it in my cloud Read the docs

SAST

source code

SCA + SBOM

dependencies

IaC

templates

DAST

running apps

Why it matters How it works What you get FAQ

Why this matters

A customer's procurement team asks for an SBOM.

Engineering exports a list of packages from one service, by hand, in a format nobody agreed on. The same week a dependency report lands with dozens of CVEs sorted by CVSS, and the team patches the top of the list — a 9.8 nobody has ever exploited — while a medium-rated library on CISA's known-exploited list ships in every build.

CVSS is not a to-do list

Severity describes the vulnerability, not how likely anyone is to use it against you. A queue sorted by CVSS alone spends the week on theoretical criticals while an actively exploited medium waits.

Ranked by exploitation, not only severity

How does it actually work?

The mechanism, not the marketing

1
Onam parses manifests and lockfiles itself, without an external scanner: Python (requirements files, Pipfile.lock, pyproject.toml, setup.cfg), npm (package.json, package-lock.json, yarn.lock), Java (pom.xml, Gradle build files), Go (go.mod), Rust (Cargo.toml, Cargo.lock), Ruby (Gemfile.lock), .NET (project files, packages.config) and PHP (composer.lock). Where a lockfile exists, its pinned versions win over the manifest.
2
Each component is matched to known advisories — the OSV database first, the NVD as a fallback — using the same advisory store as Onam's vulnerability engine.
3
Every match is enriched with its EPSS score (the probability of exploitation in the next 30 days) and whether it is on CISA's Known Exploited Vulnerabilities list, both refreshed daily.
4
A composite 0–10 risk score combines CVSS, EPSS, KEV membership and whether a fixed version exists, and maps it to a priority: Immediate, High, Medium or Low. An actively exploited medium can outrank an unexploited critical — which is the point.
5
The component list is written out as a CycloneDX 1.5 SBOM with package URLs. You can also upload an existing CycloneDX (1.4 or 1.5) or SPDX 2.3 SBOM in JSON and get the same enrichment, compare two SBOMs, record VEX statements, and run license-policy and NTIA minimum-elements checks.

What do you actually get?

Specific outputs, measurable outcomes

Native parsing across ecosystems

Python, npm, Java, Go, Rust, Ruby, .NET and PHP

Exploitation-aware ranking

EPSS and CISA KEV next to CVSS, in one 0–10 score

Fixed-version awareness

a vulnerability with an upgrade available is ranked as actionable

CycloneDX 1.5 SBOM

generated from the repository, JSON, with package URLs

SBOM import

bring CycloneDX or SPDX JSON from another tool and enrich it

SBOM diff

what was added, removed or changed between two SBOMs

VEX statements

record not affected, affected, fixed or under investigation, with a reason

License policy

permissive, weak-copyleft and strong-copyleft classification and built-in policies

NTIA minimum elements

each SBOM scored against the US baseline for SBOM content

The flow, in one picture

How Dependencies & SBOM (SCA) fits together

Manifests and lockfiles become a component list, enriched with OSV, NVD, EPSS and CISA KEV into a 0–10 risk score, with SBOM, license, NTIA, VEX and diff outputs — From lockfile to risk score. The same component list becomes the SBOM.

Illustrative layout of an SBOM result: component and CVE tiles above a vulnerable packages table — Illustrative — a stylised view of an SBOM result, not a screenshot. Package names and figures are invented.

Read the docs All of Code Security

FAQ

Questions we get a lot

It records what the lockfile pins, and a lockfile lists transitive packages as well as direct ones — so with package-lock.json, yarn.lock, Pipfile.lock, Cargo.lock, Gemfile.lock or composer.lock, transitive dependencies are covered. From a manifest alone (for example a requirements file without pins, or go.mod), only what the manifest declares is known.

Ready to see it live

Ready to see Dependencies & SBOM (SCA) on your dependencies?

Send us a repository or an existing SBOM. We will show you the risk-ranked component list and the SBOM it produces.

Book a live demo →See pricing

Related capabilities

Onam Code Security Static analysis (SAST) and secrets Onam Vulnerability Management SCA and SBOM docs