Continuous monitoring

The principle

An SBOM is only valuable when replayed continuously. A component that is clean today is vulnerable tomorrow, with no new build having taken place. That is the difference between a CI check and a compliance arrangement.

It is also why centralisation is mandatory: you do not re-evaluate thousands of files scattered across artefact registries every day.

The architecture

Archived SBOMs (every shipped version)
        │
        ▼
Steering platform ──── daily re-evaluation ────────┐
        ▲                                           │
        │                                           ▼
Vulnerability sources                        Targeted alerts
 EUVD · OSV · NVD · vendor advisories                │
 confirmed-exploitation catalogues                   ▼
 upstream project advisories             Team owning the product
                                                     │
                                                     ▼
                                         Triage → VEX → fix

The key word is targeted: the platform alerts only the teams whose products actually contain the component, in an affected version. Broadcasting produces noise and kills attention.

Sources and their use

Source	Frequency	Use
EUVD — European vulnerability database, operated by ENISA	Daily	European reference, to be preferred in your reporting
OSV	Daily	`purl` correlation, high precision on packages
NVD	Daily	Broad coverage, to be filtered to avoid CPE false positives
Confirmed-exploitation catalogues	Daily	Prioritisation trigger, strong indicator for qualification
Vendor and distribution advisories	Daily	Avoids false positives caused by backports
Upstream project advisories	By subscription	Often ahead of public databases

EUVD and the reporting platform

Two distinct European arrangements, often confused:

	EUVD	Single reporting platform (SRP)
Nature	A vulnerability database	A reporting channel
Origin	Created under NIS 2, operated by ENISA	Created by the CRA, operated by ENISA
Direction of flow	You consume it	You submit to it
Use	Continuous monitoring	24 h early warning, 72 h notification, final report

The link between them: after processing by the coordinating CSIRT and ENISA, your reports feed the European vulnerability knowledge ecosystem — of which the EUVD is the shop window. That is what “feeding the EUVD through the reporting platform” means.

Monitoring upstream

Distinct from vulnerability monitoring, and just as necessary:

subscribing to security advisories of the projects you depend on critically;
tracking activity: date of last commit, release frequency, number of active maintainers;
detecting abandoned projects, and triggering the strategy decided in Integrating open source;
alerting on maintainer or licence changes — both are risk signals, one security, one legal.

This monitoring covers a limited set of components: those critical to your products. Attempting to watch the entire transitive graph produces unusable noise.

What must be automatic

Automatic	Manual
Daily re-evaluation of the estate	Exploitability analysis
SBOM / source correlation	Drafting the VEX
Routing the alert to the owning team	Priority arbitration in case of conflict
Opening a ticket with the context	Reporting decision
SLA deadline reminders	Customer communication
Detecting a component reaching end of maintenance	Choosing the replacement strategy

The principle: the machine finds and routes, the human decides. Anything left to human initiative in the left-hand column eventually stops happening.

Metrics

Detection interval: time between a vulnerability being published and your alert.
Triage interval: time between alert and handling decision.
Remediation interval by severity level.
Coverage: share of shipped products whose SBOM is actually monitored.
Average age of open vulnerabilities.
Ratio of actionable alerts to raw alerts — see False positives.

Coverage is the first to look at: monitoring 40 % of the portfolio perfectly is not a compliance arrangement, it is a pilot.