Software supply-chain security follows the product into operation

A business application brings more than its visible features into the organisation. It also brings a development process, external components, a release pipeline and an ongoing relationship with the people who maintain it. The buyer inherits consequences from decisions it does not directly control.

Software supply-chain security is therefore an operating concern as well as an acquisition concern. For an enterprise buyer, the useful question is how evidence about the purchased product will remain connected to updates, vulnerabilities and the customer’s ability to respond.

A component list needs a route to action

GitHub’s dependency graph uses information from manifests, lock files and submitted dependencies, and supports exporting a software bill of materials. This is useful visibility, with a scope determined by the information supplied and supported.

For a buyer, the next question is which delivered release the information describes. A repository view and an installed product are related, but the relationship needs to be established. Generated artefacts, packaging and deployment choices can affect what the customer actually receives.

Then follow a component issue through the supplier relationship. Who determines whether the product is affected? How will the customer receive the conclusion? If a patch is required, what must the customer test or change? The inventory becomes useful when it supports those decisions.

Updates create a shared operating commitment

The supplier may develop and distribute a fix while the buyer controls a deployment window and a business-critical integration. Both sides can fulfil their narrow responsibilities while the vulnerable version remains in use. Procurement should establish the handover before this becomes an urgent negotiation.

Bring application operations into the discussion. Ask what a significant update would require, which dependencies need compatibility checks and who can approve a temporary restriction. That gives the contract’s support commitments a practical route into the service.

Define what you are buying and relying on

Begin with the product, deployment model and business service it supports. A hosted application, an installed package and a component embedded in your own service create different dependencies. Identify who operates the software, who applies updates and what the organisation must do if support ends.

Do not assume a security answer covering the supplier as a company also covers the specific product or release. Ask about scope, date and exclusions. A document can be genuine and still be insufficient for the decision in front of you.

Use development guidance as a vocabulary

NIST’s Secure Software Development Framework 1.1 provides high-level secure development practices and is intended to support communication between software producers and acquirers. NIST also lists SSDF 1.2 as an initial public draft. Use the published version as the reference for the current assessment and track proposed changes separately.

For buyers, the useful move is to translate the relevant practices into questions about evidence. Which release does the answer cover? Who owns the control? How are exceptions handled? What will be shared with the customer if a vulnerability affects the delivered service?

Do not confuse an inventory with an assurance result

A software bill of materials can help identify components, but the buying decision still needs to establish how the information is maintained and used. Ask which release it describes, how changes are delivered and who investigates when a listed component is reported as vulnerable.

Avoid treating the presence of a document as a pass on its own. Our suggested acceptance test is to trace a hypothetical component issue through notification, impact assessment and remediation. The supplier should explain the process and the evidence available, without pretending a tabletop exercise is proof of every future response.

The same discipline applies to a test report. Check what was tested, when it was tested and which parts of the service were excluded. A useful limitation is one you can understand and decide how to handle; an unexplained assurance badge gives you less to work with.

Make the handover to operations explicit

Procurement may negotiate the contract, but an operating team will live with the update process. Include that team in the evaluation. Confirm how advisories are received, how urgent changes are assessed and who can authorise an emergency update or temporary restriction.

For an illustrative business-critical application, a patch may require a maintenance window and a compatibility check. The buyer therefore needs more than a promise that updates are available. It needs a workable route to assess, deploy and verify them within the service’s constraints. This example is a planning scenario, not a reported supplier failure.

Keep the retained responsibilities visible. If the customer must configure a control, monitor an alert or apply an update, assign an owner before deployment. A contract clause does not automatically create an operating process.

Keep assurance connected to change

Review the evidence when the product’s scope, delivery model or support arrangements change. Reuse valid evidence where appropriate, but do not let a successful procurement exercise become permanent approval for an evolving service. The purpose is to sustain an informed decision about a dependency, not accumulate a folder of documents.

The SBOM requirements guide goes deeper on component information. Use the supplier evaluation guide to connect development claims to the actual product.