Yes, if the status and other information are correct for every product in the set. CISA says a statement may reference more than one product, and a product identifier may name a product line, a family, a branch or a version range. If the answer differs for a subset, create a separate statement.
What the standard allows
CISA's requirements say a statement conveys one status for one vulnerability across one or more products. The product identifier may specify a set: every product from a supplier, a product family or line, version ranges or a specific branch. The same document says it does not specify how to define sets of products or how to define version ranges, and points readers to SBOM or VEX implementations for that.
Group or split
| Situation | Approach |
|---|---|
| Every version in a family has the same answer | One statement naming the family |
| Versions before and after a fix differ | Separate statements, one affected, one fixed |
| One variant compiles out the vulnerable code | Separate statement with its own justification |
| Unsure about some versions | Mark those under investigation, separately |
CISA states that if status or other information changes for a subset, additional statements must be created for that subset.
Steps
- List every version and variant you ship.
- Determine the answer for each, using build and code evidence.
- Group those with an identical status and justification.
- Name each group as precisely as your identifiers allow. If you cannot express a range in your format, list versions individually.
- Review whether any group hides a difference, such as a feature flag that changes whether code is compiled in.
- Publish and raise the document version.
Risks of grouping too broadly
A broad statement is cheap to write and expensive to be wrong about. If one version in a range was actually affected, a customer on that version may skip a needed update because of your statement. Prefer narrower groups for security sensitive issues and broader groups for components that are plainly absent.
Naming sets in practice
Use the identifiers that your SBOM and customers' tools use. The OpenVEX spec says package URLs are valid identifiers and preferred, and that products can list multiple identifiers. Ranges are best expressed in whatever the format supports, and where it does not, enumerate.
Try it yourself
Open the demo and look at how reachability narrows which findings matter. A group of versions sharing the same reachability result is a good candidate for a single statement.
Click through it at your own pace, or open it full screen.
Quick check
Can one statement mix affected and fixed products?
No. A statement carries one status for all products in it.
Is a version range always safe to use?
Only if the status is true for every version in it. Check for variants and feature flags.
Safeguard's reachability analysis can show where a vulnerable function is or is not called, and the free scan gives a first look.
Sources
- Minimum Requirements for Vulnerability Exploitability eXchange (VEX), CISA, April 2023
- OpenVEX specification
Last reviewed: 19 October 2026.
