Mythos Hardening Control · MRIS 2.0 · Applies to ISO/IEC 27001 and IT-Grundschutz

MHC-06 Container security and confidential computing

Hardens runtime environments through signed images and attestation – a compromised artifact does not reach production unnoticed, and data stays protected even during processing.

At a glance

Operational benefit: ensures that only unaltered, verified container images run, and protects particularly sensitive data even during processing — including against an attacker with access to the underlying infrastructure.
Policy affected: policy on secure development and secure operations (container and cloud operations).
Dependencies: no precondition; presupposes a container or cloud platform; works together with MHC-02 (image provenance) and MHC-04 (identities).
Effort drivers: depends on the number of container workloads and on whether confidential computing is available in the platform in use. The actual effort depends on the organization's resources.
Primary metric: share of containers running in production from signed images verified before start-up; supplementary, the coverage of confidential computing for the workloads classified as particularly requiring protection.
Standards touched (no claim of fulfilment): ISO/IEC 27002 A.5.23/A.8.31; C5:2026 OPS-32 to OPS-35; NIST SP 800-190; Confidential Computing Consortium.

Control statement

Containers run only from signed images verified before start-up, drawn from controlled sources, with enforcement through the platform. Advanced hardening (Managed level): for the workloads classified as particularly requiring protection, protected execution environments (confidential computing) with proof of authenticity (remote attestation) are deployed; the classification is documented.

MHC-06 covers two protective layers of differing maturity and differing breadth of applicability: container security as a broad baseline requirement for containerized workloads, and confidential computing as advanced hardening for workloads particularly requiring protection, tenant separation, regulated data processing or infrastructure with an elevated trust risk. Both are treated together here but should be planned, assessed and evidenced separately in implementation.

Purpose and threat relevance

Containers are often assembled from publicly available base images. If such an image has been manipulated, the malicious code runs along unnoticed. AI makes it easier for attackers to find manipulated images and matching vulnerabilities. In shared cloud environments, moreover, data are encrypted in transit and at rest but are in principle visible in memory during processing — an attacker with access to the infrastructure could capture them there. The protective objective is to execute only unaltered, verified containers and to protect particularly sensitive data during processing as well.

Effect across frameworks

These are the controls and requirements the MHC acts on. The classification shows how much each control loses its effect under AI-enabled attacks.

Effect across frameworks
Number	Title	Classification / Level
ISO/IEC 27001:2022, Annex A 2 controls
A.5.23	Information security for use of cloud services	partially degraded
A.8.31	Separation of development, test and production environments	robust
IT-Grundschutz, MRIS.bd 1 requirements
MRIS.bd.2.3.A2	Using Signed Container Images and Protected Execution Environments	elevated protection needs

All 93 controls in the analysis matrix · All 23 requirements of the module family

Maturity path

Initial: container images signed; vulnerability scan before deployment.
Defined: enforcement through admission controllers in operation; use cases for confidential computing named and documented.
Managed: confidential computing in production for the workloads classified as particularly requiring protection; remote attestation automated.

Measurement and audit evidence

Metric: share of production containers from signed images verified before start-up (target: complete); additionally the coverage of confidential computing for the workloads classified as highly sensitive.
Evidence: admission controller configuration, signature and scan logs, attestation evidence for the protected environments.
Evidence logic (following ISO/IEC 27001, Clause 9): documented? — operations policy, platform configuration; responsible? — platform or operations lead; frequency? — with every deployment, scans continuous; tolerance? — no production container without a valid signature and verification.

Typical mistakes

Images are signed, but the signature is not verified at start-up — the signature is then without effect.
The admission controller is in place but runs only in warning mode; images that are not permitted are reported but not blocked.
Confidential computing is demanded across the board even though it is needed only for a few highly sensitive workloads — unnecessary effort.
Stored images are never re-scanned after the first scan; newly disclosed vulnerabilities remain undetected.

Delimitation and residual risk

Delimitation: concerns the integrity of the containers and the protection of data during processing; the provenance of the contained components is dealt with by MHC-02, and the separation of several tenants by MHC-07.
Residual risk: confidential computing protects the processing but not flaws in the application itself; protected execution environments are not available everywhere and can affect performance.
Applicability: container security is a baseline requirement for containerized workloads; confidential computing is context-dependent and often to be justified as N/A in the Statement of Applicability. Both protective layers are to be planned, assessed and evidenced separately.
ISO/IEC 27002:2022 (indirectly): A.5.23 Information security for use of cloud services; A.8.31 Separation of development, test and production environments.
Framework: C5:2026 OPS-34/35 (Container Management), OPS-32/33 (Confidential Computing), PSS-11; NIST SP 800-190; Confidential Computing Consortium; image signing via Sigstore/cosign.

Implementation in detail

Organizational and technical implementation, implementation examples and the prioritization within the overall programme are described in the Implementation Guide.

Implementation Guide (PDF)Back to the MHC catalog