Avoid phrases that claim an SBOM proves safety, completeness or compliance. Each overstates what the file shows, and a customer who later finds a gap will remember the claim. Replace them with statements that describe what the document lists, how it was made and what you will do if it is wrong.
Six phrases to retire
| Instead of | Say |
|---|---|
| "Our SBOM proves we are secure." | "Our SBOM lists what is in the product. We handle vulnerabilities separately." |
| "It is 100 percent complete." | "It covers all components we identified, including transitive ones. Gaps are marked unknown." |
| "We meet the federal standard." | "We follow the published minimum elements. Here is how." |
| "No vulnerabilities, so nothing to worry about." | "Here is the status of each finding." |
| "Everyone gets the same file." | "Each version has its own file." |
| "Your scanner is wrong." | "Let us look at each finding together." |
Why each one fails
"It proves we are secure"
CISA's 2026 text says an SBOM alone is data about software components, and that analysis of SBOMs turns data into insight about risk. The document is an input to risk management, not a verdict.
"It is 100 percent complete"
The guidance sets a goal that an SBOM include all components, including transitive ones, with no minimum depth. It also asks authors to mark unknown information explicitly and says organizations may consider errors in their risk decisions. A claim of perfection invites a test you may fail. Say what you checked.
"We meet the federal standard"
CISA's text says the minimum elements do not create new requirements, and that the document does not constitute advice for compliance, regulatory or legal purposes. Do not say a document, a contract term or a regulation requires something unless you have read that exact text. Say "we follow" only if you have mapped your files to the elements. A check is in a 17 field self check.
"No vulnerabilities"
An SBOM does not list vulnerabilities. A scan matches components to databases and may report findings. CISA's VEX document defines four statuses: not affected, affected, fixed and under investigation. Use them.
"Everyone gets the same file"
Each software version or update should have an associated SBOM. A customer on an older release needs a different file. Formats and access terms may also differ.
"Your scanner is wrong"
Scanners do what they are built to do. Show your work. See how to reply when a customer scanned your SBOM.
A short rule for safe wording
Describe the document, not the product. "The SBOM lists" is safe. "The SBOM shows we are" is not. Describe your process in the present tense only for things you actually do today. Never describe a work in progress as done, and never describe an attestation or certification you do not hold.
Make it stick
Put this table in the sales playbook. Review a few real emails each quarter for these phrases. When a rep slips, treat it as a training gap and fix the process rather than blaming the person.
Try it yourself
Open the demo and compare a component that is present with one that is exploitable. Look at why "it lists a library" and "it is a risk" are different statements.
Click through it at your own pace, or open it full screen.
Quick check
Can we say our SBOM follows CISA guidance?
Only if engineering has compared the file to the 2026 elements and can show how. Otherwise say you are working toward it.
Is it wrong to say an SBOM helps with vulnerability response?
No. The CISA text says that after learning new vulnerability information, an organization can assess whether its SBOMs contain a vulnerable component, which improves response time.
Safeguard's SBOM and dependency scanning helps teams back their statements with evidence, and the free scan is a quick first check.
Sources
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA and partners, 29 July 2026
- Minimum Requirements for Vulnerability Exploitability eXchange (VEX), CISA, April 2023
Last reviewed: 19 October 2026.
