When alleged Russian hackers compromised the SolarWinds Orion platform to spy on U.S. agencies and other high-profile entities, the tech industry renewed its call for the adoption of software bills of materials (SBOM) — an inventory of components that make up the final product.
Advocates say that will help give IT and cybersecurity professionals the knowledge needed to more quickly diagnose potentially security breaches and other issues.
Since the SolarWinds-leveraged attack was discovered in December 2020, several other notable incidents have revived the SBOM movement, including the Log4j vulnerability that impacted thousands of vendors and even more products. Discovering if your products contained the vulnerable versions of the popular Java logging software would have been easier if vendors produced SBOMs, says Liran Tancman, CEO of cybersecurity firm Rezilion.
For many years, organizations have used configuration management databases (CMBD), essentially an inventory of the organization’s IT assets.
“Therefore, the notion of an SBOM shouldn’t be a revolution,” Tancman says. “It’s an evolution.”
Related: SBOMs Are No Longer Optional
The U.S. government has mandated cybersecurity protocols and upgrades in recent years in response to a rise in cyberattacks, so SBOMs are becoming the norm in government agencies. Now, the private secot is beginning to require SBOMs of its vendors, according to Tancman.
However, what should organizations look for in SBOMS? What do SBOMs need to contain for an IT decisionmaker to be satisfied with the security of the product?
What needs to be in an SBOM?
At the bare minimum, an SBOM must contain a complete inventory of all of the software packages running in the product and which entity produced it.
“At a minimum, you need all of the software packages running in it,” Tancman says.
According to Tancman, the U.S. government defined the minimum elements for an SBOM, which includes:
- Baseline information about each component, including supplier, component name, version of the component, other unique identifies, dependency relationship, author of SBOM data and timestamp.
- Support automation, including via automatic generation and machine-readability to allow for scaling across the software ecosystem. Data formats include SPDX, CycloneDX and SWID tags.
- Practices and processes of SBOM requests, including frequency, depth, known unknowns, distribution and delivery, access control and accommodation of mistakes.
Then there are other optional fields, such as a hash or license data, Tancman says, that essentially make up an SBOM document.
Finding vulnerabilities
While the detailed analysis and inventory of the software components of the product make up the SBOM document, another part, called the Vulnerability Exploitability eXchange (VEX), is an addendum to the document that tells the user what vulnerabilities are associated with the components listed in the SBOM.
“What’s really interesting is that it doesn’t just tell you what the vulnerabilities are – it tells you if those vulnerabilities are impactful, if they’re really exploitable, and why,” Tancman says. “If you get a VEX from your vendor, you can really understand the exposure you’re inheriting.”
This helps organizations better evaluate their potential cyber risk and allocate resources to vulnerable parts of the IT system. In addition, this allows organizations to avoid back-and-forth customer service calls with vendors.
“With SBOM and VEX, I think that’s a very good start,” Tancman says.
Understanding the history of SBOMs
The concept of a detailed list of the ingredients that make up a piece of software or firmware comes from the Internet of Things (IoT) devices, which are typically very static and don’t necessarily receive regular updates.
Now, due to SolarWinds and other supply chain attacks, SBOMs are being considered for entire environments and dynamic things such as container images that get updated every day. Essentially, the scope of SBOMs is becoming much larger and applying to “everyone who is doing anything with software,” Tancman says.
“The result is we’re going to a place where it’s much more dynamic,” Tancman says. “We need something that can keep up with the pace of change in the IT environment.”
This article originally appeared on Commercial Integrators’ sister-site MyTechDecisions.com.
