Components

Components are the fundamental entities of the SBOM data model and are used to describe both the subject of the SBOM and the inventory of dependencies. Components must be described in a consistent and identifiable way to enable analysis, dependency tracking, and vulnerability resolution.

Component identity

This refers to the basic information that identifies the component, such as name, version, and unique identifiers (e.g., PURL, CPE, or SWID). These fields enable consistent identification and cross-referencing across different systems.

Component identifiers

All software dependencies must be identified with sufficient precision to enable reliable matching to vulnerability and security advisories.

Package URL (purl) standard — dependencies must use Package URL notation whenever applicable, with the appropriate ecosystem-specific type:

• Maven: pkg:maven/org.springframework/spring-core@5.3.8
• npm: pkg:npm/express@4.17.1
• NuGet: pkg:nuget/Newtonsoft.Json@13.0.1
• Python: pkg:pypi/requests@2.28.0

Generic purl usage — for third-party libraries in ecosystems without established purl types, use the generic type with sufficient detail:

• pkg:generic/custom-framework@1.2.3?download_url=https://internal.example.com/releases

Other external identifiers — include CPE or SWID identifiers when they exist for the dependency.

Cryptographic hashes — dependencies should include a cryptographic hash (SHA-256 or SHA-512) to enable integrity verification and resolve any name clashes.

SBOM references — when third-party SBOMs exist for dependencies, include references to enable recursive SBOM processing.

{
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
      "name": "log4j-core",
      "version": "2.17.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
      "cpe": "cpe:2.3:a:apache:log4j:2.17.1:*:*:*:*:*:*:*",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "779f60f3844dadc3ef597976fcb1e5127b1f343d0e48c"
        }
      ],
      "externalReferences": [
        {
          "type": "bom",
          "url": "https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.17.1/log4j-core-2.17.1.cyclonedx.xml"
        }
      ]
    }
  ]
}

Component provenance

Information about the origin and source of the component, including the supplier, manufacturer, hashes, and where applicable, included files.

File hashes

Components should include file hashes for the artifacts that make up the component at the time of SBOM creation. When there is a canonical single artifact/file for the component, a single hash for this should be provided.

When the component is made up of multiple files (e.g. a library with several .dll files) they should be included as sub-components (of type "file") with their own separate hash. In some cases this can be impractical (e.g. a software library with thousands of files) and then the recommendation is to include a hash of the release archive instead.

If there is a risk that the origin of the artifact used to produce the hash is non-obvious, an external reference (i.e. URL to a release archive or file manifest) should be included.

Custom properties

In cases where additional details are needed that are not covered by the standard schema, custom properties may be included. These can document build-specific information, internal classifications, or other metadata relevant to evaluation.

License

Components should include license information. Non-Open Source components should have valid copyright statements. See Licenses for more details about license identification.

Sub-components

When a component represents a logical grouping of other components, such as an archive file or an executable installer, the contained files should be included in the SBOM. The relationship between the container and contents can either be expressed using sub-components (in CycloneDX) or with dependency relationships.

Component types

The following mapping between component types in the current standards provides guidance when choosing which types to use.

References

Windows specific notes

Windows PE executable files (.exe, .dll, .sys etc) can have embedded metadata describing the supplier, application name, copyright etc. Corresponding SBOM components should have the same values to make it easy to correlate.

When the subject of the SBOM is a Windows application, the SBOM should include all the files that should be installed on a target system as subcomponents with hashes for each file, regardless if the delivery is packaged as an installer.

A delivery that includes third-party modules with their own installers should include the installer with relevant metadata in the SBOM.

For some installers the files that would be installed on the target system are too non-deterministic to create an accurate SBOM. In those cases just the installer should be included in the SBOM and clearly identified as an installer.

{
  "bom-ref": "bbf035ed-adaf-42f9-a666-cc5fcac2e280",
  "type": "application",
  "manufacturer": {
    "name": "Microsoft Corporation",
    "url": [
      "https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist"
    ]
  },
  "name": "Microsoft Visual C++ 2015-2022 Redistributable (x64) - 14.44.35211",
  "version": "14.44.35211.0",
  "components": [
    {
      "type": "file",
      "name": "VC_redist.x64.exe",
      "version": "14.44.35211.0",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "cc0ff0eb1dc3f5188ae6300faef32bf5beeba4bdd6e8e445a9184072096b713b"
        }
      ],
      "properties": [
        {
          "name": "observer:file:role",
          "value": "installer"
        }
      ]
    }
  ]
}

Methods and evidence

The methods used to extract and/or derive component identifiers should be documented ("evidence"). This is vital for communicating the quality and general trustworthiness of the BOM's contents. This is especially important in SBOMs where dependencies are managed with a manual or semi-automated process.

{
  "name": "example-js-library",
  "purl": "pkg:npm/example-js-library@6.0.2",
  "evidence": {
    "identity": [
      {
        "field": "purl",
        "methods": [
          {
            "technique": "manifest-analysis",
            "confidence": 0.9,
            "value": "package-lock.json"
          },
          {
            "technique": "hash-comparison",
            "confidence": 1,
            "value": "7c547a9d67cc7bc315c93b6e2ff8e4b6b41ae5be454ac249655ecb5ca2a85abf"
          }
        ]
      }
    ]
  }
}

Manual attestation example:

{
  "name": "vendor-provided-library",
  "version": "1.0.0",
  "evidence": {
    "identity": [
      {
        "field": "purl",
        "methods": [
          {
            "technique": "attestation",
            "confidence": 1
          }
        ]
      }
    ]
  }
}

External references

External references provide a way to reference information that may be relevant for a dependency, but not included with the SBOM. They may also establish specific relationships within or external to the BOM.

Documenting patched components

When suppliers modify or patch third-party components to address security vulnerabilities, bugs, backport functionality, or meet specific requirements, it is critical that these modifications are documented in the SBOM. This ensures the consumer can:

• Understand which components have been modified from their original versions
• Verify that critical security updates have been installed
• Assess the provenance and trust level of modified components
• Avoid false positives when analysing the SBOM for vulnerabilities

Modified components must be clearly distinguished from their unmodified counterparts, with a new identity (e.g. version) and their pedigree documented.

Implementation notes — CycloneDX

Requirements for documented patched components in CycloneDX:

1. Give the patched component a version distinct from its ancestor
2. Add a pedigree and ancestors section identifying the base component before any patches were applied
3. If possible, add a patches section documenting the type of patch, and include any available external references
4. If the patch resolves any known vulnerabilities, include a resolves section with the vulnerability ID

{
  "bom-ref": "pkg:generic/openssl@3.0.15+patched",
  "type": "library",
  "name": "openssl",
  "version": "3.0.15+patched",
  "purl": "pkg:generic/openssl@3.0.15+patched",
  "pedigree": {
    "ancestors": [
      {
        "type": "library",
        "name": "openssl",
        "version": "3.0.15",
        "purl": "pkg:generic/openssl@3.0.15"
      }
    ],
    "patches": [
      {
        "type": "backport",
        "diff": {
          "url": "https://github.com/openssl/openssl/commit/e96d22446e633d117e6c9904cb15b4693e956eaa"
        },
        "resolves": [
          {
            "type": "security",
            "id": "CVE-2025-4575",
            "source": {
              "name": "openssl-library.org",
              "url": "https://openssl-library.org/news/vulnerabilities/#CVE-2025-4575"
            }
          }
        ]
      }
    ]
  }
}

References

Known unknowns

In practice, suppliers sometimes integrate third-party components where the original vendor has not provided an SBOM. While the supplier knows that a particular component is included in their delivery, they lack visibility into its internal composition and dependencies. This creates a "known unknown" — a component whose presence is documented but whose contents remain opaque.

Rather than omitting these components from the SBOM (which would create an undocumented gap), suppliers must:

1. Include the component with all available information (name, version, hashes, supplier details)
2. Mark it as incomplete using the compositions section to explicitly indicate that its dependencies are unknown
3. Provide context in the description field explaining why the component lacks complete information

{
  "bom-ref": "pkg:generic/vendor-provided-library@2.0.0?checksum=sha512:ddcf92...1fa30d42f1",
  "type": "library",
  "name": "vendor-provided-library",
  "version": "2.0.0",
  "supplier": {
    "name": "Vendor Inc.",
    "url": [
      "https://vendor.com"
    ]
  },
  "hashes": [
    {
      "alg": "SHA-512",
      "content": "ddcf92...1fa30d42f1"
    }
  ],
  "description": "Vendor provided library without a provided SBOM - dependencies are unknown."
}

In the compositions section:

{
  "compositions": [
    {
      "aggregate": "incomplete",
      "assemblies": [
        "pkg:generic/vendor-provided-library@2.0.0?checksum=sha512:ddcf92...1fa30d42f1"
      ]
    }
  ]
}

References

Redactions

Some use-cases might require a supplier to redact or omit relevant supply chain information from a SBOM. Rather than omitting these components (which would create an undocumented gap), suppliers must:

1. Include the component with all available information, leaving placeholders for any information that is redacted
2. Mark it as incomplete using the compositions section
3. Provide context explaining why the component lacks complete information

{
  "bom-ref": "pkg:generic/redacted-name@redacted-version?checksum=sha512:45937035...1129dee911ba5d",
  "type": "firmware",
  "name": "redacted-name",
  "version": "redacted-version",
  "hashes": [
    {
      "alg": "SHA-512",
      "content": "45937035...1129dee911ba5d"
    }
  ]
}

In the compositions section (the aggregate type redacted is expected to be added in CycloneDX 1.7 — use incomplete in 1.6):

{
  "compositions": [
    {
      "aggregate": "redacted",
      "assemblies": [
        "pkg:generic/redacted-name@redacted-version?checksum=sha512:45937035...1129dee911ba5d"
      ]
    }
  ]
}

Third-party SBOMs

When integrating third-party components that come with their own pre-existing SBOM, suppliers should always deliver a copy and include links to the external ("upstream") SBOM.

If the upstream SBOMs are not in a standard format accepted by the content requirements, the contents (i.e. dependencies) need to be replicated and merged into the Supplier's SBOMs. The original upstream SBOMs should still be linked in this case.

How to link external SBOMs

When including a third-party component that has its own SBOM:

1. Identify the component using the established content requirements for identities
2. Identify the supplier using the established requirements for organizations (see Suppliers)
3. Reference the external SBOM using a unique identity such as a URL or BOM-Link
4. Provide verification through hashes of the upstream SBOM file
5. Document the relationship with appropriate description comments

The external SBOM reference can use either:

• URL reference: canonical link to where the SBOM was retrieved
• BOM-Link: unique identifier following the CycloneDX BOM-Link specification (urn:cdx format)
• Filename: use a file URL (e.g. file://upstream-sbom.cdx.json)

Important considerations

• The linked upstream SBOM must be included in the delivery together with the Supplier's SBOM, even if referenced with a URL
• Cryptographic hashes of the external SBOM must be included in the reference to ensure integrity
• When available, include any digital signatures provided by the third-party supplier

{
  "bom-ref": "pkg:generic/vendor-provided-library@1.0.0?checksum=sha256:708f1f53b41f...",
  "type": "library",
  "name": "vendor-provided-library",
  "version": "1.0.0",
  "supplier": {
    "name": "Vendor Inc.",
    "url": [
      "https://example.com"
    ]
  },
  "externalReferences": [
    {
      "type": "bom",
      "url": "https://example.com/sbom/component-f-1.0.0.cdx.json",
      "comment": "Component described by vendor provided SBOM",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "708f1f53b41f11f02d12a11b1a38d2905d47b099afc71a0f1124ef8582ec7313"
        }
      ]
    }
  ]
}

References

Dependency relationships

Dependency relationships document how components within the described software relate to each other. Accurate dependency information enables consumers to perform impact analysis when vulnerabilities are discovered, understand the full software supply chain, and assess cascading risks.

SBOMs must include a complete list of relationships, including all components in the inventory.

Preferred representation

Dependencies should be represented as a hierarchy rather than as a flat list:

• Each component should list only its direct dependencies
• The full dependency tree emerges from following the chain of direct dependencies
• This preserves the actual software architecture and enables accurate impact analysis

While a flat dependency list (where the root component lists all transitive dependencies directly) is technically valid, the hierarchical representation enables much more precise vulnerability impact analysis and is strongly preferred.

Special cases

Build tools and excluded dependencies — components identified as build-time only (e.g. marked with scope: "excluded" in CycloneDX, such as compilers or build tools) should still have their dependencies documented if they are included in the SBOM.

Unknown dependencies — for components where the full dependency tree is unknown this must be explicitly documented (see Known unknowns).

Patched components — dependencies on patched components should reference the patched version's identifier (see Documenting patched components).

{
  "dependencies": [
    {
      "ref": "a05bbca7-f783-44cd-aafb-f5284f81473f",
      "dependsOn": [
        "pkg:deb/debian/gcc-12@12.2.0-14?arch=amd64&distro=debian-12",
        "pkg:npm/example-js-library@6.0.2",
        "pkg:generic/vendor-provided-library@1.0.0?checksum=sha256:708f1f53b41f...",
        "pkg:generic/openssl@3.0.15+patched"
      ]
    },
    {
      "ref": "pkg:deb/debian/gcc-12@12.2.0-14?arch=amd64&distro=debian-12",
      "dependsOn": [
        "pkg:deb/debian/libstdc++-12-dev@12.2.0-14?arch=amd64&distro=debian-12"
      ]
    }
  ]
}