How to Monitor Existing Releases for New CVEs

To catch CVEs disclosed after your last build, you do not need another scanner pass. You need a tool that re-checks the SBOMs from your existing releases against fresh vulnerability data, on a continuous basis. The artifact has not changed; what changed is what we now know about its components.

This article walks through why re-scanning is the wrong reflex, what monitoring existing releases actually requires, and how to set it up without rebuilding your CI pipeline.

Why re-scanning isn’t the answer

Re-running a scanner over the same artifact gives you the same result, unless one of two things has changed: the scanner has been updated with new rules, or the underlying vulnerability database has been updated. The artifact itself is identical.

That means re-scanning is, at best, a slow indirect way of getting the latest vulnerability database to look at your old build. There is a more direct path: keep the SBOM, and run new vulnerability data against it whenever the data updates.

A few practical reasons this matters:

• Re-scans are expensive. They tie up build infrastructure, often with the same scanners that block your CI. Doing this for every release every night is wasteful.
• Re-scans assume the build is reproducible. It often is not, especially for older releases. You may not be able to rebuild a release from three months ago even if you wanted to.
• Re-scans miss the time dimension. They tell you what is true today; they do not tell you what changed since yesterday. For triage, the delta matters more than the absolute state.

What re-checking actually requires

The pattern that works is straightforward:

1. Every release has an SBOM in a known place. That SBOM does not need to be regenerated; it just needs to be retrievable.
2. A vulnerability feed runs continuously. When the feed updates (new CVE, new advisory, fixed-version notice), the system re-evaluates all known SBOMs against it.
3. Any new match becomes a finding. Findings are deduplicated, scoped to a release and environment, and routed.

The key shift is that the vulnerability data is the moving part, not the artifact. You evaluate static SBOMs against a moving database.

How to set it up without rebuilding your pipeline

You almost certainly do not need to change how you build software to start doing this. The minimal additions are:

• Make SBOM generation part of every release build. If you are not doing this already, this is the only pipeline change that matters. CycloneDX or SPDX both work; pick one your tooling supports.
• Push the SBOM to a place a monitoring tool can read it. A registry, an object store, or an API upload. Quaze accepts uploads via API or CI step; many tools have similar shapes.
• Tag the SBOM with at least product, release, and environment. “Which release is this from?” and “where is it running?” are the questions that turn a list of vulnerabilities into something a team can act on.

That is it. The monitoring tool then handles the re-checking on an ongoing basis. Your CI pipeline does not need to know about it.

A worked example

A team ships releases monthly. They have twelve releases of the last year still in support, four of which are deployed in production environments across different customers.

A new high-severity CVE is published against a transitive dependency.

• The monitoring system checks all twelve SBOMs against the new advisory.
• Three of them reference the affected version.
• Of those three, two are currently deployed in production.
• The two affected releases get flagged, with the owning team notified.

The team did not re-run anything. No build agent was touched. The SBOMs that already exist were enough.

A small gotcha: transitive dependencies and version ranges

Vulnerability advisories are increasingly precise about which versions are affected (and which are not, via fixed-version information). Make sure your monitoring tool actually respects these ranges. A tool that just matches “is this package mentioned anywhere” will produce a lot of false positives, especially for transitives that have already been patched in a later version your release happens to use.

This is one of the under-appreciated benefits of CycloneDX (and SPDX): they record version information clearly, so a monitoring tool that uses the metadata properly can make a precise call. If your SBOMs are precise, your alerts will be too.

What “continuous” actually buys you

The thing you get from continuous monitoring that you do not get from periodic scanning is time. The CVE clock starts the moment a vulnerability is published. The earlier you know which of your releases is affected, the earlier you can decide what to do about it.

If your detection cadence is “we re-scan every quarter,” your worst-case detection lag is a quarter. If your detection cadence is “the monitoring system re-checks as the feed updates,” your worst-case detection lag is hours.

For most teams, that is the difference between proactive and reactive.