Kafka CVE coverage without a Confluent-scale contract

The Apache Kafka project maintains only its most recent releases. Each minor version's support window closes when the next one ships: Kafka 3.8 reached end of life on 6 November 2024, the day 3.9 was released. Regulated teams rarely upgrade that often, so most production clusters sit on a version upstream no longer patches.

The auditor's question is simple. When an advisory affects the version you run, how do you know, and what did you do about it? A cluster on an unmaintained version has no good answer. The usual commercial answer, Confluent Platform, is Apache Kafka plus components under three separate licences, with enterprise features behind a paid subscription. Teams that do not use Schema Registry, ksqlDB or Control Center end up paying for platform features to get a patch trail.

The controls themselves are clear about scope. PCI DSS 4.0 Requirement 6.3.3 applies wherever the cluster carries or touches cardholder data, and SOC 2 CC7.1 is joined by the availability criteria, because Kafka usually sits underneath everything else. An unsupported version fails that evidence test before anyone looks at a specific CVE.

Self-managed Apache Kafka carrying regulated data, such as payments, health records or trading events, on versions between 2.8 and 3.9, in ZooKeeper or KRaft mode. Either there is no support contract, or there is one sized for more platform than the deployment uses.

The controls in play are usually PCI DSS 4.0 Requirement 6.3.3, SOC 2 CC7.1 and, for EU financial entities, the ICT risk-management obligations under DORA. How exposed the cluster is depends heavily on whether it is reachable beyond its own network, and the assessment should say which applies.

Upgrade to a maintained release and keep upgrading. Kafka's protocol compatibility means clients generally keep working, but the cadence is fast, and clusters still on ZooKeeper must migrate to KRaft on 3.9 before reaching 4.x.

Buy Confluent Platform. It brings a longer support window and its own components. It fits teams that use those components; otherwise it is a platform bought for a patch trail.

Use a managed Kafka service. The provider patches the brokers, inside its own platform, on the versions it offers.

Patch the Apache Kafka you already run through a third-party provider, with documentation an auditor can check.

OSSeva backports CVE fixes onto the Apache Kafka version already in production, from 2.8.x to 3.9.x, and covers the current 4.x line too. OSSeva Patch includes quarterly CVE patches for broker and client libraries, signed artifacts through the OSSeva registry and vulnerability disclosure notifications. It is the Apache distribution, not a fork, so a patched 3.8 stays wire-compatible with the 3.8 your clients expect. Where the better answer is to move to 3.9 and migrate to KRaft, OSSeva says so.

The audit evidence sits in OSSeva Assure: a compliance attestation package, a cluster configuration audit, and a throughput and latency review. Assure and Operate also cover Kafka Connect and Kafka Streams patches, with connector compatibility checked against each patched broker version.

For teams that also want the brokers run for them, OSSeva Operate adds 24/7 broker and consumer-lag monitoring, capacity planning and a 15-minute P1 incident response SLA, on your own clusters.