Protect Your Software Supply Chain with SBOMs – Security and Compliance

In today’s software-driven world, applications are no longer built entirely in-house. Instead, they are assembled from hundreds of open-source libraries, third-party dependencies, container images, and vendor components. While this accelerates development, it also creates hidden risks: security vulnerabilities, legal licensing issues, and a lack of visibility into what actually makes up a piece of software.

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

What is an SBOM?

An SBOM is a structured inventory or “ingredient list” of everything included in a software product.

It typically contains:

• Component name (log4j-core)
• Version (2.14.1)
• Supplier (e.g., Apache Software Foundation)
• License type (MIT, Apache, GPL, etc.)
• Hash or checksum (for integrity verification)
• Relationships (e.g., Component A depends on Component B)

Just like a food label helps consumers understand what they are eating, an SBOM helps organizations, regulators, and customers understand what’s inside their software.

Why SBOMs Matter

1. Security

When a new vulnerability (like Log4Shell in Log4j or critical OpenSSL flaws) is announced, organizations with SBOMs can instantly check whether their systems are affected.

• Log4Shell (Log4j) = a hidden logging library bug that let hackers run code on servers.
• OpenSSL flaws = cryptography library bugs that threatened secure communications.

2. Compliance

Many open-source components come with licenses. Some licenses (MIT, Apache) are permissive, while others (GPL, AGPL) impose strict requirements. SBOMs allow legal teams to confirm that distributed software complies with license policies.

I will explain Licenses in the next section.

3. Regulation & Trust

Governments and industries are making SBOMs mandatory:

• US Executive Order 14028 → SBOMs required for federal software vendors
• FDA → SBOMs required for medical devices
• EU NIS2 Directive → mandates supply chain transparency for critical sectors

Most IT companies aim to align with the following standards:

ISO/IEC 27001 & ISO/IEC 27034 (Information Security / Application Security Standards)
Scope:

• ISO/IEC 27001 → International standard for information security management systems (ISMS).
• ISO/IEC 27034 → Focuses on application security and secure software development practices.

SBOM Relevance:

• Requires organizations to maintain a comprehensive inventory of software components and assets.
• SBOMs serve as documented evidence for audits, risk assessments, and demonstrating compliance with security controls.

Even outside regulation, many enterprises now ask vendors to provide an SBOM before purchasing software.

4. Transparency & Risk Management

SBOMs provide full visibility into dependencies, helping organizations:

• Respond quickly to security incidents
• Track version history of components
• Understand risks in third-party or outsourced software

Understanding Open-Source Licenses and SBOMs

When using open-source software, it’s important to know the license that comes with each component. Licenses define how you can use, modify, and distribute the software. They generally fall into three categories: permissive, copyleft (restrictive), and specialized licenses.

1. Permissive Licenses

Permissive licenses are very flexible. They let you use, modify, and redistribute software with minimal restrictions. You can even include it in proprietary software without having to release your own code.

• MIT: Very simple; allows use, copy, modify, merge, publish, and distribute; requires attribution.
• Apache 2.0: Allows commercial use; requires notice, provides patent grants, and protects contributors.
• BSD 2-Clause / 3-Clause: Similar to MIT; requires attribution; 3-Clause adds “no endorsement” clause.
• ISC: Very short and permissive, similar to MIT.

Use case: Perfect for companies that want to include open-source code in their proprietary software without sharing their own source code.

2. Copyleft Licenses (Restrictive)

Copyleft licenses are stricter. If you distribute a modified version of the software, you must release your changes under the same license. This is often called a “viral” license because it applies to your code as well.

• GPL (General Public License): Strong copyleft; any derivative work must also be GPL.
• LGPL (Lesser GPL): Allows linking to proprietary software; only modifications to the library itself must be open-sourced.
• AGPL (Affero GPL): Extends GPL; if the software is run over a network (SaaS), the source code must be provided to users.

Use case: Good for software that wants improvements to remain open source. Not suitable if you want to keep your code private.

3. Other Specialized Licenses

Some licenses have specific rules for certain situations:

• MPL (Mozilla Public License) → Only modified files must be open-sourced; the rest of the project can remain proprietary.
• EPL (Eclipse Public License) → Similar to MPL; modifications to EPL-covered code must be released.
• Creative Commons (CC0, CC BY, etc.) → Often used for content or data rather than code; some require attribution.

SBOM Standards

A Software Bill of Materials (SBOM) is only useful if it follows a standard format that tools and organizations can read and process. Two main standards are widely used today:

1. CycloneDX

• Origin: OWASP project (Open Web Application Security Project).
• Focus: Security and DevSecOps.
• Purpose: Helps identify vulnerabilities, component versions, and security risks in software.
• Format: Machine-readable (JSON, XML), so it can be integrated with automated tools like Trivy, Syft, or Dependency-Track.

Example Use:

• Automatically scan a software build to see if it contains vulnerable libraries.
• Track which components need security patches.

1. SPDX (Software Package Data Exchange)

• Origin: Linux Foundation.
• Focus: License compliance and legal requirements.
• Purpose: Tracks software licenses, copyright notices, and compliance information.
• Format: Machine-readable (JSON, RDF, tag-value), allowing automated compliance checks.

Example Use:

• Ensure no GPL or other restricted-license components are used in a commercial product.
• Generate reports for legal audits or regulatory complianc

How SBOMs Are Created

SBOMs can be generated automatically using tools:

1.Syft (Anchore)

Syft is an open-source tool from Anchore that generates Software Bill of Materials (SBOMs). An SBOM is a detailed inventory of all software components, libraries, and dependencies inside an application, container image, or filesystem.

• Supports multiple SBOM formats:
• CycloneDX JSON
• SPDX JSON
• Table / Text / JSON outputs

Scan a Docker Image

syft python:3.11

Generate SBOM in JSON

syft python:3.11 -o json > sbom.json

Generate CycloneDX SBOM

syft python:3.11 -o cyclonedx-json > sbom-cyclonedx.json

Scan a Directory

syft /path/to/project -o json

1. Trivy (Aqua Security)

Trivy (by Aqua Security) is an open-source security and compliance scanner.

It can scan:

• Container images
• File systems / source code
• Git repositories
• Kubernetes clusters
• SBOMs (Software Bill of Materials)

Scan a Docker Image

trivy image --format cyclonedx --output sbom.json myapp:latest

Scan a Directory

trivy fs --format cyclonedx --output sbom.json .

Enterprise Tools

• Tools like Snyk, Mend, Aqua, or Dependency-Track can automatically:
• Generate SBOMs for multiple projects or containers
• Scan for vulnerabilities
• Track license compliance

How to Read an SBOM

An SBOM (Software Bill of Materials) provides detailed information about all the software components in a project. When reading an SBOM, focus on these key elements:

• Components / Packages: Lists all the software packages, libraries, and modules used in the project.
• **Version: **Shows the exact version of each component, which is important for tracking vulnerabilities.
• License: Specifies the license type for each component (e.g., MIT, GPL, Apache), helping ensure compliance with organizational or legal requirements.
• Dependencies: Indicates which components rely on others, including both direct and transitive dependencies.
• Supplier / Author: Names the organization or individual who created or maintains the component.
• Vulnerabilities (optional): Some SBOMs include CVE IDs or risk information for components with known security issues.

Tip: For small projects, you can read SBOMs manually. For larger projects, use tools like Trivy, Syft, CycloneDX CLI, or Dependency-Track. These tools can visualize dependencies, highlight vulnerabilities, and flag license issues, making SBOMs much easier to interpret.

We can use the following commands to analyze and visualize SBOM reports:

Using Trivy:

trivy sbom sbom.json

Using Grype:

grype sbom:sbom.json

What these commands do:

• Read the SBOM (sbom.json) instead of scanning the image or filesystem again.
• Check all listed components against known vulnerabilities (CVEs).
• Provide a report showing vulnerable packages, severity levels, and available fixes.

Where SBOMs Are Used

• Security teams → Vulnerability detection and monitoring
• Legal/compliance teams → License validation and audits
• Operations teams→ Tracking dependencies across environments
• Customers and regulators → Ensuring transparency before software adoption

SBOMs can be stored in:

• Artefact repositories (Nexus, Artifactory, GitHub Packages)
• Container registries (ECR, GCR, ACR — which support SBOM attachments)
• Customer deliverables (JSON/XML files shipped alongside releases)

SBOM best practices

• Automate generation – use tools, don’t create manually.
• Generate at build time – include all direct and transitive dependencies.
• Store centrally – versioned in artifact or repository.
• Integrate with security tools – scan for vulnerabilities and license issues.
• Choose the right standard – CycloneDX (security) or SPDX (license).
• Update continuously – keep SBOMs current with changes.
• Attach to releases – provide SBOMs with software or containers.
• Use for incident response – quickly identify affected components.

Okay, that’s it for this article.
Also, if you have any questions about this or anything else, please feel free to let me know in a comment below or on Instagram , Facebook or Twitter.

Thank you for reading this article, and see you soon in the next one! ❤️