Containers and registries

OCI (Open Container Initiative): a project that defines container interoperability specifications such as image, runtime, and distribution.

An OCI image is a content-addressed graph of a manifest, an optional index, a configuration, and filesystem layer descriptors. A container is a process run from the root filesystem and execution configuration derived from this image, within host isolation mechanisms such as namespaces and cgroups.

Treating an image and a container as the same thing confuses changes in the writable layer with a reproducible artifact. Namespaces provide the scope of what is visible and cgroups provide resource accounting and limits, but a container does not have its own kernel.

A security boundary does not arise from the image format alone. Look at the capabilities, seccomp, mounts and user in the runtime config together with host kernel vulnerabilities.

In the training example an image index containing both amd64 and arm64 was misread as a single amd64 manifest. The index digest and the platform manifest digests inside it point to different content. You can only trace down to the actual layers once you know which platform the executing node selected. Files created inside a container are separate from the immutable layers of the image, so do not assume they persist in a new instance.

Why does this happen?

Treating an image and a container as the same thing confuses changes in the writable layer with a reproducible artifact. Namespaces provide the scope of visibility and cgroups provide resource accounting and limits, but a container does not have its own kernel.

When is it a problem?

If you see a mismatch in the digest, platform, or permission contract, there are insufficient grounds to proceed.

Common beginner misconceptions

UID 0 inside a container does not automatically become safe from the host kernel's point of view. Check the user namespace and capability policies separately.

How to verify it yourself

Resolve the image reference by tag and by digest separately. Check the platform, config, and layer digests in the manifest.

SBOM (Software Bill of Materials): a description of the components in an artifact; on its own, it guarantees neither the absence of vulnerabilities nor trustworthiness.

A reproducible build records the source revision, dependency lock, base image digest, builder, and build arguments so that the same inputs produce a reviewable output. The SBOM, scan, provenance, and signature must be linked to the output digest.

Dockerfile layer cache speeds builds up, but a mutable package index, leaked secrets, and a wide build context can harm reproducibility and security. Use multi-stage builds, pinned digests, and cache/secret mounts to reduce what ends up in the runtime image.

Do not make zero scan findings the only goal. Record the scanner database revision, the severity policy, exploitability, and the exception owner and expiry as well.

In the training example the build used the same Git commit, but the base tag changed and the output digest differed. You cannot approve two artifacts as identical merely because the source revision matches. Track the cause of the change by bundling the base digest, the dependency lock and the builder information. Signature verification is a procedure for confirming who signed which digest, and it is performed separately from vulnerability review.

Why does this happen?

The Dockerfile layer cache speeds up builds, but a mutable package index, leaked secrets, and a broad build context can harm reproducibility and security. Use multi-stage builds, pinned digests, and cache/secret mounts to reduce what ends up in the runtime image.

When is it a problem?

If you see an unpinned base, secret exposure, or a signature failure, there are insufficient grounds to proceed.

Common beginner misconceptions

Passing a secret through ARG or ENV can leave it in the history or in a layer. Use a BuildKit secret mount and a credential with minimal scope.

How to verify it yourself

Put the Git revision, the lockfile, and the base image digest into the build metadata. Check the scope of network, secret, and cache usage per build stage.

Chain of custody: a procedure that records the owner, time, integrity, and approval each time an artifact crosses a boundary.

A registry is not a list of tags; it is a service that runs a content-addressed graph of manifests and blobs along with authentication, authorization, TLS, retention, garbage collection, and backup. An air-gapped import must prove custody and hashes at every physical and logical boundary.

A manifest references several blobs, so backing up the database and the filesystem separately at arbitrary times can break consistency. Retention and garbage collection must account for the digests currently deployed and the rollback window.

Check that a signature verified externally still points to the same digest after the internal copy. Internal tags may be rewritten, but the approved identity is kept by digest.

In the training example the archive checksum was correct but a manifest with a different tag ended up in the internal registry. Media integrity and distribution artifact identity are evidence at different boundaries. After verifying the imported archive, the internal manifest digest must also be compared with the externally approved value. A multi-platform image must include every manifest and blob; do not test only one platform and record the import as complete.

Why does this happen?

A manifest references several blobs, so backing up the DB and the filesystem separately at arbitrary times can break consistency. Retention and garbage collection must take the digests currently deployed and the rollback window into account.

When is it a problem?

If you see a mismatch among the media hash, the internal digest, and the approval sheet, there are insufficient grounds to proceed.

Common beginner misconceptions

Check that no credential file or build secret got mixed into the archive. Removable media must follow the organization's malware scan and custody procedures.

How to verify it yourself

Store the manifest digest and the signature from the external source registry. Record the SHA-256 of the export archive and the media, the owner, the timestamp, and the seal number.