One of the biggest problems that software developers face is cybersecurity. There’s the threat, risk of attack, and project compromise at every stage of the software development lifecycle.
In other words, the entire software supply chain has inherent risks that must be mitigated at every stage and with each component unit. Cybersecurity innovation has led to the development of software development frameworks or principles to ensure the efficient delivery of secure software products.
These frameworks also address user requirements throughout the software development process.
The NIST SSDF framework is an outline of core secure software development principles published on the 3rd of February, 2022, by the NIST (National Institute of Standards and Technology). The SSDF program started as far back as May 2021 in light of Executive Order 14028. However, it wasn’t until early 2022 that version 1.1 of the document was published.
This article keenly examines the NIST SSDF framework and other frameworks with similar cybersecurity, noting key similarities and differences in their operating procedures.
First, let’s examine the NIST standard in depth.
What is the NIST SSDF Framework?
The NIST SSDF framework is an upgrade of the cybersecurity principles outlined in the NIST CSWP 13 whitepaper published on the 23rd of April 2020.
The most recent publication is version 1.1 (also known as SP 800), titled Recommendations for Mitigating the Risk of Software Vulnerabilities. True to its title, it addresses software security in extreme detail, providing a set of structured practices to help software developers reduce the amount of inherent vulnerabilities in their software products and services, mitigate the impact of exploited vulnerabilities in released software, and identify the root causes of these issues to avoid future recurrences.
The publication is written in easy-to-understand industry lingo, meaning that everyone involved in the software supply chain, including consumers and software buyers, can use it, ensuring that their software product components adhere to the security measures highlighted within.
The framework is divided into four basic practices:
Prepare the Organisation (PO)
This practice infers that secure software development begins by preparing the organization or development team members for the task ahead. The preparations include ensuring that everyone in the team is well aware of the security requirements and applying them throughout the software development life cycle.
Additionally, this practice involves the communal sharing of relevant external and internal requirement policies.
Protect the Software (PS)
This practice implies that software development organizations should take necessary steps to protect the product’s constituents from unauthorized access and tampering.
This means that all code used in the building, testing, and deployment of software is to be protected from unauthorized alterations. Such tampering could compromise the intended security features of the software, leaving it at risk of hacks, viruses, and other vulnerabilities.
This is especially important in code not meant to be publicly accessible as it prevents deliberate theft, making it nigh-impossible for attackers to breach the software.
Also, all code should be stored in order of priority access, with the most sensitive configurations limited to only the most essential authorized personnel.
In addition, the practice of software protection includes providing working mechanisms to verify the integrity of each software release.
This is especially important in ensuring that consumers further down the software supply chain can verify the authenticity of the software, confirming that it hasn’t been tampered with.
Produce Well-Secured Software (PW)
This practice implies that organizations should develop and release only software with maximum security levels.
All products and services should conform to security requirements to reduce the impact of potential breaches.
The first step here is to evaluate the security risks to ascertain the most likely vulnerabilities. Then, developers should consider their software infrastructure and design, examining these potential vulnerabilities on a case-by-case basis.
One way to achieve this is to test for vulnerabilities via attack surface mapping, attack modeling, or threat modeling.
Respond to Vulnerabilities (RV)
Software development organizations should identify inherent vulnerabilities in each software release and respond aptly to prevent future recurrences.
These vulnerabilities can be confirmed and identified on an ongoing basis. This helps quicker identification of issues and facilitates even speedier remedial responses.
Vulnerabilities discovered after software release may be masked by developers in the hope that no one notices. The RV practice encourages quick response to such discoveries, limiting the window of opportunity for hackers to do even more damage.
Another relevant practice is collaborating with those further down the software supply chain to get relevant information and security feedback.
Additionally, all vulnerabilities must be quickly assessed and analyzed to gather enough data to take counteractive measures. Finally, vulnerabilities must be analyzed to identify their root causes.
Comparing the NIST SSDF to other frameworks
The frequency and severity of software supply chain hacks have recently increased, and software development organizations must devise equally innovative means of reacting to new threats.
Here are some alternative frameworks and how they compare to NIST SSDF:
BSA Framework for Secure Software
This framework focuses on security risk assessment to understand the performance of the software in various conditions.
Compared to the NIT standard, there is more emphasis on the development stage, with the postulation that any desired security outcomes are actualized in the development stage.
BSA’s framework is a holistic approach that approaches software development from the angles of secure development, capabilities, and lifecycle.
Google SLSA
Google Supply Chain Levels for Software Artifacts is a framework to verify the integrity of software components at every level of the software supply chain.
Like the NIST SSDF, it segments the secure software development, only this time, into chronological stages. There are four stages, with the final stage representing the ideal end state of the software.
Google SLSA infers that there be documentation of templates at the start of the development cycle. The idea is to provide end users with relevant security information and leave the decision-making to their discretion. Second, the guidelines prescribe the need for version control, similar to the SSDF framework’s Protect the Software practice.
Furthermore, Google SLSA dictates the need for standardized builds. Unlike the NIST SSDF, this framework emphasizes meeting the requirements of external auditors who guarantee the security of the software. Finally, the framework uses a two-person review and hermetic build process.
OWASP Comprehensive, Lightweight Application Security Process (CLASP)
CLASP comprises rule-based constituents that prescribe high-level security practices for software development, especially at the early stages.
CLASP’s practices are thus geared toward securing this critical stage of production, with a warning emphasis on the dangers of vulnerabilities that survive into production.
The first level of CLASP’s security practices is an awareness program comparable to SSDF’s Prepare the Organization model. Performing application assessments and capturing security requirements are also essential, as is building vulnerability remediation procedures.
Additionally, CLASP carries secure software development into the post-production stage, with established guidelines propagating the importance of publishing operational security guidelines.
Of the three frameworks highlighted in this article, CLASP’s model is the one that closely mirrors that of the SSDF.
Conclusion
Securing your software supply chain has never been more important than it currently is. Every day, vulnerabilities creep into the pipeline, infiltrating software infrastructure in various ways.
Developers must be alert to ensure that the procedure is uncompromised, following the best cybersecurity practices and frameworks.