Software supplier security: follow the evidence to the product you are buying

The security pack names the supplier. The contract names the product. Before an application security lead signs off the purchase, those two scopes need to meet.

A corporate development policy might be relevant across the supplier’s portfolio, or it might describe a process that a newly acquired product has not yet adopted. A testing report might cover the hosted service but exclude the connector your organisation plans to install. The buying decision turns on what the evidence actually covers.

This does not require collecting every document the supplier owns. It requires a coherent explanation of how the software you will depend on is designed, built, released and maintained, supported by evidence proportionate to its role in your business.

Use a framework to open the conversation

NIST’s Secure Software Development Framework, version 1.1, provides a vocabulary for secure-development practices and explicitly supports communication between purchasers and suppliers. It is a useful basis for questions about a development lifecycle; a supplier’s mapping to it is not, by itself, evidence that those practices operate for your product.

Be precise about the reference used. NIST published SSDF version 1.2 as an initial public draft. A supplier describing alignment with that document should identify it as a draft, rather than presenting the revision as a final requirement. The distinction keeps both parties clear about what has been assessed.

For the application security lead, the most useful questions are product-specific. Who can change code that ships to customers? How is a security-relevant design change reviewed? What prevents an unauthorised build from becoming a release? What happens when a dependency is discovered to be vulnerable after shipment?

Each question should lead to a practice and an example of that practice in operation. A policy establishes intent. A redacted review, release record or remediation history can help show how the intent becomes work.

Ask the development team to walk through one change

Choose a recent, ordinary change with security implications, such as a new integration or a change to administrative access. Ask how it moved from design to production. That walkthrough can connect several otherwise isolated pieces of assurance.

Microsoft’s published Security Development Lifecycle practices include security design review, securing the engineering environment, security testing, and monitoring and response. The useful lesson for a buyer is the spread across the lifecycle. A test at the end is only one part of the story.

For the chosen change, establish what the team considered before coding, how the implementation was reviewed, what was tested and who accepted any remaining issue. Then connect the evidence to the release delivered to customers. The exercise should expose where the process depends on an individual judgement, an automated check or an exception.

Do not assume automation makes a control stronger in every case. An automated check with narrow coverage may be useful but incomplete. An experienced review can address something that a scanner cannot, yet still need consistency and a record of the decision. The assessment is about the risk being handled and the quality of the evidence.

A component inventory needs a coverage boundary

Dependency tooling makes the same scope problem visible. GitHub documents its dependency graph as a summary of manifest and lock files, supplemented by submitted dependency information. The feature supports specified package ecosystems and can export a software bill of materials.

That is useful evidence, but a repository-derived inventory should not automatically be treated as a complete account of everything deployed. Ask the supplier how the inventory relates to the shipped release, and what covers components outside the recognised manifests. The question is about coverage, not whether a particular tool has an impressive feature list.

For a packaged product, the relevant boundary may include a container image, bundled components and an installer. For a hosted service, the buyer may need a supplier response about the affected service rather than a file describing one repository. The evidence should help answer whether a disclosed issue affects the software you use and what action is required.

This is also why the presence of a component does not settle exploitability. Ask how the supplier determines whether the vulnerable functionality is used, exposed or otherwise relevant to the deployment. A component list and an impact assessment are related pieces of evidence with different jobs.

Resolve the gap while you still have a buying decision

Consider a hypothetical supplier that has recently acquired the product you are evaluating. Its corporate security pack describes the parent company’s development process, while the acquired team still uses a separate build system. The correct conclusion is that the parent-company description has not yet established assurance for that build path.

There may be a workable interim arrangement. The acquired team could provide its own review and release evidence, with a defined transition to the parent process. Alternatively, a critical control may be absent. Those situations should not receive the same answer merely because both suppliers return a completed questionnaire.

Request a proportionate way to resolve uncertainty. Where full technical reports cannot be shared, a redacted report, scoped independent assessment or controlled walkthrough may establish enough for the decision. Make clear which question the alternative evidence answers. More pages do not compensate for missing product coverage.

Keep the wider supplier cyber assessment distinct. Corporate access, continuity and broader service risk matter, but this review concerns how the particular software is developed and maintained.

The response commitment becomes part of the product

Security assurance continues after purchase. Ask how your organisation would hear about a vulnerability affecting its version, how the supplier distinguishes a workaround from a permanent fix, and what support remains available near the product’s end of life.

A useful commitment identifies a route to an informed response, not just an acknowledgement from a generic support desk. The application security lead needs to know who can assess the affected deployment and how that assessment reaches the team responsible for remediation. Procurement can then put the relevant obligations into the commercial agreement.

The next evidence request should be a product-specific SBOM request tied to the release and decision you need to support. Used alongside development and response evidence, it helps the buying team understand the actual dependency it is accepting.