SBOM Audit: from a file upload to a prioritized vulnerability report

You have an SBOM. Regulators want it, your customers ask for it, and your CI pipeline probably already generates one. But the file itself isn't the hard part — the hard part is answering what's actually wrong with it, how bad it is, and what to do next.

That's what SBOM Package Analysis does. Drop an SPDX or CycloneDX JSON file into the web interface for an instant visual report — or send it to the SBOM Audit API (POST /api/v4/audit/sbom) and get structured JSON back for your pipelines. Same engine, same results — one path for humans, one for machines. Either way, Vulners parses every component, matches it against our vulnerability database — CVEs, OSV records, vendor advisories — and returns applicable advisories, fix versions, and the scoring and exploitation signals you need to prioritize.

This post walks through what both paths look like in practice: the interactive report, the JSON output, and the API integration.

What happens when you upload an SBOM

The web interface accepts drag-and-drop or file browsing. Supported formats are SPDX (v2.x) JSON and CycloneDX (v1.x) JSON — the two formats that most SBOM generators produce out of the box.

Once you click "Generate report," Vulners extracts every component name and version from the file, then matches each one against applicable advisories from multiple source families — OSV, CVE, and vendor-specific bulletins. The matching uses the affectedLibraries container for OSV records — which includes PURL and ecosystem/package values with affected version ranges — and SCAP-compatible configurations for other sources.

The result is a Package Analysis Report that shows three numbers up front: total packages scanned, affected packages, and clean packages. Below that, a severity breakdown — critical, high, medium, low — gives you the shape of the problem before you look at any details.

Two views: by findings and by components

The report offers two ways to read the results.

By findings lists every advisory sorted by AI Score — highest-risk first. Each entry shows the CVE or OSV identifier, a description, CVSS score, AI Score, EPSS probability, exploit availability, source count, and which packages in your SBOM are affected. Tags at the bottom of each finding — "path traversal," "cross-site scripting," "catastrophic backtracking" — are generated from the advisory content and help with quick scanning.

By components groups the same data under each affected package+version. If you're a developer deciding what to upgrade first, this is the view that maps directly to your package.json or go.mod. Each component card shows the version you have, how many vulnerabilities apply, and the full advisory list underneath.

Both views are sortable by AI Score range — useful when you want to focus on the top of the risk curve and ignore the noise at the bottom.

What's inside each advisory

Every advisory in the report carries the signals you'd otherwise need to stitch together from multiple sources:

Scoring — CVSS score with severity level, plus the Vulners AI Score that dynamically ranks risk using CVSS, EPSS, real-world exploitation data, and cross-referenced signals. The AI Score includes an uncertainty value — a confidence range that tells you how much the score might shift as more data arrives.

EPSS — Exploit Prediction Scoring System probability and percentile for each linked CVE. When you're triaging 20+ findings, the difference between 0.001 EPSS and 0.005 EPSS is the difference between "watch" and "patch now."

Exploit availability — An explicit "Exploits" badge with a count when public exploit code exists. This is tied to Vulners' exploit collection across 15 sources including GitHub, Gitee, Exploit-DB, and Metasploit.

Fix versions — The JSON report includes a fixedVersion field for each affected package. This is the piece that turns analysis into action — you know exactly what version to upgrade to.

Cross-references — The full JSON includes references to 15+ source types — NVD, GitHub Security Advisories, Red Hat, Debian, Nessus, AttackerKB, CIRCL, and more. Each advisory ID links back to the Vulners database where it inherits the full graph of connected signals.

The JSON report: machine-readable, complete

The web UI has a "Download report as .json" button that exports the full analysis. This JSON is richer than what fits on screen — it includes all 1605 packages (in a typical scan), not just the affected ones. Clean packages appear with empty applicableAdvisories arrays, which matters for compliance workflows where you need to demonstrate full coverage.

The structure is straightforward:

{
  "meta": {
    "format": "SPDX",
    "created": "2026-02-22T10:03:27.000Z",
    "name": "openclaw"
  },
  "data": [
    {
      "package": "rollup",
      "version": "4.57.1",
      "fixedVersion": "4.59.0",
      "applicableAdvisories": [
        {
          "id": "OSV:GHSA-MW96-CPMX-2VGC",
          "title": "Rollup 4 has Arbitrary File Write via Path Traversal",
          "metrics": {
            "cvss": { "score": 9.3, "severity": "CRITICAL" }
          },
          "aiScore": { "value": 6.2, "uncertainty": 1.6 },
          "epss": [{ "cve": "CVE-2026-27606", "epss": 0.00475 }],
          "exploitation": { "wildExploited": false }
        }
      ]
    }
  ]
}

Each advisory entry also includes the enchantments.dependencies.references block — a full map of related document IDs across all source families Vulners tracks. This is the same graph structure described in our data overview — an SBOM finding doesn't live in isolation; it connects outward to the entire Vulners intelligence graph.

API integration: one POST, structured results

The web interface is useful for one-off reviews. For anything recurring — CI/CD gates, nightly scans, customer-facing reports — the SBOM Audit API is a single endpoint:

curl -X POST "<https://vulners.com/api/v4/audit/sbom>" \\
  -H "X-Api-Key: YOUR_API_KEY" \\
  -H "Accept: application/json" \\
  -F "file=@/path/to/sbom.json"

POST /api/v4/audit/sbom with multipart/form-data. The response is a JSON array — same structure as the downloaded report's data field. Each item corresponds to a component found in the SBOM, with package, version, fixedVersion, and applicableAdvisories fully populated.

The API sits alongside Vulners' other Package Audit endpoints — npm, pip, Maven, Poetry, Golang — which accept native package manager output. SBOM Audit is the universal entry point when you already have a standard bill of materials; the package-specific endpoints are faster paths when you're working directly with a lockfile or dependency list.

Where SBOM Audit fits in the Vulners stack

SBOM Audit is powered by the same data backbone as the rest of Vulners:

• OSV records with affectedLibraries containers provide the package-native matching — PURL-based, ecosystem-aware, with precise version ranges.
• CVE Fusion connections mean that when an OSV record carries a CVE alias, every finding inherits the scoring, exploitation flags, and vendor bulletins that CVE has accumulated elsewhere in the database.
• Exploit collection from 15 sources feeds the "Exploits" badge on each advisory — the moment a PoC appears for a vulnerability in your SBOM, the report reflects it.
• The wildExploited flag aggregates CISA KEV, AttackerKB, ShadowServer, and CIRCL signals — so if a finding in your SBOM is being exploited in the wild, you see it immediately.

The combination matters: an SBOM tells you what you have; Vulners tells you what's wrong with it, how urgent it is, and what to do about it — using the same enrichment layer that powers our Software Audit, Linux Audit, and Intelligence products.

Try it

The SBOM Package Analysis web interface is available now. Upload an SPDX or CycloneDX JSON, get a report, download the full JSON. For API access, the endpoint is documented in the SBOM Audit API reference.

If you're generating SBOMs but not yet scanning them — or scanning them against a single source — this is the piece that connects the file to the full vulnerability graph.