David London

CISA Secure Software Self-Attestation Common Form: Procurement and Regulatory Implications 

What Happened 

On April 27, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) released a Request for Comment on the much-anticipated Secure Software Self-Attestation Common Form. This document will, when finalized, have meaningful implications on software producers selling to the U.S. Government and beyond, and it amplifies recent calls to shift security accountability to the vendor community. 

Security guidance has been historically written mostly from an operator’s versus provider’s perspective. The Secure Software Development Framework (SSDF) is the first publication from the U.S. National Institute of Standards & Technology (NIST) specifically aimed at helping the vendor community comprehensively secure software throughout its lifecycle. 

The form identifies a subset of thirty (30) SSDF practices that together constitute the minimum secure software development requirements a software producer must generally meet, and attest to meeting, before their software may be used by Federal agencies. 

Our software security partner, Synopsys, released a blog last week unpacking some key implications. In addition to their perspective, we believe the recent CISA release should be framed within a few broader regulatory and procurement take-aways, described further below: 

Why it Matters 

·       As we observed in a recent blog on the National Cybersecurity Strategy released in March 2023, this action is consistent with a U.S. Government policy decision to shift security accountability (and liability) to the makers of software products.   

·       For those organizations without a formalized secure software development program or strategy, aligning to the thirty SSDF practices will likely be a resource-intensive effort.  

·       The Federal Government has also announced an intention to aggressively pursue enforcement actions against vendors who misrepresent the status of security maturity in procurements. For example, under the U.S. Department of Justice’s Civil Cyber Fraud Initiative, Jelly Bean Communications Design LLC recently agreed to pay $293,771 to resolve False Claims Act allegations that they failed to secure personal information on a federally funded website, which Jelly Bean created, hosted, and maintained. This aggressive approach could be applied to SSDF misrepresentations in the future. 

·       While the draft form does clarify some expectations for EO 14028 software security compliance, several questions remain unanswered. As OMB M-22-18 has stated, self-attestation is the minimum expectation but agencies may make risk-based determinations that a third-party assessment is required. The recent CISA guidance is silent on how or when those determinations will be made (and who will make them). 

·       A compliance “safety valve” has been introduced in the draft form that allows products to identify and document practices they cannot attest to and develop a Plan of Action & Milestones (POA&M) to be developed. While helpful for producers who cannot immediately meet expectations, this will create potentially significant additional workloads for vendors and government agencies that must process these POA&Ms and make related risk-acceptance decisions.  

What to do about it 

While organizations that supply the U.S. Government with software products must prioritize software security efforts and compliance, we also believe that SSDF conformance will become a commonplace “north star” expectation across a broader set of commercial customers as well. If not already underway, companies should begin aligning their software lifecycle practices to the SSDF, with a higher priority for the thirty practices reflected in the attestation form.  

Let's Talk.

Let's explore ways we can help you manage risk or position for strategic growth.

202.552.5280 | Mon. – Fri. 8:00 AM – 5:00 PM EDT