This policy covers the ditto CLI, the HTTP service exposed by ditto serve, and the supporting Go and Python SDKs in this repository.

It does not cover:

• hardening your source database
• network policy or IAM configuration around the host running ditto
• OS-level security for the machine that owns the Docker runtime and dump files

Do not open a public GitHub issue for security vulnerabilities.

Email [email protected] with:

• a clear description of the issue
• steps to reproduce it
• the affected ditto version or commit
• any logs, requests, or proof-of-concept details needed to verify it

You will receive a response within 5 business days. If the issue is confirmed, we will coordinate a fix and a disclosure timeline with you.

Source database passwords and server tokens can be resolved at runtime from:

• env:VAR
• file:/path/to/secret
• arn:aws:secretsmanager:...

Secrets are not persisted in ditto's SQLite metadata store. They are resolved only when needed and cached in memory for a short period.

Copy containers bind to the local host only. They are intended to be reachable by processes on the same machine running ditto, not by arbitrary remote clients.

If you expose ditto serve, protect it with a bearer token and network controls appropriate for the environment.

Copies are restored from a dump file. If that dump contains sensitive data, any copy created from it contains the same data until obfuscation is applied.

The safest operating model is:

1. configure obfuscation rules
2. run ditto reseed
3. distribute or restore only the obfuscated dump

That keeps raw production data out of developer shells, CI jobs, and restored copies.

Access to the Docker socket is effectively host-level privilege. Anyone who can control the runtime can control ditto copy containers and, by extension, the host operating them.

Treat the machine running ditto as sensitive infrastructure:

• restrict access to the Docker socket
• encrypt local storage that contains dump files
• limit shell access to trusted operators
• rotate source credentials and server tokens when operator access changes

Security fixes are applied to the latest released version. If you are running from an unreleased commit, upgrade to the latest release first when validating whether a vulnerability still applies.