Last week, Tidelift VP of product, Lauren Hanford, and Senior Product Marketing Lead, Kanish Sharma hosted a webinar to discuss the NIST Secure Software Development Framework and how organizations can follow its guidance when they are building applications with open source software. Below are some of the highlights and to see the whole webinar, watch it on-demand here.
What is the NIST Secure Software Development Framework?
To kick off the webinar, Kanish asked: how did we get here?
In May 2021, the White House issued Executive Order 14028 on improving our nation’s cybersecurity in response to the growing number of high profile cybersecurity issues over the last decade such as SolarWinds, and Log4Shell. As directed by the executive order, the National Institute of Technology (NIST) published the NIST Secure Software Development Framework (SSDF) which outlined a set of secure development practices to help protect against future cybersecurity incidents.
In September 2022, the Executive Office of the President, Office of Management and Budget (OMB) announced memorandum M-22-18, which formalized the NIST SSDF as the government standard for secure software development, and set a timeline for federal government agencies to comply with the NIST SSDF guidelines.
When discussing memorandum M-22-18, Kanish emphasized, “If your organization is selling software, or doing business with the US government, you should be watching these developments very, very carefully. If you have not reviewed the NIST Secure Software Development Framework, or the M-22-18 guidance, we recommend that you do so as soon as possible. There are self-attestation deadlines for software deemed critical by government agencies that are fast approaching, with the first deadline being June 2023. And then self-attestation will also be required for all software in use by federal agencies by September of 2023.”
What is an attestation?
Attestation is the “issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.”
In this case, organizations selling software to the government will be required to self-attest that they conform with all of the secure software development standards outlined in the NIST guidelines.
Source: Software Supply Chain Security Guidance Under Executive Order (EO) 14028 Section 4e
Furthermore, in March 2023, the National Cybersecurity Strategy was published by the Biden-Harris Administration as a coordinated effort to improve cybersecurity for the government, industry, and citizens, establishing the nation’s cybersecurity strategy for the upcoming years, specifically calling out the need to improve open source software security through implementation of the NIST SSDF guidelines.
The National Cybersecurity Strategy further states that responsibility for insecure software should not fall on consumers or the open source software developers, but instead on the stakeholders most capable of taking action to prevent bad outcomes, namely the manufacturers and software publishers.
Breaking down the NIST framework
Lauren, who had recently published a series of blog posts on how the NIST SSDF impacts open source software, took the task of introducing the framework, “As a whole, the framework is very sensible. I love that they've recognized a lot of the hard work that organizations are already doing to get to that outcome of secure software.”
The framework is organized into four broad categories (or buckets) of work, here are each as described by Lauren:
Prepare the organization
“In the prepare the organization phase, you're really thinking about policies, requirements, roles and responsibilities within your organization. You're looking to get a shared foundation set up on the tools and practices that you're going to use, and setting up a secure environment overall, for great development to happen within.”
Protecting the software
“When you move onto protecting the software, I think of this as a systems layer. That's when you get into things that are more about traceability. You're going to see your software bills of materials start to show up here, and other ideas and concepts around provenance. How do we know artifacts are what they say they are? Do we have a clear, traceable record of what actually went out into the world?”
Produce well-secured software
“The produce well-secured software bucket is what I think of as the day-to-day. What are the coding practices that are in place? How are your development teams interacting with compliance or risk teams, security, DevOps DevSecOps—all of those sort of boots on the ground operational concepts.”
Respond to vulnerabilities
“The final bucket is respond to vulnerabilities. Everything up until this point has been described by NIST as best practices to get us to the place to minimize bad things from happening. But no matter what we all do, there will be moments when issues come up, and we need to tackle them. So this last bucket is about, what is the playbook when that happens? What's the plan going to be?”
Open source and the NIST SSDF
As stated in the National Cybersecurity Strategy, liability for insecure software should fall on the manufacturers and software publishers, not the consumers or the open source developers. So when building applications with open source software, how can organizations know which open source software components they’re using are compliant with the NIST secure software development framework? And for those packages that are not in compliance, who will be doing all the work to ensure they will be?
Lauren expanded on this, “The government is also being really clear that the responsibility and the liability is not going to be placed on the developers of open source as the upstream maintainers. Where this leaves us is that those that are producing software, that are ingesting open source to drive innovation, to drive business impact, are going to be in a new era of accountability here. We know anecdotally, and in data, the average application is built up of about 70% of open source libraries.”
“Our best case scenario today, up until this point, has been the hope that maintainers will be responsive in that fourth bucket, that they will respond to vulnerabilities that they're receiving reports, and that they will take action. [...] but what we can't continue to have here in secure development and a secure supply chain is this continued moment of crisis after crisis. A major threat happens, unpaid maintainers are having to field inquiries on that threat, all while they're trying to also fix the problem as quickly as possible.”
Unfunded mandates
Many open source maintainers see these ongoing government and industry requirements as unfunded mandates. And as it stands, about half of open source maintainers do not get paid for their work. So this means we’ll be requiring open source maintainers to undertake even more work at a time when a large number of maintainers report that they are not being paid for the work they are already doing.
We need to foster collaboration with open source maintainers and organizations, something we’re starting to see from some government working groups. And we need to support maintainers, including paying them.
How Tidelift can help
In response to the above, Kanish explained how Tidelift can help, “most organizations typically have a number of reactive approaches to find a vulnerability in the code they have. Developers will write the code to build an application and there are container security measures that might identify a vulnerability. The code, once it’s written, will go through Software Composition Analysis to find vulnerabilities, which will then tell developers to go address x, y, and z.”
“At Tidelift we’re thinking proactively. What can we do before the code is written, before an open source package is pulled into the software development lifecycle? We’ve built a people and software powered approach to manage open source more effectively. The people powered layer is where Tidelift partners directly with open source maintainers. We pay them as part of our partnership, and we ask them to take proactive steps to ensure that their open source packages are aligning to these secure development standards, such as the NIST SSDF, that enterprise organizations rely on in order to meet their security requirements. On the software powered layer, what we're doing is providing tools, data and strategies that help organizations assess the risk, and then improve the health, security, and resilience of the open source that is being used in their applications.”
The TACOS framework
Before the Q&A session with the audience, Lauren introduced the TACOS framework: “We've developed what we're calling TACOS, which is the Trusted Attestation and Compliance for Open Source framework. We will be keeping the framework in alignment with the NIST SSDF as any future enhancements come out.”
“We've taken this opportunity to plant an early flag in the ground about what practices open source projects should be complying with, and how we can assess that. There's a specification repo on GitHub for this project, and you can see how each one of these fields maps to the different components of the NIST SSDF.”
The Trusted Attestation and Compliance for Open Source (TACOS) is a framework for evaluating and attesting to the secure software development practices of open source packages. TACOS is grounded in the NIST SSDF, and draws from the OpenSSF Scorecard project and the Center for Internet Security Software Supply Chain Security Guide as well. The framework defines a machine-readable specification that can be used as a part of the overall self-attestation requirement to comply with the requirements and deadlines outlined in OMB memorandum M-22-18. Explore the TACOS framework here.
To learn more about the NIST SSDF guidelines, how the framework addresses open source software, and to hear from the lively Q&A, you can watch the webinar on-demand here. And to stay updated on the latest developments regarding government cybersecurity initiatives, make sure to visit our government open source cybersecurity center.
50 Milk St, 16th Floor, Boston, MA 02109