New secure software development rules in the US will require executives to sign forms confirming product safety if they want to work with the US federal government.
The secure software development attestation form is part of the US government’s tech security initiative and aims to make sure that software used by the government is developed securely.
The form details the minimum secure software development requirements a software company must meet before its software can be used by federal agencies.
This applies to any software developed or significantly upgraded after September 14, 2022. It doesn’t include open source software that is directly obtained by federal agencies, however.
The form must be signed by the CEO of the software company or an employee with the ‘authority to bind the corporation’.
By signing, the executives attest – confirm - that the software is developed in line with the secure software development practices within this form.
The move comes in direct response to the SolarWinds software supply chain attack in 2021.
What are the secure software development requirements?
The secure development practices themselves come from the Secure Software Development Framework published by NIST and cover four main areas.
Software development environments need to be secured, with regular logging, monitoring, and auditing of trust relationships used for authorization and access to any software development.
Why software 'security debt' is becoming a serious problem for developers
Multi-factor authentication (MFA) and conditional access needs to be in place, while sensitive data such as user credentials should be encrypted. Similarly, the rules state defensive cyber security practices, including continuous monitoring of operations and alerts, should also be used.
Software makers must make a “good-faith effort” to maintain trusted source code supply chains by employing tools or processes to address the security of internal code and third-party components. They must also maintain provenance for internal code and third-party components incorporated into their software.
Finally, under the rules, software companies must use tools to check for security vulnerabilities on an ongoing basis and prior to product, version, or update releases.
This means they will be required to have robust processes to deal with security vulnerabilities found prior to product releases, and have a vulnerability disclosure program in place.
“Failure to provide any of the information requested may result in the agency no longer utilizing the software at issue. Willfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001, a criminal statute,” the form notes.
What do secure software rules mean for devs?
The Cybersecurity and Infrastructure Security Agency (CISA) suggested that in future it would be more common for the public and private sector to make similar demands on their suppliers.
“Software underpins nearly every service our government delivers on behalf of the American people,” said Chris DeRusha, Federal CISO and Eric Goldstein, CISA executive assistant director for cyber security, in a joint statement.
“We envision a software ecosystem where our partners in state and local government, as well as in the private sector, also seek these assurances and leverage software that is built to be secure by design.”
CISA's repository for the online forms is expected to be available in late March, which gives companies some time to understand the form's content and requirements, it said.
Get tips on how to plan future data compliance and regulatory initiatives
Chris Hughes, chief security advisor at application security company Endor Labs, said while the move should be welcomed, the requirements in the form represent well-established fundamental secure development practices.
“Practices such as separating development and production environments, implementing logging and MFA are critical security controls that should exist in any modern secure software development environment,” he said.
However, it doesn’t mention anything about the need for threat modeling to enable secure-by-design systems, or memory safety.
Executives might pass the buck
A key area of concern highlighted by Hughes centers around the attestation process itself. He noted that CEOs can get another executive to sign off on the form, which raises questions over whether executives will simply delegate this to other members of staff.
“On one hand we hear that cyber security needs to be a boardroom issue and CISA even calls for c-suite involvement in their publications around secure-by-design/default, but then this form allows for this key attestation activity to be delegated to someone else in the organization and potentially keeping it from being as visible to the C-suite/CEO and executive leadership team,” he said.
The biggest challenges to meeting the requirements will be for suppliers who haven’t already implemented secure software development practices, Hughes said.
These suppliers will therefore be forced to assess their current development practices, identify deficiencies, and implement plans to fix them. This means that some organizations could be prevented from working with government agencies.
“This could lead to some suppliers exiting or avoiding the federal market due to the higher level of maturity required and potentially limited access to innovative commercial software solutions for the federal government,” he said.
