No. Suppressing a finding does not change your SBOM. An SBOM lists the components in your software. A suppression hides one vulnerability alert about a component. The package stays in the inventory, and it should, because a new advisory tomorrow will need to find it.
Two different records
| Record | Answers | Changes when |
|---|---|---|
| SBOM | What is in this software? | The build changes |
| Vulnerability finding | Is a component affected by an advisory? | New data arrives or the code changes |
| Suppression | Do we accept or reject this finding, and why? | A person decides |
| VEX statement | Is the product affected by this vulnerability? | You publish a status |
Mixing these up leads to bad habits, such as deleting a vulnerable package from the SBOM to make a scan clean. That makes the document inaccurate and makes later incident searches fail.
Why the SBOM must stay complete
When a new advisory appears, the first question is "do we ship this package?" The SBOM answers it. If you removed entries to hide findings, you have no answer, and you are back to searching repositories by hand during an incident.
What to share with customers instead
A customer who receives your SBOM and runs their own scan will see the same findings you suppressed. To pre-empt questions, send a statement of what is and is not exploitable. The OpenVEX specification defines four statuses, not affected, affected, fixed and under investigation, and a not affected statement must include either a justification or an impact statement. Our post on SBOM versus VEX explains when to send each.
Mapping a suppression to a statement
- Take the suppression's reason, such as not in execute path.
- Choose the matching justification value.
- Identify the product and component using a package identifier that matches your SBOM.
- Publish the statement with a timestamp, and update it when the suppression expires or changes.
Do not publish a statement for a deferral. A deferral is not a claim of being unaffected, so it belongs in your internal register. See mapping exception reasons to justifications.
A caution on scope
A suppression can be per project, while your SBOM may cover a whole product. Make sure any outward statement covers exactly the product and version you mean.
Keep the inventory honest
If a package truly leaves your build, the SBOM should change because you changed the build, not because a scan was inconvenient. Regenerate SBOMs from the build output, not by hand.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that the inventory lists components independent of how many findings each one has.
A short example
A team suppresses a not reachable finding in a logging library. Their SBOM still lists the library at the same version. A month later a new advisory names it, and a search of the SBOM finds every affected service in seconds. Had the library been edited out, that search would have found nothing.
Quick check
Should suppressed components be flagged in the SBOM?
Standard SBOMs do not carry suppression decisions. Use VEX or an internal register for that.
Can I remove a component to clear a scan?
Only by actually removing it from the build. Editing the document alone makes it wrong.
Sources
Last reviewed: 19 October 2026.
