CISA’s draft attestation form raises key questions about software security push

The Cybersecurity and Infrastructure Security Agency took a big step forward in the government’s secure software development push with the release of a draft “self-attestation” form for vendors last week.

Software experts say the practices outlined in the draft form represent an important baseline for federal software security.

But experts and industry representatives alike are also raising questions about missing and confusing elements in the document, as well as broader concerns about a process that will have to be replicated across government procurement offices.

CISA published a draft “Secure Software Self-Attestation Common Form” last week. The agency is accepting feedback on the form through June 26.

The form is a key component of a White House Office of Management and Budget memo that directs agencies to require software vendors to self-attest to following secure development standards released by the National Institute of Standards and Technology last February.

The requirements stem from the May 2021 cybersecurity executive order and efforts to improve security after a 2020 incident where several agencies and large corporations were compromised by malicious code that was added into SolarWinds software.

Once finalized, agencies across government are expected to use the form to meet the OMB requirements. The form will have to be signed by a company’s chief executive officer or a designated employee.

John Pescatore, director of emerging security trends at the SANS Institute, said the self-attestation form takes the conversation around software security requirements from “talk to action.”

“As far as saying, ‘All right, here’s the bare minimum if you want to sell to us,’ that’s what this attestation form is,” Pescatore said. “My question to any government agency would be, why are you buying software from anybody who can’t just very quickly say, ‘Yes,’ to all these questions?”

The attestation form’s requirements are based on NIST’s Secure Software Development Framework. They cover a range of best practices, such as building software in a secure environment, maintaining control of source code, the use of multifactor authentication and automated testing tools.

Tim Mackey, head of software supply chain risk strategy at Synopsys Software Integrity Group, said the draft form represents a “very solid baseline” for government-wide software security standards.

“One of the important things that this does is create a baseline where effectively everybody can be held to the same standards,” Mackey said. “We can agree that this is a reasonable minimum bar, and then be in a position to say, ‘Well, how can we improve beyond this?’”

But the draft attestation form also leaves on the chopping room floor nine out of the 42 total controls included in NIST’s SSDF, a decision that left former Defense Department Chief Software Officer Jason Weiss scratching his head. Weiss is now co-founder of Digital Triad Group, a company specializing in secure software development practices.

“It isn’t so much that the nine controls have been removed, it’s that they were removed without any explanation, any insight into the rationalization,” Weiss said. “There’s still time for the public to provide feedback to CISA, where they can still change this document after the feedback window closes and hopefully tighten it down or at least provide explanations as to why certain controls were eliminated.”

But OMB in its directive last year set a deadline of June 11 for agencies to start collecting the self-attestation forms for “critical software,” while the comment period for CISA’s draft form runs through the end of June. The deadline for collecting attestations for all other software is September 14.

“We’re really up against the wall because anything that’s operating systems, hypervisor, anything at that level, is requiring an attestation from the vendors starting in June,” Weiss said.

As of publication, OMB has not responded to request for comments.

The Information Technology Industry Council, whose members include many large technology providers, applauded how CISA’s draft form allows for a Federal Risk and Authorization Management (FedRAMP) assessment to be used in lieu of the self-attestation, so long as the FedRAMP assessment followed the NIST software guidelines.

ITI also commended a provision that requires agencies to get White House approval before adding any agency-specific requirements to the common attestation form.

But Gordon Bitko, ITI’s executive vice president of policy, said the organization also has several outstanding questions about the attestation process, including how agencies will collect and use the data included in the forms, and what risk factors would allow agencies to request additional artifacts, like Software Bills of Material.

And Bitko said ITI’s members are also concerned about the tight timelines for reviewing the draft form before OMB requirements for critical software go into effect.

“I think it’s important to get these issues cleared up,” Bitko said. “This is my own personal opinion, but I would rather there be a little bit of a delay to get them resolved, rather than using the form when there’s uncertainty about how it’s going to be used and what are the consequences. . . . Everybody understands the criticality of all this. I think we run the risk of one step forward, and two steps back if we can’t get this stuff right up front.”

Meanwhile, Weiss also pointed out that as currently outlined, the form does not provide any consideration for providing attestations in machine-readable formats. The need for some aspect of automation in the process be especially acute for software-as-a-service providers, he said, who often push code into production multiple times per day through a “continuous integration and continuous delivery” (CI/CD) approach.

“The idea that we’re going to go out here and capture all of this information as handwritten notes and signed on a PDF that’s emailed to somebody is, in my opinion, a major shortcoming of the approach,” Weiss said. “What we need is the ability to provide this information electronically.”

Multiple commenters also pointed to the need for more clarity around how often a software vendor would need to submit new forms as they update their software. Under the requirements laid out by OMB, a new attestation is required for existing software that’s modified by “major” version changes under widely adopted “semantic” versioning schemes.

“If you do a major update, and there was no change to your software development process, do you have to test again to say everything is still the same?” Bitko said. “It doesn’t define exactly what a major update is . . . you could see where there’s room for that to be interpreted differently by different agencies and different providers.”

Weiss said the lack of clarity around the update process could present a “substantial loophole” for industry, where vendors may not release “major” updates to their software for years, while still applying changes through “minor” updates and patches.

“So anybody with an existing deployment anywhere in the U.S. federal government has a very direct and open loophole to avoid this whole self-attestation requirement,” Weiss said.

Despite flagging some issues with the form and overall process, security experts lauded OMB and CISA’s push to adopt secure development practices across government.

And Pescatore pointed to previous security initiatives in government that seemed to have warts and challenges in the beginning, such as mandates for agencies to adopt secure Domain Name System measures and anti-spoofing standards for email.

“Don’t let perfect get in the way of good,” Pescatore said. “This attestation is just one piece. But it’s an important flag to put in the ground.”

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.