What's needed for SBOM success? [Q&A]

Enterprises are increasingly looking to software bills of materials (SBOM) to understand the components inside the tech products they use in order to secure their software supply chain.

But do SBOMs really provide value? And how can they be used more effectively? We talked to Varun Badhwar, CEO and co-founder of Endor Labs, to find out the keys to using SBOMs successfully.

BN: Why has having an SBOM become so important?

VB: It's not about the SBOM itself; it's more that modern software development is already very complex and shows no sign of becoming simpler to secure. The vast majority of the code in new software solutions isn't written by the developers; it's instead pulled into each new project without the developers’ approval or even knowledge. They typically don't know where it came from, how it's being used, and how safe it is. These are indirect or transitive dependencies, where the tiniest vulnerability can be exploited for profit.

Meanwhile, the external environment is arguably even more cloudy. After multiple breaches and other problems that originated with transitive dependencies, there's a plethora of regulatory and legislative requirements in place. From a White House Executive Order to the National Defense Authorizations Act of 2023, the government is putting rules in place that are more specific than ever before.

In a lot of these situations, an SBOM isn't the only answer, but it is often part of the answer.

SBOMs have gained in importance and visibility because a comprehensive SBOM provides transparency into a very clouded process. It features a list of (ideally) all the software components used to build an application or product. This level of visibility makes it easier to answer questions around ease of use, security issues, and more.

BN: When should you be demanding an SBOM from a vendor?

VB: You may not need an SBOM from every vendor whose product you use. A better first step may be to identify the most critical service providers and off-the-shelf solutions. If operations rely on data maintained by third parties -- and that includes just about everyone -- then it's important to determine what would happen if that data suffers a loss of confidentiality, integrity or availability.

Map out what would happen in a 'worst case scenario,' working with your various business departments to determine what the financial costs of each would be.

Once you've established the potential impact of a breach for each vendor, you can rank them in descending order. Based on your resources and organizational risk appetite, you’ll need to draw a line somewhere as to where to focus your analysis.

For some organizations with stringent security needs, every vendor with any impact on the data will need to provide an SBOM. For others, it may be mandated only for a subset of critical providers.

Also important to keep in mind is the sophistication of your vendors themselves. Are they currently capable of providing you with an SBOM? A highly specialized startup might reasonably explain that they are focusing all of their efforts on solving a particular problem rather than providing detailed representations of their software's composition. A more mature enterprise vendor, however, should be more capable of providing you what you need.

BN: What are the things to look out for in an SBOM and how can you analyze one effectively?

VB: The term SBOM has been widely used, and even more widely interpreted, but it’s typically an inventory of all the components that make up a piece of software. It includes details about each component, and can be used to look up whether a version of a software package has any known vulnerabilities. It should detail all dependencies, direct and indirect, encompassing source, level of security, license, expiration, upgrades and more.

There are tools currently available to identify CVEs in SBOMs, but more analysis is needed. The best is reachability analysis, which involves a 'forward' pass in the call graph, starting from the client and checking to see which packages in the dependency set can be reached. There are other analysis methods too, but the key is to describe the outputs in a consistent and easily consumable format.

BN: If you identify a vulnerability from an SBOM what’s your next step?

VB: Simply finding vulnerabilities is not the answer. There are several ways to identify common vulnerabilities and exposures (CVEs) hidden in the code -- this is how we get the endless stream of false alerts that drain productivity and cause fatigue. The related complication is that while developers track packages, the actual reuse occurs at the code level. The strategy here is one of priority: How can an organization determine which vulnerabilities pose the greatest risk to the operation, and how can risks be remediated?

One good option is reachability analysis. This approach tracks the specific elements of the code in a dependency that's being reused, which helps the organization establish whether a security problem in the code affects the project, whether a dependency update is safe, and even whether code removals will affect other potential users. This isn't the only path forward, but the goal is always the same: Organizations need to describe relevant outputs in consistent and comprehensive terms.

Assuming you have a good idea of the risk(s) posed by the vulnerabilities identified in the SBOM, it's best to dig a little deeper into the specific issues. For example:

• Do you have a policy that specifies your risk appetite and tolerance?
• Who has the authority to accept incremental risk above that level?
• Who is accountable for resolving the issues identified?
• What do your contracts with your customers say?
• How will you enforce these requirements?

BN: What is VEX, how does it differ from SBOMs and why is it useful for organizations?

VB: VEX, or Vulnerability Exploitability Exchange, is a system for software producers to share their assessment of the vulnerabilities in their software components. VEX is the mechanism through which software producers classify and label the vulnerabilities in their software.

VEX collateral is used to provide a consistent and standardized way to describe vulnerabilities. They include standard details about the vulnerability, such as its severity. They also include an analysis of whether the vulnerability may be exploitable, how it can be mitigated or fixed, and known workarounds.

While SBOMs will only tell you if vulnerabilities affect software components, a VEX allows teams to communicate not only the vulnerabilities that affect particular components, but also explain if those vulnerabilities affect the application.

Image credit: Momius/depositphotos.com