An executive order issued in May by the Biden Administration has elevated the status of the software bill of materials, by mandating their use in federal government contracting.
Enterprises can look for more transparency from software vendors after the Biden Administration’s recent mandate that software bills of materials be provided by companies attempting to do business with the federal government.
Software bills of materials, frequently abbreviated to SBOMs, aren’t a new concept. The idea comes from the manufacturing sector, where it’s often crucial for buyers to fully understand the components and materials that were used to make a particular piece of equipment.
For example, a train engine might contain parts that aren’t rated for certain levels of vibration stress, making it unsuitable for use on a particular type of track. The goal of an SBOM is similar, listing all the proprietary, open source, and licensed components being used in a particular piece of software, so that a buyer can review it and check whether any of those components are outdated or insecure.
“One of the benefits of something like an SBOM is that it’s not only giving you ‘what you have now,’ but ‘what you have in the future,’” said IDC research director Jim Mercer. “So if you’re using [software composition analysis], it gives you that visibility, what you have, but it’ll also help you avoid risk–it’ll tell you when you’re using open source software that’s out of date.”
A standard SBOM format would have particular upsides in sectors where many stacks rely heavily on existing intellectual propery, including networking. Some of the most infamous security breaches of recent years were predicated on security flaws in commonly used software components, including Ripple20 and Heartbleed.
Scott Crawford, infosecurity research director for 451 Research, said that some standard data formats for SBOM-type information already exist, including SPDX, CycloneDX, and SWIDtags. But these all work differently, and are designed for slightly different purposes. SPDX, for example, is a general-use SBOM format managed by a Linux Foundation working group, while CycloneDX is published by the Open Source Web Application Security Project and consequently is aimed mostly at application-security issues.
This variability is part of what the government is hoping to address, according to Crawford.
“One of the things they’re suggesting is that the SBOM acknowledge ‘known unknowns’ as a point of explicitness in depth,” he said. “Ideally, you can track a complete graph of the assembled software, but some dependencies may be unclear, there might be a binary you don’t have full visibility into.”
That said, some in the security world see SPDX as a ready-made standard; no new format needs to be created at all. Needless to say, the Linux Foundation has already thrown its support behind this viewpoint, and Dale Gardner, a senior research director at Gartner, said that they’re not alone. That despite efforts by the National Institute of Standards and Technology to encourage SBOMs in the same area.
“We’ll see what happens if something comes out NIST, but the thing that comes up when I talk to customers is SPDX having some tailwind behind it,” he said.
The government’s move to adopt standardized SBOMs is highly likely to prompt industry-wide adherence to whatever standard is eventually settled upon. It might not be a hassle-free transition for the industry because there are costs involved in auditing and documenting software in a systematic way. But Gardner argued that more widespread SBOM use is past due.
“A lot of things that are being recommended are things that orgs should be doing anyway,” he said. “It’s a requirement to clean things up and start operating in a secure manner.”
Exactly how disruptive the informal adoption of an SBOM standard will be, for vendors, depends on that vendor’s particular situation. Some, according to Forrester principal analyst Sandy Carielli, already produce something like an SBOM on their own.
“For those with mature processes, that might be a not-very-heavy lift,” she said, “[but] if you’re not building in that tooling into your development cycle, the point at which you can reliably, automatically produce an SBOM is a little bit harder to ascertain.”
SBOMs alone won’t solve all security problems on their own, of course. But the idea is to build awareness about potential security threats and change the expectations for vendors in a positive direction.
“I think it’s putting pressure on the cloud providers to make sure their offerings are secure,” said Mercer. “The more people that are using SBOMs, the better.”
This article originally appeared on NetworkWorld.