Report privately, through GitHub's private vulnerability reporting. That opens a draft advisory visible only to the maintainers.

Please do not open a public issue, a pull request, or a discussion for something you believe is exploitable. A public report starts a clock on every deployment running the affected version, and there is no way to take it back.

A report is easier to act on with:

• the version or commit, and which features were enabled (kafka, s3, coordination-nats, coordination-dynamodb, …);
• what an attacker gains, and what they need in order to reach it;
• the smallest reproduction you have. A failing test against spate-test's mocks is ideal, but a description of the sequence is enough.

You do not need a working exploit, and you do not need to be sure. A report that turns out to be a non-issue costs one reply; an unreported one can cost data.

Response targets for a single-maintainer project:

You will be credited in the advisory unless you ask not to be. There is no bug bounty.

This framework is a library that runs inside your own pipelines.

In scope

• A way to make the pipeline lose or duplicate data in a manner the at-least-once contract forbids, most importantly committing a source watermark past unacknowledged data.
• Memory unsafety, or a panic reachable from record data rather than from configuration.
• Credentials or record contents leaking into logs, metric labels, or error messages.
• A parser that can be driven to unbounded memory or CPU by input from the source; record payloads and object-store responses are the interesting ones.
• Anything that lets configuration under an attacker's control execute code.

Not in scope

• Vulnerabilities in the systems this framework connects to. Report those to Kafka, ClickHouse, NATS, or your object-store vendor.
• Resource exhaustion from configuration you chose, such as setting a queue capacity larger than available memory.
• Advisories against a dependency where the vulnerable code path is not reachable from this framework. Those are still worth reporting, and are triaged as maintenance rather than as an incident. Every advisory this project has accepted is recorded where the tool reporting it is configured, in deny.toml for cargo-deny and in an osv-scanner.toml beside each lockfile, with its reason and the condition for removing it.
• Anything requiring an attacker who already has the ability to run code in your pipeline process.

The newest 0.x minor.

A fix lands on main and ships as the next patch of that minor. There are no maintenance branches and no backports by default.

If a specific older version blocks you, say so on the advisory and a branch can be cut from its tag. That is a conversation, not a standing commitment.

All crate versions in lockstep, so "the newest minor" means the same thing for every one of them.

Each control below is recorded where it is enforced, in deny.toml, in the workflow that runs it, or in the script it calls:

• Cargo.lock and package-lock.json are committed, and CI builds --locked / npm ci, so a build cannot resolve a different graph. Two invocations are outside that and are documented where they appear.
• Every GitHub Action is pinned to a full commit SHA, and zizmor fails CI if a pin, a token scope, or a checkout credential setting regresses.
• cargo deny check advisories runs on every pull request and nightly, so an advisory published against a crate already in the lockfile is caught within a day. This covers the Rust tree; the documentation site's npm dependencies are not gated in CI.
• Dependency updates arrive as reviewed pull requests after a soak period on the registry: 7 days, or 14 where a breaking change can hide. Security updates bypass the soak entirely.
• npm lifecycle scripts are disabled at install time, in both places npm runs.