Dependency Dossiers: Turning SBOMs into Commercial Leverage for UK Buyers

Software bills of materials have a familiar failure mode in UK procurement. A supplier attaches a CycloneDX or SPDX file to a security questionnaire, the file is stored against the contract, and no one looks at it again until an incident prompts a hurried search. The document satisfies a checkbox; it does not change a decision. That is a missed opportunity. An SBOM is most useful when treated as a dependency dossier: a maintained record that informs risk acceptance, renewal leverage and incident response.

Ask for evidence that supports a decision

An SBOM received as a one-off spreadsheet is difficult to trust and harder to use. Procurement teams should begin with a small set of questions that establish whether the document can support a commercial or security decision. Which product and version does the SBOM describe? Does it cover runtime components, container images, firmware and bundled third-party libraries, or only the top-level application? Is it machine-readable, and in which schema? Who maintains it, how often is it refreshed, and through which channel will updates arrive?

The supplier should also be asked how it handles vulnerability disclosure. Does it issue VEX statements explaining whether a known vulnerability affects the product? Can it provide a component inventory for a specific release rather than a generic product family? What happens at end of support, when components may remain in use but no longer receive updates? These questions do not require a security team to review every line. They test whether the supplier has a repeatable process or has produced a document for the procurement exercise alone.

For UK organisations, the framing matters. The National Cyber Security Centre has long encouraged software supply chain assurance, and public sector buyers increasingly expect component transparency in security schedules. But the commercial benefit should not be overlooked. A supplier that can answer dependency questions quickly is usually easier to manage during an incident and easier to hold to a remediation timetable.

Triage transitive dependencies by exposure, not count

Transitive dependencies are where SBOM programmes often stall. A mid-sized application can list hundreds of components, many of them indirect, and a raw count of known vulnerabilities is not a useful risk measure. Buyers should resist the temptation to demand zero vulnerable components. That goal is unrealistic and encourages suppliers to minimise disclosure rather than improve engineering.

A more practical approach is to prioritise by exposure. Which components are reachable at runtime? Which sit in internet-facing services or privileged management planes? Which are compiled out, disabled by configuration or covered by a compensating control? Ask the supplier for VEX statements where available, and sample the SBOM against public advisories for the components that matter most. The aim is not perfect completeness on day one. It is a defensible method for deciding where to press for evidence and where to accept residual risk.

Buyers should also ask how the supplier tracks transitive dependencies after release. A component list that is accurate at contract signature but never refreshed is of limited value. The stronger position is a contractual right to an updated SBOM at defined intervals and after critical vulnerabilities. That right turns a static artefact into a working input for incident response and renewal discussions.

Put clauses in the standard pack

SBOM clauses should not be bespoke for every agreement. A standard clause set, tiered by supplier criticality, keeps procurement moving while giving security and contract teams a consistent baseline. For high-risk suppliers, require an initial SBOM before go-live, an updated SBOM for material releases, a quarterly refresh for critical products, and a refreshed SBOM within five working days of a critical vulnerability affecting a listed component. Lower-risk suppliers can be asked for an annual refresh and on request.

Define the accepted formats and minimum fields in the security schedule. State that the SBOM must be machine-readable, identify the product and version, list components with versions and identifiers where available, and describe dependency relationships. Include an acceptance criterion that the supplier confirms the scope of the SBOM and any known exclusions. Avoid language that treats an SBOM as a warranty of security; it is an assurance input, not a transfer of liability.

Confidentiality also needs attention. A detailed component list can reveal architecture and supplier choices. Use the existing NDA or a secure evidence repository rather than allowing SBOMs to circulate as email attachments. For renewal, include a right to request a current SBOM and a final component inventory on exit. These terms are modest, but they give the buyer something concrete to compare when contracts come up for review.

Measure the habit, not the artefact

A procurement advantage appears when SBOMs become comparable across suppliers. Track a small number of measures: the proportion of critical products with a current SBOM, the time taken to receive an updated SBOM after a critical vulnerability, the proportion of material releases accompanied by VEX statements, and the supplier's response time to dependency questions. Review these in quarterly service meetings rather than filing them away.

That evidence changes the renewal conversation. A supplier that maintains its dependency dossier can demonstrate operational discipline. A supplier that cannot may still be viable, but the buyer can price the assurance gap into the decision, ask for a remediation plan or require additional controls. In 2026, SBOMs should not be treated as a compliance ritual. Used as a maintained dossier, they give UK organisations a practical way to question vendors, triage transitive risk and negotiate from evidence rather than assumption.