Why receiving a list does not mean it is usable
Consider a hypothetical enterprise buying access control management software. At the security team's request, it added one sentence to the contract: "The supplier shall provide a software bill of materials." At go-live the supplier sent a spreadsheet listing a few dozen component names, with no version numbers and no indication of which release the list described. Six months later a serious vulnerability was disclosed in a widely used open-source component. The security team wanted to confirm whether the access control software was affected but found that the list could not answer the question. They had to email the supplier and wait a week for a reply. The list existed, but it did not help when it was most needed.
The U.S. National Telecommunications and Information Administration published its minimum elements for a software bill of materials in 2021, grouping the requirements into three categories: data fields, automation support, and practices and processes. The data fields include supplier name, component name, component version, other unique identifiers, dependency relationships, the author of the SBOM data and a timestamp. Automation support calls for common machine-readable formats. Practices and processes cover update frequency, depth, how "known unknowns" are stated, distribution and access control. In 2025 the U.S. Cybersecurity and Infrastructure Security Agency released an updated public comment draft proposing additional elements such as component hash, license, tool name and generation context; for now it should be treated as a draft rather than a final document.
Write acceptable requirements into procurement clauses
JOTOglobal suggests that the procurement lead and the security lead write the requirements into a technical annex together, instead of leaving a single statement of principle. The annex should at least specify which machine-readable format is used; that every release and patch version comes with its own matching SBOM; how deep the SBOM must go, for example listing at least direct dependencies and stating the coverage of transitive ones; that anything that cannot be confirmed is explicitly marked as unknown rather than omitted; and the delivery method, update deadline and who receives it. If the software is delivered as a cloud service and the enterprise cannot obtain an installable package, require the supplier instead to describe its component management and vulnerability response process, and agree how quickly it will state whether the service is affected when a public vulnerability appears.
The clauses should also set out internal responsibilities for receiving and keeping the SBOM. An SBOM may expose technical details of the supplier, so the enterprise should limit who can view it and store it according to the confidentiality terms in the contract. For critical systems, the enterprise can also require a vulnerability statement accompanying the SBOM that indicates whether a known vulnerability is exploitable in the product, reducing the effort of checking each one. All these requirements should be raised at the tender stage, so suppliers can assess whether they can meet them, rather than added at acceptance and causing contract disputes. During evaluation, a sample SBOM can be one of the scoring items, with bidders asked to provide a real SBOM for a comparable product for the technical team to read.
Accept the delivery in three steps
The first step is a format and completeness check. The security team opens the SBOM with a common open-source or commercial tool, confirms that the file can be parsed, that every component has a name, version and unique identifier, and that the author and generation time are filled in, and checks that the product version stated in the SBOM matches the software actually delivered. The second step is a sample comparison. Engineers install the software in an authorized test environment, pick several major components and compare the version shown in installation directories, package information or at runtime with what the SBOM records. Where they differ, the discrepancy is recorded and the supplier is asked to explain or regenerate the SBOM.
The third step is a trial of a real query. The security team picks a recently disclosed vulnerability, assumes it must confirm whether the product is affected, searches with the SBOM in the asset or vulnerability management system, and records how long it took to reach a conclusion and whether the supplier still had to be contacted. If the results need a great deal of manual judgment, the identifiers or depth of the SBOM are not yet sufficient, and this should be listed in the acceptance opinion with an agreed date for correction. The results of the three steps, the issues found and the supplier's replies all go into the acceptance report, signed jointly by procurement, security and the system owner. If the supplier still cannot fill in key fields by the agreed deadline, the acceptance report should state how the related payment milestone or retention condition will be handled, and the procurement lead follows up.
Maintenance after go-live, common mistakes and limits
After go-live, the system owner ensures that the SBOM is updated with every upgrade and that it is linked to the specific deployed instance in the asset management system. If SBOMs are kept only in a shared folder, the matching version is often impossible to find when a vulnerability appears. One common mistake is to treat the SBOM as a one-time deliverable that is never updated after sign-off. Another is to believe that having an SBOM means the software is secure. In fact the SBOM only says what is inside; it does not say whether those components have exploitable vulnerabilities, which still requires vulnerability intelligence, supplier advisories and testing where needed.
The clause points and acceptance steps in this article are organizational guidance from JOTOglobal and do not constitute legal advice; specific contract wording should be decided by the enterprise's legal team in light of local regulations and the supplier's situation. The minimum elements document is aimed mainly at U.S. federal procurement, and other regions and industries may have different mandatory requirements. Suppliers of small or custom software may find it hard to meet every requirement at once, so the enterprise can tier the requirements by system importance and agree a timetable for gradual compliance in the contract. Material descriptions for cloud services, hardware firmware and AI models are still evolving and should be assessed against what suppliers can actually provide.