The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the White House’s Office of Management and Budget (OMB) have released their Secure Software Development Attestation Form, a long-anticipated worksheet that asks organizations that sell software and services to the federal government to attest to the security of their wares.
With its March 11 release, the federal government started the clock for software producers to assess and publicly acknowledge that they are following a range of security development best practices meant to keep their software from being compromised.
However, experts who have reviewed the initiative and its final product warn that gaps in the federal government’s attestation framework may leave the door open to sophisticated attackers capable of executing software supply chain attacks.
Here’s what we know about CISA’s new software attestation form — and what needs to change to manage modern software supply chain risk.
[ See Special Report: The State of Software Supply Chain Security (SSCS) 2024 | Download: State of SSCS ]
From EO 14028 to now: It's been a journey
The Secure Software Development Attestation Form was in the works for almost three years, ever since the Biden administration issued Executive Order (EO) 14028, "Improving the Nation’s Cybersecurity" in May 2021. Between then and now, additional guidance was issued, beginning with Presidential Memorandum M-22-18, which was released in September 2022 and laid out the requirements for the attestation form. That memorandum was followed by another, M-23-16, in June 2023, which addressed the kinds of software covered by the form, described conditions for noncompliance, and set the deadline for producers of “critical software” and “all software” to submit attestation forms following issuance of the finalized attestation form by the OMB.
At a high level, software development organizations selling their wares to the federal government must submit an attestation form for their software in PDF format or via an online portal. The software must have been developed after September 14, 2022, or undergone a major version update after that same date (for example, going from version 2.5 to 3.0 and not merely to 2.5.1). Importantly, providers of cloud-based software as a services that are subject to “continuous changes” must also submit attestation forms.
Wiggle words are a worry
CISA's Secure Software Development Attestation Form, first sent to the OMB on March 8 for approval, has been received with mixed responses. While the broad outlines of the form are solid, the final form provides opportunities for software development organizations to sidestep more robust development security measures. However, the attestation form does require the signatory — either the CEO of the software producer or a designee with the authority to “bind the company” — to acknowledge the use of best practices outlined in the Secure Software Development Framework (SSDF) produced by the National Institute of Standards and Technology (NIST).
Those best practices include the deployment of “secure environments” for development environments that are separated from non-development IT environments and that employ logging, monitoring, and auditing to spot unusual behavior. The form also inquires as to whether the software producer uses multifactor authentication, continuous security monitoring, data encryption, and incident response.
With the new attestation form, software producers also must attest to their use of tools or other processes to “manage related vulnerabilities” for “internal code and third-party components.” Additionally, the software producer that signs the attestation form must acknowledge that it uses “automated tools or comparable processes” to check for security vulnerabilities in its code, maintain a vulnerability disclosure program, and have a program for addressing disclosed vulnerabilities.
Charlie Jones, director of product for software supply chain security at ReversingLabs, said those requirements — and the need for a CEO (or designee) signature — send a clear message.
“They are a strong signal that the U.S. government wants software suppliers to take these security standards seriously and that they are ready to hold someone accountable in the event that they fail to properly manage risk."
—Charlie Jones
But the attestation form contains a lot of "wiggle words" that weaken the impact of its requirements, Jones said. For example, signatories attest to maintaining "provenance for internal code and third-party components incorporated into the software to the greatest extent feasible."
Upon review, many weak phrases are included, Jones said. For example:
- Software producers have to make “a good-faith effort” to maintain trusted source code supply chains by monitoring code security and managing vulnerabilities.
- Encryption should be used to secure sensitive data such as credentials used within development environments “to the extent practicable and based on risk.”
- Vulnerabilities must be disclosed in “a timely manner.”
Jones said software producers are likely to liberally interpret such phrases, in their favor.
The fuzzy terminology also gives producers a ready tool to push back on efforts by federal agencies and regulators to call them out on perceived failings. It will likely fall to regulators and, possibly, the courts to draw the lines around those phrases — a time-consuming process that will forestall uniform compliance.
Dropping the SBOM: A missed opportunity
Squishy language aside, one of the biggest issues with CISA's attestation form is its failure to address a range of software supply chain risks that have already proved to be vectors of attack for sophisticated actors. These gaps were brought to CISA’s attention during the comment period, including by ReversingLabs, but they were not closed in the final revision of the form.
In fact, the CISA seems to have toned down language that might have addressed supply chain risks. For example, a draft of the attestation form noted, "Software producers may be asked by agencies to provide additional attestation artifacts or documentation, such as a Software Bill of Materials (SBOMs) or documentation from a third-party assessor, beyond what is required by this common form.” However, the final form merely notes that "agency-specific instructions may be provided to the software producer outside of this common form.”
Jones said the omission of an SBOM requirement is a missed opportunity.
“The complex mixture of proprietary, commercial, and open source code in modern software projects prompted calls for greater supply chain transparency. Development organizations need to be able to identify risks in the software they are creating, ranging from exploitable software vulnerabilities to legal risks and technical debt."
—Charlie Jones
Beyond vulnerabilities: Software supply chain security is a requirement
As ReversingLabs noted in its comments to the federal government, the attestation form focuses on the identification, remediation, and disclosure of software vulnerabilities to the exclusion of supply chain risks.
Vulnerability management is a necessary goal, but it is insufficient to thwart attacks targeting software supply chains. To address threats such as those, CISA and the OMB need to require software publishers to look beyond software vulnerabilities to the kinds of threats and attacks that enabled incidents such as the hacks of software provider SolarWinds and VoIP provider 3CX.
[ See related: NVD Analysis: Why you need to modernize your application security ]
To give federal agencies confidence that those kinds of threats have been addressed, a comprehensive software attestation form should capture the software producer’s methods for addressing modern threats, including software tampering, malware injection, signature manipulation and leaked development secrets.
Get up to speed fast, development teams
While imperfect, the attestation form will have an impact on the federal government’s software supply chain security fairly quickly. Makers of critical software must have their attestation forms submitted within three months (by June 8, 2024). Makers of all other kinds of software named in the two memoranda must have their attestation forms submitted within six months (by September 8, 2024).
