There is no published release. Nothing from this repository goes to a package registry, and there is no version line to backport to. Security fixes are made on main.

Do not open a public issue. Use the repository's private GitHub Security Advisory form. If that is unavailable, email shawn@zsumz.com with [kafka-benchmarks security] in the subject.

Include the affected revision, the smallest practical reproducer, the security impact, and any known mitigations. Do not include live credentials, broker endpoints you do not own, or third-party private data.

You should receive an acknowledgement within three business days and an initial triage assessment within seven. Those are coordination goals, not a service-level agreement: this is a small project, and stating a target honestly is more useful than promising a response time nobody is staffed to guarantee.

Please allow a reasonable remediation and coordinated-disclosure window. The maintainer will credit reporters who want attribution and will keep reporters informed when a fix or advisory is ready.

In scope: the control plane, the adapters and the shim in this repository, the scripts, the evidence-sealing path, and the CI workflows. The interesting failure modes here are integrity rather than confidentiality — anything that lets a bundle claim an experiment, an environment, a digest, or a verification result that does not match what actually ran is a security issue even when no secret is exposed. So is anything that causes the harness to execute a command it was not configured with, including through a crafted scenario file or a crafted adapter response.

Out of scope for this repository, and better reported to their own maintainers: Apache Kafka broker vulnerabilities, librdkafka, third-party dependencies, and the public kafkars, kafka-driver, and kafka-wire repositories. Benchmark results themselves are not confidential, and a bundle sealed on a developer machine is expected to record that machine's hostname and toolchain.