The National Institute of Standards and Technologies (NIST) Secure Software Development Framework (SSDF, and its UK counterpart, Code of Practice for Software Vendors) is meant to address the fact that most organizations tend to tack on security at the end of their Software Development Lifecycle (SDLC) rather than making the implementation of security a key goal throughout the process. In other words,the outcome of:

• A typical software development process is a tremendous amount of work for the security team in a very short amount of time, usually bound by a pressing release date. 
• The outcome of a software development process based on SSDF is a secure product, ready to release. 

It sounds simple – why wouldn’t you take a secure approach to creating software? Unfortunately, despite the fact that the latest version of the SSDF (v1.1) was released a few years ago, it remains poorly adopted due to a number of factors, including:

• Creating the bridge between theory and practice may be more costly than all but the largest enterprises can afford.
• Developers are often tasked with putting into practice the principles outlined in the SSDF, but typically lack the necessary security training.
• The reluctance of most organizations to slow down code delivery in order to address security concerns, especially in competitive markets.

Additionally, it requires the adoption of security best practices by development teams, which means overcoming the tradition of decades of non-secure development practices that prioritize creativity and speed over security. For example, take PO #5: Implement and Maintain Secure Environments for Software Development:

• Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.

Locking down developer environments is likely to be met with quite a bit of pushback from highly creative individuals known for their ability to work around restrictions. Similarly, securing build/test environments means creating a hardened CI/CD system, which can add quite a lot of overhead to already overloaded DevOps teams. 

But adopting SSDF doesn’t have to be onerous, or particularly expensive in terms of time and resources with the right (read: automated) approach. 

How To Automate SSDF Requirements

Given that >80% of any modern codebase is open source code, securing your open source supply chain is key to adopting SSDF. The ActiveState Platform automates many SSDF security concerns, allowing you to deliver code just as quickly, but in a more secure manner. For example:

• Scalable Consistency refers to the fact that the open source runtimes your projects require are built securely from source code using a hardened, tamper proof build service, allowing you to start secure.
• Empirical Observability provides insight into all your open source components, no matter where they’re deployed. Identify vulnerable components and where they’re deployed faster.
• Unrestricted Upgrades refers to the ability to identify vulnerable open source components, upgrade them and then rebuild your runtime and its container in minutes, decreasing Mean Time To Remediation (MTTR).

How do these three capabilities fit into the SSDF? There are a number of practices that the ActiveState Platform can help you meet, including: 

PS1 — Protect All Forms of Code from Unauthorized Access and Tampering 

Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software.

Software supply chain attacks are a significant – and growing – threat to software security. The software supply chain includes all imported, third-party code (e.g., open source dependencies), as well as build systems (e.g., CI/CD systems) and staging/deployment systems (e.g., binary repositories), as well. Unauthorized tampering at any point in the software supply chain can result in the production of unsecure software.

The ActiveState Platform eliminates unauthorized access/tampering in both developer and build environments by:

• Building developer environments from up-to-date, vetted source code stored in a secured, restricted local repository. This process eliminates vectors like malware (e.g., trojans, backdoors, spyware, etc) that may be missed by binary scans, while minimizing vulnerabilities that hackers may target since the latest versions of components are used.
• Implementing a hardened, tamper-proof build service to build all open source components from source code in a reproducible manner. Hashes are validated at each step, and the build discarded on mismatch. This eliminates vectors like build script tampering and dynamic inclusion of remote resources, among others. It can also be used to build your internal packages, as well. 

PS2 — Provide a Mechanism for Verifying Software Release Integrity

Help software acquirers ensure that the software they acquire is legitimate and has not been tampered with.

The ActiveState Platform provides assurance in the form of Authenticode signing for MS Windows users, as well as verifying hashes throughout the build process and subsequently at installation (i.e., our CLI, the State Tool, verifies the hash of each open source component it installs).

But ActiveState goes a step further by providing:

• Provenance Attestations that verify the source/origin of all open source dependencies.
• Verification Summary Attestations (VSAs) that verify whether an open source dependency was built in a secure manner.

PS3 — Archive and Protect Each Software Release

Preserve software releases in order to help identify, analyze, and eliminate vulnerabilities discovered in the software after release.

Key to this process is the collection, safeguarding, maintaining and sharing of provenance data for all components of each software release. The ActiveState Platform provides this information in multiple ways:

• Generates a Software Bill Of Materials (SBOM) that can provide static, point-in-time identification of all open source components used in a product.
• Generates Provenance Attestations for all open source components denoting where the component was sourced from.

SBOMs and Attestations are regenerated every time a runtime environment is updated, and can be referenced as either static documents or via an API for easy inclusion in the software development process. 

PW4 — Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality

Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software by reusing software modules and services that have already had their security posture checked.

Too many organizations follow this recommendation to the letter by establishing a repository of “golden dependencies” that are then forever reused and never updated. As a result, >80% of developers admit shipping products with vulnerable components. 

The alternative solution is to build all open source components in-house so they can better be kept up to date. But this method of vendoring all your open source dependencies is not only expensive, it may not meet security standards if they aren’t built with a hardened build system. 

ActiveState helps by:

• Verifying the integrity and provenance of open source component source code for you.
• Building all open source components from vetted source code in order to eliminate the threats posed by binary scanners due to alarm fatigue.
• Providing a software repository to host approved and vetted open source components.
• Allowing authorized users to maintain and update a set of approved open source components, per project.
• Retaining a git-like snapshot of all versions of open source runtimes as they are modified over time.

RV1 — Identify and Confirm Vulnerabilities on an Ongoing Basis

Help ensure that vulnerabilities are identified more quickly so that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers.

ActiveState can help here by:

• Providing warnings and email notifications when open source components are found to be vulnerable, thereby reducing time to vulnerability identification.
• Providing a live dashboard view of all open source components and their CVEs currently deployed in all environments for all projects so they can be remediated faster.

Conclusions: Automating SSDF

The mental shift is by far the most expensive part of adopting a secure software development framework. While most professionals will admit that the SSDF’s recommendations are just common sense, they go against our collective decades of learned experience. It’s impossible to underestimate our resistance to change, especially in a software culture that celebrates “moving fast and breaking things.” 

The only realistic way for the software industry to adopt secure software development is if it can be added without friction or disruption, which means automating as many of the SSDF’s provisions as possible. 

Given that the majority (>80%) of a codebase is open source code, securing the open source supply chain should be the first goal of any organization when it comes to adopting SSDF.  ActiveState automates many of the key provisions for open source components, simplifying the implementation of a secure software development framework, including:

• Securing all open source components in the development environment.
• Providing a hardened build service for open source and proprietary components.
• Generating metadata like SBOMs and Attestations that can be used to verify the provenance of open source components.
• Facilitating remediation of open source components through early and continuous identification of vulnerabilities, as well as automated rebuilding of runtime environments.

Next Steps

Adopting NIST’s SSDF is a journey, not a destination. The best place to start is with your open source dependencies. Read our The Journey to Software Supply Chain Security eBook to get prepared.