What breaks when a container can modify read-only files in the underlying image?

A read-only image no longer behaves as a shared, immutable base. An attacker who can write through the vulnerability may alter files used by other containers on the same host, poison future containers started from that image, and bypass read-only host mounts. In multi-container environments, that turns one container compromise into a broader integrity problem across the platform.

What stops a container image from being trustworthy?

A container image is supposed to be an immutable base. If a container can alter files that should be read-only, the image is no longer trustworthy as a shared artefact. That breaks the assumption that a container starts from the same known state every time, which is why image integrity, isolation and runtime enforcement matter as much as the image contents themselves.

How does one writable image undermine the rest of the platform?

The immediate problem is not just local tampering, it is trust propagation. When one workload can modify the underlying image layers, the change can affect other containers launched from the same image, especially in dense hosts or shared registries. That means the blast radius can extend beyond the original container to future deployments, image promotion pipelines and any control that assumes the base image is unchanged.

Container security guidance treats image integrity and runtime separation as core controls for exactly this reason. NIST SP 800-190 Container Security describes the image, registry, orchestrator and runtime as separate trust boundaries, and NIST SP 800-190 Container Security is the clearest external reference for that model.

When the shared base can be rewritten, the platform loses one of its strongest efficiency properties: many workloads can no longer safely inherit the same artefact. Instead of a common baseline, each subsequent container may inherit hidden tampering, which makes diagnosis, rollback and provenance checks much harder.

Why does this become an integrity and escalation problem rather than a simple file-permission bug?

This failure mode matters because it can convert a container compromise into a persistence mechanism. A malicious process does not need to escape the container immediately to create damage; it can poison a shared image, alter startup logic, replace scripts or change configuration files that later containers trust. In practice, that is an integrity breach with platform-wide consequences, not just a single-process defect.

It also creates a bypass path around the intent of read-only host mounts. If the underlying image can be modified indirectly, the attacker may be able to influence files that operators believed were protected by mount policy. The result is a mismatch between the documented security posture and the actual runtime behaviour, which is exactly the kind of gap that makes container incidents hard to detect early.

For practitioners who want a broader control lens, NIST Cybersecurity Framework 2.0 is useful for mapping the issue to protection, detection and recovery outcomes, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides the underlying integrity, access control and configuration management control set.

What should operators verify before they trust a “read-only” container design?

Operators should verify that the read-only behaviour is enforced by the runtime and not only by convention in the deployment spec. The important question is whether the container can actually modify the backing image layers, writable overlay, startup artifacts or any mounted path that later workloads depend on. If those paths are mutable, the design is already broken regardless of what the YAML says.

It is also worth checking whether the image is shared across environments or promoted through a pipeline without re-signing or revalidation. A tampered layer can become a durable supply-chain problem if teams treat the image as reusable after compromise. For identity and access-adjacent governance of the artefacts involved, NHIMG’s Massive Docker Hub Secrets Leak is a strong companion reference because it shows how compromise inside container images can persist as a reusable trust problem.

Where the platform depends on image immutability for release safety, teams should treat any writable image path as a release-blocking defect. That is especially true if the image is shared across multiple services, because one compromised container can taint many later starts.

Risk and Threat Considerations

The core risk is trust collapse: a container that can write to supposedly read-only image content can silently alter the base that other containers rely on. That creates a persistence path, a lateral integrity problem across workloads, and a chance to bypass operational assumptions about immutable infrastructure.

Failure mechanism: The attacker abuses write access through the overlay, mount handling or runtime weakness to modify files that should have remained immutable, then waits for those altered files to be reused by other containers or future deployments.

Impact: Operators can lose provenance, rollback confidence and isolation guarantees at the same time, which means a single container compromise can spread into a broader platform integrity incident.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-7 — Software, Firmware, and Information Integrity	Covers tampering with image contents and runtime integrity loss.
	CM-6 — Configuration Settings	Applies to preserving immutable container and mount configurations.
Recommendation — Enforce integrity checks and alert on unauthorized file or image modification. Lock down container filesystem and mount settings to prevent writable image paths.
NIST CSF 2.0	PR.DS-01 — Data-at-rest is protected	Image files and shared artefacts must remain protected at rest against tampering.
	PR.PS-01 — Configuration management	Read-only container behaviour depends on controlled, enforced runtime configuration.
Recommendation — Protect stored image artefacts so they cannot be altered by running containers. Verify and enforce read-only runtime settings for containers and shared mounts.
ISO/IEC 27001:2022	A.8.13 — Information backup	Image tampering raises the need for recovery from trusted baseline artefacts.
Recommendation — Keep trusted image baselines so compromised artefacts can be restored quickly.

Practitioner Guidance

What to verify: Confirm that the runtime enforces immutability at the filesystem and mount layer, not just in deployment policy. If a container can influence shared image layers or reused startup files, treat the control as failed even if the workload appears to run normally.

Common mistake: Teams often stop at “the container is read-only” without testing whether the backing image, overlay and shared artefacts are also protected. Read-only intent is not the same as enforced immutability.

Decision rule: If a container can modify artefacts that later containers inherit, prioritise containment and rebuild of every dependent image before you investigate whether the original compromise was otherwise contained.

Practitioner takeaway: Immutable containers are only trustworthy when the immutability is real, enforced end to end, and validated against reuse across the fleet.