SSDF Compliance Meets Zero Trust for Code: Execution Governance

With the cyber threat landscape as dangerous as it is, development organizations need all the guidance they can get to build and procure software securely. NIST created the Secure Software Development Framework in response to Executive Order 14028 and the demonstrated risks that incidents like the Colonial Pipeline attack exposed.

SSDF is a strong foundation for secure software development contracts. It is also a framework that governs the build side of the software lifecycle. What it does not address is the execution side: what delivered software artifacts will do when they run. Both sides of that equation belong in a well-written software development contract, and here is how to build them in.

What SSDF Governs

SSDF defines four best practice categories. Prepare the Organization to ensure your organization is structured to develop software securely. Protect the Software covers protecting all components from potential compromise throughout development. Produce Well-Secured Software focuses on releasing software with minimal exploitable vulnerabilities. Respond to Vulnerabilities addresses identifying and remediating vulnerabilities in released software and preventing future ones.

Vendor attestation to SSDF practices confirms that a supplier’s development process meets defined standards. That confirmation is meaningful for supply chain governance. What it does not confirm is what the resulting artifacts can do when they execute in your environment. A vendor can fully comply with SSDF and still deliver software that contains behavioral capabilities your organization has never authorized.

Build SSDF Fundamentals into Your Contracts

The following ten areas give contracts a solid security foundation and are drawn directly from SSDF for best practices. Define criteria for software security checks throughout the development of lifecycle. Protect all forms of code from unauthorized access and tampering by following least-privilege principles across development, build, distribution, and update environments. Provide a mechanism for verifying software release integrity by digitally signing code throughout the lifecycle. Verify that third-party software complies with your security requirements before integration. Configure compilation and build processes to improve executable security. Test executable code to identify vulnerabilities and verify compliance with security requirements. Review human-readable code to identify vulnerabilities and verify compliance. Configure software to secure settings by default. Archive and protect each software release. Identify, analyze, and remediate vulnerabilities continuously post-release.

Contract Considerations Worth Thinking Through

Time and resources are finite in every development engagement, so a few lenses help prioritize which requirements to include and how strictly to enforce them.

Risk asks what is put at risk by including or excluding a specific requirement and whether delivery timelines can absorb the security checks planned. Cost means that when trade-offs are necessary, you should prioritize requirements that protect the highest-value systems and highest-risk execution environments. Feasibility asks whether the resources are available to execute the requirements and whether the scope is realistic for the vendor you are engaging.