sqlite-backups handles live production data and credentials (S3 secret keys, database paths), so security issues are taken seriously.

Please do not open a public issue for security vulnerabilities.

Report privately through GitHub's Security tab → Report a vulnerability (also known as private vulnerability reporting). If you cannot use that flow, email the maintainer directly (address published on the GitHub profile) and encrypt sensitive details if a PGP key is available.

Please include:

• Affected version/commit and configuration.
• Steps to reproduce, ideally minimal.
• Impact assessment — e.g. "secret key exposure via X", "artifact tampering via Y".

You can expect an acknowledgement within 5 business days and a fix coordinated through a private advisory. We will credit you in the advisory unless you prefer to stay anonymous.

• The daemon opens the live database read-only; it never writes to the source database.
• Snapshots are written atomically (temp file + rename), so a crash can never leave a half-written artifact under its final name.
• The S3 SigV4 signer is stdlib-only; secret keys exist only in the config file. Keep the config file readable by the daemon user only (chmod 600). The systemd unit ships with UMask=0077.
• The hardened systemd unit drops privileges and capabilities — see deploy/sqlite-backups.service. When deploying, set User=/Group= to the least-privileged account that can still read the live database.