The updates from the government regarding open source cybersecurity have been coming fast over the past several months and it can be hard to know what’s important and what requires action. Last week, Tidelift CEO and co-founder Donald Fischer hosted a live webinar where he broke down the most important cybersecurity-related actions being taken by the U.S. government, including what organizations need to do to comply when it comes to the open source software supply chain.
Below, we provide the key moments of Donald’s talk but if you’d like to watch the webinar in full, including seeing a demo of how Tidelift can help from Tidelift Solutions Architect Larry Copeland, you can follow this link.
Government cybersecurity actions: a timeline
In response to high-profile cybersecurity events from the SolarWinds hack on proprietary software to the Log4Shell incident with open source software, the U.S. government has taken action to spur necessary improvements to national cybersecurity. Starting with White House Executive Order 14028 in 2021, and more recently with the update to memorandum M-22-18, memorandum M-23-16, the government has rolled out guidelines, deadlines, and resources to help organizations stay in compliance.
Donald kicked the webinar off with a rundown of the timeline of U.S. government cybersecurity events and honed in on the Office of Management and Budget’s (OMB) memorandum M-22-18 which was presented to us in September 2022.
“We had the first real teeth show up with M-22-18. This memo set specific deadlines by which organizations that supply the U.S. government, including companies supplying software products and services, will need to self-attest that their software is built using specific secure software development practices, those that were laid out in the NIST Secure Software Development Framework (SSDF). Specifically, this requirement applies to not only the code that those organizations write themselves, but any code that goes into their product or service, including third party open source components that are integrated into their applications.”
What is required for government cybersecurity compliance?
Organizations that sell software to the U.S. government are being asked to meet cybersecurity guidelines and attest that their organization meets these requirements with proper documentation. Donald broke down what type of information needs to be documented and the deadlines the government set out for compliance, “Any organization that is supplying a U.S. government agency will be asked to issue a statement that their product or service conforms with the NIST SSDF and guidelines. And again, that includes for the open source components that are integrated into their applications, even if that organization didn't offer that software in the first place.”
When will organizations need to prove they’re compliant with NIST SSDF guidelines?
In June 2023’s update to OMB’s M-22-18, memorandum M-23-16, the deadlines for compliance were adjusted to accommodate for feedback on CISA’s proposed self-attestation form, presented in April 2023. Commenters were given three months to provide their opinions on the draft (deadline of June 26, 2023) and with the feedback now in CISA’s hands, it’s only a matter of time for the release of the finalized draft. Donald spoke on this draft and the dependent deadlines:
“Once the form for the self attestation is finalized, then the clock starts ticking. Organizations will have three months from the date of release of that final attestation form to begin attesting that their products and services are following these secure development practices for any applications deemed critical. Then they'll have six months for all other applications that are not deemed critical. The bottom line is it means that the deadline for critical software is going to be late this year 2023 or early next year 2024 by our best assessment, and then all applications delivered to us government agencies, three months after that.”
What is the penalty for non-compliance?
Donald reminded listeners that, while unclear before, the government has since stated the penalties for non-compliance.
“U.S. government agencies must discontinue their use of software, if the software producer's documentation is unsatisfactory, or if the software producer has not clearly documented the practices to attest, and if the provider cannot provide a plan of action to mitigate the risks associated with unaddressed secure development practices. If your organization does not provide the necessary attestations, your organization can be in significant risk of losing access to the largest purchaser of goods and services in the world, the U.S. government. And that's as true in IT as it is in other markets as well.”
A safety net: POA&M
The U.S. government understands that there’s a lot of work to be done for organizations to be prepared to make attestations. M-23-16 addresses this issue by providing organizations a means to apply for extensions, as long as they provide a plan of actions and milestones (POA&M).
“Software producers, as part of their POA&M, are going to need to specifically identify the practices that they're currently unable to attest to. They’ll need to specifically document how they're going to bridge that gap—the plan that they're putting into place to mitigate those risks and with specific timelines for when they're going to complete that gap. By presenting a convincing case that you have a plan to get into compliance and the specifics of what that plan is, that's the only way your plan of action milestones will be approved, and you'll be able to continue supplying US government agencies in the interim.”
What about open source software compliance?
The NIST SSDF states that organizations will need to verify that open-source software components in use comply with NIST requirements throughout their life cycles, meaning organizations will need to attest to the software development practices followed by the third-party components in their software applications. This is big, especially because 92% of applications contain open source components and the average application contains 70% - 80% open source code.
“How do you get that information about these secure software development practices for code that your organization ships, but you didn't write?” Donald asked. “Most of the code in most commercial applications these days that's getting shipped is third party open source code.”
Who’s going to do the work to make sure these open source components are compliant?
Many open source maintainers see these government requirements as unfunded mandates, standards and regulations they didn’t sign up for, and with no incentive to see them complete. At Tidelift we want to see maintainers get paid for their hard—and crucial—work.
“There's a really critical question, which is, who is going to be responsible and incentivized to ensure that those open source components are aligned to the NIST secure software development framework, allowing your organizations to confidently and accurately make these mandatory attestations?” Donald asked. He went on to describe how the Tidelift Subscription model aims to help maintainers meet the requirements for government cybersecurity compliance, all while getting paid for the necessary work.
“Tidelift partners directly with the independent open source maintainers behind thousands of the most widely-used open source components in application development, and we pay those maintainers to create an incentive for them to ensure their packages align with these secure software development practices. We give them the tools, the processes, and the capability to ensure that they're covering that landscape of required secure development practices. We verify the work that they're doing and we capture their statements of fact about what specific secure development practices they did or did not follow for specific versions of their open source software.
In other words, we do that work in partnership with these financially incentivized open source creators and we make available to our customers the results of that work, which is software that follows these secure development practices, but also very importantly, the data that certifies that yes, a process was undertaken, here's the evidence that it was completed. This is all really important for addressing these self-attestation requirements.”
— — — — — — — — — —
To hear about a helpful summary of the NIST SSDF guidelines (the guidelines organizations must attest they comply with), to see Tidelift in action, and to hear an audience Q&A, you can watch the full webinar by following this link.
Learn more about how Tidelift can help your organization attest to the security of the open source software in use at your organization with open source data validated by Tidelift and our paid maintainer partners.
50 Milk St, 16th Floor, Boston, MA 02109