In response to an increase in cybersecurity attacks, from the SolarWinds hack on proprietary software to the Log4Shell incident on the open source software supply chain, the U.S. government issued a series of actions and guidelines to address the nation's cybersecurity. If there’s one major takeaway from the various government actions, it’s that organizations selling software to the U.S. government need to attest that they comply with the recommended secure development practices.
In a recent article for Security Boulevard, Tidelift CEO and co-founder Donald Fischer discusses the importance of understanding and preparing to comply with the recent government actions, and why ignoring these guidelines can put vendors’ government contracts at risk.
What are the U.S. government cybersecurity requirements?
Donald starts by outlining the key actions and guidelines that organizations selling software to the U.S. government should be aware of:
Memorandum M-22-18
In September 2022, the Office of Management and Budget (OMB) released memorandum M-22-18. This memo set the deadlines for which organizations selling software to the U.S. government need to attest that they confirm with the NIST Secure Software Development Framework (SSDF) guidelines.
Important to note: The attestations provided by organizations must not only cover the secure development practices of proprietary software, but also the open source software components they use.
Memorandum M-23-16
In June 2023, the OMB announced memorandum M-23-16, a direct follow-up to M-22-18. This memo put emphasis on the penalties for organizations that do not submit attestations to confirm they comply with the NIST software supply chain security guidance. (M-23-16 also extended the deadlines originally set by M-22-18, more on these deadlines on our blog.)
As Donald puts it, “If organizations are not able to come into compliance or they do not submit a plan for how they are going to bring their software into compliance, the penalties are severe.” (Source: Security Boulevard)
Directly from the memorandum:
“The [federal] agency must discontinue use of the software if the agency finds the software producer’s documentation unsatisfactory or if the agency is unable to confirm that the producer has identified the practices to which it cannot attest; documented practices they have in place to mitigate associated risk; and submitted a plan of actions and milestones to the agency.”
Plan of action and milestones (POA&M)
One saving grace is that, because obtaining attestations is a large ask for some, M-23-16 introduces the concept of a plan of action and milestones (POA&M). Organizations can apply for an extension by showing a completed POA&M.
How can organizations prepare?
The request can seem daunting, but Donald lays out how organizations can prepare for self-attesting. First, organizations need to be aware of the actions being rolled out by the government and understanding the NIST SSDF is a great starting point. Learning what materials are in use at your organization, creating a software bill of materials (SBOM) to start, is another recommended step. Furthermore, understanding what open source software is being used in your applications and whether or not they’re secure is key.
To learn about how your organization can prepare, the highlights of the NIST SSDF, and more you can read the full article on Security Boulevard.
50 Milk St, 16th Floor, Boston, MA 02109