Selling Software to the US Government? Know Security Attestation First

Over the past several months, the US government has introduced several new requirements affecting organizations that sell software to government agencies. Because these new requirements are complex, many leaders are not yet sure how their organization will be impacted. In this article, I'll share some of the most important concepts you'll need to understand so you can protect your government business and stay in compliance.

New Software Security Requirements: What Has Changed?

Over the past several years, high-profile security incidents like those that affected SolarWinds and the open source package Log4j have increased government attention on software security. Starting with White House Executive Order 14028 on improving the nation's cybersecurity in May 2021, a series of actions over the last two years have led to a set of clear requirements that impact any government software supplier.

Going forward, any organization selling software to the US government will be required to self-attest that it conforms with the secure software development practices outlined by the government in the NIST Secure Software Development Framework.

One of the most important things to understand is that organizations must not simply attest that they follow these practices themselves for the software code they write, but also that the open source components they pull into their applications follow these practices as well.

In early June, the government reaffirmed these requirements in OMB memorandum M-23-16 (PDF), and set deadlines for compliance that are fast approaching — likely to arrive in in the fourth quarter of this year (for critical software) and the first quarter of next year (for all other software).

This means that over the next few months, organizations will be scrambling to understand these new attestation requirements and determine how their organization will comply, both for the code they write themselves and the open source components that they bring into their software products.

According to M-23-16, the penalty for noncompliance is severe:

"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…"

Particularly Challenging Case of Open Source

As many organizations are diving more deeply into the attestation requirements, they're discovering that compliance, especially against tight deadlines, may prove challenging. The NIST SSDF is a complex framework for security, and it will take time for organizations to not only ensure they comply with these practices, but also document their practices in detail.

But even more daunting is that the government is asking suppliers to attest to the security practices of their entire software product, which includes the open source components in that software. Today, modern software is often made up largely of open source components that have been cobbled together, along with some custom software. In our research we've found that over 90% of applications contain open source components, and in many cases open source makes up more than 70% of the code base.

Your organization can attest to its own security practices, but how exactly can you attest to the security practices followed by the open source maintainers who write and maintain the open source code you use in your applications?

It's a huge challenge, and organizations are looking to open source maintainers for more information about their security practices. Unfortunately, many of these open source maintainers are unpaid volunteers, who work on open source as a hobby on nights and weekends. So, asking for them to do the extra work to validate that their security practices match the high standards set by the NIST SSDF isn't practical.

One way organizations can avoid this challenge is to just not use open source in their applications. And while that sounds like a simple solution on its face, it is also an increasingly nonviable alternative, as open source in many ways has become the de facto modern development platform.

A better way to solve this problem is to ensure the maintainers of the packages you rely on are being paid to do this important security work.

This may require that you do extra research to ensure the open source components you are using have maintainers behind them who are being paid — either by corporate benefactors, by foundations, or by commercial efforts — to validate their packages meet these important security standards. Or you can even reach out to maintainers yourself and become a corporate sponsor of their work. When designing your approach, keep in mind that most nontrivial modern applications have thousands of distinct open source dependencies, each created and maintained by a different individual or team, so the manual effort to scale this approach is considerable.

A Challenging but Necessary Step Forward

These requirements may be painful to comply with, but against the backdrop of increasing security vulnerabilities doing massive harm to public and private sectors, they are a necessary step forward. The US government is the largest buyer of goods and services in the world, and that's as true for IT as it is for other domains. By using its purchasing power to force improvements to the overall security standard for software, the government is helping to ensure a safer, more secure future.