Introduction
Draft ETSI EN 304 635 is one of the standards being developed to support the Cyber Resilience Act (CRA). It covers virtualisation and container execution stacks: virtual machines, container environments, and the systems used to manage them.
In the open source world, this means technologies and ecosystems around Docker, Podman, containerd, CRI-O, Kubernetes, KVM/QEMU and similar solutions.
The draft has the interesting point of defining more than requirements for individual components. It also defines assumptions about the environment in which they operate and how their security risk is assessed.
A few points are worth highlighting.
- First, the draft distinguishes the product from its Operational Environment (OE). Clause 4.3.3 states that compliance of Operational Environment components with CRA essential requirements may be presumed when the corresponding harmonised standards are applied. Where no harmonised standard exists, the system or product integrator should ensure equivalent security measures. The question is what to do if the Operational Environment components are open source…
- Second, clause 5.1 introduces three security risk profiles. Products need to be assigned to one of these profiles. This may affect which use cases and applications a product can support.
The concept of a “representative use case” is important here. Under clause 5.1.2.1, the product context needs to have an equivalent or higher security risk profile than the representative use case to which it is assigned, and the manufacturer needs to justify this assignment in the conformity assessment documentation.
These assumptions matter because compliance is not only about whether a container runtime or hypervisor implements a particular security feature. It also depends on how the product is used, what it depends on, and the security context in which it operates.
While reviewing the draft, we also identified several points where the requirements could be clearer or easier to assess in practice. In particular, our comments cover the boundary between the OS and container stack, requirements containing multiple “shall” statements, vulnerability management, SBOM interoperability and representation of vendor patches when applied to used open source components (not covered!).
Our standardization comments are reproduced below verbatim.
Note: this work was possible thanks to a grant from the CYBERSTAND program.
Implementation
Nous soumettons nos commentaires en anglais, le texte principal de la norme étant en anglais, tout comme nos propositions de modification.
Draft ETSI EN 304 635 V1.0.1 (2026-06)
- Comment 1 – Clause 4.2.3.1 – Scope of OS mechanisms
The OS implementation is out of scope, but the current wording can be read as including kernel implementations of namespaces, seccomp and cgroups. The scope should instead identify the user-space components interacting with these mechanisms.
=> Proposed change:
Replace:
“Enforcement modules that manage container isolation, resource control, and sandboxing through OS or application-level mechanisms (e.g. namespaces, microVMs, seccomp, cgroups)”
with:
“Enforcement modules that manage container isolation, resource control, and sandboxing through OS or application-level mechanisms (e.g. user-space tools interacting with the implementation of namespaces, seccomp and cgroups; microVMs).”
- Comment 2 – Clause 4.2 / 4.2.5.1 – Components using the same OS mechanisms
Applications can use mechanisms such as seccomp, namespaces or cgroups without being part of or a dependency of the CES. This should be explicit in the scope.
=> Proposed addition:
“Out of scope are applications that use the same OS security mechanisms as containerization mechanisms, but for purposes unrelated to the operation of the CES, for example applications using seccomp for selective blocking of system calls.”
- Comment 3 – Clause 4.3.2 – Use of “should”
All conditions in this clause use “should” and are therefore not normative requirements. If these conditions are required for conformity, they should be part of normative requirements.
=> Proposed change:
Integrate the applicable conditions from clause 4.3.2 into the corresponding normative requirements using “shall”.
- Comment 4 – Clause 5.3.2.3 – REQ-CE-AUTH-002 contains two requirements
REQ-CE-AUTH-002 contains two “shall” conditions that can be implemented and assessed separately.
=> Proposed change:
Split REQ-CE-AUTH-002 into two requirements, with one “shall” condition in each.
- Comment 5 – Clause 5.3.2.5 – REQ-CE-CONF-001 does not identify what is separated
REQ-CE-CONF-001 does not specify what must be separated: container images, OS users, or another resource or actor.
=> Proposed change:
Clarify the subjects between which separation is required.
=> Proposed NOTE:
“NOTE: Such separation may be implemented using operating-system user-level access control granularity and file permissions.”
- Comment 6 – Clause 5.3.3.5 – Multiple “shall” conditions
REQ-CO-CONF-001 and REQ-CO-CONF-002 contain multiple “shall” conditions. Independently implementable or assessable conditions should be separate requirements.
=> Proposed change:
Split independent “shall” conditions into separate requirements. If the conditions form one logical flow, make this relationship explicit.
- Comment 7 – Clause 5.3.3.6 – Multiple requirements in REQ-CO-UPD-001
REQ-CO-UPD-001 contains separate steps that can be implemented and assessed independently.
=> Proposed change:
Split REQ-CO-UPD-001 into two requirements.
- Comment 8 – Clause 5.4.1 – REQ-ASSUR-VULM-001 cannot always be fulfilled
There is necessarily a delay between discovery of a vulnerability and availability of a mitigation. The current requirement can therefore become impossible to fulfil as soon as a new exploitable vulnerability is disclosed.
=> Proposed replacement:
“REQ-ASSUR-VULM-001: The product shall not contain unmitigated known exploitable vulnerabilities at the time of release.”
Add:
“REQ-ASSUR-VULM-002: The product shall have automatic search for available updates activated by default.”
- Comment 9 – REQ-ASSUR-SBOM-001 – Vendor patches to open-source components
A vendor can use a patched open-source component while keeping its upstream version identifier. The version alone is then insufficient to identify the actual source or determine its vulnerability status.
=> Proposed addition:
“For open-source components, if the manufacturer uses a version modified from the upstream version, the SBOM shall list all applied patches or provide a provenance location from which the modified version and its modifications can be identified, for example a public source code repository.”
- Comment 10 – REQ-ASSUR-SBOM-001 – SBOM interoperability
“Machine-readable” does not guarantee interoperability. A vendor-specific format could satisfy the requirement while being unusable by standard SBOM and vulnerability scanning tools and then the scan in assesment becomes technicall unfeasable.
=> Proposed replacement:
“The SBOM shall be provided in a machine-readable, interoperable format based on a recognized SBOM standard, such as SPDX or CycloneDX.”
- Comment 11 – REQ-ASSUR-SBOM-003 – Components not present in the CES
The current wording can be read as requiring every listed component type to be present in the CES.
=> Proposed replacement:
“For CES, the SBOM shall include, if the given component is part of the CES, at minimum:”
- Comment 12 – Clause 6.5.1.1 – Informative reference used normatively
Clause 6.5.1.1 requires following a procedure from prEN 40000-1-3 [i.13], but [i.13] is an informative reference. A reference required to fulfil a normative requirement is effectively normative.
=> Proposed change:
Move prEN 40000-1-3 to the normative references, or change clause 6.5.1.1 so that conformity does not depend on it.
