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": "THALES - GBU/BL"
      }
    ],
    "component": {
      "bom-ref": "74e274a790ebedd8bedfbfb07c7f8e57",
      "type": "file",
      "name": "/path-to-project/basic-java-project-for-scanning"
    }
  }
}

Minimum Elements Required

These elements have been defined and validated at Thales Group level, based on the EU Cyber Resilience Act and CISA 2025 minimum elements.

Global metadata

• SBOM Author (mandatory): The name of the entity that creates the SBOM data for a component.
• BOM Version (mandatory)
• Creation Timestamp (mandatory): ISO 8601 format (e.g. 2024-05-23T13:51:37Z).
• Confidentiality Level (optional): Internal Thales classification (C1, C2, C3, C4). Defaults the project classification level.
• Tool Name (optional): The name of the tool used to generate the SBOM.
• SBOM Type (mandatory): DESIGN, SOURCE, BUILD, ANALYZED, or DEPLOYED.
• SBOM Phase (mandatory):DEVELOPMENT, PRODUCTION, MAINTENANCE, or ARCHIVE.

Per-component fields

• Software Producer (mandatory): For open-source software, the name of the stewarding organization.
• Component Name (mandatory)
• Component Version (mandatory)
• Unique Component Identifier (mandatory): CPE, PURL, and/or SWHID. PURL is preferred.
• Top Dependency (mandatory): At minimum, the direct dependencies contained in the product.
• Transitive Dependency (optional): Required in specific compliance contexts
• Component Hash & Algorithm (optional): SHA-256 minimum when present.
• License Information (optional): Required in case of HIPAA compliance.
• Known Vulnerability References (optional): Required in specific compliance contexts (e.g. HIPAA, DGA-MI security class Essential or Important).

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 :

SBOM field compliance

The tables below document two things: where each required element maps to in the CycloneDX schema, and how the three Software Factory tools actually populate those fields in practice.

CycloneDX field mapping

The table below maps each Thales minimum element to its location in the CycloneDX schema and indicates the minimum spec version in which the field became available.

Use the Available since column to verify that your tool’s export version covers the fields you need before relying on native output alone.

Global metadata

Per-component fields

For a complete view of how these elements fit together, refer to the CycloneDX Object Model .

Tool compliance matrix

The table below shows which Thales minimum elements each Software Factory tool populates natively in a default CycloneDX export.

✅ = present and populated for all components — ⚠️ = partial or requires configuration — ❌ = absent

SBOM Composition for Multi-Component Products

Modern systems often consist of multiple components: microservices, multi-module projects, shared libraries, and container images.

In such architectures, you rarely have a single build producing a single SBOM. Instead, each component has its own lifecycle and pipeline.

CycloneDX supports two main patterns to manage this complexity:

Pattern 1 — One SBOM per component + BOM-Link

Each component (service, library, container image) generates its own SBOM during its own build pipeline.

A product-level SBOM then references these component SBOMs using the CycloneDX bom-link mechanism.

• Every component SBOM is stored in a stable location (e.g. Artifactory).
• The product-level SBOM:
  • Describes the overall product (metadata.component).
  • Includes components[] entries for each sub-component.
  • Uses bom-link to reference the SBOM of each component via a stable URI.
• Tools can follow these links to reconstruct the full dependency graph.

Advantages:

• Scales well to large microservice / multi-module systems.
• Each team owns its SBOM, generated in its own pipeline.
• Component SBOMs are reusable across multiple products.
• Aligns with incremental delivery and independent versioning.

Constraints:

• Requires a consistent storage and naming strategy (e.g. Artifactory paths).
• Some downstream consumers still prefer/expect a single “flattened” SBOM file.

When To Use:

• You have many services or modules with independent lifecycles.
• You want to reuse the same component SBOM across multiple products.
• You have a central platform or SCA tool that can ingest BOM-links.

Pattern 2 — Merged SBOM using cyclonedx-cli

All component SBOMs are generated independently, then merged into a single SBOM document using the CycloneDX CLI.

Each component (service A, service B, frontend, etc.) produces a CycloneDX SBOM. A dedicated job (e.g. release pipeline) collects these SBOMs and merges them:

cyclonedx-cli merge \
  --input-files \
    service-a.sbom.json \
    service-b.sbom.json \
    frontend.sbom.json \
  --output-file \
    product-merged.sbom.json \
  --output-format json

When to use:

• Simple delivery model where the whole product is shipped as a single release
• Downstream consumer or customer portal expects a single SBOM file.

SBOM enrichment pipeline

The pipeline below closes the remaining gaps through a sequence of generation, enrichment, validation and publication steps.

It is designed for a Java/Maven project but the pattern applies to any software build system.

Pipeline CI/CD
│
├─ 1. Generation        SBOM Generation + Vulnerability Scan
│
├─ 2. Enrichment / Merge        Post-generation script
│       ├─ Inject SBOM author          → metadata.authors[].name
│       ├─ Inject generation context   → metadata.lifecycles[].phase = "build"
│       ├─ Merge into one "System SBOM"→ cyclonedx --merge
│
├─ 3. Validation        cdx-validator + sbom-scorecard (gate — fails the build ?)
│
└─ 4. Publication       Artifactory (internal) + public endpoint (CRA obligation)

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?