White House preps security controls for commercial software

The White House has previewed plans to implement the security requirements for commercial software called for in the Executive Order on Improving the Nation’s Cybersecurity. A fact sheet released in October represents an effort to leverage the federal government’s procurement power to bolster cybersecurity. 

One key piece of the plan to put cybersecurity at the forefront of acquisition is the use of software bills of materials (SBOMs) — machine-readable lists of the components in software products — to help confirm in real time whether the products are susceptible to cyberthreats. 

Some trade groups have argued against legislative proposals that would require software vendors to provide SBOMs and attest that their products are free of known defects. But other experts and industry leaders say the time has come for SBOMs to be standard practice.

For example, the widespread exploitation of a vulnerability known as Log4Shell in the Apache Log4j software library posed a significant threat because of the ubiquity of that open source code in commercial software. Such vulnerabilities are driving concerns about risks to the worldwide software ecosystem and prompting policymakers to act sooner rather than later.

“What we just saw from Log4j is that there is a need where we can improve the security for open source software,” said Phil Stupak, director of federal cybersecurity at the Office of the National Cyber Director, at an industry event in September. “We have an obligation to do that.”

“SBOMs are like the basic ‘ingredients list’ that goes into your digital product,” said Jon Geater, co-founder of the software-as-a-service platform RKVST. “Just like some people really need to know if a candy bar contains wheat or nuts, a digital consumer needs to know what is going into their estate.”

Geater added that SBOMs represent the first step in helping enterprises properly manage their own risks. “If they wake up to a big news story like Log4Shell, they can now take a look at everything they have and instantly see where Log4j is in their infrastructure without having to wait for all their vendors to separately and individually contact them,” he said.

‘More than enough guidance’ for SBOMs

The federal government has multiple efforts underway to implement software security standards, including a push at the National Institute of Standards and Technology to expand and mature its Secure Software Development Framework (SSDF) and a stakeholder-led effort at the National Telecommunications and Information Administration to improve transparency into software components.

“Long story short, there’s more than enough guidance for agencies to properly begin producing and requiring SBOMs,” said JC Herz, co-chair of NTIA’s Software Transparency Standards and Formats Working Group and co-founder of the software supply chain intelligence platform Ion Channel. “The uncomfortable unanswered question is: What are they going to do with the findings when it becomes obvious that vendors and contractors are not maintaining their products and deliverables? Some very grown-up conversations will need to happen.”

The most recent guidance from the Office of Management and Budget offers advice to organizations struggling to produce full SBOMs: Start small, with letters of attestation from software providers confirming the secure development and shipment of their products. 

“These letters are not standardized and probably never will be, but that doesn’t matter,” Geater said. “It’s the attestation that is important, ensuring that evidence you rely on today will remain independently verifiable and can’t be modified, shredded or deleted.” 

Speeding the rule-making process

Although the Federal Acquisition Regulatory Council typically has to follow a rule-making process that involves months of collecting, analyzing and responding to public comments, the White House and federal agencies have a couple of options to speed the implementation of new third-party software requirements, said Soraya Correa, former chief procurement officer at the Department of Homeland Security. 

“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 while procurement officials finalize a rule. “That process can take — on a fast track — probably about a good four months.” 

She added that procurement officials at the Defense Department, NASA and the General Services Administration would likely conduct an analysis to determine potential impacts on the private sector before attempting to speed the implementation process. 

“The pressure is naturally there because we know the risks that we face when we do these procurements,” Correa 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.”

An OMB spokesperson told FCW that the FAR Council will consider what actions are necessary to implement standards for third-party software featured in NIST’s SSDF. 

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 at Dell Technologies, told FCW. 

Douglas Schmidt, an engineering professor at Vanderbilt University and a former member of the Department of the Air Force Scientific Advisory Board, said he supported the White House move to implement third-party software security requirements for federal agencies. He added that the Defense Department’s Cybersecurity Maturity Model Certification “defines a very comprehensive set of controls” that agencies could use to ensure that software products have met standardized requirements. 

However, he said SBOMs and other security standards alone cannot mitigate cyberthreats. Automated tools that continually evaluate software for vulnerabilities will also play a crucial role. 

Do agencies know what to do with SBOMs?

Henry Young, director of policy at BSA, said SBOMs can help an organization “understand the full composition of its software for successful incident response and recovery,” but the mandatory implementation of such inventory lists may not be ready for codification. 

“We know SBOMs deliver important information, but if the recipient of that data isn’t ready to absorb and act on it, the information is simply not valuable,” Young said. “Right now, vendors can put an SBOM together, but without industry standardization, the process for turning an SBOM into the action necessary to make concrete cybersecurity improvements isn’t yet ready to be done at scale.”

Ross Nodurft, former head of OMB’s cyber team and now executive director of the Alliance for Digital Innovation, told FCW that “SBOMs can be a portion of any broader software supply chain risk management approach” but cautioned that “focusing on SBOMs risks missing the forest for the trees.”

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. Agencies must secure letters of attestation by June 2023 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.