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

In my previous blog post I shared some thoughts regarding why organizations developing applications with open source components should be paying close attention to the NIST Secure Software Development Framework (SSDF). 

Ensuring your organization’s security practices are in compliance with the NIST framework will be increasingly important for organizations selling software to the government. But every organization building applications with open source will want to understand this framework so that they can take advantage of new safe harbor protections proposed as part of the U.S. National Cybersecurity Strategy 🥕 and avoid negative consequences of the government’s intent to shift security liability to software producers 😳.

In this post, I will dive into more detail about the four categories of work highlighted by the NIST SSDF and provide details on how Tidelift helps organizations comply with this framework for the open source they bring into their applications. Before I get started, let’s quickly review the NIST SSDF categories:

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.

As I mentioned in the previous post, three out of the four categories of work here require proactive efforts to ensure secure software development. The industry is well-versed in the practice of building code, identifying vulnerabilities, and fixing vulnerabilities. Unfortunately, identifying and fixing vulnerabilities is no longer going to be enough to keep end consumers safe from potential software supply chain attacks—and protect your organization from liability. The NIST SSDF is guiding the industry toward taking actions that limit the number of vulnerabilities and other supply chain attacks in the first place, by implementing practices of responsible decision making and documented action with regards to which commercial and open source components are used in the software development lifecycle (SDLC).

Tidelift’s proactive approach to improving open source software outcomes

Over the last few years it has become clear to us that reactive approaches like scanning for and addressing known vulnerabilities, while valuable, are not by themselves getting us the security outcomes the industry needs.

In addition to these reactive efforts, organizations should be investing in proactive efforts that improve the health, security, and overall resilience of the open source software supply chain. We recognize that open source maintainers need to be at the forefront of any such efforts and have invested heavily to build the infrastructure and partnerships with the maintainers of thousands of the most-relied upon open source packages to meet this growing need.

As part of our partnership with maintainers, we pay them to implement development standards that have resulted in measurable improvements of their open source components and their upstream and downstream dependency graphs. Our model combines the best practices for secure development with a system of defined standards around those best practices that we pay maintainers to validate they meet, now and into the future.

We also leverage these standards to examine open source as a whole and identify where standards may not be met . We ensure  open source maintainers are incentivized fairly for the work of keeping their packages safe, and that open source users have all the relevant data they need to make informed decisions on which open source components to rely on—and how to best address issues when they arise. 

Secure software development does not happen by accident. The desired standards must be clear, and the work needed to meet those standards must be paid for. For too long, open source maintainers have been bearing the weight of a growing wave of noise on vulnerabilities and other software supply chain issues. Tidelift’s approach benefits both open source maintainers and open source consumers. 

So, let’s look at the framework that the NIST SSDF outlines, and how Tidelift’s work with maintainers drives results!

How Tidelift helps organizations building with open source software

Prepare the organization

Tidelift defines and continuously evolves standards that align people, processes, and technology for secure software development throughout the SDLC.

The NIST SSDF calls out the value in making secure software development policies and compliance data available as users select new software components, due to the implications of how modern software is built, in nested graphs. Tidelift clearly communicates our dependency standards to our partnered maintainers and when specific dependencies aren’t meeting those standards. We also provide risk indicators, as well as vulnerability security scores and remediation recommendations (including any first-party information about workarounds!) to our partnered maintainers so they can make informed decisions. This data also includes vulnerability disclosure policies for each of the third party components they rely on. 

Tidelift addresses provenance and integrity of open source software packages throughout the lifecycle. We work with maintainers to ensure they meet and will uphold our code of conduct before entering into and throughout the course of our partnership. We sign contracts with each of our partnered maintainers ensuring clarity on the set of standards we require, and that their packages are meeting our standards. Our ongoing policies include enabling two-factor authentication and validating release managers, which ensure integrity within the SDLC. We also have an offboarding process for when a maintainer may be ready to stop maintaining a package. This ensures supply chain resilience with a succession plan, or appropriate communications indicating that a package has been abandoned, and why.

The NIST SSDF also requires that all individuals participating in the SDLC are able and prepared to perform their roles and responsibilities. Tidelift has practices and people in place to handle responsible security disclosure processes, and we are in continuous communication with our partnered maintainers on our set of standards, how we evolve those standards, and ensure that they are upholding their contractual agreement on the standards and the secure development practices those standards represent.

The NIST-recommended exceptions process is also critical to our model, as there can be false positives or other anomalies in reported problems with open source packages. Our exceptions process collects machine-readable first-party data directly from maintainers on when and why particular problems may not apply to their packages or their package dependencies.

It is clear that evaluating and managing all of this work at scale will require automation and efficiency, which is called out in the NIST SSDF. Tidelift is the only solution that leverages both human and software capabilities to create an audit trail of secure development-related actions taken by open source maintainers. We make this data available through APIs that can be consumed by other vendors, in order to provide the most up-to-date, verified information available on open source packages.

Our partnership with maintainers is also giving us a channel to learn more about their development, build, and deployment tools and practices. We are actively researching the role and risk of dependency update processes, dependency pinning, and binary artifact presence in development across multiple ecosystems, as well as continuing to learn and understand maintainers’ various build processes. All of this work with maintainers enables us to evolve our set of policies that create secure software development practices and outcomes.

Protecting the software

As modern software is built and assembled in many stages, it’s important to ensure the integrity of all of the code and third-party components that go into it. The NIST framework provides clear examples of how organizations should approach storing code, verifying provenance, and archiving data over time in order to minimize attack surface area and reduce time to mitigate when problems show up.

Tidelift is an industry leader with a proven and successful approach to clearly communicating secure development standards and incentivizing compliance. We ensure maintainers have two-factor authentication (2FA) enabled both on their source code repositories and their package manager, which covers both development and distribution tooling.

Tidelift also has a workflow in place for partnered maintainers to verify release managers on their packages. Having access to the package manager means a maintainer or contributor can push new releases. If this user is not trusted, they could push trojaned code, or an improper release (see this post about the event-stream incident for one recent example).

Additionally, each new person who has access to a package manager is an additional person who needs to ensure they have taken appropriate steps to secure their account. Tidelift continuously produces a list of accounts that have access to push new packages, and we ask maintainers to confirm that all detected accounts are authorized and approved users that should have access. When we detect a change to the set of detected accounts, we notify our partnered maintainers to confirm new added users and attest to the accuracy of the user list we compile.

Produce well-secured software

Tidelift has a multi-step approach to open source software lifecycle management. It begins with verifying the identity of the open source package maintenance team, vetting compliance with our code of conduct, and completing a set of secure software development attestations. These attestations account for practices such as:

• Including a security disclosure policy
• Implementing 2FA
• Documenting a versioning scheme
• Verifying license information
• Documenting release streams that receive security responses

In addition to being the original security disclosure source for many of our partnered maintainers, Tidelift also continuously reviews and maps affected releases for all NIST vulnerability reports.  We do this so we can work with our partnered maintainers to provide a recorded response of remediations, or any mitigation measures directly to our customers. Mitigations can include false positive status, available workarounds, affected methods, and other conditions of applicability. Tidelift is the only solution that is able to provide this first-party attestation data. This data has led to more secure open source development and proven valuable for our customers who have been able to implement remediation quickly and efficiently with minimal impact on development.

In addition, Tidelift provides a repository of vetted open source packages that are reviewed against a suite of secure development standards, including the presence of applicable vulnerabilities, in order for our customers to have the best set of components to choose from as they decide which packages to include in their applications. This application of our set of standards applied before a dependency even enters an organization, or that can be continuously assessed at build, or post-deployment time, gives open source consumers the peace of mind, and paper trail, that they have been acting in good faith.

Tidelift’s contractual agreement with our partnered maintainers ensures that their open source components are actively maintained with timely responses to security matters. In the event where a maintainer might want to stop maintaining a package, we implement a 30-day window to work through this process with the maintainer to find another party available to take on the component maintenance, depending on how widely the component is used.

Respond to vulnerabilities

No person, process, or tool can fully ensure that vulnerabilities will not enter into an open source package, and the NIST SSDF acknowledges that with an entire section of best practices around how to respond to vulnerabilities. Tidelift has a robust end-to-end practice with our partnered maintainers to ensure responsiveness in a way that minimizes risk to the end consumer of open source packages.

Tidelift’s approach starts with working with maintainers to ensure that their package has a discoverable security policy. Having and following a policy is the foundation of responsible security disclosure practices. In addition, Tidelift offers a service for maintainers to stand as their security point of contact, a service that the majority of our maintainer partners utilize today. This creates a frictionless, scalable way for maintainers to have a remediation and communication partner if and when vulnerabilities come up. This service has been cited publicly as a value-add by our maintainer community.

In the event a vulnerability occurs, Tidelift’s automated continuous review and assessment process notifies maintainers, requiring them to address the vulnerability through a series of remediation and mitigation steps. Or, if the maintainer believes the vulnerability reported is a false positive, they can report that as well. Tidelift’s approach to navigating various classes of vulnerabilities with our partnered maintainers has positively affected tens of thousands of supply chains, creating safer software throughout transitive dependency graphs.

We also create the record of what specific releases are affected by vulnerabilities, as well as updating version maps with clear guidance on what release streams are no longer safe to use, and which are no longer receiving backported security fixes from the maintainer. 

The importance of open source maintainers

Tidelift has partnered with independent open source software maintainers since 2018 to understand and develop a framework for secure software development. Because of the interconnected nature of open source, this work with maintainers has benefitted over two million supply chains that impact our customers. Each package within a dependency graph has a specific level of “blast radius” that it can affect when a vulnerability or security compromise happens. It’s important to understand that criticality is not just top downloads or GitHub stars. It’s how these packages show up deeply nested in dependency graphs, and what happens if they are abandoned or compromised.

Security is a high priority initiative for our maintainer community, they depend on the reliable income that Tidelift provides to implement layers of security measures within their development practices. Tidelift provides a unique solution that puts maintainers at the forefront and incentivizes them to implement secure development practices while also collecting and normalizing first-party open source data that organizations can use to make informed decisions on how to continuously improve the health and security of the applications they build using open source components.

Without Tidelift, software producers who need to comply with the NIST framework and meet OMB M-22-18 attestation deadlines have no assurances that open source maintainers have the incentives, clarity, and available time to be responsive to secure software development demands.

Without Tidelift, software producers who need to comply with the NIST framework and meet OMB M-22-18 attestation deadlines have no assurances that open source maintainers have the incentives, clarity, and available time to be responsive to secure software development demands.

How to ensure your open source software supply chain meets impending M-22-18 software attestation requirements

The OMB M-22-18 specifically outlines a timeline for organizations doing business with government agencies to provide attestations of their compliance with the NIST SSDF. There is still work to be done to understand and formally define what an open source package attestation might look like. Thanks to our collaboration with open source maintainers and focus on improving the security and resilience of the open source software supply chain, we have a strong and informed opinion on what an open source attestation should look like. In the next post of this series, I will provide a detailed template of an open source attestation and what organizations can do to start incorporating this into their software development practices.

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