Your vendor just sent you an SBOM. You need to know if it's actually useful or just compliance theater. CISA updated their SBOM guidance to require "information for all components with no minimum depth," but most SBOMs still arrive with critical gaps. A rapid verification method can spot these problems in fewer than five minutes.
What the Data Shows
Security teams face a practical problem: SBOMs arrive in various states of completeness, and detailed validation takes hours you don't have. The gap between what CISA requires and what vendors deliver creates blind spots in your vulnerability management program.
The issue isn't whether SBOMs matter. They do. The issue is that you can't trust an SBOM just because it exists. Missing components mean missed vulnerabilities. Incomplete dependency trees mean you can't answer "are we affected?" when the next Log4Shell drops.
Key Findings: Where SBOMs Break Down
Missing transitive dependencies. Your SBOM lists the direct dependencies your team added to the project. It doesn't list what those dependencies pulled in. When a vulnerability hits a library three levels deep, you're flying blind. Check this by comparing your SBOM's component count against what a dependency scanner reports. If your Node.js project shows 15 packages in the SBOM but npm list --all returns 847, you have a transparency problem.
Container base images treated as black boxes. Your SBOM shows your application code and maybe the packages you installed. It doesn't show what came with the base image. Alpine, Ubuntu, or Red Hat base images contain hundreds of system packages. If your SBOM doesn't list them, you can't track vulnerabilities in glibc, OpenSSL, or other critical system libraries. Run a container scanning tool like Docker Scout against the same image and count the components it finds versus what's in your SBOM.
Build-time dependencies excluded. Your SBOM captures runtime dependencies but ignores what was present during compilation. This matters because build tools can inject malicious code. The SolarWinds attack compromised the build environment, not the runtime. If your SBOM doesn't distinguish between runtime and build-time components, you're missing half the attack surface.
No provenance metadata. The SBOM lists component names and versions but not where they came from. Was this package pulled from the official npm registry or a mirror? Was the container image built in your CI/CD pipeline or downloaded from an unknown registry? Without provenance data, you can't verify authenticity or track down compromised sources.
Timestamps and tool information missing. When was this SBOM generated? What tool created it? Which version? If you can't answer these questions, you can't determine if the SBOM reflects current code or a six-month-old snapshot. Stale SBOMs are worse than no SBOM because they create false confidence.
What This Means for Your Team
You need a quick filter to separate useful SBOMs from paperwork. The sniff test isn't a replacement for thorough validation, but it catches obvious problems before you invest time in detailed analysis.
Start with component counts. Generate a fresh SBOM using your own tooling and compare the component count to what your vendor provided. A 10x difference signals a problem. Your vendor's SBOM shows 50 components, but Syft generates an SBOM with 500? Either your vendor's tool is configured incorrectly, or they're deliberately hiding complexity.
Check depth indicators. SBOMs in CycloneDX or SPDX format can include dependency relationships. Look for components marked as transitive dependencies. If every component appears as a direct dependency, the SBOM is incomplete. Real software has dependency trees, not flat lists.
Verify base image contents. If you're reviewing a container SBOM, cross-reference it against the base image documentation. An Alpine-based container should include apk packages. A Debian-based container should list apt packages. Missing these entirely means the SBOM only covers your application layer.
Look for VEX integration. Vulnerability Exploitability eXchange (VEX) documents tell you which vulnerabilities actually matter in your context. An SBOM without VEX support forces you to manually triage every CVE. Check whether your vendor's SBOM format supports VEX and whether they provide VEX documents alongside the SBOM.
Action Items by Priority
Immediate: Document your sniff test criteria. Write down what constitutes a failed sniff test for your organization. Set minimum component counts based on your technology stack. Define which metadata fields are mandatory. Share this checklist with procurement so vendors know your requirements upfront.
This week: Test your current SBOMs. Pull the most recent SBOMs from your top five vendors. Run your sniff test. Document the failures. This gives you baseline data and identifies which vendor relationships need immediate attention.
This month: Automate the sniff test. Build a script that compares vendor-provided SBOMs against SBOMs you generate internally. Flag discrepancies automatically. This turns a manual five-minute check into a continuous validation process. If you're using container registries, integrate SBOM validation into your image admission policies.
This quarter: Update vendor contracts. Add SBOM quality requirements to your procurement process. Specify minimum completeness standards, required metadata fields, and update frequency. Make SBOM validation a gate in your vendor risk assessment program. Vendors who can't meet these requirements either need to improve their tooling or lose your business.
Ongoing: Track SBOM quality metrics. Measure how many vendor SBOMs pass your sniff test each month. Track the time required to validate SBOMs. Monitor how quickly you can answer "are we affected?" when new vulnerabilities emerge. These metrics justify investment in better tooling and demonstrate the value of SBOM requirements to leadership.
The sniff test isn't about perfection. It's about quickly identifying SBOMs that won't help you during an incident. When you're responding to a critical vulnerability at 2 a.m., you need to know within minutes whether you're affected. An incomplete SBOM turns that five-minute check into a five-hour investigation.
