Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all components—including open-source libraries, third-party modules, and their versions—that constitute a software application. The concept is analogous to a bill of materials used in manufacturing, which lists every part required to build a product. In software, the SBOM provides transparency into the supply chain, enabling organizations to quickly identify and respond to vulnerabilities in their dependencies.

The need for SBOMs became urgent after high-profile supply chain attacks such as SolarWinds (2020) and the Log4j vulnerability (2021). In the SolarWinds attack, malicious code was inserted into a legitimate software update, affecting thousands of customers who had no way to inventory the components of the software they were using. Similarly, Log4j (CVE-2021-44228) was a critical remote code execution vulnerability in the widely used Apache Log4j logging library. Organizations scrambled to find all instances of Log4j in their environments—a task that took weeks for many due to lack of component visibility. SBOMs solve this problem by providing a standardized, queryable list of components.

An SBOM is typically generated during the software build process. Build tools (e.g., Maven, Gradle, npm, pip) resolve dependencies and output a manifest file. This manifest is then transformed into a standard SBOM format. The two most common formats are:

Both formats are machine-readable (JSON or XML). An SBOM contains:

Generating an SBOM typically involves a build plugin or CLI tool. Examples:

- For Maven (CycloneDX):

<plugin>
      <groupId>org.cyclonedx</groupId>
      <artifactId>cyclonedx-maven-plugin</artifactId>
      <version>2.7.1</version>
      <executions>
          <execution>
              <phase>package</phase>
              <goals>
                  <goal>makeAggregateBom</goal>
              </goals>
          </execution>
      </executions>
  </plugin>

Run: mvn package -> generates target/bom.json.

- For npm (SPDX):

npm install --save-dev spdx-sbom-generator
  npx spdx-sbom-generator

- For Python (CycloneDX):

pip install cyclonedx-bom
  cyclonedx-py -i requirements.txt -o bom.json

Verification: An SBOM can be validated against its schema to ensure correctness. For CycloneDX, use:

npm install -g @cyclonedx/cyclonedx-cli
cyclonedx-cli validate bom.json

SBOMs integrate with vulnerability databases (e.g., NVD, GitHub Advisory Database) to identify known vulnerabilities. Tools like OWASP Dependency-Check, Snyk, and Black Duck ingest SBOMs and cross-reference component versions against CVE databases. This process is called SBOM-based vulnerability scanning. The scanner outputs a list of vulnerabilities affecting the components in the SBOM, including severity scores (CVSS) and remediation advice.

In a CI/CD pipeline, SBOM generation is typically automated after every build. The SBOM is then stored in a repository (e.g., a database or artifact store) for later querying. When a new vulnerability is disclosed, the security team can query the SBOM repository to find all affected applications within minutes, rather than manually searching.

SBOMs are increasingly mandated by regulations. The US Executive Order on Improving the Nation's Cybersecurity (EO 14028) requires software vendors selling to the federal government to provide SBOMs. The NTIA (National Telecommunications and Information Administration) has published minimum elements for SBOMs. The EU Cyber Resilience Act also includes SBOM requirements.

CycloneDX (OWASP):

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "version": "2.14.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1",
      "hashes": [{"alg": "SHA-256", "content": "abc123..."}]
    }
  ]
}

SPDX (Linux Foundation):

{
  "spdxVersion": "SPDX-2.3",
  "packages": [
    {
      "name": "log4j-core",
      "versionInfo": "2.14.1",
      "supplier": "Organization: Apache Software Foundation",
      "checksums": [{"algorithm": "SHA256", "checksumValue": "abc123..."}]
    }
  ]
}

The CS0-003 exam expects you to understand:

You will not be asked to generate an SBOM from scratch, but you may be given a sample SBOM and asked to identify a component or vulnerability.

Scenario 1: Large Financial Institution

A global bank uses hundreds of microservices built on Java and Node.js. Each microservice depends on dozens of open-source libraries. The bank adopted CycloneDX SBOM generation in their CI/CD pipeline (Jenkins). Every build produces an SBOM that is uploaded to a central Dependency-Track instance. When Log4j vulnerability was announced, the security team queried Dependency-Track for all components named "log4j-core" with version < 2.17.0. Within 10 minutes, they identified 47 microservices using vulnerable versions. They prioritized patching based on the CVSS score (10.0) and business criticality. The team then triggered automated rebuilds with the updated dependency. The SBOM repository allowed them to track remediation progress and provide evidence to auditors. Without SBOMs, the bank would have spent weeks manually reviewing each service's dependencies.

Scenario 2: SaaS Provider

A SaaS company provides a customer-facing web application. They use a commercial vulnerability scanner that integrates with their CI/CD pipeline. They generate SPDX SBOMs for every release and store them in an S3 bucket. When a vulnerability is disclosed in a popular npm package (e.g., node-fetch), they query the S3 bucket using Athena to find all builds that include the affected version. They then notify the affected customers and deploy patches. The company also shares SBOMs with enterprise customers as part of their security compliance. This transparency has helped them win contracts with government agencies that require SBOMs per EO 14028.

Common Problems When Misconfigured

Performance Considerations: Generating an SBOM adds minimal overhead (a few seconds) to the build process. Storing SBOMs requires negligible storage (a few KB per SBOM). Querying an SBOM repository with millions of entries should be indexed for performance. Tools like Dependency-Track can handle tens of thousands of SBOMs.