Analyzing SBOMs for security risks

Let’s assume we have two identical software products from different vendors. We analyzed the Software Bill of Materials (SBOMs) for each product and found the following results:

At first glance, it would appear that product “A” is more secure, simply based on the lower number of CVEs. But just taking this information at face value is misleading. Not all vulnerabilities are exploitable, and we can’t easily identify which ones are based on an SBOM alone.

The transparency offered by SBOMs might inadvertently direct us towards fixing CVEs for policy compliance rather than addressing the most significant security threats.

CVE severity vs likelihood of exploitation

The key issue with the above analysis is that a CVSS base score, and thus the severity rating of a CVE, is only that: a base score. It reflects only the pure technical risk, not context.

Moreover, a CVSS base score doesn’t consider if exploit code exists or if exploits are actively used to compromise systems. An effective risk reduction strategy should ask: What are the most likely risks? How probable is it that any of these CVEs will be exploited in either product?

To learn about CVEs known to be exploited in the wild, we can refer to CISA’s KEVlist. This will inform us if either product contains flaws actively targeted by adversaries.

Additionally, it would be beneficial to assess if CVEs are likely to be exploited. Predicting exploit likelihood straddles the line between art and science, but it’s still useful for focusing limited resources. FIRST’s EPSS system implements this idea: Each published CVE gets assigned a likelihood of exploitation within the next 30 days, ranked between 0 (unlikely) and 1 (likely).

Reanalyzing the hypothetical SBOMs with these added factors gives us the following table:

Now, the answer to “Which product is more secure?” leans towards “B”. This is because it has no vulnerabilities currently under active exploitation and the predicted maximum likelihood of exploitation is much lower.

In this scenario, Product A’s risk reduction strategy was:

1. Fix all critical CVEs.
2. Fix all high CVEs.

Product B’s strategy was:

1. Address all actively exploited CVEs.
2. Prioritize fixing CVEs based on the highest EPSS score, stopping at 0.05.

Product B’s approach has the advantage of using less resources for a very likely much harder attack surface. Yet, in a largely compliance-driven landscape, it could be dismissed as ineffective.

Both strategies would undeniably gain from more context, but SBOMs don’t supply this information.

VEX

Vulnerability Exchange (VEX) documents act as the dynamic counterpart to static SBOMs. While an SBOM details the component list of a product release, a VEX ideally describes all known vulnerabilities that could impact these components. While an SBOM typically only changes with each new product release, a VEX might be updated daily to account for new CVEs. You can think of a VEX as a regularly updated warranty report.

SBOMs lack the comprehensive data needed for a full impact assessment. However, software vendors can share the outcomes of their CVE assessments with customers. This offers transparency about the actual impact, instead of only potential impact that SBOMs provide.

For software vendors, the same tradeoff exists: Should they follow the compliance route by assessing all critical and high CVEs? Or should they adopt a more efficient risk reduction strategy, potentially based on the KEVlist and EPSS?

SBOM transparency and incentives

In summary, SBOM transparency pushes software vendors to address and resolve all critical and high-severity CVEs. Even though some customers might accept a VEX detailing the non-impact, the overarching compliance pressure will largely dictate what gets fixed. In some cases, customers might demand that all CVEs be addressed. As a result, the financial and operational burdens of software vendors will likely rise because of these compliance demands.

Given these incentives, can we genuinely trust that vendor-provided SBOMs offer comprehensive coverage of architectural components? Would SaaS vendors, for instance, be tempted to exclude significant portions of their internal systems from their SBOMs to circumvent this heightened transparency and the associated costs? Would elements like a central authentication system or its supporting services and infrastructure be disclosed?