Skip to main content

Managing the SBOM Registry

A Software Bill of Materials (SBOM) is a foundational element of modern supply chain security and a core requirement for compliance under the Cyber Resilience Act (CRA). The CVD Portal features a comprehensive SBOM Registry, providing a centralized repository for tracking the third-party libraries, open-source components, and proprietary code that make up your software products.

The registry allows you to import standard SBOM formats (such as SPDX and CycloneDX) generated by your build pipelines. Once ingested, you can run an on-demand CVE scan from any submission detail page - the portal correlates each registered component against the Global CVE Allocation System, which indexes 79 upstream vulnerability sources, and surfaces matching vulnerabilities with CVSS scores, EPSS probabilities and exploitation evidence. The Threat Intelligence page also automatically surfaces your top SBOM components in the live vendor feed, giving you a real-time view of newly published CVEs affecting your stack.

Maintaining an accurate and up-to-date SBOM Registry is essential for rapid incident response. When a major vulnerability (like Log4Shell) is disclosed, the registry allows you to instantly determine which of your products are affected and where the vulnerable component is located. This comprehensive visibility is crucial for demonstrating control over your software supply chain and fulfilling regulatory obligations regarding component transparency.

Which product an SBOM covers​

An SBOM names a product. Annex VII point 8 of the CRA files the SBOM in a product's technical documentation and requires it to be produced to market surveillance authorities on reasoned request, so the obligation belongs to the product rather than to the manufacturer.

You do not have to pick a product to upload one. Leaving the scope set to All products stores an account-wide SBOM, and every product that has none of its own uses it. If you ship one thing, or one component list genuinely describes everything you ship, this is the right answer and nothing else needs doing.

Uploading an SBOM for a specific product overrides the account-wide one for that product alone. Other products carry on using the account-wide list. On a product's Evidence tab, the SBOM card names which of the two is in force, so an inherited component list is never mistaken for one written for that product.

Two consequences worth knowing:

  • Removing a product's own SBOM does not leave it bare. It falls back to the account-wide one if there is one, and the technical file is rewritten to describe that instead.
  • Advisory findings are attributed to the SBOM that produced them. A finding from a product's own SBOM raises a review trigger on that product only. A finding from the account-wide SBOM still reaches every product, because that list speaks for all of them.

Whichever scope you upload at, the SBOM is written into the technical file of every product it covers, and satisfies Annex VII point 8 there. Until a product has one, its Annex VII export is blocked, and the Evidence tab says so.

The CI endpoint takes an optional productId for the same purpose. Omitting it pushes to the account-wide SBOM, which is what existing pipelines already do and what they keep doing. A monorepo that builds several products pushes each one by id. See the API overview.

The GitHub connector writes the account-wide SBOM, since a connection names one repository. A product with its own SBOM keeps overriding it.

Keeping the registry current​

One SBOM is stored per product, plus the account-wide one, and every upload replaces the SBOM at that scope. The registry shows when each was last refreshed, and flags any that is more than 90 days old. The control register runs the same 90-day check on a schedule, against the oldest SBOM in the account, so one actively maintained product cannot mask a neglected one.

The reason to act on that flag is that correlation only knows the versions your stored SBOM pins. Upgrade a component and the old advisories keep matching until you re-upload, so a registry left alone for a quarter accumulates findings against versions you no longer ship. Those are not false positives about the component, they are true statements about a stale snapshot, which is why the fix is a re-upload rather than dismissing them one by one.

Once you do re-upload, the next scan closes the findings that no longer apply. Each scan reconciles the stored findings against the SBOM as it stands, stamping a resolution date on anything the current component set no longer matches, so the supply-chain checks in the control register recover on their own after an upgrade. Resolved findings are kept, not deleted, and stay visible as history on the supply-chain page. A finding whose vulnerable version returns to the SBOM reopens and alerts again.

There are two ways to avoid the problem rather than manage it. Pushing the SBOM from your build pipeline on every release makes the freshness clock track your release cadence instead of anyone's memory, and the API overview has the endpoint. Where no such pipeline step exists, connecting GitHub has the portal read your repository's dependency graph every night and replace the account-wide SBOM itself.

How component matching works​

Correlation runs against GCVE, which indexes vulnerabilities by CPE vendor and product across 79 upstream sources. Where your SBOM declares a CPE for a component (CycloneDX cpe, SPDX cpe23Type), the portal uses it directly, which makes the match a lookup rather than a name guess. Where it does not, the component name is mapped onto a vendor and product heuristically. Generating SBOMs that include CPEs alongside package URLs measurably improves match quality.

A package that appears at more than one version is registered at each of them, and scanned at each of them. This matters because a direct dependency is often patched while an older copy of the same package survives deeper in the tree, and only the older copy is vulnerable. The same name in two ecosystems, requests on npm and requests on PyPI for example, is likewise kept apart, since they are unrelated packages.

Each match carries its exploitation context: EPSS score, KEV catalogue assertions, and sighting counts. See Exploitation Signals.