New Cybersecurity Requirements may put Vendors’ Gov’t Contracts at Risk

In the wake of a recent series of cybersecurity events including Log4Shell and SUNBURST, governments around the world have been exploring ways to use their purchasing power to improve software vendors’ security practices. In the U.S., a series of recent government actions revealed that a critical element of this plan is to force organizations doing business with the government to self-attest that their software security practices meet a defined government standard. The consequences of not using these secure development practices have also become clear: Government agencies will cease doing business with vendors that cannot attest that they are following these recommended practices.

To ensure your organization is prepared and not risking lucrative U.S. government contracts, it is important to understand what you’ll be asked to do—and when.

Cybersecurity Requirements for Organizations Selling Software to the US Government

In September 2022, the White House Office of Management and Budget (OMB) released a memo, dubbed M-22-18, on enhancing the security of the software supply chain. This document set deadlines by which any organization selling software to the U.S. government would need to provide an attestation that they conform with the secure software development standards outlined in another government publication, the NIST Secure Software Development Framework (SSDF).

Importantly, these attestations must not only cover the development practices of the software built by the organization itself but also the open source software components that are used within the software. This piece of the memo has been seen as exceptionally challenging since open source software makes up the vast majority of the code in many modern applications. Not only that, but the maintainers of this open source software are often volunteers who are not being paid for this work.

Even more challenging, the government has set tight deadlines for software vendors to provide these attestations. While dates are not yet final, it is expected that the deadline by which organizations need to provide these attestations for software deemed “critical” may come as soon as Q4 of 2023, while all other software will be required to provide attestations by Q1 2024.

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. From the most recent memorandum on this subject, M-23-16:

“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.”

Because the government is attempting to bring software vendors into compliance so quickly, one saving grace is that M-23-16 introduces the concept of a plan of action and milestones (POA&M) as a temporary bridge to allow software suppliers to show they are making progress toward their attestation requirements. M-23-16 explains the hoops an organization will need to jump through to get an approved attestation deferral via POA&M:

“First, the producer of a given software application must identify the practices to which they cannot attest, document practices they have in place to mitigate associated risks and submit a POA&M to an agency. If the agency finds the documentation satisfactory, it may continue using the software, but must concurrently seek an extension of the deadline for attestation from OMB. Extension requests submitted to OMB must include a copy of the software producer’s POA&M.”

What Should Software Suppliers Do Now?

As you might expect, organizations are working quickly to figure out the best ways to complete these attestation requirements or apply for POA&M extensions. Where should you begin?

The first thing any vendor selling software to the government should do is familiarize themselves with the government’s suggested secure software development framework, the NIST SSDF. The SSDF framework covers four high-level areas, with a unique set of expected tasks/actions under each:

Prepare the Organization: Organizations should ensure that people, processes and technology are prepared to perform secure software development at the organization level.
Protect the Software: Organizations should protect all components of their software from tampering and unauthorized access.
Produce Well-Secured Software: Organizations should leverage people, processes and tools to produce well-secured software with minimal security vulnerabilities in its releases.
Respond to Vulnerabilities: Organizations should identify residual vulnerabilities in their software releases and have processes and accountability to respond appropriately to those vulnerabilities and prevent similar ones from occurring in the future.

Organizations can begin mapping their own internal software development practices against this standard and begin to document their internal practices to prepare for attestations.

Next, organizations must start looking for more data on the secure software development practices used by the creators of the open source components used within their software. This is where things get exceptionally tricky. Because most open source software is freely downloaded from the internet and provided with no warranty by its creators, organizations must do their best to understand how the software was developed and how it is maintained.

If the organization cannot find information on the security practices of the open source projects they use, either from the creators of the project themselves or by enlisting the help of a company that works with maintainers to document their security practices, it should consider removing that software from the product or applying for a POA&M extension until it is able to get this information.

Finally, organizations should watch closely for additional guidance from the White House Office of Management and Budget. The final attestation form is under review now, and once it is released (expected within the next few months), organizations will have more information about exactly what is expected of them. The one thing organizations should not do is nothing, as it has become very clear that expanded cybersecurity requirements are upon us, and those organizations that are not paying attention are risking the loss of their government business.

Avatar photo

Donald Fischer

Donald Fischer is co-founder and CEO of Tidelift. Previously he was a product manager and executive at Red Hat, and an investor and board member at over a dozen open source software startups.

donald-fischer has 1 posts and counting.See all posts by donald-fischer