The CISA has released a form that identifies the minimum requirements of secure software development for organizations that produce software for the government. The attestation details additional security measures that software providers must abide by during the development process. This is to ensure that software used by the government is created in a secure environment and checked for vulnerabilities. Furthermore, the attestation implements a policy requiring developers to disclose known vulnerabilities. 

Security leaders weigh in 

Dr. Harry Wang, VP Strategic Partnerships at Sonar

“On Monday, CISA and the Office of Management and Budget (OMB) released a secure software development attestation form, a new requirement for software providers to the government. The form, which should be available this month, essentially ensures that these companies develop their software in secure environments. Separate production and development environments, better code quality, enforced multi-factor authentication, encryption, and, importantly, continuous monitoring/testing of code — these are all ways companies can ensure better security in their software.

“This announcement comes on the heels of the White House’s mandate for the use of memory-safe programming languages last month as well as NIST’s Cybersecurity Framework 2.0, all of which propose measures for better software security. It underscores the foundational issues created by bad software code and, in turn, the critical need for improved standards, processes, and measurement in the software development lifecycle (SDLC). Based on what we saw in Sonar’s telemetry data, there is on average one issue in every 27 lines of code. For companies with millions of lines of code, that’s tens of thousands of exposures to vulnerabilities, risks, and engineering debt. Together, these new regulations are the continued call for a proactive approach to addressing software vulnerabilities, including at the source code level.

By adopting a more secure production environment, memory-safe programming languages, Clean Code principles, and continuous code quality analysis to reduce tech debt, developers can prevent security incidents, reduce risk exposures, and improve the availability of their applications. This becomes increasingly important as we expect the volume of code produced to increase with the use and innovation of AI code assistants. As a technology community, further accountability for the software we put into production – specifically the code that software is built on – will benefit everyone.”

Tim Mackey, Head of Software Supply Chain Risk Strategy at Synopsys Software Integrity Group

“Like most government requirements, and the Self-Attestation form is a requirement, there are penalties for noncompliance. The form needs to be signed by someone within the software provider’s leadership team, potentially the CEO, and false statements are punishable under 18 U.S.C. § 1001, which covers False Statements made to the U.S. government. What this means is that any software producer that might be tempted to simply respond “Yes” to all questions should think twice about doing so.

Obviously, if you’re required to attest to software development practices, it’s helpful if those practices are well known and well understood. This is where the Self-Attestation form makes life easy, as software providers are expected to follow a subset of the NIST Secure Software Development Framework (SSDF) activities…

For those businesses that are pursuing a FedRAMP Authorization, the Self-Attestation form allows for a FedRAMP 3PAO Assessor to provide an independent attestation that can be used in lieu of self-attestation.

But what about all those businesses whose software is in use within the U.S. government but aren’t FedRAMP authorized? Some might feel that the risk of making a mistake when self-attesting isn’t worth taking. Given that there are far more than the 328 FedRAMP-authorized applications running within the U.S. government, a trustworthy attestation process needs to exist. Ideally, it should identify whether the corporate policies governing software development are consistently followed by development teams.”