When an SBOM search finds nothing, record the exact query, the set of SBOMs searched with their dates, the products with no SBOM, who ran it and when, and the verdict with its basis. A zero result is only meaningful if you can show what was searched and what was not.
Why a negative result needs evidence
A customer or auditor who asks "were you affected?" is really asking how you know. "We searched and found nothing" is not an answer without scope. The CISA minimum requirements for VEX say a not affected statement must include a justification or an impact statement explaining how or why the product is not affected. A search record is the factual base for that explanation.
The record, field by field
| Field | Example content |
|---|---|
| Advisory reference | Identifier and the date you read it |
| Component identity | Ecosystem, namespace, name, affected range |
| Query | The exact purl prefix or search string used |
| Scope | Which SBOM store, how many SBOMs, product list |
| SBOM dates | Oldest and newest generation dates in the set |
| Depth | Whether transitive dependencies were included |
| Gaps | Products or releases with no SBOM, listed by name |
| Result | Zero hits, or hits removed with reasons |
| Verdict | Not affected, with the justification type |
| Reviewer and time | Name and timestamp in a consistent format |
Match the justification to the evidence
The OpenVEX specification defines a justification of component_not_present for the case where the search shows the component is simply not there. Use that only when your scope was complete. If some products had no SBOM, the honest status for those is under investigation, and the record should say so.
Common weak spots
- Searching a stale SBOM set. If the newest SBOM is months old, say so, or regenerate first.
- Searching direct dependencies only. A zero result then covers less than it appears to.
- Searching one name spelling when the advisory lists several.
- Not recording the products excluded from the search.
Retention
Keep the record with the incident file, in the same place you keep customer notices. Retention periods depend on your policies and contracts, so check them with your compliance owner. The point is that someone can reconstruct the check later without asking you.
Related reading
The post on reporting not affected honestly covers the wording side, and VEX not affected justifications for unreachable code covers a different basis for the same status.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding is judged before a verdict is recorded.
Quick check
Is a zero result the same as not affected?
Only when the search covered every shipped product with a complete, current SBOM. Otherwise list the gaps.
Who should sign off on the record?
The person who ran the search and a reviewer, with timestamps. Your own policy decides the details.
Safeguard's compliance and evidence automation supports keeping these records alongside the findings.
Sources
Last reviewed: 19 October 2026.
