Thank them, ask for the evidence, verify against the build, and answer within a stated time. If they are right, issue a revised SBOM with a new version and explain the cause. If they are wrong, show why. Never argue first and check later.
Why this is serious
CISA's 2026 minimum elements say an SBOM should include all components that make up the target software, including transitive dependencies, and that a recipient should be able to conclude that a newly reported vulnerability does not affect them if the SBOM does not list the affected component. A missing component breaks that promise. The same text also says SBOM authors should correct errors promptly, and that organizations may weigh errors in their risk decisions.
So treat this as time sensitive, and as a trust moment.
Step by step
- Acknowledge. Reply the same day. Say you are checking and give a time for the next message.
- Get the evidence. Ask what they found, how they found it and which SBOM version they hold. Many customers compare against a scan of the shipped artifact.
- Reproduce. Engineering rebuilds or inspects the exact release and looks for the component.
- Classify the cause. See the table below.
- Respond with the result. Include what was wrong, what is now correct and what you changed.
- Send the revised file. Use a new SBOM version and timestamp, since the CISA text says corrections warrant a revised SBOM.
Common causes
| Cause | What happened | Fix |
|---|---|---|
| Generated before build | Source analysis missed a component added at build time | State the generation context, add an after build SBOM |
| Vendored or copied code | Code copied into the repo was not tracked as a dependency | Record it as a dependency, as the CISA text suggests |
| Base image packages | The operating system layer was not scanned | Include the image layer in the next SBOM |
| Shaded or bundled libraries | Libraries were repackaged into one archive | Analyse the artifact |
| Genuinely not shipped | The component is a dev or test tool only | Explain and point to the build output |
Wording for the reply
Thank you for flagging this. We checked version 4.2 against the shipped artifact. You are right that library X is present and was missing from the file we sent. It was added at build time and our source based generation did not see it. We have issued a revised SBOM, version 1.1, generated after build, and listed the change. We have also changed our process so the file is checked against the artifact before it is sent.
If the customer is wrong, write the same reply with the evidence, such as the dependency tree showing the component is dev only.
Do not take it personally
The 2021 NTIA report asked consumers to be tolerant of occasional incidental error, welcoming corrections without penalty when offered in good faith, but said this tolerance does not extend to intentional obfuscation or willful ignorance. Good faith correction is the expected behaviour on both sides.
Try it yourself
Open the demo and expand a direct dependency to see its indirect ones. Look for how a library can sit several levels down, where a check of the top level would miss it.
Click through it at your own pace, or open it full screen.
Quick check
Should we send a corrected file or just a note?
Send a corrected file with a new SBOM version and timestamp, plus a short note on what changed. See how to explain a revised SBOM.
What if the missing component has a known vulnerability?
Treat it as an investigation. Give the customer a status for it, using the four VEX values: affected, fixed, not affected or under investigation.
Safeguard's SBOM and dependency scanning and reachability analysis can help engineering tie components to how code uses them, and the free scan is a way to see a first pass.
Sources
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA and partners, 29 July 2026
- The Minimum Elements For a Software Bill of Materials (NTIA, 2021)
- Minimum Requirements for Vulnerability Exploitability eXchange (VEX), CISA, April 2023
Last reviewed: 19 October 2026.
