Many of our customers run Camunda in their own environments—across cloud, hybrid, and self-managed deployments—where our container images are deployed into production clusters, scanned by internal security tooling, and evaluated as part of compliance processes. The security characteristics of those images directly affect your risk posture, and your security is a priority for us.
With that responsibility in mind, we revisited an important question: Can we structurally reduce the inherited risk in our base images for everyone who runs Camunda—not only in our managed SaaS offering, but also in the images you deploy yourselves?
Rather than focusing only on downstream scanning and remediation, we looked at the foundation itself to address risk at its source, reduce recurring vulnerability triage, and create a more predictable security baseline for both our teams and our customers.
In our internal comparisons, Camunda 8 images built on hardened Minimus base images showed 354 fewer known common vulnerabilities and exposures (CVEs) at the base layer than images built on our previous base images over the same period.
The challenge: inherited vulnerabilities in container images
When you deploy Camunda in your own environment, the container images that underpin core components become part of your security and compliance posture. Those images are scanned by your internal tools, reviewed by platform security teams, and often included in audit and risk management workflows. The characteristics of the base image therefore directly influence the volume of findings your teams need to assess and manage.
Container images are built in layers, combining application code with a language runtime, operating system libraries, and supporting utilities. Each layer introduces dependencies, and each dependency can introduce potential vulnerabilities.
Because Camunda services rely on language runtimes and underlying OS libraries, traditional base images can carry a substantial dependency footprint, which in turn can generate a steady stream of inherited CVEs.
Even when images are fully up to date, new vulnerabilities are continuously disclosed against upstream components. These inherited CVEs appear in registry scans, CI pipelines, and cluster-level security tooling across your environment. Many originate from lower-level packages that are not directly used by your application workloads but still surface in dashboards, reports, and policy checks.
For teams running Camunda, this can translate into recurring operational effort: reviewing newly disclosed CVEs, determining whether they apply, documenting risk decisions, and validating updates or mitigations. Even when a vulnerability is not exploitable in context, it still needs to be evaluated and often explained during internal reviews or audits.
Our goal was to reduce that background workload for you by addressing inherited vulnerabilities at their source. By reducing the number of CVEs present in the base layer itself, we can help lower the volume of findings that surface in your scans and make it easier for your teams to focus on issues that genuinely require action.
Our approach: moving to hardened base images from Minimus
To reduce inherited risk at the foundation of our container stack, we transitioned several core base images to hardened images from Minimus. Minimus provides small, security‑hardened container images that reduce the operating system and runtime dependencies included in the image, while remaining compatible with standard language runtimes.
As part of our collaboration, Minimus also operates against clear service-level objectives (SLOs) for vulnerability remediation: when upstream fixes become available for CVEs in their base images, they rebuild and publish updated images within agreed timeframes. That gives us a cleaner, more predictable base layer and shortens the time between a disclosed CVE, a fixed base image, and an updated Camunda 8 image.
For customers running Camunda Self-Managed, this base layer matters because it sits underneath multiple platform components (for example, the Zeebe engine and gateway). If the base layer carries a large dependency footprint, those inherited packages (and their CVEs) show up repeatedly across scans, registries, and cluster policies.
A concrete example: Zeebe’s container image
Starting in Q2 2026, Camunda’s Zeebe container build supports a hardened base option via build arguments. By default, the image uses a hardened OpenJRE base from Minimus (pinned by digest), with a public Temurin JRE fallback available when explicitly selected.
The Dockerfile documents this choice clearly, making the base layer explicit and reproducible. This gives us a practical way to shrink the OS and runtime footprint for JVM-based components without changing application behavior.
Why this matters for Self-Managed customers
Camunda Self-Managed deployments are run in environments our customers control—from Kubernetes clusters to VM-based infrastructure—and are integrated into their internal security, compliance, and vulnerability management workflows. The container images that underpin core components such as Zeebe, Operate, Tasklist, Optimize, and Identity are scanned in registries, evaluated by platform security teams, and often reviewed as part of audit processes.
When inherited CVEs are present in the base layer, they surface across multiple deployed services at once. That can translate into recurring triage cycles, exception handling, policy discussions, and documentation work—even when the underlying vulnerability is not exploitable in the context of a given workload.
By reducing inherited vulnerabilities at the base-image layer, we reduce that background noise across the entire Self-Managed footprint. Customers see fewer alerts in their dashboards, fewer findings to justify during audits, and a clearer signal when a vulnerability genuinely requires attention. The result is a more predictable security baseline across all deployed Camunda components, without requiring changes to application configuration or operational processes.
Scope of the change
We applied this transition to four widely used base images in our environment: Node, OpenJDK, OpenJRE, and PHP. These images underpin multiple services and represent a meaningful portion of our container footprint.
To measure impact, we tracked CVE counts across two parallel tracks: traditional third-party images and hardened images from Minimus. Running scans against both sets of images using Grype, we were able to see the difference in CVEs between the two.
We looked at two distinct measurements:
- How many CVEs were eliminated from our stack as a result of changing our base images?
- How many new CVEs did we avoid (ie, CVEs that would have impacted us with the old base images, but never impacted the hardened images).
Immediate results: 354 fewer vulnerabilities
To answer the first question, we compared the CVEs found by Grype immediately before and after switching base images. Scanning the base images themselves showed us the following results—a total reduction of 354 CVEs. The Node, OpenJRE and PHP components below are all part of the Camunda application and our distributed images, while OpenJDK is used within our internal build process.
| Base image | Date of Change | Original Image CVE Count | Hardened Image CVE Count | CVE Reduction |
| Node | January 2026 | 234 | 1 | 233 |
| OpenJDK | November 2025 | 37 | 2 | 35 |
| OpenJRE | November 2025 | 11 | 0 | 11 |
| PHP | December 2025 | 75 | 0 | 75 |
| Total | 357 | 3 | 354 |
This was not the result of suppressing findings or changing scanner settings. The vulnerabilities simply weren’t present in the base layer.
Ongoing reduction: eliminating the security noise
Security posture is not static. New vulnerabilities are disclosed continuously as upstream projects evolve, and those disclosures can trigger alerts, reviews, patch work, rebuilds, and documentation.
After including the new base images in release versions of Camunda, we’ve monitored the ongoing impact of newly disclosed CVEs over time. A total of 147 new CVEs were disclosed against the traditional base images we used. Of these, only 3 impacted the new hardened images—a 97.9% reduction in new CVEs.
Here’s the per-image breakdown of those ongoing CVEs avoided:
| Base Image | Camunda Component | Original Image New CVEs | Hardened Image New CVEs | CVE Reduction |
| Node | Console Web-Modeler webapp | 42 | 2 | 40 |
| OpenJDK | Operate Tasklist Zeebe Optimize Connectors Management Identity Web-Modeler restapi | 36 | 1 | 35 |
| OpenJRE | Operate Tasklist Zeebe Optimize Connectors Management Identity Web-Modeler restapi | 34 | 0 | 34 |
| PHP | Web-Modeler websockets | 35 | 0 | 35 |
| Total | 147 | 3 | 144 |
The practical impact here is less about a single snapshot and more about the recurring workload that doesn’t have to happen. When inherited CVEs continually appear, they create a recurring operational tax: triage cycles, exploitability assessments, policy discussions, risk documentation, rebuilds, retesting, and coordinated updates across services that share the same base.
By keeping the base layer clean, we reduce that recurring workload. Our teams can spend more time strengthening application-level security controls, improving reliability and performance, and delivering new platform capabilities, instead of repeatedly evaluating inherited OS- or runtime-level findings.
For our Camunda 8 Self-Managed customers, the benefit is similar: fewer inherited CVEs means fewer alerts, fewer documented exceptions, and less time spent proving that a finding is not exploitable in context. The end result is a more predictable baseline and a clearer signal when something genuinely needs attention.
This reflects an important shift: not just managing vulnerability volume, but reducing vulnerability surface area by design.
What this means for you
When you run Camunda, this base layer is integrated into your internal security, compliance, and vulnerability management workflows. By reducing inherited vulnerabilities at the source, we reduce the background noise and deliver key operational benefits to you:
- Reduced operational tax: Fewer inherited CVEs means less time spent on recurring triage, documentation, and policy discussions.
- Cleaner scans: Fewer alerts in your dashboards and compliance reports.
- Faster time to value: Fewer blocking findings in early scans and reviews make it easier to move from evaluation to production, and to roll out updates without repeated rework.
- Clearer signal: Your teams can focus on vulnerabilities that genuinely require attention, not inherited OS-level findings.
Continuing to strengthen the foundation
This base image transition is one example of how we continue to invest in secure-by-design architecture across the Camunda platform. By adopting hardened images from Minimus and reducing inherited vulnerabilities at the source, we have strengthened our container security posture and reduced attack surface across multiple services.
Security is ongoing work. Foundational layers matter—especially when our customers depend on secure, reliable deployments in their own environments—and we will continue to evaluate and improve them as our platform evolves.
