dataflow-rs 4.0.0

# Security Policy

## Supported Versions

Maintainers issue security fixes for the latest `4.x` minor release. Older
releases do not receive backports; upgrade to the current release.

| Version              | Supported |
|----------------------|-----------|
| Latest 4.x minor     | Yes       |
| < 4.0                | No        |

This policy covers all four published artifacts, which share a version number:

- [`dataflow-rs`](https://crates.io/crates/dataflow-rs) (crates.io)
- [`dataflow-rs-derive`](https://crates.io/crates/dataflow-rs-derive) (crates.io)
- [`@goplasmatic/dataflow-wasm`](https://www.npmjs.com/package/@goplasmatic/dataflow-wasm) (npm)
- [`@goplasmatic/dataflow-ui`](https://www.npmjs.com/package/@goplasmatic/dataflow-ui) (npm)

## Reporting a Vulnerability

**Do not open a public issue for security reports.**

Use GitHub's private vulnerability reporting:
[Report a vulnerability](https://github.com/GoPlasmatic/dataflow-rs/security/advisories/new).
This opens a private thread visible only to the maintainers.

If you cannot use GitHub advisories, email **shankar@goplasmatic.io** with
`[SECURITY] dataflow-rs` in the subject line.

Include:

- The affected version and artifact (crate, wasm, or UI)
- A description of the issue and its impact
- Steps to reproduce, with a minimal workflow JSON or code sample
- Any known mitigations

### Response Timeline

- **Acknowledgement** within 3 business days
- **Initial assessment** (reproduction and severity) within 10 business days
- **Fix and release** within 30 days of a confirmed report, or sooner for high-severity issues
- **Credit** in the release notes and advisory, unless you prefer otherwise

Maintainers coordinate disclosure timing with you and publish details after a
fix ships.

## Scope

In scope:

- Memory-safety or panic-based denial of service in the engine, reachable from
  workflow JSON, message payloads, or the wasm bindings
- JSONLogic evaluation that escapes its intended sandbox (reading or writing
  outside the `data` / `metadata` / `temp_data` context and the engine-held
  secret store that `{"secret": "name"}` reads)
- A secret value reaching a serialized message, a trace, an error, an observer
  event or a log line
- Unbounded resource consumption triggered by attacker-controlled input, such as
  parser input in `parse_json` / `parse_xml`
- Vulnerabilities in the published npm packages, including the bundled wasm

Out of scope:

- Vulnerabilities in dependencies with an existing RUSTSEC advisory. The
  `cargo-deny` job tracks these (see [`deny.toml`](deny.toml)). Open a normal
  issue if you spot one we have missed.
- Behaviour of custom `Function` implementations you supply. The
  engine executes registered functions by design; treat workflow definitions as
  trusted configuration.
- Resource exhaustion from workflows you authored yourself. Workflow JSON is
  configuration, not untrusted input; if you accept workflow definitions from
  untrusted parties, you must validate and sandbox them yourself.

## Trust Model

Dataflow-rs treats **workflow definitions as trusted configuration** and
**message payloads as untrusted data**. Conditions and mappings are JSONLogic
expressions with no filesystem, network, or process access, evaluated only
against a message's own context plus the secrets the host hands the engine
through `ExprEngineBuilder::secrets` (`Secrets`), which expressions read with `{"secret": "name"}` and the
engine never records. Reports that depend on an attacker being able
to supply arbitrary workflow JSON fall outside this model, but we are still
interested in hearing about them. Say so in your report and we will assess it.