Knowing Whether an Upstream Vulnerability Affects You
Audience. Whoever answers "does this new CVE affect our products?" That question arrives by email, from a customer, or from a regulator, and it usually arrives with urgency.
Outcome. A component inventory accurate enough that the answer is a lookup rather than an investigation, plus alerting so the question reaches you before your customers do.
Why it matters. CRA Annex I Part II requires you to identify and document the components in your products, and clause 7.10 of EN 40000-1-2 covers third-party component cybersecurity management. Most of what you ship is code you did not write.
Time required. Uploading an SBOM takes minutes. Keeping it current is a build-pipeline change and a real project.
The flow at a glance
The diagram shows the whole flow on one page, from an uploaded component list to a decision on one advisory. The steps below explain each part. Select the diagram to open it at full size. The example product is fictional.
The map, because this spans three navigation areas
These screens sit under different parts of the app, which makes the workflow harder to see than it should be.
| Screen | Where | What it answers |
|---|---|---|
| SBOM Registry | Settings | What is in our products |
| Supply Chain Intelligence | CRA rail | What advisories affect those exact versions |
| Exposure Search | CRA rail | Which products one CVE affects |
| Supply Chain Partners | CRA rail | Which suppliers, and what is their disclosure posture |
| Monitoring Sources | Settings | Where advisories come from |
| Hardware Registry | Settings | Physical components and firmware |
| Pipeline Findings | CVD rail | What our own CI scanners found |
Steps 1 and 2 are the load-bearing ones. Everything else supports them.
Step 1. Upload an SBOM
Open Settings, then SBOM Registry.
Accepted formats are CycloneDX JSON, SPDX 2.x JSON or SPDX 3 JSON-LD, or a recognised manifest, being package.json, requirements.txt, go.mod, Cargo.toml, Gemfile.lock, or a Maven pom.xml. Upper and lower case in the filename do not matter, and a requirements file can have a suffix, such as requirements-dev.txt. A CycloneDX or SPDX XML file is refused with a message that asks for the JSON form. Up to 5 MB and 10,000 components.
The registry also scores the SBOM against BSI TR-03183-2, showing whether it meets the minimum data fields.
The matcher needs an exact version for each component. A component with no version is skipped, and the page counts it. A version range is a worse problem, because it looks like an answer. In a package.json, a range such as ^4.17.0 is checked as 4.17.0, the lowest version in the range, which is not always the version you ship. The page shows it as 4.17.0 (from range ^4.17.0). A Cargo.toml requirement such as "1.2" is a range too, because Cargo reads it as ^1.2. It is checked as 1.2.0 and shows as 1.2.0 (from range ^1.2). Only =1.2.3 pins a version in a Cargo.toml. In both files, a range with no lower bound, such as <2.0.0 or *, has no lowest version, so the component counts as having no version. A Cargo.toml is read in all its dependency tables, including [build-dependencies] and platform tables such as [target.'cfg(unix)'.dependencies], and [workspace.dependencies] in a workspace root. A member crate line such as serde.workspace = true has no version of its own. In a member Cargo.toml uploaded alone, the upload result lists that line as a line the parser cannot read. The workspace root Cargo.toml gives those versions. A renamed dependency, such as rand_old = { package = "rand" }, is checked as the crate rand. In a requirements.txt, a line without an exact == version becomes a component with no version. A tag such as latest, a range such as ^1.2, a Git URL or a Maven ${property} also counts as no version. The upload result also lists the lines that the parser cannot read, such as -r and -e lines, Git URLs and package.json dependencies from Git or a file path. An SBOM made from the lockfile or the build gives the versions you ship. This is the single highest-value thing to fix in your build.
The matcher also needs the package ecosystem. It comes from the purl of each component, or from the manifest type. OSV.dev takes eight purl types, npm, pypi, golang, cargo, maven, gem, nuget and composer. An OS package, a C or C++ library or a firmware image has none of these. Give such a component a CPE with a version, and the matcher asks NVD instead. Without a CPE, the matcher skips it.
Which product an SBOM covers
An SBOM names a product. In the registry, the This SBOM covers control sets the scope. Choose All products when one component list describes everything you ship. Choose a product to give that product its own SBOM, which overrides the all-products list for that product alone.
The GitHub connector follows the same rule. On the Integrations page, the GitHub card has a This repository describes picker. Leave it on All products if the repository is your only component source. If you ship several products, bind the repository to the one product it builds, or its dependency graph is written into the technical file of every product you own.
Step 2. Check real exposure
Open Supply Chain Intel, and look at SBOM Exposure.
Every component is matched against OSV.dev by exact version. Only advisories whose affected range actually includes the version you shipped are listed, so this is real exposure rather than every CVE ever filed against the package. A component with no OSV ecosystem but with a versioned CPE is matched against NVD by that CPE.
The header reports how many components were scanned out of the total, so partial coverage is visible rather than implied. When the page can check no component, it says Nothing checked with a warning, never No known vulnerabilities. This is the usual result for a firmware SBOM with no purls and no CPEs. A scan that checked no component does not count as a check. The technical file then says that the SBOM cannot be checked, and no finding closes for a component that the SBOM still lists.
This is the authoritative answer to "are we affected". It is not the same as the SBOM scan on a submission page, which matches by vendor and product name without the version and over-reports. When the two disagree, this one is right.
The page keeps a match result for 10 minutes. A change to any SBOM of your company starts a new match. Scan SBOM now on the Supply Chain Partners page runs the scan again and updates the stored findings. On Enterprise, a daily job runs it automatically and alerts by email and webhook when a new advisory first matches a component. A match that is on a KEV list, or that is HIGH or CRITICAL, also opens a review trigger on the product. A second daily job watches the open findings and alerts when KEV catalogues or sightings start to report exploitation. It never marks a report as actively exploited. A person decides that, see SOP-04.
Step 2b. Answer one CVE for every product
Open Exposure Search and enter one CVE, GHSA or OSV identifier, for example CVE-2021-44228.
The search checks the SBOM of each active product, up to 50 products, and gives one result for each product. A product uses its own SBOM, or the account-wide SBOM when it has none of its own.
| Result | Meaning |
|---|---|
| Affected | A component version in the SBOM is inside the affected range |
| Not affected (version) | The component is in the SBOM, at a version outside the affected range |
| Not affected (VEX) | A VEX statement on the finding says not affected or fixed |
| Not in SBOM | No component in the SBOM is named in the advisory |
| Unknown | No SBOM, an SBOM older than 90 days, an advisory with no package data, a failed lookup, a matching component with no version, or a range floor that is not affected |
An unknown result is not a clean result. Fix the reason and search again.
For an affected product, an admin can click Start Article 14 report. This creates a report for the product, or opens the report that is already open for the same CVE. The report lists the affected components and holds an Article 14 draft. If the product link, the components or the draft cannot be saved, the page says so. Click again, and it saves only the missing parts. The search never records the Article 14 decision. A person decides on the report page whether the vulnerability is actively exploited, see SOP-04.
Step 3. Watch the vendors you depend on
On the same page, add vendors to the Vendor watchlist.
Advisories are matched by the vendor of the affected product, not by free-text search, so following sap returns advisories that actually affect SAP products rather than anything mentioning SAP.
Each card shows CVE identifier, severity, a KEV badge that names the catalogues that report exploitation, an EPSS score where one exists, and a sighting count. Where a vendor matched more advisories than fit on one page, the card says so rather than presenting a truncated list as complete.
A dated time range is at most 120 days, because the upstream NVD API rejects a wider window in a single query. Select All time to see advisories with no date limit, newest first.
Step 4. Record your suppliers
Open Supply Chain Partners.
Third-party component cybersecurity management under EN 40000-1-2 clause 7.10. Add each supplier, then record the components they supply with a VEX status: not affected, affected, fixed, under investigation, or unknown.
Run CVD scan probes the partner's domain for a security.txt and a reachable CVD policy, which tells you whether they can receive a report at all.
Each partner also shows Known vulnerable in your SBOM, joining your recorded components against the findings from Step 2. If it is empty, the panel says why rather than showing nothing.
Findings close by themselves. Each scan reconciles the ledger against the SBOM you have stored right now, so once you upgrade a component past the affected range, its finding stops counting as a live exposure and the supply-chain entries in the control register can go green again. Nothing is deleted. A closed finding moves under Previously resolved on the partner, with the date it closed, because "we found this and fixed it" is the evidence an assessor asks for. If the same vulnerable version comes back into the SBOM, the finding reopens and alerts again.
Two cases deliberately do not close a finding. A scan where OSV.dev did not answer for part of your SBOM leaves everything still pinned untouched, since silence from an upstream API is not an all-clear. An SBOM that lists no components at all is treated as a broken upload rather than proof that everything is fixed.
A supplier with no disclosure channel is a supply-chain risk in itself. If you cannot report a vulnerability to them, you cannot get it fixed, and that belongs in your risk assessment.
Step 5. Confirm where advisories come from
Open Settings, then Monitoring Sources.
Seeded with NVD, GitHub Security Advisories, EUVD, CERT/CC and vendor bulletins. NVD and GitHub are polled automatically, and the list records when each was last checked and what it found.
This page is read-only and exists as RCP-2 evidence that monitoring is in place, which is a question an auditor will ask.
Step 6. Register hardware, if you ship any
Open Settings, then Hardware Registry.
Record component name, identifier such as MAC or serial, producer and firmware version. This is the hardware counterpart to the SBOM and satisfies the hardware component inventory clause.
Step 7. Feed in your own scanner output
Open Pipeline Findings.
SAST and SCA results from your CI, posted as SARIF 2.1.0 to POST /api/v1/scan/sarif with an API key scoped to sarif:write. A FOSSA vulnerability export goes to POST /api/v1/scan/fossa with the same key scope. There is no upload button by design, since this is meant to run on every build.
Findings dedupe by fingerprint, so re-running a scan never piles up duplicates, and a dismissed finding does not resurrect. Promote to submission moves a real issue into the triage workflow in SOP-05.
Completion checklist
- SBOM uploaded, with pinned versions rather than ranges
- TR-03183-2 conformance reviewed and gaps understood
- SBOM Exposure reviewed, and every match triaged or dismissed with a reason
- Exposure Search run for each new CVE that reaches you, and every unknown result resolved
- Vendor watchlist covers your significant upstream dependencies
- Suppliers recorded with their components and VEX status
- Every supplier scanned for a disclosure channel
- Monitoring sources confirmed as polling
- Hardware components registered, if applicable
- CI posting SARIF, if you run SAST or SCA
Plan differences
| Feature | Required plan |
|---|---|
| SBOM Registry, Supply Chain Intelligence, Monitoring Sources, Hardware Registry | Pro |
| Supply Chain Partners, on-demand SBOM scan, Exposure Search | Compliance |
| Daily automated SBOM alerts, Pipeline Findings, the v1 API | Enterprise |
Below Enterprise the daily scan does not run, so Step 2 is something a person has to remember to do. Put it on a calendar.
Keeping it honest
An SBOM uploaded once and never updated is worse than none, because it produces confident answers about a product you no longer ship. Regenerate it on every release, ideally from the build itself through the v1 API rather than by hand.