<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=705633339897683&amp;ev=PageView&amp;noscript=1">

How the NIST Secure Software Development Framework impacts open source software, p.1

Lauren Hanford
by Lauren Hanford
on March 2, 2023

Updated on April 17, 2023

Don't miss the latest from Tidelift

Over the past year, the U.S. government has been extremely active developing strategies, policies, and regulations with the intent of improving cybersecurity for our government and for our nation’s citizens and businesses. At Tidelift, we’ve focused on helping organizations that use open source to build applications understand how these new initiatives will impact their work (you can get caught up on our coverage at our government open source cybersecurity resource center).  

To quickly summarize a few of the highlights:

  • May 2021: the White House issued Executive Order 14028 on improving our nation’s cybersecurity, which set in motion many of the efforts that followed.
  • February 2022: as directed by the Executive Order, the National Institute of Standards and Technology (NIST) published NIST Secure Software Development Framework (SSDF), SP 800-218 and the NIST Software Supply Chain Security Guidance.
  • September 2022: the Executive Office of the President, Office of Management and Budget announced memorandum M-22-18, which formalized the NIST framework as the government requirements for developing secure software, and mandated federal government agencies comply with these guidelines. It also set aggressive timelines for compliance, both for the agencies themselves and for organizations that provide software to these agencies.
  • According to M-22-18, any organization that sells software to the government will be required to self-attest that their software complies with the NIST guidelines as soon as June 2023 (for critical software) and September 2023 (for all other software). 
  • March 2023: the National Cybersecurity Strategy was published by the Biden-Harris Administration aimed to "secure the full benefits of a safe and secure digital ecosystem for all Americans". This document specifically calls out the need to improve open source software security through the implementation of the NIST SSDF guidelines.
  • It further states that responsibility for insecure software should not fall on consumers or the open source developers, but instead on the stakeholders most capable of taking action to prevent bad outcomes, namely the manufacturers and software publishers. Read our in-depth advisory to learn more about the National Cybersecurity Strategy

Understanding the NIST Secure Software Development Framework

As these timelines for self-attestation are only a few months away, we performed a deeper analysis of the NIST framework that organizations will need to attest that they comply with, specifically to  learn what these guidelines mean for organizations building applications with open source.

First off, it is important to recognize that the NIST SSDF is focused on improving security outcomes through the implementation of healthy software development practices. It does not, however, provide a detailed prescription for how the various recommended practices should be, but rather a series of examples per practice. 

The framework is organized into four broad categories of work:

  1. Prepare the organization: Organizations should ensure that people, processes, and technology are prepared to perform secure software development at the organization level.
  2. Protecting the software: Organizations should protect all components of their software from tampering and unauthorized access.
  3. Produce well-secured software: Organizations should leverage people, processes and tools to produce well-secured software with minimal security vulnerabilities in its releases.
  4. Respond to vulnerabilities: Organizations should identify residual vulnerabilities in their software releases and have process and accountability to respond appropriately to those vulnerabilities and prevent similar ones from occurring in the future.

Historically most organizations have employed reactive measures to ensure the security of the software and applications they produce. It is important to note that three out of the four NIST SSDF categories require organizations to introduce proactive efforts to ensure secure software development. This will require organizations to consider new approaches, especially as it relates to open source software and the ability to perform due diligence on the components their developers use. 

The open source gap

When it comes to open source, there has traditionally been no central compliance office, toolset, or process covering the millions of ecosystems, packages, and most critically, the maintainers who create them and keep them up to date. Instead, there are dependency relationships between packages that can be sprawling, and ever-shifting. There is also a lack of clarity and consistency regarding the security processes across each type of open source package or ecosystem. End consumers are the group ultimately harmed when there is a lack of accountability on managing the open source dependencies that make up modern software.

Many of the volunteer open source maintainers have made it clear that their software is offered as-is, without warranty. It is the responsibility of downstream consumers of open source to know what packages they are bringing into their applications, and to ensure the fitness (security, maintenance and legal risk exposure) for use of those packages within their organization. The US government and companion NIST SSDF framework is now codifying this into measurable practices.  

We have seen efforts in some shared open source toolsets to begin addressing this gap. For example, package managers PyPI and npm have begun enforcing multi-factor authentication by requiring maintainers to comply. Source code repository GitHub has made security tooling available to maintainers in order to manage their dependencies and some development process risks. 

What have we learned? Developers are not always willing to take on unpaid extra work to add security to their packages, on software that is made available free, without warranty, and under an “as is” license.

While these early efforts are useful, they are not being fully embraced, implemented, or mandated across enough of the open source software landscape to align with what NIST has described. So, package managers and source code repositories aren’t seeing enough traction to comply with M-22-18, and individual vendors or the government itself can’t enforce compliance, or even collect first party data on compliance at scale. What’s the answer, especially for organizations that are using open source in their applications, selling software to the government, and facing impending self-attestation timelines?

Tidelift has established the community relationships and infrastructure to appropriately incentivize maintainers for this growing body of unfunded mandates. We are actively working with our partnered maintainers to clarify expectations, ensuring that we’re actually creating secure software outcomes. Along the way, we create a comprehensive record of practices over time, across dependency graphs.

How will attestation requirements apply to open source?

Ensuring compliance with the over thirty pages of NIST guidelines for internally developed software will be challenging in itself. As it relates to open source software, organizations need to ask: who is going to implement and document these secure development practices?

The NIST SSDF is clear throughout the framework that there are going to be policy, process, and attestation requirements for open source and other third-party components. Organizations should start considering their strategy for answering questions like (phrases in quotes below are pulled directly from the NIST framework):

  • What are our “defined policies for securing software development processes throughout the software development lifecycle ”and how will we ensure external open source volunteers maintain that security, including for open-source and other third-party software components utilized by software being developed”?
  • How will we communicate those secure software development requirements to the thousands of maintainers building the third-party components that make up business-critical software for our organization
  • How will we continuously “verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles”?

Gathering this information at scale from open source maintainers is challenging since the open source software supply chain is not a traditional supply chain where organizations have formal business relationships with their “suppliers.” 

Organizations and the industry at large need a solution that makes it possible to continuously attest to the practices of open source components created and maintained by volunteer maintainers at scale and in a centralized manner. 

Organizations also need assurances that these secure development practices are being communicated to upstream maintainers, and that maintenance teams are being incentivized and held accountable to do the actual work required to comply with the standards. These standards and attestations are not static, and it’s not enough to simply report on a limited amount of security, maintenance and licensing data for compliance at a single point in time.

How can Tidelift help?

For the past 6 years, Tidelift has focused on building a solution to address this challenge. We partner with the maintainers of thousands of the most-relied upon open source packages and pay them to ensure their packages align with industry and federal standards such as those proposed in the NIST SSDF (and other published security efforts like OpenSSF Security Scorecards). 

In my next post, I will dive into further details about the work required for organizations building applications with open source to align to each of the four NIST SSDF categories and how Tidelift helps customers make informed decisions about their open source components with verified first-party data directly from open source maintainers. Our job is to ensure that maintainers have the clarity and incentives they need to do the work that only they can do. 

If you are an open source maintainer who is looking to be appropriately compensated for the value of this new work, you can see if Tidelift already has recurring income available for your package by visiting our maintainers webpage and searching for your package in the search bar at the top of the page.

NEXT: Read part two and part three of our series on NIST SSDF. 

New call-to-action