An OCI artifact is any content other than a container image, such as a Helm chart, an SBOM, a signature or a policy bundle, stored in an OCI-compliant registry using the same manifest format as images. That lets one registry hold and distribute many kinds of supply chain material with shared access control.
What does the specification say?
The Open Container Initiative's image specification includes guidance for artifact authors. It states that content other than OCI container images may be packaged using the image manifest, and that in this case the config.mediaType value should not be a known OCI image config media type. It also notes that, because of registry limitations in the past, some tools used the image config media type for non-image artifacts and put artifact-specific values in layer media types.
In plain terms, a manifest points to blobs by digest, and a media type tells clients what each blob is. A client that does not understand the type should not treat it as a runnable image.
The OCI project announced version 1.1 of the image and distribution specs in March 2024. Among the additions, the distribution spec's referrers API lets a client list artifacts that point to a given manifest, using a subject field. This is how a signature or SBOM is linked to the image it describes.
Why do artifacts matter for supply chain security?
Because the evidence about an image should travel with it. Without a common place, SBOMs sit in a wiki, signatures in a separate store, and scan results in a dashboard. With artifacts, you can attach these to an image digest and query them from the same registry the deployment pipeline already trusts.
It also means the registry becomes a larger target. It now holds the proof of integrity as well as the thing being verified. If an attacker can write to the registry, they might replace both an image and its attached signature, unless signatures are verified against keys the registry cannot touch.
What can go wrong?
Tags move, digests do not. Pulling by tag can return different content tomorrow. Pull and verify by digest.
Type confusion. A client that accepts any artifact as an image, or a tool that treats unknown media types loosely, can mishandle content. Validate media types.
Weak write control. Many teams give CI broad push rights to the whole registry. A single compromised job can then overwrite things. Scope push access per repository and per pipeline.
Unverified attachments. An SBOM or attestation attached by anyone is only a claim. Check who signed it.
Retention gaps. Garbage collection can remove artifacts that reference deleted images, or leave orphans. Define the policy.
A constructed example
A team builds an image and pushes it as registry.example.com/app@sha256 followed by the digest. A signing step attaches a signature, a second step attaches an SBOM, and each uses the image digest as its subject. At deploy time the admission check lists referrers for the digest, requires a valid signature from the build identity, and refuses any image that lacks one. An attacker who pushes a lookalike image with no signature gets blocked at the gate, even though the registry accepted the upload.
How to check or apply this
- Inventory what your registry holds today. Look for non-image content such as charts and attachments.
- Deploy by digest. Record the digest in release records and in your deployment manifests.
- Sign images and attached artifacts, and verify signatures at deploy time against trusted identities or keys.
- Scope write access per repository and per pipeline identity, and use short-lived credentials.
- Keep your registry software current, since it implements the distribution spec and the referrers API.
- Set media type allowlists in tooling where it supports them.
- Define retention for attached artifacts and test that cleanup does not delete evidence you need for audits.
- Mirror critical third party images into your own registry and scan on ingest.
- Log pushes, pulls and deletes, and review anomalies.
Quick check
Is an OCI artifact the same as a container image?
No. Both use the same manifest structure and registry, but an artifact is non-image content, identified by its media type, and is not meant to be run as a container.
Why attach an SBOM to the registry instead of storing it elsewhere?
It stays linked to the exact image digest it describes and inherits the registry's access control. You still need to verify who produced it.
Sources
- OCI Image Spec, guidance for artifacts authors
- OCI Distribution Spec
- Open Container Initiative, Image and Distribution Specs v1.1
- SLSA
Last reviewed: 18 October 2026.
