The Open Component Model (OCM) is an open standard to describe software-bill-of-deliveries (SBOD). OCM is a technology-agnostic and machine-readable format focused on the software artifacts that must be delivered for software products.
By providing a globally unique identity scheme, OCM can be employed throughout the entire software lifecycle management process, from build to compliance, to deployment.
It can be used as a common basis and lingua franca for the exchange, access and transport of delivery artifacts between different tools, processes and environments.
To support fenced or otherwise restricted environments, OCM provides a mechanism to transparently adapt access information for artifacts during transport. This means that applications accessing the component information in a particular environment always receive location specific access information that is valid for their own environment.
OCM is a technology-agnostic model to describe artifacts and the specific means by which to access their content. In this context we understand technology-agnostic to mean the following:
- the model can describe any artifact regardless of its technology
- artifacts can be stored using any storage backend technology or repository
- the model information can be stored using any storage backend technology or repository
OCM is (explicitly) not meant to describe the complete bill of materials of a software product, in relation to the packages those delivery artifacts are composed of. This makes OCM a simpler model in comparison with standards such as CycloneDX. OCM provides detailed and unambiguous specifications with respect to delivery and deployment related aspects such as transport and signing of software artifacts. Further information about artifacts (like typical SBOMs) can be added using labels, additional resources or even component versions.
The Open Component Model is an interpretation layer on top of existing storage technologies and is not itself a repository technology. Therefore, it does not define an authentication scheme but, rather, uses those defined by the underlying storage technology.
To use a backend storage technology as an OCM repository it is necessary to provide:
- an implementation for accessing artifacts in the desired backend and mapping them to a blob format
- a specification for a mapping scheme describing how to map the elements of the Open Component Model to the supported elements of the backend storage technology
- an implementation of all the mapping schemes for the storage scenarios used in a dedicated environment
1.1 Component Descriptor
1.2 Component Repository
2.1 OCM Elements
2.2 OCM Operations
2.3 Storage Backend Mappings
2.4 Formats and Names
2.5 Denotation Schemes
A. Storage Backend Mappings
B. Access Method Types
C. Resource Types
D. Labels
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Accompanying to this specification a ready-to-go reference implementation is provided, which supports the common environment and access types for objects in the Kubernetes ecosystem. A (Go) library provides a framework for adding further implementations of the model extension points under the hood of a generic OCM API, and a command line tool based on this library supports general operations, like composing, viewing, transporting and signing of component versions.
Code contributions, feature requests, bug reports, and help requests are very welcome. Please refer to the Contributing Guide in the Community repository for more information on how to contribute to OCM.
OCM follows the CNCF Code of Conduct.
Copyright 2022 SAP SE or an SAP affiliate company and Open Component Model contributors. Please see our LICENSE for copyright and license information. Detailed information including third-party components and their licensing/copyright information is available via the REUSE tool.