New guidance issued by the White House on Wednesday gives agencies a timeline for beginning to obtain self-attestations from software developers before using their products, rather than relying on third-party assessments.
Self-attestation refers to documentation that developers must provide to demonstrate their compliance with the Secure Software Development Framework. This is a key framework that federal IT leaders and the wider tech industry have been aware of since at least March, when the White House required agencies to start adopting it.
Details included in the latest OMB memo lay to rest concerns expressed by IT and cybersecurity experts canvassed by FedScoop in June, who worried that it could require software developers to obtain third-party verification of their compliance, which would take years to set up sensors and monitors and ensure qualified auditors existed.
Speaking with FedScoop following publication of the memo Wednesday, Dan Lorenc, CEO of software security startup Chainguard, said the White House’s decision to start with self-attestation was “pretty obvious early on.”
“If they’d have done third-party, it would’ve been shocking at this point,” he added. According to Lorenc, it is the first step to “kick-starting a complex ecosystem” in which vendors will soon be required to assess their own vendors in a wave that is likely to “spread pretty rapidly across the industry”.
Lorenc believes a transition to third-party assessments will happen at some point, a view not shared by everyone in industry.
According to Henry Young, director of policy at industry group The Software Alliance, such assessments from a third-party provider may not be necessary.
“What I’m seeing is that it’s likely that a majority of procurements can be undertaken with a vendor’s attestation, rather than the more onerous third-party certification,” he said, emphasizing that software vendors take the assurances they make very seriously because of their direct effect on customers.
The White House memo mandates any self-attestation include the software developer’s name, a description of relevant products and a statement attesting the developer complies with secure development practices.
Despite this, agencies may still require third-party assessments based on risk-based determinations on the product or service’s criticality, according to the guidance. These can be performed by either a Federal Risk and Authorization Management Program (FedRAMP) assessor or another they approve.
The Federal Acquisition Regulatory Council also plans to develop a standard self-attestation form for agencies.
Currently, basic scanning or software composition analysis tools are used after software is built to generate a machine-readable software bill of materials (SBOM), but agencies can already do that. Modern SBOMs will be developer-generated and include more information for a fuller picture of the software supply chain, Lorenc said.
Despite lawmakers’ recent efforts to codify SBOMs in the federal procurement process within the House spending bill, software developers want the government to clarify which artifacts — threat models, log entries, source code files and vulnerability scan reports — they’ll contain and how they’re to be shared before proceeding.
Language in that bill would prohibit the purchase of software with known vulnerabilities inside.
“That’s the type of thing that sounds great at first, until you get into the trenches and realize how messy a lot of these vulnerability databases are and how poor the data quality is,” Lorenc added.
SBOMs will only magnify that poor data quality, he said.
While Young is happy the White House memo includes many industry best practices concerning secure software development, capabilities and life cycle, he’s disappointed the same practices aren’t required within agencies and through contractors developing software.
The memo also doesn’t address how to streamline self-attestation across the government.
“The guidance does not do anything to harmonize requirements between agencies,” Young said. “So that means that vendors might have to provide the same or similar documentation to different agencies, which doesn’t seem to be the best use of cybersecurity resources.”