SBOM Requirements for Software Vendors: What Buyers Ask For

Demand comes from a few directions:

• Government buyers. US federal software supply chain rules that followed Executive Order 14028 pushed agencies to ask suppliers for SBOMs and secure development attestations. Requirements evolve, so check current guidance for any contract.
• Regulated and large enterprise buyers. Security teams add SBOM requests to procurement checklists so they can answer 'are we affected?' within hours when a new vulnerability is announced.
• Insurers and auditors, in some cases, as part of supply chain risk questions.
• Regulation abroad. The EU's Cyber Resilience Act is expected to bring SBOM-related duties for products with digital elements sold in Europe. Ask counsel about timing and scope for your products.

The practical reason is the same everywhere: when a widely used library has a flaw, buyers want to know quickly whether your product contains it.

For a baseline, use the minimum elements published by the US National Telecommunications and Information Administration (NTIA) in 2021:

• Supplier name for each component.
• Component name.
• Version.
• Other unique identifiers, such as a package URL, so tools can match components to vulnerability data.
• Dependency relationships, showing which component includes which.
• Author of the SBOM data.
• Timestamp of when it was generated.

Use a standard format so buyers' tools can read it. The two widely used are SPDX and CycloneDX. Include transitive dependencies (the libraries your libraries use), not only what's in your manifest, because that's where surprises hide. Buyers may ask for more, such as license data, so confirm their expectations in the contract.

Generate them from real builds, not by hand:

1. Choose a format (SPDX or CycloneDX) and a generator that supports your languages and package managers.
2. Run it in CI on every release build, so the SBOM describes exactly what shipped.
3. Include container images if you ship them: scan the image, not only the source repository, since base images add their own packages.
4. Store it with the release, versioned and tied to the build identifier.
5. Sign or checksum it, so a buyer can verify it wasn't altered.
6. Feed it to vulnerability matching. A dependency scanner such as Snyk fits here, since it helps match the inventory against known vulnerabilities and license issues. Confirm in a demo which ecosystems it supports.

An SBOM that's regenerated on every build never goes stale, which is the most common failure of manual ones.

Decide how buyers receive it: a download in a customer portal, an attachment on request or an API. Say how often it updates and how you'll notify customers about significant changes.

When a new vulnerability lands, use the SBOM to answer three questions fast: does any release contain the affected component, is the vulnerable code reachable, and which customers run those releases? Publish your assessment, sometimes as a VEX statement that says whether a product is affected. Then set deadlines. CISA's federal directives required agencies to patch critical vulnerabilities on internet-facing systems within 15 days¹, which is a reasonable yardstick for your own commitments to buyers, though your contracts define the binding terms.

Avoid these failure modes:

• Direct dependencies only. Most risk sits deeper in the tree.
• One-time export. An SBOM made at launch and never updated describes software you no longer ship.
• Missing identifiers. Without versions and package URLs, no tool can match components to advisories.
• Ignoring build tools and images. Base images and build-time packages matter to your customers too.
• No owner. Nobody triages what the SBOM reveals.

Supply chain questions often appear alongside security training and insurance forms, so see the cyber insurance security requirements checklist and the security awareness training guide. To compare scanning approaches, read Snyk vs Veracode vs GitHub Advanced Security.