Continuous SBOM monitoring, end to end

Why SBOM generation isn't enough

An SBOM tells you what was in a build the day it was produced. It does not, on its own, tell you anything about vulnerabilities disclosed against those components afterwards. A release shipped six months ago has the same SBOM today as it did then, but its risk profile has almost certainly changed.

Most pipelines today stop at generation: a CI step emits a CycloneDX or SPDX file, attaches it to the artifact, and the team moves on. The vulnerability picture keeps moving without it. The whole purpose of having an SBOM is to be able to re-evaluate it against fresh threat data — and that is exactly the workflow most teams have not yet stood up.

The deeper article: What Happens After SBOM Generation?

The five stages of an SBOM lifecycle

A complete lifecycle has five stages, each of which depends on the one before it being done well:

1. Generate. Produce an SBOM as a CI artifact for every release of every product. CycloneDX or SPDX both work.
2. Store. Put the SBOM somewhere it can be retrieved by both humans and machines, tagged with product, release, and environment.
3. Monitor. Re-check stored SBOMs against fresh vulnerability data continuously, not just at build time.
4. Triage. When monitoring surfaces a new finding, route it to the owning team and capture the decision and reasoning.
5. Report. Produce evidence packs and regulatory disclosures on the cadence your obligations require.

Most teams handle stages 1 and 2 well, then drop off. Closing the gap to stage 3 is the part that turns SBOMs from a compliance checkbox into operational value.

The deeper article: SBOM Lifecycle Management: what comes after generation.

How continuous monitoring actually works

Continuous monitoring sounds vague, but the implementation is straightforward. You do not need to rebuild your CI pipeline, and you almost certainly do not need to re-scan artifacts.

The pattern that works: keep every release's SBOM in an inventory a monitoring tool can read; run a vulnerability feed continuously against that inventory; emit a finding whenever a match appears that did not exist before. The vulnerability data is the moving part, not the artifact. Re-scanning the same artifact tells you nothing new unless either the artifact or the scanner has changed; running new vulnerability data against an existing SBOM directly answers the question that matters.

The deeper article: How to Monitor Existing Releases for New CVEs.

Tying findings to releases and environments

A vulnerability finding that is not tied to a release and an environment is hard to act on. When a new CVE drops, the practical questions a response team needs to answer, in order, are:

• Does any release we own contain the affected component and version?
• Of those releases, which are currently deployed?
• Of those deployments, which are in production?
• Who owns the affected component in those releases?
• What does the fix path look like?

Each question narrows the response. A monitoring layer that models releases and environments as first-class entities can answer all five within seconds. A scanner that only reports against bare artifacts can answer the first one, and the rest become a manual hunt.

The deeper article: How to Know Which Environments Are Affected by a CVE.

CycloneDX or SPDX?

Both formats are good. The practical choice depends on your existing tooling and your compliance footprint. CycloneDX is the OWASP project, designed with security workflows in mind and with first-class VEX support; SPDX is the Linux Foundation project, with a stronger heritage in license compliance and recognition as ISO/IEC 5962:2021. A good monitoring tool should ingest both, normalize internally, and produce identical findings either way.

The deeper article: CycloneDX vs SPDX: which one to use for continuous monitoring.

What the EU Cyber Resilience Act expects

The CRA's operational core is Article 13, which expects continuous vulnerability handling across the support period of every product placed on the EU market. Periodic scans do not meet the bar. Article 14 layers on reporting timelines: 24-hour early warning, 72-hour notification, and a final report within a month for actively exploited vulnerabilities and severe incidents.

A monitoring layer that re-evaluates existing SBOMs against fresh vulnerability data, routes findings to owners, captures triage decisions, and produces evidence packs on a schedule is essentially the operational shape the CRA expects. None of this is exotic; it just has to actually happen.

The deeper article: What the Cyber Resilience Act asks of vulnerability handling.

A worked example

A new high-severity CVE is published against a transitive dependency. A team that has put this workflow in place:

• Detects the new advisory within hours via continuous monitoring.
• Identifies that release 2.4.1, deployed in production-eu, references the affected component.
• Routes the finding to the platform team that owns the component.
• Captures the triage decision (apply upstream patch, schedule hotfix release 2.4.2).
• Logs the activity for the next scheduled evidence pack.

The team did not re-run any scans. They did not rebuild any artifacts. The data was modelled correctly in advance, so the workflow was almost mechanical when the CVE landed.

Where Quaze fits

Quaze is the continuous monitoring layer that sits on top of the SBOMs your pipeline already produces. It ingests CycloneDX and SPDX, models releases and environments as first-class concepts, watches everything against fresh vulnerability data, routes findings to owners, and produces audit-ready evidence packs on a schedule.

You keep your existing build pipeline. You keep your existing SBOM tooling. Quaze handles the part of the lifecycle most teams have not yet built for themselves.