Asking vendors for an SBOM and actually using it

Reference article · 6 min read

Many agencies now have a clause in their software contracts requiring a software bill of materials. Far fewer have a place to put one when it arrives, a person assigned to read it, or a plan for the morning a serious vulnerability is announced in a component that may sit inside a dozen systems. An SBOM that lands as an email attachment and is never opened costs the agency negotiating time and returns nothing.

The purpose of the exercise is narrow and worth stating plainly. When a widely used library turns out to be exploitable, you want to answer two questions in hours rather than in weeks of vendor phone calls: which of our systems contain that component, and at which versions. Everything below serves that question.

What an SBOM is, and what it is not

An SBOM is an inventory of the components that make up a piece of software, including open source libraries pulled in as dependencies, with enough identifying detail to match a component against a published advisory. It is not a vulnerability report, not a security assessment, and not a statement that the product is safe. A component list tells you what you have. Deciding whether a listed component is actually reachable and exploitable in that product is separate work, and the vendor is usually the only party who can do it.

A federal executive order on cybersecurity issued in 2021 moved SBOM into mainstream software procurement, and the National Telecommunications and Information Administration published a set of minimum data elements in response. CISA has continued to develop guidance since. Federal direction in this area has been revised more than once and state requirements vary, so confirm current obligations with the official source and your own counsel rather than with a summary like this one.

Specify format and cadence in the contract

Two machine-readable formats dominate: SPDX and CycloneDX. Both are maintained by established organizations, both have been taken up by standards bodies, and both are supported by common tooling. Name one, or accept either, and require a machine-readable serialization such as JSON or XML. A PDF list of marketing names is not an SBOM, because nothing in it can be matched against an advisory for a specific library version.

Cadence matters as much as format:

• An SBOM with each delivered release or version you install, accept, or renew.
• An updated SBOM when the component inventory changes, not on an annual calendar. For continuously delivered software, set a refresh interval and require an update on material change.
• A delivery channel that is not email. A portal, a repository, or an endpoint your staff can pull from without opening a ticket.
• A named contact accountable for SBOM accuracy and for answering component questions during an incident, with a stated response window.

Minimum fields to insist on

Track the published minimum elements rather than inventing your own list. At a minimum, each component entry should carry the supplier name, the component name, the component version, a unique identifier such as a package URL or CPE, the dependency relationship showing what depends on what, the author of the SBOM data, and a timestamp.

Add two more if you can get them. License information, because it answers a different set of legal questions from the same document. And a companion VEX statement, or vulnerability exploitability exchange, in which the vendor says whether a known vulnerability in a listed component actually affects their product. VEX is what keeps an SBOM from generating hundreds of false alarms.

SaaS versus installed software

For software you install and run, insist on a per-version SBOM covering what you actually deploy, including container images if the product ships that way. This is the strong case, and vendors who build modern pipelines can generate it automatically.

For SaaS, adjust expectations without abandoning the requirement. You do not operate the system, the vendor may change components weekly, and a point-in-time inventory ages quickly. What you can reasonably require instead is a current SBOM for the service on request, a commitment to notify you within a defined period when a component with a critical vulnerability is present in the environment, and a written description of their remediation timelines. Pair it with whatever independent assessment evidence the vendor holds. The SBOM supports those obligations; it does not replace them.

Store it so you can search it during an incident

An SBOM you cannot query is a filing-cabinet exhibit. Decide before the first delivery where these files live, who owns that location, and how someone searches across all of them at once.

• Keep SBOMs in one repository, tied to the system inventory entry for the product and to the contract number.
• Preserve every version. You need history to know what a system contained last quarter.
• Use tooling that ingests SPDX or CycloneDX and supports a component-and-version search across all stored documents. Several open source and commercial options do this, and a modest scripted approach over JSON files is better than nothing.
• Run a dry run. Pick a real component, search for it, and time how long the answer takes.

When the vendor refuses or sends something useless

Refusal is a finding, not a dead end. Ask what is behind it. Some vendors have no build pipeline capable of generating an inventory, which tells you something about their engineering maturity. Some are worried about disclosing proprietary structure, which is usually addressable with confidentiality terms and controlled distribution.

If the delivered file is a PDF of product names, reject it in writing as nonconforming and cite the format clause. Give a cure period. If the SBOM is machine-readable but shallow, listing only top-level components with no transitive dependencies, say so specifically and ask for the depth of the dependency graph the tooling can produce, along with a statement of known unknowns. For legacy systems where generation is genuinely infeasible, document the gap, record the compensating controls, and set a date to revisit at renewal.

How to start

1. Add SBOM language to new solicitations before retrofitting existing contracts, and use renewals as the retrofit opportunity.
2. Ask candidate vendors during evaluation: what format do you produce, what tool generates it, how deep does it go, how often is it refreshed, and do you publish VEX statements.
3. Request a sample SBOM for an existing product as part of the response. The sample tells you more than the answer does.
4. Stand up the repository and the search method before the first delivery arrives.
5. Assign an owner, and give that person the authority to reject a nonconforming delivery.

HQT works with state and local agencies on software development, security, and the contract and engineering practices that sit between them.

Frequently asked questions