When you're evaluating a new software vendor, understanding what you're actually buying is crucial. This means knowing the components, dependencies, and third-party libraries within their product. A Software Bill of Materials (SBOM) provides this visibility, but only if you request the right information.
This guide helps you request an SBOM from vendors during procurement, explains the significance of each field for your risk posture, and shows you how to validate what you receive.
Purpose of the Template
Use this template when you're:
- Conducting vendor due diligence during software procurement
- Renewing contracts with existing software providers
- Responding to audit findings about third-party software risk
- Building an inventory of software components across your environment
The template requests the minimum elements outlined in joint guidance from CISA, FBI, NSA, and 15 international cybersecurity authorities. The latest update includes ten additional data fields and clarifications to eight existing components, reflecting how SBOM tooling has matured since 2021.
Prerequisites
Before you send this request:
Confirm your legal right to request an SBOM. Review your contract language. If you're still negotiating, add SBOM delivery as a contractual requirement. If the contract is signed, check whether your security audit rights extend to component-level transparency.
Identify your format preference. The three main SBOM formats are SPDX, CycloneDX, and SWID. Most vulnerability scanning tools support at least one of these. Check your tooling before specifying a format in your request.
Determine your update cadence. SBOMs go stale quickly. Decide whether you need updates quarterly, with each release, or when critical vulnerabilities emerge in common components.
Know your cloud and AI requirements. If you're procuring software-as-a-service solutions or AI-based systems, you'll need additional fields beyond the baseline minimum elements. These environments require further transparency efforts.
The Template
Subject: SBOM Request for [Product Name] Security Review
Dear [Vendor Contact],
As part of our software security evaluation process, we're requesting a Software Bill of Materials (SBOM) for [Product Name]. This request aligns with guidance from CISA and international cybersecurity authorities on software supply chain transparency.
Please provide an SBOM that includes the following minimum elements:
Component Information:
- Component name
- Component version
- Unique identifier (such as Package URL or CPE)
- Supplier name
- Cryptographic hash of the component
Dependency Mapping:
- Relationship data showing how components connect
- Dependency depth (direct vs. transitive dependencies)
- Known vulnerabilities (CVE identifiers where applicable)
Metadata:
- SBOM author and timestamp
- SBOM format and specification version
- Component license information
Additional Fields:
- Component download location or repository
- Primary component purpose or function
- Verification method for component integrity
- Pedigree information (how the component was obtained or modified)
- Component supplier contact information
- External references (security advisories, documentation)
- Release notes or change log references
- Component end-of-life or support status
- Known configuration dependencies
- Runtime environment requirements
Format and Delivery:
- Preferred format: [SPDX / CycloneDX / SWID]
- Delivery method: [secure file transfer / vendor portal / email encryption]
- Update frequency: [quarterly / with each release / upon request]
For Cloud-Based or AI Solutions:
If [Product Name] operates as a service or incorporates AI components, please also include:
- Container and orchestration layer components
- Model training data sources and lineage (for AI systems)
- Third-party API dependencies
- Infrastructure-as-code components
Please deliver the SBOM within [timeframe, typically 10-15 business days]. If any requested elements are not available, provide an explanation and timeline for when they will be included.
Contact me at [your email] with questions or to schedule a discussion about your SBOM generation process.
[Your Name]
[Your Title]
[Organization]
Customizing the Template
Adjust the component depth based on your risk appetite. For critical infrastructure or high-risk environments, specify that you need transitive dependencies mapped to at least three levels deep. For lower-risk applications, direct dependencies may suffice.
Tailor the update frequency to your vulnerability management cadence. If you scan for vulnerabilities weekly, quarterly SBOM updates leave you exposed. Request updates aligned with your scanning schedule, or ask for notification when components with known CVEs are updated.
Add industry-specific requirements. Healthcare organizations should request confirmation that components comply with HIPAA Security Rule requirements. Financial services firms may need components mapped to GLBA Safeguards Rule controls. Don't assume the vendor knows your regulatory context.
Specify your verification needs. If you'll be validating cryptographic hashes yourself, request the specific hash algorithm (SHA-256 is standard). If you're using automated SBOM analysis tools, confirm the format is compatible with your tooling.
Scale the request for vendor size. A three-person startup won't have the same SBOM maturity as an enterprise vendor. For smaller vendors, focus on the core component list and known vulnerabilities first, then work toward the full minimum elements over time.
For SaaS procurement, add service-layer transparency. Request information about the runtime environment, container registries, and third-party cloud services the vendor depends on. These aren't captured in traditional SBOMs but create supply chain risk in cloud environments.
Validation Steps
Once you receive the SBOM:
Check completeness against your request. Open the file in an SBOM viewer or text editor. Verify that all requested fields are populated, not just present but empty. If supplier contact information is missing for third-party components, you can't reach them when a vulnerability drops.
Cross-reference components with known vulnerabilities. Feed the SBOM into your vulnerability scanner or use a free tool like OWASP Dependency-Check. You should immediately see any components with published CVEs. If nothing flags, either you're lucky or the component identifiers are malformed.
Validate cryptographic hashes. If the vendor provided hashes, spot-check a few components by downloading them from their stated repositories and generating hashes yourself. Mismatched hashes mean either the SBOM is outdated or the vendor doesn't have strong component verification processes.
Assess dependency depth. Look for how many layers of transitive dependencies exist. If you see only direct dependencies in a complex application, the SBOM is incomplete. Modern applications routinely have dependencies that pull in dozens of additional libraries.
Review license compatibility. If you're in a regulated industry, certain open-source licenses create compliance risk. Check that component licenses are documented and compatible with your organization's policies.
Test the update process. Don't wait until a critical vulnerability emerges to find out the vendor can't deliver updated SBOMs quickly. Request a test update within 30 days of receiving the initial SBOM to confirm their process works.
Document gaps and negotiate remediation. If the vendor can't provide certain elements, document what's missing and get a written commitment on when they'll be available. This becomes part of your vendor risk register.
You're not just collecting a document. You're building visibility into software supply chain risk that didn't exist before. When the next major vulnerability hits a widely used library, you'll know within minutes whether your vendors are exposed, not weeks later when they finally release a patch.
