SBOM: What & Why?

👋 Hi! I’m Bibin Wilson. In each edition, I share practical tips, guides, and the latest trends in DevOps and MLOps to make your day-to-day DevOps tasks more efficient. If someone forwarded this email to you, you can subscribe here to never miss out!

In today's edition, we will look at,

• What is SBOM really?

• SBOM Tools

• Centralized SBOM analysis

As a DevOps engineer or a lead designing CI/CD solutions, SBOM is an important piece of the pipeline that helps keep your applications secure and remediate vulnerabilities faster.

To understand SBOM better, let's look at a real-world example that had a significant impact.

Log4j vulnerability

Log4j is a popular open-source popular logging framework for Java applications. Typically used in most java based applications.

Most of you might remember the Log4Shell vulnerability (November 2021), a critical security flaw discovered in Apache Log4J. One of the most dangerous vulnerabilities ever

It allowed attackers to execute remote code on a system simply by logging a malicious string.

Now, imagine an organization using Log4J in hundreds of applications across different environments.

How do you track and fix this vulnerability across all applications?

How do you ensure every system has been patched and no outdated version remains?

This is where SBOM (Software Bill of Materials) comes in.

What is SBOM?

A Software Bill of Materials (SBOM) is a detailed list of all software components, libraries, and dependencies used in an application.

Now you might ask,

If we already declare dependencies in pom.xml (for Maven), package.json (for Node.js), or requirements.txt (for Python), why do we need an SBOM?

The key differences lie in visibility, security tracking, and compliance.

For example, a pom.xml file (or similar) only includes direct dependencies that the developer explicitly declares.

Where as an SBOM report generated by SBOM tools has,

1. Direct dependencies (what you declare in pom.xml).

2. Transitive dependencies (dependencies that your dependencies use).

3. System libraries and third-party packages included at runtime.

4. Contains additional metadata like licenses, known vulnerabilities

5. Can include components from build tools, operating system, etc.

6. Can be used for security auditing and compliance.

Also, pom.xml only manages dependencies, but does not track security issues.

SBOM tools have integration with security databases (like CVE/NVD) and continuously checks for vulnerabilities.

For example, a developer updates dependencies in pom.xml, but forgets to check for security vulnerabilities. An SBOM tool like Grype or Trivy will alert them if the new version is still vulnerable.

In short, SBOM serves as the foundation for vulnerability management by providing a detailed inventory.

SBOM Generation Tools

The following open-source tools can help you generate SBOM reports and integrate them into your CI/CD pipelines:

• Trivy

• Syft

Reports are generally generated in CycloneDX and SPDX JSON formats.

The following image shows the SBOM workflow using Trivy and sample GitHub Action pipeline steps to generate an SBOM.

Every push or pull request generates an SBOM and checks for vulnerabilities, embedding security into your pipeline.

Centralised SBOM Analysis

When it comes to real-world SBOM generation and analysis in organizations, you need a centralized platform to store all the SBOMs generated by CI/CD tools.

Once you have that, you can easily track all the libraries and dependencies in a central location.

In case of a new vulnerability, you can quickly identify all the applications that use the affected library.

Dependency-Track is one such continuous SBOM analysis platform supported by OWASP.

It also has integrations with security databases (like CVE/NVD) and continuously checks for vulnerabilities.

Even after passing security checks in CI/CD, a new vulnerability may be discovered after a few days. The platform keeps scanning for the latest vulnerabilities, ensuring ongoing security monitoring.