On March 22nd NIST released the final version of the SSDF 1.1 (Secure software development framework).
The framework was initially published in September 2021 as a draft version. All the high-level practices and tasks remain the same with a lot of the differences centered around the various examples provided.
What is the NIST SP 800-218 framework? The SSDF consolidates longstanding best-practice recommendations for secure software development. Its customizable, sector-agnostic approach is built to facilitate cross-department (and producer/acquirer) communications to help define strategic goals and assess current gaps.
NIST recommends balancing risk against cost, feasibility, and applicability when deciding which practices to implement. Automation is a key feature to be considered with the desired goal of automating as many of the checks and processes promoting software security as possible.
Differences between the final and draft versions:
Integrity verification – When discussing vulnerabilities, there is more of a focus on integrity verification when looking both at your code and at libraries/products acquired from external sources.
Immutable attestations – The responsibility for implementing the practices may be distributed among different organizations, especially when considering the complexity of software supply chains. Visibility drops significantly the further upstream or downstream the chain you go. That’s why NIST recommends codifying the shared responsibility involving both the providers and the consumers of a platform/service in a contract or agreement. It should be clear which party is responsible for each practice and task and how each provider will attest to their conformance with the agreement. The ‘trust but verify’ axiom holds true here – immutable attestations that can easily be shared between software producers and software acquirers are key to increasing all stakeholders’ trust in the software supply chain.
Open-source community involvement – NIST states that future work will likely take the form of specific use cases and that it intends to collaborate with the open-source community. Considering that most commercial code products in use today include significant open-source code elements, it is natural to include the open-source community in planning and implementing software life-cycle security.
Vulnerability severity scores as a KRI (Key Risk Indicator) – Another change taking effect is severity scores as a key indicator. Knowing that a lot of cyber security personnel suffer from alert fatigue, it makes sense for each organization to define the vulnerability score scale that’s right for it and the specific treatment each such score merits.
Less human access, more automation – NIST encourages minimizing direct human access to toolchain systems, such as build services. The more people have access, the more mistakes could happen. This falls, again, in the same vein as the recommendation for greater automation.
SBOMs with integrity – When discussing the SBOM (Software Bill of Materials), NIST recommends employing strong protection to the integrity of the artifact, as well as providing a way for recipients to verify that integrity. The recipients can be people from both inside and outside the organization, so it makes sense to employ a third-party system for sharing secure SBOMs.
Binary vs source code integrity – If the integrity or provenance of acquired binaries cannot be confirmed, it’s suggested to build those binaries anew from the source code. That is assuming you can verify the source code’s integrity and provenance. It’s the responsibility of all links in the software supply chain to provide verifiable proof of integrity, through digital signatures or other mechanisms like an SBOM.
Summary
Overall, NIST considers that “The SSDF’s practices, tasks, and implementation examples represent a starting point to consider. They are meant to be changed and customized, and to evolve over time.”
The SSDF is not a checklist you should follow, but instead provides guidance for planning and implementing a risk-based approach to secure software development.
Unlike US law-based regulations, the SSDF is going to be business-based – The government will leverage its buying power to get the market to adhere to this new best-practices framework. If you cannot show adherence to the framework, you won’t be considered for government contracts. We’re likely to see a trickle-down effect where organizations considering applying for government contracts will require all their vendors and suppliers to comply as well, and so on down the software supply chain.
To learn more about the new regulations and SSDF, check out our webinar on “Demystifying New Cybersecurity Regulations in 2022”.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
