White House preps security controls for commercial software acquisition
The administration is attempting to leverage the procurement powers of the federal government to bolster software cybersecurity for the first time.
The White House announced plans this week to implement a new set of security requirements covering the acquisition of commercial software in keeping with the provisions of the cybersecurity executive order the president signed last year.
A fact sheet the administration released this week about the new software security requirements suggested the White House was attempting for the first time to leverage the federal government's procurement powers to bolster cybersecurity in software products across the private sector.
A spokesperson for the Office of Management and Budget told FCW that the Federal Acquisition Regulation (FAR) Council will consider what actions are necessary to implement standards for third-party software featured in the National Institute of Standards and Technology standard Secure Software Development Framework (SSDF).
That framework seeks to ensure security practices have been followed throughout each step of the software development life cycle. It features measures to implement and maintain secure environments for software development, as well as methods to share provenance data for all components of software releases and to track new requirements, risks and management decisions. NIST has also rolled out subsequent programs for software contractors to provide new labels detailing the manufacturers' internet of things and software security efforts.
Software developers and industry leaders see the White House announcement as another step closer to the eventual governmentwide adoption of Software Bills of Materials—machine-readable lists of components that make up a software product, which can help confirm in real-time whether those products are susceptible to vulnerabilities and emerging cyber threats.
"SBOMs can deliver tool interoperability and allow for the easy exchange of information from vendor to supplier to agency," Chris Wysopal, founder and chief technology officer of Veracode, told FCW. "There should be no reason that a software company, contractor or agency can't assess its code, including any potential open source used in the software they have built, used or plan to purchase."
While the FAR Council typically has to follow a "fairly lengthy" rule-making process that includes months of collecting, analyzing and responding to public comments, the White House and federal agencies have a couple options to speed up the implementation of new third-party software requirements, according to former Department of Homeland Security Chief Procurement Officer Soraya Correa.
"They can do an interim rule to get something going right away, and the other thing they can do is a FAR deviation to implement a rule," Correa told FCW, explaining that waivers can enforce the requirements as procurement officials work to finalize the official rule. "That process can take—on a fast track—probably about a good four months."
Correa added that procurement officials across the Department of Defense, NASA and General Services Administration would conduct an analysis to determine potential impacts on the private sector before taking steps to speed up the implementation process.
"The pressure is naturally there, because we know the risks that we face when we do these procurements," she said. "We've got to get them done quickly, but we also have to protect the data, the system that these solutions are riding on and the integrity of the process."
OMB previously instructed agencies to obtain self-attestations from software providers outlining their compliance with the standardized development practices, and said the FAR Council was planning to propose rule-making to implement a standard self-attestation form. Those directives also pointed to NIST guidance on third-party software development.
"By requiring a standardized approach to secure software development like [SSDF], we can better mitigate risk and help reduce the number of vulnerabilities released in software," Eric Baize, vice president of product and application security of Dell Technologies, told FCW.
Earlier this month, trade groups sent a letter to the heads of multiple congressional committees warning that SBOMs "will not achieve the desired utility" in federal agencies due to an apparent "lack of standardization" for their dissemination and use.
Those groups acknowledged the importance of SBOMs serving as a foundational block in enterprise-wide cybersecurity, but effectively argued that agencies were not prepared to fully leverage the lists to mitigate cyber risks.
Still, many experts told FCW there was enough guidance for agencies to begin properly implementing SBOMs – and that now is the time to require their use throughout the federal government.
Douglas Schmidt, engineering professor at Vanderbilt University and a former member of the Air Force Scientific Advisory Board, said he supported the White House move to implement third-party software security requirements for federal agencies.
"The Cybersecurity Maturity Model Certification (CMMC) standard defines a very comprehensive set of controls" he added, which agencies could use to ensure software products have met the standardized requirements.
But Schmidt also noted that SBOMs and other security features cannot mitigate cyber threats alone; automated tools to evaluate software for vulnerabilities will also play a critical role in bolstering governmentwide cybersecurity.
As the White House moves to bolster software cybersecurity, experts said the true test will be how agencies utilize and leverage new technologies and security controls.
"Vendors should easily be able to provide SBOMs, but the real challenge is turning lists of software features and components into an understanding of risk," Wysopal said. "A list of features alone doesn't tell you whether something is vulnerable, which is really the key to protecting government networks and information."
The White House announcement on software acquisition comes as the clock is ticking on key portions of the cybersecurity executive order. Agencies have until September 2023 to collect letters of attestation from vendors to assert that third-party software is compliant with secure software development practices. For critical software, which NIST defines as software with direct or privileged access to networking or computing resources or otherwise performing functions critical to trust, agencies must secure letters of attestation by June 2023.