Understanding OS-level CVEs in Docker images built with Mendix Portable Runtime

Issue

Security scans of Docker images built from Mendix Portable Runtime packages report operating-system Common Vulnerabilities and Exposures (CVEs), including Ubuntu-related findings. Clarification is required on why these findings appear, who owns remediation, and which mitigation actions reduce exposure.

Environment

• Applications deployed with Docker

Cause

Mendix Portable Runtime does not include an operating system or Java runtime. The Mendix Portable Runtime package is a ZIP archive that contains Mendix Runtime, application model content, Java dependencies, and configuration files.

During containerization, the operating-system layer is inherited from the Java base image defined in the Dockerfile FROM instruction. The guide Reference Guide for Docker Deployment uses eclipse-temurin:21-jdk as an example template, not as a required base image. Tags such as eclipse-temurin:21-jdk-jammy resolve to Ubuntu-based layers, so Ubuntu CVEs appear in scan results.

Container scanners evaluate the full image filesystem, including inherited operating-system layers, and not only Mendix Portable Runtime application content.

Solution/Workaround

Use the following process to classify findings, assign ownership, and reduce the operating-system CVE surface.

1. Apply the vulnerability ownership model:
   • Operating-system and base-image package CVEs: base-image maintainer publishes fixes; customer rebuilds and redeploys.
   • Java runtime image CVEs: image publisher publishes refreshed image; customer adopts image and rebuilds.
   • Mendix Runtime and Java archive (JAR) CVEs: Mendix provides runtime updates; customer upgrades Mendix Portable Runtime version and redeploys.
   • Platform-supported module and library CVEs: Mendix provides fixes in supported versions; customer updates modules and redeploys.
   • Custom Dockerfile additions: customer owns remediation.
2. Applying OS package upgrades at build time. 
   You can reduce the attack surface by running OS package upgrades during the Docker build. For example:

#Ubuntu-based:
FROM eclipse-temurin:21-jdk-jammy
RUN apt-get update && apt-get -y upgrade && rm -rf /var/lib/apt/lists/*

or

#Red Hat UBI-based:
FROM eclipse-temurin:21-jdk-ubi9-minimal
RUN microdnf update -y && microdnf clean all

3. Choosing a hardened or commercially supported base image. 
   Mendix Portable Runtime gives users full freedom and flexibility to choose their own Java base image. Users are not required to use the example image from the documentation. They can use any compliant JDK 21 image, including commercially supported and hardened options such as Red Hat's hardened OpenJDK images, which offer managed CVE patching and formal support:

• Red Hat Hardened Images — Build and Deploy Secure Minimal Containers
• Red Hat OpenJDK image CVE reporting
  This flexibility is particularly valuable for environments with strict InfoSec requirements, as it allows alignment with users organization's approved image catalogue and patching cadence.

4. Mendix Portable Runtime is a flexible and straightforward method for isolated server-based deployments. It is specifically designed to give customers full control over their base image — a key security advantage over the standard Docker-based deployment approach. Upgrading to a more recent Mendix version (e.g., 11.6.7 or 11.12) may also eliminate several CVEs reported under /mendix/lib/runtime/bundle. Updating Marketplace modules to their latest supported versions may additionally resolve vulnerabilities under /mendix/app/model.

Additional information

• Mendix Portable Runtime
• Reference Guide for Docker Deployment