kms

# Security policy

KMS is security-sensitive software. Please report suspected vulnerabilities privately.

## Supported versions

Only the latest patch release in the current minor series receives security fixes.

| Version | Supported |
|---|---|
| 0.1.x | yes |
| < 0.1 | no |

## Reporting a vulnerability

Email [hello@parlant.co](mailto:hello@parlant.co) with the subject `KMS security report`.

Do not open a public issue with exploit details, secret material, or production incident data. We will acknowledge the report, coordinate investigation and remediation privately, and agree on disclosure timing with the reporter.

A good report includes:

- affected version/commit;
- deployment mode: crypto-only, embedded, standalone, or remote;
- database backend: SQLite or PostgreSQL;
- RMK provider: local, StackIT, AWS, or GCP;
- whether HTTP API/session/factors are involved;
- minimal reproduction steps;
- impact and preconditions;
- logs only after removing secrets.

Never include:

- plaintext secrets;
- ciphertext from production data;
- bearer tokens/session secrets/API tokens;
- passwords/passphrases/factor codes;
- RMK key files/cloud credentials;
- fallback private keys.

## Security-sensitive defaults

Production deployments should:

- set `KMS_SESSION_HASH_KEY` to a high-entropy secret;
- disable crash dumps with `ERL_CRASH_DUMP_BYTES=0` or `ERL_CRASH_DUMP_SECONDS=0`;
- use explicit RMK config;
- protect SQLite DB/WAL/SHM files or PostgreSQL credentials;
- disable request-body logging for KMS HTTP routes;
- serve remote KMS only behind TLS or trusted private networking.

See [Security docs](docs/security.md).