SBOM: A Prerequisite for Software Security – Part 1

1️⃣ Background

In recent years, cyberattacks have escalated beyond isolated incidents and evolved into large-scale attacks targeting entire software supply chains.

• Log4j (CVE-2021-44228, aka Log4Shell / Nov 2021): A single vulnerability in a widely-used logging library exposed hundreds of millions of systems globally to critical risk.

• SolarWinds (Dec 2020): A compromised build tool inserted a backdoor, enabling covert access to thousands of corporate networks.

What did these incidents have in common?

The vulnerabilities didn’t originate from in-house code, but from external libraries and third-party components—the building blocks of modern software.

In response, the U.S. government issued Executive Order 14028 in 2021, aiming to strengthen software supply chain security.

At the core of this initiative was the concept of the Software Bill of Materials (SBOM).

Since then, SBOM has gained global traction, becoming a key requirement in EU RED certification and FDA cybersecurity guidance for medical devices.

2️⃣ What is SBOM?

An SBOM (Software Bill of Materials) is essentially a machine-readable inventory of all components that make up a software product—including libraries, modules, and dependencies.

What does an SBOM typically include?

• Component name and version (e.g., log4j-core 2.14.1)

• License (e.g., Apache-2.0)

• Supplier (e.g., Maven repository URL)

• Identifiers (e.g., PURL, CPE, etc.)

Here’s an example SBOM entry in CycloneDX format:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "version": "2.14.1",
      "group": "org.apache.logging.log4j",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1",
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ]
    }
  ]
}

💡 Note: Other SBOM formats include SPDX and SWID. The SBOM ecosystem is continuously evolving.

The SBOM JSON document above allows for the following analysis:

Key Benefits of SBOM

An SBOM is more than just a list. It plays a critical role in improving software transparency, security, and compliance.

3️⃣ Vulnerability Analysis Using SBOM

To unlock its full potential, an SBOM must go beyond documentation—it should enable automated vulnerability analysis.

Key concepts involved in this process are CPE, CVE, and VEX.

Key Terminology

Example: Analyzing log4j-core 2.14.1

1. Identify the Component in the SBOM

Let’s assume the SBOM includes the following entry:

• Name: log4j-core

• Version: 2.14.1

• Vendor: apache

This information is either automatically generated by an SBOM tool or extracted directly from your build system.

2. Find the Matching CPE

Next, identify the CPE (Common Platform Enumeration) that corresponds to this component.

Visit the official NVD CPE Search page and enter relevant keywords such as log4j, log4j-core, or apache.

Once located, the corresponding CPE for log4j-core 2.14.1 will look like this:

• # CPE
  cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*

💡 Note: The component names and versions listed in your SBOM may not exactly match how they appear in the NVD CPE database.

For example, log4j-core might simply be listed as log4j in CPE records. In such cases, you’ll need to rely on fuzzy matching or best-fit identification using additional metadata.

3. Look Up the CVEs

Once the CPE is determined, you can retrieve related CVEs (Common Vulnerabilities and Exposures).

In this example, the identified CPE for log4j-core 2.14.1 is associated with CVE-2021-44228, also known as Log4Shell—a remote code execution (RCE) vulnerability that had widespread global impact.

This CVE is marked with the highest severity rating:
CVSS Score: 10.0 (Critical) → Immediate remediation is required.

💡 Reminder: The CVSS (Common Vulnerability Scoring System) is an industry-standard metric for rating the severity of vulnerabilities on a scale from 0 to 10. A score of 10 means the issue is critically severe and requires urgent attention.

4. VEX Document

The final step is to determine whether the identified CVE actually affects your system.

This is where the VEX (Vulnerability Exploitability eXchange) document comes into play.

For instance, the following VEX JSON file states that although CVE-2021-44228 exists, your system is not vulnerable because the affected component (e.g., the JNDI feature) is not present or in use:

{
  "vulnerabilities": [
    {
      "id": "CVE-2021-44228",
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable"
      },
      "affects": [
        {
          "ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1"
        }
      ]
    }
  ]
}

Common analysis.state values in VEX:

• affected : The vulnerability does affect the component.

• not_affected : The vulnerability does not affect the component.

• under_investigation : Still under assessment.

• requires_configuration : The exploitability depends on specific configurations.

• deprecated : The component is no longer in use.

These values follow standard definitions outlined in the VEX specification.

4️⃣ Benefits of SBOM-Based Vulnerability Analysis

When organizations implement an end-to-end CPE → CVE → VEX workflow, the SBOM becomes far more than a list of dependencies—it becomes a powerful and actionable security asset.

With this system in place, you can:

• Quickly and accurately identify vulnerable components

• Prioritize and respond only to relevant threats, improving resource efficiency

• Minimize confusion and overhead between development, security, and compliance teams

Even better, integrating SBOM tools into your CI/CD pipeline allows for real-time monitoring and automated remediation, enabling proactive and scalable vulnerability management.

5️⃣ Conclusion

As software supply chain threats become increasingly sophisticated, the SBOM is no longer a "nice to have"—it is a foundational requirement for trustworthy, secure software delivery.

Every organization must implement a process for generating, managing, and analyzing SBOMs, not only to comply with emerging regulations (like EU RED, FDA guidelines) but to ensure operational resilience.

SBOM is no longer optional. It’s a prerequisite for secure, transparent, and compliant software operations.