Software Bill of Materials: Understanding What You’re Actually Running

The Growing Complexity of Software and the Need for SBOMs

Modern software is built on countless third-party libraries—database connectors, frameworks, serialization tools, and more. These dependencies (and their dependencies) speed up development but introduce hidden risks: bloat, security vulnerabilities, and legal complications.

To manage this, we use an SBOM (Software Bill of Materials), a document listing all the software components in a system. Two major formats are OWASP’s CycloneDX (lightweight) and the Linux Foundation’s SPDX (more detailed, includes license info).

Once generated, SBOMs let us:

• Detect known vulnerabilities (e.g., CVEs)
• Review software licenses for legal risks

‍

‍

Why a Complete List Matters

‍

Using third-party libraries brings real risks. Famous incidents include:

• Equifax breach (2017): CVE-2017-5638 in Apache Struts allowed remote code execution. Hackers exfiltrated sensitive data of millions.
• Left-pad (2016): A tiny, critical NPM package was pulled, breaking CI/CD pipelines everywhere—many didn’t even know they depended on it.
• Log4Shell (2021): A critical vulnerability in Log4j (Java logger) forced teams to urgently locate and patch every instance of it.

‍

Keeping a living SBOM helps teams respond faster to incidents and understand the risk surface.

‍

In 2021, President Biden signed Executive Order 2021-10460, requiring SBOMs for critical software used by the federal government. The aim: quickly identify vulnerable software during future incidents.

‍

‍

Legal Risks of Dependencies

‍

‍

Licensing is often overlooked. Some licenses (e.g., GPL, Creative Commons non-commercial) may conflict with your business model, restrict usage, or even force source code disclosure. These risks are legal, not technical—but just as important.

‍

‍

How to Generate an SBOM with Syft

‍

Syft is a free tool to create SBOMs from container images or directories. It supports CycloneDX and SPDX in JSON or XML.

Example:

1. Clone the Spring PetClinic project:
   https://github.com/spring-projects/spring-petclinic
2. Run mvn package to install dependencies
3. Generate the SBOM:
   syft {project_dir} -o spdx-json > petclinic_spdx.json

The output includes:

• Package names and versions
• Licenses
• File paths
• Relationships between dependencies

‍

‍

Analyzing with Bomber

Bomber scans SBOMs for known vulnerabilities (CVEs), and outputs:

• HTML (human-readable)
• JSON (complete, with CVE IDs)

Use the JSON format if you want to automate parsing or reporting. Be cautious: if no version is specified, Bomber lists all vulnerabilities ever reported for that package, which may not apply.

‍

‍

Conclusion

SBOMs are powerful tools to improve security visibility and compliance. Tools like Syft and Bomber make them easy to generate and use. Whether you're a developer or security engineer, understanding and maintaining an SBOM is a key step toward resilient software.