SBOM requirements: ask for a file your security team can actually use

An SBOM attached to a procurement response can satisfy a document request while leaving the security team unable to answer its first operational question: does this describe the software we run? For an application security lead, the requirement should end with a usable investigation workflow, not a file delivered to a buyer’s inbox.

A software bill of materials identifies components and associated information about a software product. Its value depends on scope, identity and currency. Before specifying a format, agree which deployed product the organisation needs to investigate and who will use the information when a vulnerability is disclosed.

Bind the document to the release

Ask for the product name, edition, release identifier and the build or artefact identifier used to distinguish the delivered software. Where an artefact digest is available, agree how it maps to the installed package or image. Record the document’s creation time and generation method. A date alone cannot establish which release it describes.

Separate the vendor’s repository, built package and deployed system. GitHub’s SBOM export documentation says its repository export represents the current dependency graph in SPDX format. It includes dependency information such as versions and package identifiers, and excludes dependents: other projects that rely on the repository. That is a useful, defined output. A buyer still needs evidence connecting that output to the supplied release.

Consider a hypothetical supplier that sends a repository export generated today while the enterprise runs an older appliance release. The file may be valid and the supplier may be cooperative, but neither fact proves coverage of the appliance. Ask for the release mapping and explain the gap before passing the requirement.

For a hosted service, discuss what the supplier can identify as a release or deployment and how customers learn that its composition has changed. Do not force a desktop-package model onto a continuously updated service, or accept “SaaS” as an explanation for having no useful component or change information.

Require an explicit scope, including what is unknown

State whether the requested inventory covers application dependencies, transitive dependencies, bundled operating-system packages, containers, plugins and separately supplied components. Ask how dynamically loaded or customer-added elements are treated. The appropriate boundary follows the product being purchased; it is not identical for every supplier.

The CycloneDX specification can describe direct and transitive dependency relationships, services and composition completeness. Its completeness vocabulary includes incomplete and unknown states. These are useful distinctions for procurement: a declared limitation gives the receiving team something to investigate. A bare “complete” claim without a generation boundary does not.

Request the reason for each material omission and the plan for resolving it. Separate a known exclusion from a component the supplier has not been able to identify. Both can create uncertainty, but they require different follow-up.

Agree the format and exact schema version with the team that will ingest the file. “Industry-standard SBOM” is not sufficiently precise. A newer specification can represent information that an older receiving tool ignores, while an accepted older version may omit a capability you need. Validate a sample through the actual ingestion path before making that version a contractual deliverable.

Give procurement a requirement that can be accepted

A concise request can specify five things without becoming an indiscriminate questionnaire:

1. Product binding: the release and artefact to which the SBOM applies, with a mapping to the supplied software.
2. Coverage: component types, dependency depth and known exclusions, with the generation method and creation time.
3. Usable identity: component names, versions and appropriate ecosystem identifiers, such as Package URLs where applicable, with dependency relationships needed by the receiving workflow.
4. Delivery and change: agreed format version, secure delivery route, updates for relevant releases and corrections when material inaccuracies are discovered.
5. Operational support: a supplier contact and agreed response process for vulnerability applicability questions, fixes and mitigations.

Set acceptance around what the team can demonstrate: the document parses, its release matches the purchased artefact, important identifiers survive ingestion and declared exclusions remain visible. Syntax validation confirms structure. It does not independently establish that every component is present.

Rehearse the vulnerability question

Dependency-Track’s documentation makes component identity operationally concrete. Its analysers use identifiers such as CPEs and Package URLs to match components against vulnerability intelligence, with different requirements for different sources. A spreadsheet of approximate library names is therefore not interchangeable with information the selected analyser can reliably match.

Using a safe sample, ask the receiving team to locate a known component, associate it with the relevant product release and route a finding to an owner. Check the outcome when an identifier is missing or ambiguous. The workflow should expose uncertainty rather than reporting an apparently clean product because nothing matched.

Then separate presence from applicability. A matching component and version is a reason to investigate whether the vulnerable code and necessary conditions are present in the supplied product. Ask the supplier for the basis of its conclusion, affected releases and remediation options. Treat an assertion that a product is unaffected as attributable supplier evidence, not an independent test performed by your team.

The response owner must also connect the product to installations and service owners. Knowing that a component appears in a release is of limited use if nobody can find where that release is deployed. Keep that asset mapping in the operational inventory and link it to the SBOM record.

Keep the requirement useful after signature

Retain the history needed to investigate older deployed releases. Test how corrected SBOMs are distinguished from previous files, how new releases trigger delivery and who follows up a missing update. An initial document can become stale while the contract remains compliant with vague wording.

An SBOM supports transparency; it does not establish secure development, absence of unknown flaws or readiness to respond. Use it as one part of a product-specific review of software supplier security evidence. The strongest procurement outcome is a file the team can use, a clear statement of its limitations and a supplier process that answers the next question.