IT pros pan government software supply chain security advice

Federal SBOM statements deemed contradictory, confusing

Last year's presidential executive order kicked the development of software bills of material (SBOM) into high gear. These machine-readable lists of the software components and dependencies that make up an application were mentioned in the executive order to ensure transparency from federal software suppliers and shore up software supply chains. The order was followed last week by a memo from the White House Office of Management and Budget reiterating that SBOM may be required by federal agencies from software suppliers based on the criticality of the application.

These mandates were as expected, but multiple industry organization raised the alarm about legislation currently working its way through Congress under the 2023 National Defense Authorization Act (NDAA). Earlier this month, a group of organizations -- comprised of the Alliance for Digital Innovation, the Software Alliance, the Cybersecurity Coalition, and the Information Technology Industry Association --published an open letter to Congressional leaders raising objections to SBOM requirements in the bill.

As drafted, the legislation "provides conflicting requirements with respect to certifications and notifications," the open letter from the groups stated. "In one instance, the provision requires certification that the items in the BOM are free of vulnerabilities or defects, and in another it requests a plan to mitigate all identified vulnerabilities."

It's absolutely clear that the people who wrote it do not understand continuous delivery ... nor do they understand how defects get passed downstream.

Any such vagueness and contradiction could provide a path to working around the intent of requirements, which is to shore up software security, said Daniel Kennedy, an analyst at S&P Global.

"The idea that continually updated software can be free of vulnerabilities is not a realistic goal," he said. "There are gaps between identification and fix, and patch availability and application, and while those gaps can be a result of inattention, they can also be a function of a proper approach to testing the effects of a software patch before deployment in an environment."

Wheeler said he expects many of the semantic kinks within the NDAA bill to be worked out or addressed by the Department of Homeland Security (DHS) follow-on guidance regarding relevant contracts, for which the bill also calls.

But as written, the NDAA would also impose a 180-day deadline to comply with SBOM requirements following this DHS publication, which Wheeler said is far too short a time frame given the state of SBOM technology.

"Generating SBOM is not something the software industry has done yet, in general, other than in special cases," he said. "This is a huge change in the software industry, and I do think that we're going to get there, [but not] in any reasonable way in the time frames that they're envisioning here."

Some problems in SBOM, such as support for rapidly changing cloud-native applications, remain largely unsolved -- though projects are afoot to address these issues. But even the most mature SBOM tech struggles with the fundamental problems of transitive dependencies -- where nested layers of software components make transparency difficult -- as well as false positives and negatives in detecting vulnerabilities.

It may be that 180-day requirement is eliminated before the bill passes the Senate or that the DHS interpretation accepts "best effort" SBOM at the 180-day deadline, Wheeler said. In the worst-case scenario, he worries that too short a time frame for compliance could hurt the public perception of SBOM effectiveness.

"I fear that will actually hurt, because then people will say, 'Oh, SBOM are crappy and not reliable,'" he said.

Software supply chain security confusion adds to risks, for now

SBOM adoption will likely charge ahead. But in the meantime, confusion about how to implement software supply chain security represents its own kind of risk.

"Nobody knows exactly what to do," said Dan Lorenc, co-creator of the Sigstore project and co-founder and CEO of software supply chain security vendor Chainguard. "There's a whole bunch of things that claim to solve parts of the problem and don't really do that."

Chainguard launched this week a free training resource for developers on all aspects of software supply chain security named Chainguard Academy in a bid to cut down on this confusion. But it will likely take about a year before third-party auditors are trained on concepts such as SBOM and formal certifications are available in this field, Lorenc estimated.

"We want to build up to actual certifications over time, but the compliance frameworks are still shifting around," he said.

This week also saw the first generally available release of Chainguard Enforce -- a supply chain security policy orchestration product that ensures only trusted container images are run in Kubernetes clusters.

Katie Norton

This type of "day two" operation is a broad area of SBOM tech that remains nascent, according to Katie Norton, an analyst at IDC.

"The biggest issue with SBOM is not generating them, but ... how are SBOM going to be stored and shared?" she said. "To be actually useful in the case of a vulnerability like Log4Shell, a company is going to need to be able to aggregate all their SBOMs, and they need to be able to be queried."

Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.