Open Component Model Explained: Software Bill of Delivery

The Open Component Model (OCM) is an open standard answering a surprisingly mundane question: what exactly belongs to a software delivery? Not to the source code, not to a single container image, but to the complete delivery of a product across environment boundaries. OCM aptly calls this a “Software Bill of Delivery”. Where an SBOM describes what an artifact is made of, OCM describes which artifacts ship together, where they live and how to verify their integrity. This article explains the model, its tooling and the scenarios where it earns its keep.

The problem: a delivery is more than an image

A real product release is a bundle: several container images, Helm charts, configuration files, perhaps binaries and documentation. This bundle travels through stations, from the build environment via internal registries to the customer environment, which in regulated industries is often fully disconnected from the internet. At the latest when transporting into an air-gapped environment, the usual approach of “we just reference registry URLs” falls apart: the source system’s URLs are worthless on the other side, while digests and signatures still have to survive the journey untouched.

This is where OCM starts. A component descriptor describes a component version with its resources (images, charts, files), its sources and its references to further components. The format is technology-agnostic and machine-readable; a shortened example:

meta:
  schemaVersion: v2
component:
  name: acme.org/billing
  version: 2.4.1
  provider: acme
  resources:
    - name: billing-image
      type: ociImage
      version: 2.4.1
      access:
        type: ociArtifact
        imageReference: ghcr.io/acme/billing:2.4.1
      digest:
        hashAlgorithm: SHA-256
        value: 8a1f...
  componentReferences:
    - name: payment-gateway
      componentName: acme.org/payment-gateway
      version: 1.9.0

The crucial trick sits in the access block: it separates an artifact’s identity from its storage location. When transporting into another environment, the OCM tooling rewrites the access information (by value instead of by reference) while digests and signatures stay stable. The component remains the same; only its location changes.

Sign, transport, verify

To move descriptors and artifacts together, OCM defines the Common Transport Format (CTF), a file-based layout as a directory, .tar or .tgz. A complete delivery becomes a file you can write to a medium and import into an OCI registry on the far side. The CLI flow is deliberately unspectacular:

ocm transfer componentversion ghcr.io/acme//acme.org/billing:2.4.1 ./delivery.ctf
ocm sign componentversion --signature acme-release ./delivery.ctf
ocm verify componentversion --signature acme-release ./delivery.ctf

Signatures cover the component graph including artifact digests. The recipient verifies against the public key and then knows that neither descriptor nor referenced artifacts were modified in transit. For Kubernetes environments the project additionally ships the OCM K8s Toolkit, an operator that makes component versions available in-cluster and, combined with Flux or kro, forms a complete deployment chain, including configuration and localization of image references at deploy time.

Who is behind it and why that matters

OCM was initiated by SAP, which uses it internally to deliver large product estates, and is developed today as an open source project under Apache-2.0, embedded in the NeoNephos Foundation under the umbrella of Linux Foundation Europe and funded within the European sovereignty program ApeiroRA. The specification, a Go library, the CLI and the Kubernetes operator are public, documented at ocm.software.

That origin explains the design focus: OCM is built for scenarios where software has to move across environment and organizational boundaries in a controlled way. It fits a period in which many European companies are re-evaluating their dependencies; verifiable, signed delivery chains are the operational side of digital sovereignty, a topic we covered in our sovereign cloud article.

When OCM is the right choice, and when not

To be honest about it: if you deploy a single SaaS product from one pipeline into your own cloud, you do not need OCM. The standard pays off when at least one of three patterns applies. First, delivery to third parties, such as customers deploying on-premises or into their own clouds. Second, air-gapped or heavily regulated target environments where transport by medium and signature verification are mandatory. Third, product portfolios made of many components with independent release cycles, whose per-release composition must be documented and verifiable.

Towards the SBOM, OCM is complementary rather than competing: SBOMs describe the contents of individual artifacts and travel inside OCM deliveries as resources. How such nested structures work on the SPDX level is covered in our deep dive on cascading SPDX documents.

Conclusion

OCM closes a gap previously served only by homegrown solutions: an open, signable, transportable standard for the question of what ships together. For product deliveries to customers, regulated environments and air-gapped scenarios the model deserves a serious look, especially since tooling and governance are open. If you want to move your delivery pipeline to signed, traceable deliveries, we support you from architecture to implementation: cloud and infrastructure at EverBright.

Frequently Asked Questions

What is the Open Component Model?

The Open Component Model is an open, technology-agnostic standard for describing software deliveries, a Software Bill of Delivery. Component descriptors capture the artifacts, sources and references of a component version in machine-readable form, including signatures and digests. Initiated by SAP, OCM is developed openly today under the NeoNephos Foundation.

What is the difference between an SBOM and OCM?

An SBOM describes what a single artifact is made of, for example which packages live inside a container image. OCM describes which artifacts together form a delivery, where they are stored and how to verify their integrity. The two complement each other: SBOMs travel as resources inside OCM deliveries.

What is the Common Transport Format (CTF) for?

CTF is OCM’s file-based format that captures a complete delivery, descriptors plus artifacts, as a directory, tar or tgz archive. It enables transporting deliveries without a network connection, for example into air-gapped environments, and importing them into an OCI registry on the target side.

Who benefits from adopting OCM?

OCM benefits vendors delivering software to customers with their own environments, regulated and air-gapped scenarios with mandatory signature verification, and product portfolios composed of many independently versioned components. For simple SaaS deployments from one pipeline into your own cloud it is usually overhead.