Introduction: The Significance of SSDF and SBOMs
Most of the conversations I’m having these days tend to circle around the NIST 800-218 or more colloquially, the Secure Software Development Framework (SSDF). These conversations are in direct response to the EO-14028 and particularly, section 4, Enhancing Software Supply Security. I hadn’t taken a look at the standard and decided it was time to dig into the details. I promptly loaded this into my Kindle reader on my iPad, where I have almost every technical book or document I’ve read for the last 10 years, and looked for where Software Bills of Materials (SBOMs) fit in.
Understanding the SSDF
Right out the gate, the document sets the tone in its ‘abstract’ by highlighting that the SSDF is a “core set of high-level secure software development practices” while pointing out that few SDLC “…models explicitly address software security in detail.” Following the SSDF should help software producers to reduce: vulnerabilities, and the potential impact of exploitations while addressing the root causes of vulnerabilities. While the abstract goes on to talk about how the SSDF facilitates communication I felt the Introduction had a more succinct description: “This document provides a common language to describe fundamental secure software development practices… …The common language helps facilitate communications about secure software practices among both internal and external organizational stakeholders…”
High-Level Practices of the SSDF
So what exactly are the high-level practices? Turns out there are just 4 but those are further broken down into ‘task’ and the document even provides ‘notional implementation examples’ to help clarify each ‘task’. It is important to note that the SSDF is not prescriptive in how to implement each practice, “the focus is on the outcomes of the practices rather than on the tools, techniques, and mechanisms to do so.”
Preparing the Organization: An Umbrella Task
First up is to Prepare the Organization which I think most people would agree is an umbrella task to the remaining three practices. Preparing the organization is broken down into three simple tasks:
- Identify and document all of the security requirements for development infrastructure and processes and maintain them over time.
- Identify and document all of the security requirements for internally developed software to meet and maintain over time
- Communicate requirements to all third parties who will provide commercial software components for reuse by the organization’s own software.
Protecting the Software: Utilizing SBOMs
The next practice is to Protect the Software (PS) which is described as “Organizations should protect all components of their software from tampering or unauthorized access.” When we look at the ‘tasks’ we see this part is about things like preventing unauthorized changes to the code, providing a mechanism to verify software integrity, and archiving and protecting each software release. It is in that third item that we get our first mention of SBOMs. Task PS 3.2 tells us to collect, safeguard, maintain, and share provenance data for all components in each software release (i.e. in an SBOM). It also suggests making those SBOMs available to consumers of the software. For those folks looking specifically ‘where’ an SBOM fits into the SSDF, there you have your first instance.
Producing Well-Secured Software: SBOMs in Practice
The next place we see SBOMs mentioned in the SSDF is in the Produce Well-Secured Software (PW) which is initially described in the broadest of terms. To paraphrase it, identify the risk for the software and how the design and architecture mitigate those risks. In a bit of commentary at the end of this practice is a shout-out to Secure By Design saying that, “Addressing security requirements and risk during software design is key to improving software security and helps improve development efficiency. It is in PW 4 that we see SBOMs pop up again which fits with the practice of “reuse existing, well-secured software when feasible instead of duplicating functionality.” Task PW 4.1 essentially expands on that with, “Acquire and maintain well-secured software components from commercial, open-source, and other third party developers for use by the organization’s software. National Implementation Example #3 tells us to obtain an SBOM for all of the software to assist in risk assessments. There you have the second specific instance of SBOMs in the SSDF. Interestingly, they are essentially symmetrical in that PS says to create and share SBOMs and PW directs us to obtain SBOMs for third-party software.
Responding to Vulnerabilities: Continuous Monitoring with SBOMs
The last practice is Respond[ing] to Vulnerabilities (RV) which does not mention SBOMs in any of its tasks or Notional Implementation Examples. The focus of RV 1.1 is to ‘gather information from software acquirers, users, and public sources on potential vulnerabilities in the software and third-party components that the software uses and investigate all credible reports.’ The 3rd example for implementation suggests ‘automatically review provenance and software composition data for all software components to identify any new vulnerabilities they have.’ That sounds an awful lot like doing continuous monitoring for new vulns down to the sub-component level which is easily achieved with SBOMs in a platform that can regularly check for any vulnerabilities that have been reported.
Conclusion: The Importance of SBOMs
In review, it seems SBOMs play a role in every facet of the SSDF from identifying the need at a high level and then applying SBOMs in practice to protect your infrastructure, the software you are producing and it plays a role in ongoing monitoring and vulnerability response. The vulnerability response section includes reporting your own vulns, and by extension, vulns that don’t affect your software as well as monitoring for vulns in third-party software. The SSDF is not radically different from other Secure Software Development Frameworks and I think you’ll find that SBOMs play an important role across all functions in those as well. The spreadsheet conveniently maps its ‘task’ to other security frameworks in the references column. These list the framework and the specific piece it relates to. For instance, our PS 3.2 from above maps to BSIMM: SE3.6, EO14028: 4e(vi), 4e(vii), 4e(ix), 4e(x) and other NIST standards like SP80053: SA-8, SR-3, SR-4 or SP800161: SA-8, SR-3, SR-4.
So, suppose someone asks you exactly how SBOMs fit in. In that case, you now understand they help us secure and monitor the software we produce, to identify and manage risk in the software we acquire. They help us to identify and respond to emerging vulnerabilities.
