What do teams get wrong about SBOMs and vendor questionnaires?

What SBOMs and questionnaires can actually tell you

SBOMs and vendor questionnaires are evidence inputs, not security verdicts. An SBOM can tell you which components, packages, and versions are present; a questionnaire can tell you how a supplier describes its controls, practices, and dependencies. That is useful for triage, prioritisation, and follow-up, but it is not the same as proving the software is safe in your environment.

The practical mistake is to treat a populated form or a clean-looking component list as a finished risk decision. The same dependency can be low risk in one deployment and high risk in another, depending on exposure, reachability, privilege, data access, compensating controls, and whether the vulnerable path is even exercised.

Why the gap between disclosure and risk stays wide

What teams often miss is that SBOMs describe inventory, not exploitability. They help you answer “what is in the product?” and “what does the supplier say about it?”, but they do not answer “can an attacker reach the vulnerable code path?”, “is the component actually enabled?”, or “does this weakness matter to a real business workflow?”.

That gap is why the most useful SBOM review is not binary. A disclosed library or package may be entirely irrelevant if it is dead code, isolated, or blocked by configuration. Conversely, a modest-looking component can be critical if it sits on a high-value path, processes sensitive data, or is exposed through a public interface. Teams that skip this second step end up confusing disclosure completeness with security assurance.

This is also where supplier questionnaires are frequently over-read. A strong answer can indicate maturity, but it still needs corroboration. For example, a supplier may say it scans dependencies, rotates credentials, or follows secure development practices, yet none of that proves the specific release you received has no known exposure or that the supplier’s controls cover the exact environment you run.

How practitioners should use them in review and decision-making

Use SBOMs and questionnaires to narrow the field, then validate with independent evidence. That usually means checking whether the component is reachable, whether the vulnerable function is invoked, whether the deployment boundaries reduce blast radius, and whether compensating controls materially change the exposure. It also means distinguishing product claims from evidence you can verify yourself.

For software supply-chain checks, the useful mindset is to connect disclosure to control, not disclosure to trust. Open source and supplier-provided inventories are strongest when they help you target scanning, prioritise patching, request clarifications, and compare suppliers on concrete practices. They are weakest when they are used as a blanket statement that risk has been eliminated. OpenSSF is a useful external reference point for supply-chain security practices, but the operational decision still depends on your deployment context.

AI Supply Chain Security and AI-BOM Guide illustrates the same lesson in a broader supply-chain setting: inventory is the start of analysis, not the conclusion. The reader takeaway for traditional SBOMs is the same, even when the product is not AI-related.

Risk and Threat Considerations

The main risk is decision error: teams over-trust partial disclosures and under-estimate reachable weakness. That can leave exploitable components, exposed dependencies, or hidden third-party risk in production because the review stopped at “present in the bill of materials” or “answered the questionnaire”.

Failure mechanism: Inventory and attestation are mistaken for validation. A component may be listed without revealing whether it is callable, internet-facing, enabled by configuration, or chained into a sensitive business process, while a supplier statement may omit exceptions, scope limits, or environment-specific exposure.

Impact: Security teams may defer patching, accept unsafe supplier risk, or miss an exploitable path until after a compromise, audit finding, or incident demonstrates that the disclosed information was not enough to support a real risk decision.

Practitioner Guidance

What to verify: Tie every material SBOM finding to reachability, exposure, and business criticality before you decide whether it matters. If you cannot answer where the component sits in the architecture and whether the vulnerable path is actually reachable, treat the item as unresolved rather than safe.

Decision rule: If the disclosure is all you have, classify it as a screening input and keep investigating; if you also have evidence of reachability, privilege, or a sensitive workflow, escalate it as a real risk regardless of how complete the paperwork looks.

Practitioner takeaway: Good teams do not ask SBOMs and questionnaires to prove safety, they use them to decide where proof is still missing and where deeper validation is warranted.

Related resources from NHI Mgmt Group

• What do security teams get wrong about vendor offboarding?
• What do security teams get wrong about vendor access in public safety environments?
• What do security teams get wrong about vendor evaluation?
• What do security teams get wrong about vendor management in SOC 2?