To decide which supported releases an advisory affects, take the component version in each release's SBOM, test it against the advisory's affected range, then check whether you backported a fix. Group the results by support status, because customers on supported, extended and ended releases need different messages.
Definitions
An affected range is the set of component versions an advisory says contain the flaw. A backport is a fix applied to an older line of a component without moving to the newest version. A support window is the period in which you handle vulnerabilities and ship updates for a release.
The three checks
| Check | Question | Result |
|---|---|---|
| Range | Is the shipped component version inside the affected range? | Possibly affected |
| Backport | Did we patch this line ourselves, or does the supplier ship a patched build with the same version number? | Possibly fixed |
| Use | Is the vulnerable code present and reachable in our product? | Affected or not affected |
Skipping the second check produces false alarms, and skipping the first produces misses.
Steps
- List every release in a support window from your release records.
- For each, read the component version from the SBOM you built for that release, not from the current main branch.
- Test each version against the advisory range using the ecosystem's version rules.
- For hits, check your patch records for a backport.
- For remaining hits, decide the use question and record the answer.
- Write a status per release: affected, fixed, not affected or under investigation.
What to tell each cohort
- Current release: the fixed version and upgrade steps.
- Older supported release: a patched point release, or a workaround, with a date.
- Release past support: say plainly that it will not receive a fix, and recommend upgrading. The EU Cyber Resilience Act's Annex II asks manufacturers to state the end date of the support period, so customers can know this in advance.
Pitfalls
- Using the current SBOM for an old release. The dependency set may have changed.
- Reading "fixed in 2.4.1" as "all 2.x is affected". Check where the range starts too.
- Assuming a distribution's package version number equals the upstream one.
- Forgetting a bundled copy of the component, covered in shaded dependencies.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how findings are grouped and tracked to a status.
Quick check
Do I need a VEX statement for every release?
You need an accurate status for every release a customer might run. A statement can cover a version range if the facts are the same across it.
What if the SBOM for an old release does not exist?
Say so, rebuild it from the tagged source if you can, and mark the result as reconstructed.
Safeguard's SBOM and dependency scanning and reachability analysis help with the range and use checks. A free scan can show the component list for a project.
Sources
- Regulation (EU) 2024/2847, EUR-Lex, Annex II
Last reviewed: 19 October 2026.
