Security

SafeStream Enterprise runs entirely inside your network. We never receive your records, and the software sends us no telemetry.

How the product protects your data

• Fail closed. A record that can't be processed goes to an access-restricted dead-letter topic. If the brokers don't acknowledge a batch, the connector exits without committing, and restarts from the last safe point. An unredacted record never reaches the clean topic.
• Hostile XML is refused. Any XML document with a DTD is rejected, which blocks entity-expansion bombs and XXE attacks. Nesting depth is capped for both JSON and XML.
• Keys and headers too. Kafka message keys and header values are redacted, not just message bodies.
• No content in logs. Operational logs and metrics carry topics, offsets and counts, never payloads.
• Hardened runtime. A distroless image with no shell, running as non-root on a read-only filesystem with all Linux capabilities dropped. A default-deny network policy allows traffic only to your Kafka brokers and DNS.
• Verifiable releases. Container images are published with an SBOM and build provenance. The redaction engine is open source, so you can read and test it.

Reporting a vulnerability

If you believe you've found a security issue in SafeStream, email security@safestreamdata.com. Please include:

• the affected version or component,
• steps to reproduce the issue,
• the impact you think it has.

We aim to acknowledge reports within 3 business days and to keep you updated until the issue is fixed. Please give us reasonable time to release a fix before sharing details publicly.

We won't take legal action against research done in good faith that avoids privacy violations, data destruction and service disruption, and that only tests systems you own or are authorised to test.

Machine-readable contact details: security.txt