What an SBOM tells you that a security questionnaire can’t
Procurement · 6-min read · Assess a vendor → · updated June 2026
A security questionnaire and an SBOM answer different questions. One captures what a vendor says; the other is independently verifiable. Confusing the two is how unverified claims sneak into a procurement decision.
Two different questions
| Security questionnaire | SBOM + vulnerability data | |
|---|---|---|
| Answers | “What are your processes & certifications?” | “What’s actually inside the software, and is it vulnerable?” |
| Source | The vendor (self-reported) | Public data: NVD, CISA KEV, EPSS, endoflife.date |
| Verifiable? | No — you take their word | Yes — independently checkable |
| Covers | People, process, compliance | The software you’d run |
| Blind spot | Known CVEs, active exploitation, EOL | Org practices, incident response, contracts |
Why you need both
A vendor can hold SOC 2 and ISO 27001, run a tidy security program, and still ship a product bundling a component with a critical, actively-exploited CVE. The questionnaire won’t surface that; the software-composition layer will. Conversely, a clean vulnerability scan doesn’t tell you whether the vendor would notify you of a breach. Assess both.
Do both in one place — free
- Create a free vendor assessment — questionnaire + IsItPatched-verified vulnerability data, kept separate.
- Scan an SBOM — a fix-first verdict for every component, in your browser.
- Free questionnaire template — the questions to ask the vendor.
Turn this into action. A questionnaire is what the vendor says; an SBOM and vulnerability data are independently verifiable. Why you need both to assess a product.
Assess a vendor — free →Frequently asked questions
Why isn’t a security questionnaire enough to assess a vendor?
A questionnaire is self-reported — it records what the vendor says about their processes and certifications. It is essential context, but it can’t tell you whether the specific software version you’d run has known, open vulnerabilities, is being actively exploited, or is past end-of-life. Those are independently verifiable facts about the software itself, not the vendor’s policies.
What does an SBOM add?
A Software Bill of Materials lists the components inside a product. Matched against public vulnerability data (NVD, CISA KEV, EPSS), it turns "trust us, we’re secure" into "here are the known issues in what you’d actually deploy, and which are being exploited right now." It’s evidence, not assertion.
Should I use both?
Yes. The questionnaire covers people, process and compliance (SOC 2, ISO 27001, incident response, backups); the SBOM/vulnerability layer covers the software you’d run. Together they give a complete picture. Used alone, a questionnaire is unverified and an SBOM lacks organisational context.
How does IsItPatched combine them?
When you create a vendor assessment, IsItPatched keeps the self-reported questionnaire and the independently-verified software-composition data (open CVEs, CISA KEV exploitation, end-of-life) in separate, clearly-labelled sections — never blended into one score — and lets you export the combined picture.
This guide is a vendor-neutral explainer. It is informational, not legal or compliance advice. See our disclaimer.