Your platform team runs its quarterly container scan, and the Camunda images come back with findings, like every other image in the registry. By the next morning, the questions have reached your vendor. Which findings matter? When will they be fixed? Who is accountable for the ones buried in third-party components?
Those questions get harder to answer every quarter. The CVE Program published 48,244 common vulnerabilities and exposures (CVEs) in 2025 and 35,872 in the first half of 2026 alone, according to its published metrics. Discovery keeps getting faster, too, because language models make flaws cheaper to find for defenders and attackers alike. Any product built on open source components shows up in a scanner eventually, so be skeptical of a vendor that promises otherwise. What you can hold a vendor to is less noise at the source, an honest assessment of what remains, fixes for every supported version, and evidence you can check yourself.
Fewer findings, starting with the base image
Most scanner findings in a container image don't come from the application. They come from the layers underneath it: operating system packages, language runtimes, and utilities that ship in the base image whether the application uses them or not.
Since late 2025, Camunda has moved its core container images onto hardened, minimal base images, starting with 8.9 and backported to 8.8 and 8.7. Measured with the open source scanner Grype, the switch removed 354 known CVEs at the base layer and left three. In the months that followed, 147 new CVEs were disclosed against the old base images, and only three of them affected the hardened ones, a 97.9% reduction. None of that came from suppressing findings or changing scanner settings, as the full breakdown shows.
Camunda 8.10 goes further. The Orchestration Cluster, which runs your processes, now ships only as one unified image, and the separate component images are retired, so there's one artifact to scan and track. The release also completes the move away from bundled third-party infrastructure images. In August 2025, Bitnami moved many public images to a legacy repository that no longer receives security patches. Camunda offered patched enterprise images for PostgreSQL, Elasticsearch, and Keycloak in 8.8, disabled those sub-charts by default in 8.9, and removes them from the Helm chart in 8.10, so each of those services runs on infrastructure its own vendor maintains.
The release tightens defaults, too. The connector secret filter now runs in strict mode out of the box, so a connector resolves a secret only in the field that declared it at modeling time. Authentication for the Orchestration Cluster, Camunda Hub, and Optimize now runs through one shared security library instead of separate identity stacks. And the legacy component APIs deprecated in 8.8 are gone, replaced by the authenticated Orchestration Cluster REST API.
Finding vulnerabilities before anyone else does
Camunda scans its source code, open source dependencies, and released container images continuously, and dependency upgrades arrive as automated pull requests. Monitoring covers every released version, including older ones still running in customer environments.
Penetration testing adds an attacker's point of view. The Camunda Trust Center holds management summaries of recent tests covering Camunda 8, connectors, the Software as a Service (SaaS) infrastructure, and AI features, among others.
Outside reports get the same attention. Researchers and customers can file a Security Report ticket in Camunda's Jira, visible only to the reporter and Camunda staff, as described on the Camunda security page.
Camunda's information security team didn't wait for scanners or outside researchers to find the next flaw. In 2026, it began running AI-assisted security assessments against Camunda's own code, on its own initiative. Models audit the source, run dynamic tests, and write proofs of concept, while security engineers scope each engagement, review every finding, and decide what goes to engineering.
Engineering is testing earlier, too. A dependency vulnerability check runs on pull requests, so a change that pulls in a known-vulnerable library gets flagged before it merges, and teams can bring InfoSec in while a feature is still being built. Camunda's source code is public, and anyone with a capable model can go looking for flaws in it. The aim is to find them first, before a release rather than after it.
Separating the findings that matter from the rest
A CVE in a library doesn't make Camunda exploitable through it. Often the vulnerable code never runs, or it runs only in a configuration you don't use. Every report gets a root cause analysis and an assessment of real risk and impact before it gets a priority. Models now help draft those assessments, and a security engineer reviews each one before it reaches a customer.
You can see that assessment in the notices. When Camunda patched two Eclipse Jetty vulnerabilities in Optimize in September, the notice stated that the default Optimize configuration wasn't exploitable for one of them, because it applied only with HTTP/2 explicitly enabled. The FEEL notice spelled out exactly which permissions an attacker would need. With details like these, your security team can rank a finding in minutes instead of opening an investigation.
When your own scanner flags something, start by scanning the current patch release, because many findings against older builds are already fixed. Then send the scan report to Camunda Support with the version you run. Camunda's security team assesses each finding and tells you whether it affects Camunda and when a fix is coming.
Fixes for every supported version
Enterprise customers get 18 months of standard support for each minor release, which covers at least the three most recent minor versions. Camunda's release policy targets a patch release every month for every supported version, security fixes included, and urgent fixes ship outside that cycle when needed. Community users receive fixes in the next alpha or minor release. We proactively scan CVEs in versions under ESUP and issue security notices if they are affected. In the case a customer reports a vulnerability, Camunda treats it as a bug under the service levels agreed in that customer's contract.
How a fix reaches you depends on how you run Camunda. In Camunda 8 SaaS, Camunda patches the fleet. For the FEEL flaw, every SaaS cluster on every supported version was updated on September 12 and 13, and the public notice followed on September 21, once patch releases for Self-Managed were ready. For critical issues, Camunda can update SaaS clusters immediately, without advance notice. With auto-updates enabled, routine patch releases reach your clusters without any action on your side.
In Self-Managed, your team applies the patch release, which makes staying on a supported version the most effective security control you own. The FEEL fix shipped for 8.9, 8.8, and 8.7. Versions past their support window remain affected.
Transparency you can plan around
Camunda's security page states the goal plainly: establish trust through transparency. In practice, that means a public security notice once a fix or a practical workaround is available. Each notice lists the affected components and versions, the fixed releases, and the severity, with a link to the CVE or GitHub security advisory where one exists. An RSS feed delivers notices as they're published, and Camunda 7 has its own notices page.
For your own analysis, Camunda publishes CycloneDX software bills of materials (SBOMs), listing every direct and transitive third-party dependency for Camunda 8 components. The source code for Camunda 8 and connectors is public on GitHub.
Assurance you can verify
Product practices sit inside a company security program that outside auditors review. Camunda holds ISO 27001 and ISO 27018 certificates and has a SOC 2 Type II report for Camunda 8 SaaS. Under a non-disclosure agreement, the Trust Center also provides the vulnerability management procedure, the software development policy, incident response drill summaries, business continuity test results, a shared responsibility model for SaaS, and the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire (CAIQ), the standard questionnaire many security reviews start from.
Security for what runs on the platform
Patching protects the platform. Agents need controls that live in the process, not just in the prompt. Camunda orchestrates agents from the outside, as participants in an end-to-end process, and from the inside, with enforceable steps between an agent’s reasoning and its actions. Before an agent calls a payment API, the process can require a policy check or a human approval. Camunda records every action and decision automatically, so when a regulator asks why something happened, you have the answer.
As companies re-engineer their processes around AI, security teams also want to know what the platform lets AI agents do. According to the 2026 Camunda State of Agentic Orchestration and Automation Report, 71% of organizations use AI agents, yet only 11% of use cases reached production last year. Getting the rest into production means answering the security team's questions about what those agents can touch.
Camunda answers those questions in the process itself. Outer orchestration (outside the agent) coordinates agents, people, and systems across the end-to-end process. Inner orchestration (inside the agent) puts enforceable steps between an agent's reasoning and its actions, so before an agent calls a payment API, the process can require a policy check or a human approval. Camunda records every action and decision automatically, which gives auditors the same evidence trail for agents that they expect for the rest of the business.
CVE counts will keep climbing. Judge a vendor by how much of that noise it removes before it reaches you, and by how quickly it closes the rest. Ready to orchestrate? Start your review at the Camunda Trust Center, and bring anything it doesn't answer to your Camunda account team.
