The Open Container Initiative (OCI) is an open governance project under the Linux Foundation that defines industry standards for container formats and runtimes. Its specifications mean an image built with one tool can be stored in any compliant registry and run by any compliant runtime.
What is the OCI and who started it?
According to the OCI's own overview, the project launched on 22 June 2015, formed by Docker, CoreOS and other leaders in the container industry, under the auspices of the Linux Foundation. Its stated purpose is creating open industry standards around container formats and runtimes. Docker donated its container format and its runtime, runC, as the starting point.
The reason is simple. Before a standard, "a container image" meant whatever one vendor's tool produced. A standard lets tools compete on features while sharing a format.
What are the three specifications?
The OCI currently contains three.
Runtime Specification. It describes how to run a filesystem bundle that has been unpacked on disk. A runtime downloads an image, unpacks it into a bundle and runs it.
Image Specification. It defines how to create an image, typically done by a build system. The output is an image manifest, a filesystem layer serialization and an image configuration. The manifest holds metadata about the image's contents and the content-addressable identity of the layer archives. The configuration holds details such as arguments and environment variables. Together they are the OCI image.
Distribution Specification. It standardizes the API for distributing images. The OCI says it reached version 1.0 in May 2020 and that it is generic enough to distribute any type of content, not only container images.
Why does this matter for security?
Three consequences follow from the design.
Content addressing gives you a verifiable identity. Because layers and manifests are identified by content, a digest names exactly one set of bytes. A tag such as v1.2 can be moved to point at a different image tomorrow. A digest cannot. That is why pinning deployments to digests is a common supply chain control.
A common format lets one set of tools inspect everything. Scanners, SBOM generators and policy engines can read the same manifest and layers regardless of which builder created the image. It also means a vulnerability scan of an image looks at the layers and their packages, not at the Dockerfile that produced it.
A generic distribution API lets registries hold more than images. Because the specification is designed for any content, teams store signatures, attestations and SBOMs next to the image they describe. The standard enables this, but it does not mandate it. Whether you sign and verify is up to your process.
What the OCI does not do
The standards define formats and APIs. They do not decide whether an image is safe, whether the base image is maintained, or whether the registry has sound access controls. A compliant image can contain a vulnerable library, and a compliant runtime can run it with excessive privileges.
A constructed example
A team builds an image in CI and pushes it to a registry. The deploy manifest references the image by tag. An engineer with push access, or an attacker with stolen credentials, pushes a different image under the same tag, and the next deployment pulls it. After an incident review, the team changes two things. The pipeline records the digest of each build and deploys by digest. It also restricts who can push to the production repository. The standard did not cause the problem, but its content-addressed design made the fix easy.
How to check or apply this
- Reference images by digest in production deploys, and record the digest in your build output.
- Scan the layers of the image you will actually run, not only the source repository.
- Keep an SBOM for each image and store it alongside the image in the registry if your tools support it.
- Restrict push rights on production repositories and log them.
- Choose maintained base images and rebuild on a schedule so base layer fixes arrive.
- Run containers with the least privilege the runtime allows.
Safeguard's dependency scanning and SBOM features read the packages inside images, which is the part the format leaves open.
Quick check
Is a Docker image an OCI image?
Docker's tooling produces images in a format that follows the OCI image specification, since Docker donated the format that became its basis. Check your tool's documentation for the exact format version.
Does OCI compliance mean an image is secure?
No. It means the image follows a standard format. Contents still need scanning, signing and sound registry controls.
Sources
Last reviewed: 18 October 2026.
