Dependencies and SBOM (SCA)
Dependency analysis runs on every repository scan. It reads manifests and lockfiles itself — no external scanner — matches each component to known advisories, and writes a CycloneDX SBOM.
Supported manifests and lockfiles
| Ecosystem | Files read |
|---|---|
| Python | requirements*.txt, Pipfile.lock, pyproject.toml, setup.cfg |
| npm | package.json, package-lock.json, yarn.lock |
| Java | pom.xml, build.gradle, build.gradle.kts |
| Go | go.mod |
| Rust | Cargo.toml, Cargo.lock |
| Ruby | Gemfile.lock |
| .NET | *.csproj, packages.config |
| PHP | composer.lock |
Where a lockfile and its manifest are both present, the lockfile's pinned versions are used. A lockfile also lists transitive packages, so those are covered; from a manifest alone, only declared dependencies are known.
Not read today: poetry.lock, pnpm-lock.yaml, go.sum, Gradle lockfiles, and a Pipfile without its lock. For those stacks, generate an SBOM with your build tool and upload it.
Matching and enrichment
- Advisories — each component is matched against the OSV database, with the NVD as a fallback, from the same store the Vulnerability engine maintains.
- Exploit signals — each match gets its EPSS score and CISA KEV membership, cached and refreshed daily.
- Risk score — a composite 0–10 score from CVSS, EPSS, KEV and fix availability.
| Score | Priority |
|---|---|
| 8.0–10.0 | Immediate |
| 6.0–7.9 | High |
| 3.0–5.9 | Medium |
| 0.0–2.9 | Low |
EPSS and KEV move the score in both directions: a vulnerability with very low exploitation probability is scored down, and one on the KEV list is scored up. Onam does not perform call-graph reachability analysis.
SBOM
- Output: CycloneDX 1.5, JSON, with package URLs.
- Input: upload CycloneDX 1.4 or 1.5, or SPDX 2.3, in JSON. Uploaded SBOMs get the same enrichment.
- Diff: compare any two SBOMs to see what was added, removed or changed.
SPDX export and XML formats are not available today.
VEX
Record a VEX statement against a component and vulnerability — not affected, affected, fixed or under investigation — with a justification. Advisories marked not affected are left out of that component's results.
License and policy checks
Licenses are classified as permissive, weak copyleft or strong copyleft. Built-in policies cover: no unmitigated critical vulnerabilities, no high vulnerabilities with a known fix left unpatched, no strong copyleft, every component licensed, no unrecognised licenses, and a maximum critical count.
License checks need license data. Uploaded SBOMs usually carry it; components found by parsing lockfiles usually do not, so run license policy on uploaded SBOMs.
NTIA minimum elements
Each SBOM can be checked against the NTIA minimum elements for an SBOM and scored 0–100, which is useful before sending one to a customer or regulator.
Not covered here
Container images are not scanned by Code Security today. Vulnerabilities in images and running workloads are covered by the Vulnerability and Container Security engines.