Secure software delivery: an SSDF-informed checklist for buyers and teams

Make security part of the delivery agreement

A software project needs a shared understanding of what secure delivery means in its context. Identify the information the application handles, the people who can access it and the actions that could cause significant harm. Use those facts to define requirements and review activities. A generic promise to follow best practices is difficult to verify at acceptance.

NIST's Secure Software Development Framework version 1.1 provides high-level practices that can be integrated into a development lifecycle. It is intended to help reduce vulnerabilities, address their effects and improve underlying development practices. [1] The checklist here is an implementation aid informed by that framework, not a claim that a project is certified or free from vulnerabilities.

Review the design before implementation hardens

Map the main data flows and trust boundaries. Identify where authentication and authorisation occur, where sensitive information is stored and which external services are trusted. Review plausible misuse cases alongside normal user stories. For example, a user who can view their own records should not be able to retrieve another customer's records by changing an identifier.

Turn important findings into explicit requirements and acceptance checks. Name the owner of each unresolved risk and the decision needed. Keep the review proportional to the application, but revisit it when new integrations or privileged features change the design. A short maintained record is more useful than a large assessment that no longer describes the system.

Protect source, dependencies and build access

Control who can change production code and release configuration. Use review appropriate to the change and protect the credentials used by build systems. Separate ordinary development activity from the authority to publish a production release where the environment supports that separation. Record exceptions so they can be reviewed rather than becoming invisible permanent access.

Track the third-party components included in the delivered application. Ask how versions are selected, how vulnerability information is assessed and who decides when an update is required. A component inventory helps investigation, but its existence alone does not establish that dependencies are safe. The team needs an operational process for evaluating and acting on relevant findings.

Make verification relevant to actual risk

Combine review and automated checks with tests of important security behaviour. Test access boundaries, input handling and failure paths using the real application design. A scanner may identify useful issues, but it cannot establish that every business rule is enforced. Prioritise findings according to exposure, impact and available mitigations rather than treating all tool output as equally urgent.

Use representative test data that does not unnecessarily expose live personal or confidential information. Keep evidence of what was tested, which release it applies to and any accepted limitations. When a defect is fixed, verify the intended behaviour and consider a regression check that would detect its return. Do not present a passing test suite as a guarantee against future discovery.

Keep release identity and rollback clear

Identify the artifact being deployed and the source revision from which it was built. Record relevant configuration and approvals. Reduce manual changes that cannot be reproduced, and protect release artifacts against unauthorised modification. Operators should be able to determine what is running without relying on a developer's memory.

Plan rollback and recovery alongside deployment. Database changes can make a simple application rollback unsafe, so rehearse the actual sequence and define decision points. Verify monitoring, logging and access configuration in the target environment. A release is not complete merely because the application starts; its essential workflows and operational controls need validation.

Agree maintenance and vulnerability response

Before handover, name the party responsible for receiving vulnerability reports, assessing exposure, preparing fixes and communicating with affected stakeholders. Specify support boundaries and how ownership changes when a contract ends. Keep an inventory of deployed versions so an issue in a dependency can be traced to the services that use it.

Evo's Software Development service can incorporate these requirements into delivery planning. Ask for a concise evidence pack covering architecture decisions, relevant verification, release identity and maintenance responsibilities. That record makes acceptance more concrete and gives the operations team a stronger starting point when the software enters everyday use.

Frequently asked questions