Tidelift advisory: How the proposed CISA self-attestation form impacts open source

On April 27, CISA released a proposed draft of the long-awaited self-attestation form organizations selling software to the government will need to use to attest to the secure development practices they follow, as specified in OMB memorandum M-22-18.

This is not the final document, and in fact CISA is providing a 60 day window for public feedback on the draft, which, as expected closely adheres to the secure software development practices established in the NIST Secure Software Development Framework (SSDF).

As initial self-attestation deadlines are approaching quickly (June 2023 for software deemed critical, September 2023 for all other software), organizations selling software to the U.S. government will want to review this proposed self-attestation format so they can begin to prepare for when the final document is released in 60 days.

In this advisory, we’ll share a few key observations for how this attestation form in its current state will impact organizations use of open source software in the applications they sell to the government.

Software suppliers will need to attest that they’ve minimized open source-related risk 

The proposed attestation form makes it clear that organizations will be required to make formal attestations not only about the software they write, but also included third-party open source software components – which typically comprise over 70% of the code in a modern application. From the document:

“Software producers who utilize freely obtained elements in their software are required to attest that they have taken specific steps, detailed in “Section III – Attestation and Signature” of the common form, to minimize the risks of relying on such software in their products.”

Here’s the relevant detail from Section III, including the proposed attestation that software suppliers will need to make regarding the open source they use in their applications:

“On behalf of the above-specified company, I attest that [software producer] presently makes consistent use of the following practices, drawn from the secure software development framework (SSDF), in developing the software identified in Section I:

1. The software is developed and built in secure environments. Those environments are secured by the following actions, at a minimum:

a. Separating and protecting each environment involved in developing and building software;

b. Regularly logging, monitoring, and auditing trust relationships used for authorization and access:

i. to any software development and build environments; and
ii. among components within each environment;

c. Enforcing multi-factor authentication and conditional access across the environments relevant to developing and building software in a manner that minimized security risk;

d. Taking consistent and reasonable steps to document as well as minimize use or inclusion of software products that create undue risk within the environments used to develop and build software;

e. Encrypting sensitive data, such as credentials, to the extent practicable and based on risk;

f. Implementing defensive cyber security practices, including continuous monitoring of operations and alerts and, as necessary, responding to suspected and confirmed cyber incidents;”

How will you attest to the development practices of the open source components in your applications?

Reading this, there are several included components that require first-hand information from the open source maintainers themselves to properly complete the attestation. 

For example, in order to attest to the logging, monitoring, and auditing of the trust relationships used for authorization and access, independent community open source maintainers will need to provide information on their build and release processes, and least privileged access practices. Tidelift’s direct work with maintainers ensures these standards are visible and incentivized, leveraging standards from industry-led initiatives like OpenSSF Scorecards, as well as community conversations about actual day to day open source maintainer practices.

When it comes to enforcing two-factor authentication, many open source projects don’t do this  today, although Tidelift requires its partnered open source maintainers to attest that they have enabled two-factor authentication for their projects.

And when it comes to the processes they have in place for responding to cyber incidents, Tidelift works with our maintainers to put in place responsible disclosure policies, and in many cases serves as the security disclosure partner, validating research inputs and passing along the information to maintainers to take action to secure their package. Tidelift also helps in the CVE creation and accurate metadata for software producers to mitigate the risks that a CVE may present.

Paying maintainers is the best way to ensure these attestations are complete for open source

The hard reality is that doing the work to ensure these secure development practices are in place on open source projects takes time. And with Tidelift’s recent survey of open source maintainers demonstrating that the vast majority of maintainers are independent volunteers, it is unfair to expect them to take on all of this additional work for free.

Yet, organizations using open source in the applications they sell to the government will have a responsibility to ensure all of the components in their applications are using secure development practices, so how do we ensure the work gets done?

Simple—directly partner with and pay maintainers to complete the required work and then keep their attestations regarding their secure software development practices up to date over time.

Tidelift provides a way for organizations to pay maintainers at scale to ensure they put in place the secure development practices outlined in the NIST SSDF as well as those described in other important industry initiatives like the OpenSSF scorecards project. Tidelift is also maintaining a set of attestations for all upstream open source package secure development practices, keeping these up to date over time.

If you want to learn more about how Tidelift can help your organization comply with secure software development attestation requirements: 

• Visit our government open source cybersecurity resource center
• Watch our recent webinar on how the NIST SSDF impacts open source software
• Download a sample of the Tidelift open source attestation report
• Learn more about the Tidelift Subscription