SBOM Guide: Examples & Validation Tools

An sbom example is a formal, machine-readable inventory listing all components, libraries, and dependencies included in a piece of software. It functions like a “list of ingredients,” providing crucial transparency into the software supply chain. This helps organizations quickly identify and mitigate security vulnerabilities or licensing conflicts within their applications, addressing a major concern in modern software security. It typically follows standard formats like SPDX or CycloneDX to ensure interoperability between tools.

Purpose of this guide

This guide is for developers, security analysts, and compliance managers seeking to understand the practical application of a Software Bill of Materials (SBOM). It solves the problem of abstract concepts by showing what a real-world SBOM contains and how to use it effectively. You will learn to interpret standard formats, identify critical information such as component names, versions, and licenses, and understand how this data is used to secure your software supply chain. This knowledge helps you avoid common mistakes, like using incomplete data, and enables proactive risk management.

What is an SBOM and why do examples matter

A Software Bill of Materials (SBOM) is a formal machine-readable inventory that provides comprehensive documentation of all software components, dependencies, and relationships within an application or system. Think of it as the digital equivalent of an ingredients list on food packaging – it tells you exactly what’s inside your software product, where each component came from, and how they all connect together.

SBOMs are foundational to firmware security, especially as attackers increasingly target third-party components in embedded systems. Without a complete inventory of dependencies, teams can’t rapidly respond to vulnerabilities like those found in IP camera firmware or NAS devices—where a single unpatched library can expose entire networks.

The importance of SBOMs has skyrocketed following Executive Order 14028, which mandates that federal agencies require SBOM documentation for software procurement. This regulatory framework establishes SBOMs as critical tools for maintaining software composition transparency and enabling effective dependency tracking across digital supply chains.

Understanding SBOMs through practical examples is essential because these documents serve as the foundation for modern vulnerability management strategies. When security researchers discover a new vulnerability in a widely-used component like Log4j, organizations with comprehensive SBOMs can immediately identify which applications are affected and prioritize remediation efforts accordingly.

The relationship between SBOMs and software components is fundamental to understanding their value. Each SBOM documents not just the primary software components but also the complex web of transitive dependencies – libraries that your direct dependencies rely upon. This comprehensive inventory approach ensures that no component remains hidden, providing complete visibility into your software’s attack surface.

Common SBOM formats SPDX vs CycloneDX

The SBOM ecosystem has converged around two primary format standards: SPDX (Software Package Data Exchange) and CycloneDX. Both formats implement the core SBOM structure but with different emphases and specialized strengths that make them suitable for different organizational needs.

While SPDX excels in license tracking, CycloneDX integrates directly with security tooling like Trivy—making it the preferred choice for teams automating vulnerability detection. This synergy enables firmware testing pipelines to flag risky dependencies before deployment.

SPDX emerged from the Linux Foundation’s efforts to standardize license compliance processes for open source software. Its document-centric approach makes it particularly valuable for organizations that need to maintain strict governance policies around software licensing and intellectual property management.

CycloneDX, developed by OWASP, takes a security-first approach with built-in support for vulnerability tracking and risk assessment. Its BOM-centric structure makes it ideal for organizations prioritizing security scanning and threat management in their software development lifecycle.

For SBOM format details, visit the SPDX specification and more real-world samples are available from this CycloneDX example repo.

Both formats support multiple serialization options including JSON, XML, and YAML, ensuring compatibility with diverse toolchains and integration requirements. The choice between SPDX and CycloneDX often depends on whether your primary concern is license compliance or security vulnerability management.

Anatomy of an SPDX SBOM example

SPDX SBOMs follow a structured, document-centric approach that organizes information into clearly defined sections. Let’s examine a practical SPDX example in JSON format, which represents the most commonly used serialization for automated processing and tool integration.

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "WebApp-v1.2.0",
  "documentNamespace": "https://company.com/spdx/WebApp-v1.2.0",
  "creationInfo": {
    "created": "2024-01-15T10:30:00Z",
    "creators": ["Tool: SPDX-Generator-v2.3", "Person: Security Team"]
  },
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-WebApp",
      "name": "WebApp",
      "versionInfo": "1.2.0",
      "downloadLocation": "https://github.com/company/webapp/releases/tag/v1.2.0",
      "filesAnalyzed": false,
      "licenseConcluded": "MIT",
      "licenseDeclared": "MIT",
      "copyrightText": "Copyright 2024 Company Inc."
    },
    {
      "SPDXID": "SPDXRef-Package-Express",
      "name": "express",
      "versionInfo": "4.18.2",
      "downloadLocation": "https://registry.npmjs.org/express/-/express-4.18.2.tgz",
      "filesAnalyzed": false,
      "licenseConcluded": "MIT",
      "supplier": "Person: TJ Holowaychuk",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "5de93946c2c91ed8e5a8ef1b3b8e8e8b1a2a3b4c5d6e7f8g9h0i1j2k3l4m5n6o7p"
        }
      ]
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relationshipType": "DESCRIBES",
      "relatedSpdxElement": "SPDXRef-Package-WebApp"
    },
    {
      "spdxElementId": "SPDXRef-Package-WebApp",
      "relationshipType": "DEPENDS_ON",
      "relatedSpdxElement": "SPDXRef-Package-Express"
    }
  ]
}

The Document Creation section establishes the SBOM’s provenance and version control information. The spdxVersion field ensures compatibility with parsing tools, while the creationInfo provides an audit trail showing when and how the SBOM was generated. This manifest file approach ensures data integrity throughout the software development lifecycle.

Package Information sections contain the core inventory management data that makes SBOMs valuable for dependency tracking. Each package entry includes essential identifiers like name and version, along with cryptographic checksums that enable verification of component authenticity. The downloadLocation field provides traceability back to the original source, supporting supply chain transparency initiatives.

The Relationships section maps the connections between software components, creating a dependency graph that security teams can analyze for vulnerability propagation paths. The relationship types like DEPENDS_ON and DESCRIBES create a formal structure that automated tools can process to understand component hierarchies and potential impact zones.

This SPDX example satisfies all NTIA Minimum Elements requirements, including supplier name, component name, version, unique identifier, dependency relationships, and SBOM author information. This compliance ensures the SBOM can be used for federal procurement and regulatory requirements under Executive Order 14028.

Exploring a CycloneDX SBOM example

CycloneDX takes a security-focused approach to SBOM structure, organizing information around the concept of a Bill of Materials with integrated vulnerability tracking capabilities. Here’s a comprehensive CycloneDX example that demonstrates its security-centric features:

The vulnerabilities section in CycloneDX isn’t just illustrative—it mirrors real-world scenarios like the authentication bypass in Zyxel NAS devices, where a flawed dependency chain allowed post-auth command injection. Having an SBOM would have enabled immediate impact assessment across all affected products.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:12345678-1234-5678-9012-123456789012",
  "version": 1,
  "metadata": {
    "timestamp": "2024-01-15T10:30:00.000Z",
    "tools": [
      {
        "vendor": "Company Security Tools",
        "name": "SecurityScanner",
        "version": "2.1.0"
      }
    ],
    "component": {
      "type": "application",
      "name": "WebApp",
      "version": "1.2.0"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "[email protected]",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/[email protected]",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "5de93946c2c91ed8e5a8ef1b3b8e8e8b1a2a3b4c5d6e7f8g9h0i1j2k3l4m5n6o7p"
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
    },
    {
      "type": "library",
      "bom-ref": "[email protected]",
      "name": "lodash",
      "version": "4.17.20",
      "purl": "pkg:npm/[email protected]",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6a7b8c9d0e1f2g3"
        }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "[email protected]",
      "dependsOn": ["[email protected]"]
    }
  ],
  "vulnerabilities": [
    {
      "id": "CVE-2021-23337",
      "source": {
        "name": "NVD",
        "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23337"
      },
      "ratings": [
        {
          "source": {
            "name": "NVD"
          },
          "score": 7.2,
          "severity": "high",
          "method": "CVSSv3",
          "vector": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H"
        }
      ],
      "affects": [
        {
          "ref": "[email protected]"
        }
      ],
      "description": "Lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function."
    }
  ]
}

The BOM Metadata section establishes the digital supply chain context with timestamps and tool information that support inventory management processes. The serialNumber provides a unique identifier for this specific SBOM version, enabling precise tracking across software releases and updates.

Component Inventory uses Package URLs (PURLs) as standardized identifiers that work across different package ecosystems. This approach ensures consistent component identification whether dealing with npm packages, Maven artifacts, or Docker images. The cryptographic hashes provide integrity verification for each component.

The Vulnerabilities section represents CycloneDX’s key differentiator – direct integration of security information within the SBOM structure. This example shows how CVE-2021-23337 affecting Lodash is documented with complete CVSS scoring, impact assessment, and affected component mapping.

The Dependencies section creates explicit mappings between components, enabling security teams to trace vulnerability impact through the entire dependency tree. When a vulnerability is discovered in a transitive dependency like Lodash, this structure immediately reveals which primary components are affected and need attention.

This CycloneDX example demonstrates compliance with NTIA Minimum Elements while providing enhanced security capabilities that support proactive vulnerability management. The integration of CVSS scores and severity ratings enables automated prioritization of security remediation efforts based on actual risk levels rather than simple vulnerability counts.

Once you’ve generated an SBOM, ensure it’s structurally valid and complete—learn how to perform robust SBOM validation to meet compliance and security standards.