Secure Software Development Attestation Form released by CISA
The CISA has released a form that outlines the basic requirements for secure software development for organizations that create software for the government. The attestation specifies additional security measures that software providers must adhere to during the development process. This is crucial to ensure that the software used by the government is developed in a secure environment and is thoroughly checked for vulnerabilities. In addition, the attestation enforces a policy that mandates developers to disclose any known vulnerabilities.
Security leaders comment
Dr. Harry Wang, VP Strategic Partnerships at Sonar
“Recently, CISA and the Office of Management and Budget (OMB) introduced a secure software development attestation form as a new requirement for software providers to the government. The form, expected to be available this month, ensures that these companies develop their software in secure environments. By having separate production and development environments, improving code quality, enforcing multi-factor authentication, encryption, and implementing continuous monitoring/testing of code, companies can enhance the security of their software.
“This announcement follows the White House’s directive to use memory-safe programming languages and NIST’s Cybersecurity Framework 2.0, all of which propose steps for improving software security. It highlights the foundational issues caused by poor software code and emphasizes the urgent need for enhanced standards, processes, and measurement in the software development lifecycle (SDLC). Based on statistics from Sonar’s telemetry data, there is an average of one issue in every 27 lines of code. For companies with millions of lines of code, this could mean tens of thousands of vulnerabilities, risks, and engineering debt. These new regulations call for a proactive approach in addressing software vulnerabilities, especially at the source code level.
By embracing a more secure production environment, memory-safe programming languages, Clean Code principles, and continuous code quality analysis to reduce technical debt, developers can prevent security incidents, mitigate risk, and enhance the availability of their applications. This becomes increasingly important as the volume of code produced is expected to rise with the use and advancement of AI code assistants. As a tech community, taking more responsibility for the software we deploy – specifically the code on which the software is built – will benefit everyone.”
Tim Mackey, Head of Software Supply Chain Risk Strategy at Synopsys Software Integrity Group
“Similar to most government requirements, the Self-Attestation form is a mandatory requirement with penalties for noncompliance. The form must be signed by a member of the software provider’s leadership team, potentially the CEO, and making false statements is punishable under 18 U.S.C. § 1001, which pertains to False Statements made to the U.S. government. This means that any software producer tempted to simply respond ‘Yes’ to all questions should think twice.
It’s crucial for software development practices to be well-known and understood if required to attest to them. The Self-Attestation form simplifies this as software providers are expected to follow a subset of the NIST Secure Software Development Framework (SSDF) activities…
For businesses seeking a FedRAMP Authorization, the Self-Attestation form allows for a FedRAMP 3PAO Assessor to provide an independent attestation instead of self-attestation.
However, what about businesses whose software is used in the U.S. government but aren’t FedRAMP authorized? Some may feel that the risk of making a mistake when self-attesting is too high. Given that there are more than 328 FedRAMP-authorized applications in use in the U.S. government, a reliable attestation process is necessary. Ideally, this process would ensure that corporate policies governing software development are consistently followed by development teams.”
