SBOM Requirements

SBOMs must contain a complete and structured inventory of software components, along with supporting metadata that enables traceability, vulnerability analysis, supplier identification and compliance verification.

In some cases, a field may be defined as optional in a standards specification but is Required here. For example, unique identifiers or provenance information must always be present, even if considered optional elsewhere.

Maturity levels

To support evaluation, two general maturity levels for SBOM completeness are distinguished:

• Maturity level 1 (L1) — content that is simple to obtain through first-hand automated observation using standard SBOM generation tools (e.g. basic metadata, declared components, top-level hashes).
• Maturity level 2 (L2) — content that is moderately difficult to obtain and may require domain-specific tools, manual enrichment, human analysis, or access to proprietary or internal sources (e.g. transitive dependencies, redacted relationships, embedded licenses or pedigree data).

High-level SBOM requirements

Attestation metadata

Each SBOM must contain top-level metadata that uniquely identifies the document, indicates when it was created, and provides a consistent revision number.

At a minimum, the following are required:

• A globally unique identifier for the SBOM document
• A creation timestamp indicating when the SBOM was generated or exported
• The manufacturer or author that created the SBOM

This information must be present regardless of whether it is optional in the base specification. For example in CycloneDX, the serialNumber field is optional, but for reliable tracking it is treated as required to ensure SBOM uniqueness across submissions.

These identifiers play a critical role in versioning, digital signatures, and comparison between artifacts over time. The timestamp must reflect the generation or export time of the SBOM, not just a build or packaging date.

{
  "serialNumber": "urn:uuid:1181ba0e-da66-4e8f-9c7f-4ed976c37bf1",
  "version": 1,
  "metadata": {
    "timestamp": "2025-03-25T10:40:25+00:00"
  }
}

Lifecycle and provenance

In addition to basic identification, SBOMs must include information describing how the document was produced, who was involved in its creation, and which phase of the product lifecycle the data represents.

This information increases the transparency and credibility of the SBOM, and allows Consumers to better assess the trustworthiness of its contents.

{
  "metadata": {
    "lifecycles": [
      {
        "phase": "build"
      }
    ]
  }
}

Tool information

The SBOM must include information about the tool or tools used to generate it. This is essential for understanding the scope, capabilities, and potential limitations of the SBOM content.

At a minimum, the tool name must be included. The version number is strongly recommended, as it enables Consumers to evaluate the expected feature set and behavior at the time of generation. When available, a URL to the tool's official website or repository should also be provided.

{
  "metadata": {
    "tools": {
      "components": [
        {
          "name": "observer",
          "version": "0.9.1"
        }
      ]
    }
  }
}

Subject of the SBOM

Every SBOM must clearly define the subject it describes — typically a software application, component, or system. This includes identifying what the SBOM refers to, how it can be distinguished from other components, and which files or artifacts it relates to.

At a minimum, the subject should include:

• Type — such as "application", "library", or "container"
• Name and version — a clear identifier for the software the SBOM describes

Where applicable, additional artifact-level details should also be included, such as:

• Filenames and cryptographic hashes for distributed files. This should include both any distributed archives or installers and the files that would be installed in a target runtime environment
• Other available identifiers for the subject (e.g. CPE, SWID tags) including any product identifiers shared between Supplier and Consumer

{
  "metadata": {
    "component": {
      "bom-ref": "a05bbca7-f783-44cd-aafb-f5284f81473f",
      "type": "application",
      "name": "example-application",
      "version": "1.0.0",
      "purl": "pkg:swid/Example%20Inc/example.com/example-application@1.0.0?tag_id=a05bbca7-f783-44cd-aafb-f5284f81473f",
      "manufacturer": {
        "name": "Example AB",
        "url": [
          "https://www.example.com",
          "https://lei.info/549300MLH00Y3BN4HD49"
        ],
        "contact": [
          {
            "name": "Security Team",
            "email": "security@example.com"
          }
        ]
      },
      "components": [
        {
          "type": "file",
          "name": "example.exe",
          "hashes": [
            {
              "alg": "SHA-256",
              "content": "f6d71a1bcd45764550a42dfaa179bc43b63ee879ec6f875bfd39fca013515da7"
            }
          ]
        },
        {
          "type": "file",
          "name": "lib-example.dll",
          "hashes": [
            {
              "alg": "SHA-256",
              "content": "36b5e543365f73bc221c88ec6be6a2b9609063ddd34219496ed4bad579936bd9"
            }
          ]
        }
      ]
    }
  }
}