Use the oci type for images stored in registries that follow the OCI Distribution Specification, with the sha256 digest as the version, because a digest identifies one exact artifact. The docker type also exists and allows a tag, but the registry notes tags can move, so a digest is preferred either way.
Two types, two histories
The purl type registry lists both. The oci type is described as covering artifacts in registries that conform to the OCI Distribution Specification, including images built by Docker and others. The docker type is described simply as for Docker images, with Docker Hub as its default repository.
The practical difference is how each handles where an image lives and what the version means.
Side by side
| Part | oci type | docker type |
|---|---|---|
| Namespace | Prohibited | Optional, the registry, user or organization |
| Name | Required, lowercased, the last fragment of the repository name | Required |
| Version | The sha256 digest, needed to identify the artifact uniquely | Image id digest or a tag, digest preferred |
| Default repository | None, registry agnostic by default | Docker Hub |
| Qualifiers | arch, repository_url, tag | None defined in the registry entry |
For oci, if the repository name is library/debian, the purl name is debian. The location goes in the repository_url qualifier instead of the namespace.
Registry examples
pkg:oci/debian@sha256%3A244fd47e07d10?repository_url=docker.io%2Flibrary%2Fdebian&arch=amd64&tag=latest
pkg:oci/hello-wasm@sha256:244fd47e07d10?tag=v1
pkg:docker/cassandra@latest
pkg:docker/customer/dockerimage@sha256%3A244fd47e07d10?repository_url=gcr.io
The digests in these examples are shortened for illustration. Use the full digest in practice.
Why a digest and not a tag
A tag is a label that a publisher can point at a different image tomorrow. A digest is a hash of the content. If your SBOM says the image was latest, nobody can later tell which build you meant. If it says a specific digest, anyone can check.
The oci entry says the digest is required to uniquely identify the artifact. The docker entry says tags can be moved and a sha256 image id is preferred. Both agree on the substance.
A decision guide
- Do you control the SBOM generator? Use oci with the digest as the version.
- Do you need to record where the image was pulled from? Add repository_url.
- Do you want a human friendly label too? Add tag as a qualifier, remembering it is only a hint.
- Do you consume SBOMs that use docker? Accept both types and normalize in your own store.
- Does a downstream matcher need operating system packages? Those are separate components with their own purls, such as deb or apk, inside the image SBOM.
Mistakes to avoid
Encoding the registry in the namespace for the oci type is not allowed, because the namespace is prohibited. Dropping the digest and keeping only a tag makes the identifier unstable. Treating the image purl as a stand in for its contents misses the point: the image purl names the artifact, and the packages inside need their own entries.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the image identity at the top, then the packages listed beneath it.
Where this fits
Digest based identity pairs well with signing and attestation. See attaching an SBOM to a container image with cosign. Safeguard offers container scanning with SBOMs, and the free scan is a quick way to try it.
Quick check
Can an oci purl have a namespace?
No. The registry marks the namespace as prohibited. Put location information in the repository_url qualifier.
Is a tag enough to identify an image?
No. Tags can be moved, so record the sha256 digest as the version.
Sources
Last reviewed: 19 October 2026.
