Skip to main content

Leverage framework built by the pros to write your next software development contract

  

With the cyber threat landscape as dangerous as it is, development shops need all the guidance they can get to build secure software. Fortunately, the National Institute of Standards and Technology (NIST) created the Secure Software Development Framework (SSDF) in response to Executive Order 14028 and the infamous cyberattack on the Colonial Pipeline.

Here’s how you can leverage this framework to write robust software development contracts and ensure developers are following best practices.

What is SSDF?

SSDF is a set of cybersecurity guidelines intended to reduce the number of vulnerabilities in software used by federal agencies. But it can apply to any organization, and it’s worth building into your software development contracts.

Build SSDF Cybersecurity Fundamentals into Your Contracts

Software developers in any sector can (and should) compare their own practices to the SSDF to find weaknesses and liabilities when developing software. NIST defines four best-practice categories in their approach to standardizing federal cybersecurity to give agencies an idea of what a well-secured network looks like.

  • Prepare the Organization (PO): Ensure that your organization is prepared to develop software securely.

  • Protect the Software (PS): Protect all components of your software from potential threats.

  • Produce Well-Secured Software (PW): Produce secure software with minimal vulnerabilities upon release.

  • Respond to Vulnerabilities (RV): Identify and address any residual vulnerabilities in released software, and work to prevent future vulnerabilities.

Understanding NIST’s fundamental categories for sound and secure software will help identify which requirements to build into development contracts. Consider leveraging some or all of the following ten steps into contracts to strengthen your cybersecurity efforts.

  1. Define criteria for software security checks.

  2. Protect all forms of code from unauthorized access and tampering by safeguarding the development, build, distribution, and update environments and following the principle of least privilege.

  3. Provide a mechanism for verifying software release integrity by digitally signing the code throughout the software lifecycle.

  4. Verify that third-party software complies with security requirements.

  5. Configure the compilation and build processes to improve executable security.

  6. Test executable code to identify vulnerabilities and verify compliance with security requirements.

  7. Review and/or analyze human-readable code to identify vulnerabilities and verify compliance with security requirements.

  8. Configure the software to have secure settings by default.

  9. Archive and protect each software release.

  10. Identify, analyze, and remediate vulnerabilities continuously.

Considerations for SSDF as a Guide

While the SSDF provides a great foundational framework for secure software development, there are considerations to take into account regarding which practices can realistically be implemented. Time and resources are precious commodities in software development. It helps to consider your most limited commodity and prioritize around that to minimize risk — of either a failed software delivery or a successful cyberattack.

Risk

While planning for software development, with all its processes and milestones mapped out, consider what might be put at risk with certain requirements. Can dates be met the number of rigorous security and QA checks needed? What about the financial risk if a process takes longer or needs more resources than expected?

Cost

With regard to financial risk, there may effectively be budgetary limits on which requirements can be implemented. If this is the case, prioritize the ones that will keep the network most secure from threat actors.

Feasibility

Is there access to the right resources to address the requirements and make the security checks planned for the contract? Are the requirements excessively cautious or overly restrictive? Are you asking too much? It might be worth consulting with a developer before submitting your contract if you’re unsure.

Applicability

Are the requirements really applicable for the end product? Are they going to help in its development or just cost more time and resources?

Automatability

Planning for growth is important for any organization. Consider which requirements are scalable. Automating some of them may also help keep costs down in the long run.

Dependencies

Consider cybersecurity practices in place: make sure new requirements won’t disrupt valuable existing processes.

Stay Informed to Stay Ahead

Even for those not developing software themselves, it pays to stay up to date on the latest fundamental cybersecurity measures. To further stretch and test your knowledge, try hosting cyber wargames within your organization or learn more about malware and shadow IT.

Tags:

federal