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.11 covers third-party due diligence. 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 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 |
| 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 or SPDX 2.x JSON, or a recognised manifest by exact filename, being package.json, requirements.txt, go.mod, Cargo.toml, Gemfile.lock, or a Maven pom.xml. 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.
Components without a pinned version are skipped by the matcher. A dependency listed as ^4.17.0 cannot be checked against an advisory's affected range, so a loose SBOM produces confident silence rather than an answer. This is the single highest-value thing to fix in your build.
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.
The header reports how many components were scanned out of the total, so partial coverage is visible rather than implied.
This is the authoritative answer to "are we affected". It is not the same as the SBOM scan on a submission page, which matches on description text and over-reports. When the two disagree, this one is right.
Scan now re-runs the match on demand. On Enterprise, a daily job runs it automatically and alerts by email and webhook when a new advisory first matches a component.
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 CISA KEV badge where the vulnerability is known exploited, 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.
The time range is capped at 120 days because the upstream API rejects a wider window in a single query. The options offered are the ones that can actually be served.
Step 4. Record your suppliers
Open Supply Chain Partners.
Third-party due diligence under CRA clause 7.11. 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.
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 map. 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. 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
- 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 | 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.