Selling software to the U.S. government? Know security attestation first; a recap

For the past two years, the U.S. government has put a magnifying glass on cybersecurity with various executive orders and requirements. In just the past few months, the U.S. government has introduced several new requirements affecting organizations that sell software to government agencies. Many leaders in these organizations are not entirely sure on how these requirements will affect them. 

In a recent article for Dark Reading, Tidelift CEO and co-founder Donald Fischer shares what these new requirements entail and how an organization can stay in compliance and protect their government business. 

New software security requirements: What has changed?

After several high-profile security incidents, the government started putting more attention on software security, starting with the White House Executive Order 14028 in May 2021. By February 2022, the government updated the NIST Secure Software Development Framework, outlining that any organization selling software to the U.S. government will be required to self-attest that it conforms with the secure software development practices. 

“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,” Donald writes, “but also that the open source components they pull into their applications follow these practices as well.”

Come June 2023, the government reaffirmed these requirements in OMB memorandum M-23-16 (PDF), and set deadlines for compliance. The penalty for noncompliance is severe, with federal agencies discontinuing use of software that does not meet the requirements. 

Particularly challenging case of open source

As organizations dive into the new attestation requirements, they are discovering that the NIST SSDF is a complex framework for security, and it will take time for the organizations to not only ensure they comply with these practices, but also document their practices in detail. Especially when it comes to attesting to the security practices of the open source components in the software they are using. 

“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?” Donald writes. 

This is a huge challenge. Organizations are looking to the open source maintainers to make sure their security practices match the high standards set by the NIST SSDF. However, many of these open source maintainers are unpaid volunteers, who work on open source as a hobby on nights and weekends. They often have no incentive to put in the extra work to validate that their software meets these standards. 

Organizations can avoid this challenge altogether by just not using any open source components in their software, but that doesn’t really seem like a viable option when Tidelift has 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.

“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,” Donald writes. 

A challenging but necessary step forward

The U.S. 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. 

“These requirements may be painful to comply with,” Donald writes. “But against the backdrop of increasing security vulnerabilities doing massive harm to public and private sectors, they are a necessary step forward.”

Read Donald’s full article on Dark Reading for more details on the challenging new safety requirements needed to improve security and work toward a more secure future.