Format of SBOM¶
This section describes the structure and metadata of the SBOMs published for MOSK releases and serves as a technical reference for cloud operators, explaining how to utilize a release SBOM and programmatically confirm that local artifacts match the official Mirantis release.
General structure¶
Mirantis publishes a release SBOM for each MOSK release as a single Gzip-compressed file through the Mirantis CDN. The SBOM is authored in CycloneDX v1.6 (JSON). The download link for the file is available in the release notes under the Release artifacts page.
The release SBOM describes all components necessary to deploy or update a MOSK or management cluster. These include container images, binaries (compressed Helm charts and virtual machine images), and host operating system packages. To ensure integrity and authenticity, the SBOM file is cryptographically signed using a Mirantis public certificate.
The SBOM uses the standard CycloneDX document structure: a header (SBOM metadata) followed by a list of components representing the retrieved artifacts. Each component entry includes a version and at least one cryptographic hash to validate artifact integrity after download.
Component grouping¶
Components within the SBOM file are organized into a three-level grouping scheme. This hierarchy enables operators to locate specific subsystems and target states efficiently:
Cluster release: the top level, where SBOM groups components by cluster release, for example,
mosk-21-2-0-26-2.A Cluster release is a versioned, immutable description of the desired target state of a management or MOSK cluster, and defines the exact component set and versions used to deploy or update a cluster to that state.
Functional subsystem: within each Cluster release, SBOM categorizes components by functional subsystem, such as core, LCM, bare metal, and OpenStack.
Artifact type: within each subsystem group, components are further grouped by artifact type, including Helm, Docker, and binary.
This structure allows for targeted queries, such as dentifying all artifacts required for OpenStack in a specific release, without filtering a flat list.
Mirantis-specific extensions and conventions¶
While maintaining strict compliance with the CycloneDX standard, Mirantis introduces specific conventions to streamline operationalization for MOSK within enterprise environments.
Licensing information¶
MOSK SBOM includes licensing information for each component.
For compound artifacts, such as container images containing multiple packages, the license and version correspond to primary functional component. For example, an Alpine-based container image running a Mirantis proprietary Kubernetes controller is identified under the Mirantis Proprietary License, despite containing open-source auxiliary packages.
Detailed inventories of image contents are available in the in-depth container SBOMs described below.
Upstream open-source repositories¶
For components based primarily on open-source software, Mirantis includes
an external reference to the public source code repository through
the component externalReferences section to support compliance
and traceability.
In-depth SBOMs for container images¶
Mirantis publishes a dedicated, extended SBOM for every container image listed in the release SBOM. These per-image SBOMs are also Gzip-compressed, cryptographically signed CycloneDX JSON files. These files enumerate all internal contents, including auxiliary packages, libraries, and binaries.
The release SBOM provides the URL to these image-specific SBOMs within
the externalReferences section. This approach keeps the primary release
SBOM focused on deployment requirements while enabling deep security and
compliance audits when necessary.
SBOM integrity and authenticity¶
Mirantis protects SBOM integrity through a two-step verification process: validating the SBOM file and subsequently verifying every referenced artifact.
SBOM verification¶
Every MOSK SBOM file is shipped with a cryptographic
signature that can be used to verify its integrity. The signature is
generated based on the SBOM contents after Gzip-compression and is stored
in a separate file with the same name but with the .sig extension.
To ensure the integrity of a SBOM file, operators need to validate the signature using Cosign and the official Mirantis public key:
Obtain the public key from the Mirantis GitHub repository for MOSK SBOM trust.
Verify the SBOM blob:
cosign verify-blob \ --key mirantis.pub \ --signature mosk-sbom-XXX.json.gz.sig \ mosk-sbom-XXX.json.gz
Warning
If verification fails, the SBOM file must be treated as untrusted. Do not use unverified SBOMs for automated downloads, inventory updates, or compliance evidence.
For audit purposes, Mirantis recommends recording the following metadata for every verified SBOM:
Release version
SBOM checksum
Verification timestamp
Certificate fingerprint
Artifact verification¶
Once the SBOM file is verified, the downloaded artifacts need to be checked against the checksum provided in the corresponding SBOM entry:
For binaries and Helm charts, compute the file’s hash and compare the result with the SBOM value
For container images, use immutable digests to ensure the deployed image matches the expected identity
For host operating system packages, continue using package manager repository signature verification as the primary control, using hashes in the SBOM index as an additional consistency check
See also