Build an SBOM Vulnerability Enrichment Workflow

An SBOM becomes operationally useful when package coordinates connect to owners, deployed assets, and current vulnerability evidence. The OSV Vulnerability Scraper supplies the advisory layer while leaving inventory parsing and asset context in the system that already owns them.

Normalize package coordinates first

Convert CycloneDX components, SPDX packages, or package URLs into OSV ecosystem names and versions. Submit bounded batches such as:

{"packages":["PyPI:requests@2.31.0","npm:lodash@4.17.20","Go:golang.org/x/net"],"maxResultsPerPackage":50}

Store a mapping from each submitted string to the SBOM component ID, product, repository, environment, and team. The result's matched_input then reconnects every advisory to the correct assets. Preserve affected ranges and references as structured evidence; avoid reducing a record to a title and severity alone.

The useful data model is many-to-many. One component can match several advisories, one advisory can affect several packages, and the same package can appear in many products. Keep these relationships explicit. Deduplicate network queries for identical package/version coordinates, but do not discard downstream asset associations.

Severity is not equivalent to business risk. Add reachability, exposure, internet accessibility, data sensitivity, exploit evidence, and service criticality before prioritizing work. CISA KEV can provide a separate actively exploited signal, while OSV supplies package-aware range detail.

Run enrichment whenever a new SBOM is accepted and refresh active components on a schedule. Compare IDs, modified timestamps, fixed-version events, and withdrawal state. Retain historical snapshots for auditability, because an advisory can evolve after the original deployment review. This division keeps the SBOM authoritative for inventory and OSV authoritative for its aggregated advisory view.