Software Bill of Materials

The objective of this page is to provide Thales software development teams with a clear framework for generating, managing, and distributing Software Bills of Materials (SBOMs).

This guide is closely linked to our Software Composition Analysis practices.

While SCA tools are also used to detect vulnerabilities and license risks, this page will focus on the SBOM as the standardized output to share those findings.

On this page, you will find:

• Breakdown of SBOM content
• Different types of SBOMs and when to use them
• Comparisons between CycloneDX and SPDX
• Tools generating SBOM in the Software Factory
• Checklist to ensure your project meets internal standards

SBOM presentation

A Software Bill of Materials (SBOM) is a comprehensive, machine-readable inventory of all components, libraries, and dependencies used to build a software application.

Think of it as an ingredient list for software.

What is in the SBOM?

• Identity: Component names, versions, and PURLs (Package URLs).
• Provenance: Supplier info and dependency relationships.
• Integrity: Cryptographic hashes (SHA-256) for verification.
• Legal: Licensing information for compliance.

SBOM Example

{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:bb944afd-0cc8-11f1-951f-42f068657abd",
  "version": 1,
  "metadata": {
    "timestamp": "2026-02-18T13:53:07+01:00",
    "tools": {
      "services": [
        {
          "name": "JFrog Xray Scanner",
          "version": "3.118.42"
        }
      ]
    },
    "authors": [
      {
        "name": "JFrog"
      }
    ],
    "component": {
      "bom-ref": "74e274a790ebedd8bedfbfb07c7f8e57",
      "type": "file",
      "name": "/path-to-project/basic-java-project-for-scanning"
    }
  }
}

Minimum Elements Required

To meet modern transparency standards (evolving from the 2021 NTIA), CISA now defines a more robust set of minimum elements . These ensure that an SBOM is not just a list, but a technically verifiable and context-aware document.

• SBOM Author: The entity that created the SBOM data for this component.
• Software Producer: The entity that originally created the component (replaces the older “Supplier” field to avoid ambiguity).
• Component Name: The name assigned to the software component by the Software Producer.
• Component Version: The specific identifier for the code delivery.
• Software Identifiers: Machine-readable keys. PURL is preferred.
• Component Hash: The cryptographic signature (e.g., SHA-256) of the artifact.
• License: The legal terms for the component.
• Dependency Relationship: Defines how components relate to build a dependency graph.
• Tool Name: The specific tool(s) used to generate or enrich the SBOM (e.g., JFrog Xray or Syft).
• Timestamp: The ISO 8601 record of when the SBOM data was last updated or generated.
• Generation Context: Identifies when the SBOM was made (e.g., Before, During, or After Build). Matches the SBOM Types .

SBOM Types

SBOMs are generated at different stages of the Software Development Lifecycle (SDLC). According to the official CISA framework , they are categorized into six distinct types:

Source SBOM

A Source SBOM is created by analyzing source code, manifest files, and lockfiles before the build. It provides an “as-designed” view of the software dependencies.

• Key Contents: Declared dependencies in manifests (package-lock.json, pom.xml, requirements.txt), source code locations, and licensing information.
• Characteristics:
  • Early Inventory: Provides a list of dependencies before resources are spent on building or deploying.
  • Developer-Centric: Integrates easily into local IDEs and early CI pipelines for immediate feedback.

Build SBOM

A Build SBOM is generated during the compilation or packaging phase. It captures the precise composition of the artifact by observing the actual resolution of dependencies in the build environment.

• Key Contents:
  • Direct and transitive dependencies resolved at build time.
  • Build-time tools (compilers, SDKs, linkers) and environment context.
  • Exact versions, cryptographic hashes, and commit references.
• Characteristics:
  • Authoritative: The most accurate record of what was actually shipped.
  • Reproducible: Provides a permanent audit trail connecting source code to the final binary.
  • Compliance-Ready: The standard type for sharing software inventories with customers and partners.

Analyzed SBOM

An Analyzed SBOM is generated by performing a deep scan (binary or container analysis) on the final artifact. This is essential when the original source code or build pipeline is inaccessible.

• Key Contents:
  • Components identified through “fingerprinting” or signature matching.
  • Operating system packages, container layers, and base images.
  • Unpacked libraries and statically linked binaries.
• Characteristics:
  • Verifiable: Confirms the actual contents of a “black box” artifact regardless of what the manifest claims.
  • Third-Party Standard: The primary method for generating transparency for proprietary / vendor-supplied software.
  • Post-Build Analysis: Scans the final product to find hidden or undocumented risks.

SBOM Formats

Two main standards dominate SBOM generation:

CycloneDX

CycloneDX is a lightweight SBOM standard designed specifically for application security use cases and supply chain component analysis.

Key characteristics:

• Purpose-built for security: Optimized for vulnerability management and security analysis
• Modern and extensible: Actively developed with regular updates
• Comprehensive component types: Software, hardware, services, machine learning models
• Rich vulnerability exchange: Native support for VEX (Vulnerability Exploitability eXchange)
• Format options: XML, JSON, Protocol Buffers.

SPDX

SPDX is an ISO standard (ISO/IEC 5962:2021), originally created for license compliance but now expanded to include security information.

Key characteristics:

• ISO standard: Formally recognized international standard
• License compliance focus: Originally designed for open-source license tracking
• Mature ecosystem: Long history and established tooling
• Multiple formats: Tag-value, JSON, YAML, RDF, XML
• Detailed provenance: Strong focus on component origin and relationships

Comparison CycloneDX vs SPDX

Tools Generating SBOM

Software Composition Analysis tools play a crucial role in identifying and managing open-source and third-party components, and in generating Software Bills of Materials (SBOMs).

The table below compares the SBOM generation capabilities of Software Factory SCA tools :

Developer Checklist & Best Practices

Use this checklist to ensure your project’s SBOM strategy meets Thales security and compliance standards.

Generation & Automation

• Automate in CI/CD: Is SBOM generated automatically during the build or package stage of the pipeline?
• CISA Compliance: Does your SBOM include the minimum Elements ?

Storage & Distribution

• Co-location: Is the SBOM stored in the same repository as the artifact in Artifactory?
• Standard Naming: Are you using a clear naming convention? like Recommended: [artifact-name]-[version].sbom.json
• Versioning: Does the SBOM version string strictly match the software release version it describes?
• Container Integration: For Docker/OCI images, are you using tools like cosign to attest and attach the SBOM to the image in the registry?

Consumption & Vulnerability Management

• VEX Implementation: do you provide a VEX (Vulnerability Exploitability eXchange) file to document the “Not Affected” / “False Positive” status?
• Platform Ingestion: Have you identified to whom you should provide the SBOM so it can be ingested for continuous monitoring?