Governance & Risk Management , Government , Industry Specific

Experts Say CISA's Software Attestation Form Lacks Key Parts

The U.S. federal government's secure software development self-attestation form for manufacturers takes bold steps towards securing the supply chain but lacks key components that should be incorporated into iterative versions of the document, experts told Information Security Media Group.

See Also: Zero Trust Unleashed: Keeping Government Secrets Safer Than the Crown Jewels

The final version of the Cybersecurity and Infrastructure Security Agency's software attestation form, released on Monday, requires software producers that contract with the federal government to attest that their products are developed in alignment with a series of specific secure software development practices.

Publication of the form started a 90-day countdown clock for publishers of "critical software" selling to the government to begin incorporating the form and a 180-day countdown for sellers of other applications.

Chris DeRusha, federal CISO and deputy national cyber director, along with Eric Goldstein, CISA's executive assistant director for cybersecurity, said in a joint blog post on Monday that the form helps ensure organizations "take ownership of security outcomes so the burden of security does not fall solely on the customer."

While the form includes fundamental secure development practices that federal software suppliers should be able to meet, "some key practices seem to be neglected," said Chris Hughes, chief security adviser for Endor Labs and a cyber innovation fellow at CISA.

Hughes criticized the final version of the attestation form for leaving out threat modeling requirements and told ISMG the document "lacks any mention of memory safety, which has ironically also been a core message from CISA in other avenues."

"The biggest challenges to meeting the requirements will be for those suppliers who haven't implemented secure software development practices" or followed guidance such as the National Institute of Technology's Secure Software Development Framework, Hughes said. "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."

Software producers must attest that their products were produced in secure environments, with regular logging, monitoring and auditing of trust relationships used for authorization and access. The form also requires developers to enforce multifactor authentication and conditional access across certain environments, as well as to encrypt sensitive data and implement defensive cybersecurity practices such as continuous monitoring of operations and alerts.

"This will greatly influence the overall security of products being used by or sold to the government, however, there are still some very real gaps," said Joe Nicastro, chief technology officer of the application security posture management platform Legit Security. Nicastro said the form does not allow organizations to attest in an automated way and warned that it risks introducing "very manual processes into an organization's security workflows."

CISA declined to provide comment about the attestation form lacking certain components or about concerns that young and resource-constrained software companies may have struggles meeting the deadline for compliance.

The federal government's biggest challenge when it comes to ensuring its software is secure by design isn't a lack of critical components on its attestation form or the compliance deadline, according to John Speed Meyers, a security data scientist for the software supply chain firm ChainGuard.

"There is no current systematic way to measure how 'trustworthy' the software Uncle Sam buys is," Meyers said. "Without that simple baseline, it will be hard to know if companies complying with these attestations lead to 'trustworthy' systems."

Experts said future versions of the attestation form should include clearer vulnerability management guidelines, as well as requirements for software bills of materials, memory-safe programming languages and stricter penalties for companies that provide false attestations.

"Memory-safe languages were left out because many suppliers aren't there yet and couldn't quickly attest to using memory-safe languages currently," Hughes said, describing the transition to memory-safe languages as "more of an aspirational, industrywide shift."

"Six months in theory should be enough time for most organizations to meet some of the fundamental requirements such as separating environments, implementing logging and using MFA," he added. "That said, some of the practices that involve third-party components, provenance, and so on may be tough for some organizations who aren't mature in that area as it stands now."

CISA's Executive Assistant Director for Cybersecurity Eric Goldstein said in a statement sent to ISMG that the agency and its partners at the Office of Management and Budget "will continue to refine and mature both the attestation form and submission to reduce burdens for applicable software producers."*

*Update March 14, 2024 14:06 UTC: Adds comment from CISA's Eric Goldstein.