How Databasus enforces security?

Databasus is responsible for sensitive data:

  • it accesses your DB;
  • it backs it up (meaning makes a copy of data);
  • it keeps credentials to be able to access your DB on a regular basis;
  • it saves backups in your S3 or other cloud storages (if you enable it);

Therefore, there is a main priority for Databasus to be enterprise-level secure and reliable.

To make sure:

  • sensitive data is never exposed and always encrypted;
  • backups are encrypted and useless even if someone sees them in the cloud storage;
  • Databasus doesn't even receive access to DB with write or update access;
  • all actions are logged and can be audited;

All these steps protect your data. As you know, there is no 100% secure system, but we do our best to make it as secure as possible. Even in case of hacking, nobody will be able to corrupt your data.

Databasus enforces security on three levels:

  1. Sensitive data encryption;
  2. Backups encryption;
  3. Read-only access to DB.

Level 1: sensitive data encryption

Internally, Databasus uses PostgreSQL DB to store connection details, configs, settings of notifiers and storages (S3, Google Drive, Dropbox, etc.).

Any sensitive data is encrypted. For example:

  • passwords
  • tokens
  • webhooks with secrets

So in DB Databasus keeps only hashes or encoded values. For encryption is used AES-256-GCM algorithm. Also, despite the encryption, those values are never exposed via API or UI.

The secret key used for encryption is stored on local storage (./databasus-data/secret.key by default) and is not present in the DB itself. So DB compromise doesn't give access to sensitive data.

Level 2: backups encryption

Each backup file is encrypted on the fly during backup creation. Databasus uses AES-256-GCM encryption algorithm, which ensures that backup data cannot be read without the encryption key and any tampering is detected during decryption.

Backups flow through this pipeline:

PostgreSQL pg_dump → Compression → Encryption → Cloud Storage

Each backup gets its own unique encryption key derived from:

  • Master key (stored in ./databasus-data/secret.key)
  • Backup ID
  • Random salt (unique per backup)

Result: Even if someone gains access to your cloud storage (S3, Google Drive, etc.), they cannot read the backups without your master key.

Level 3: read-only access to DB

Databasus enforces the principle of least privilege - it only needs read access to create backups, never write access. This protects your database from accidental or malicious data corruption through the backup tool.

Before accepting database credentials, Databasus performs checks across three levels:

  1. Role-level: Verifies the user is NOT a superuser and cannot create roles or databases
  2. Database-level: Ensures no CREATE or TEMP privileges
  3. Table-level: Confirms zero write permissions (INSERT, UPDATE, DELETE, TRUNCATE, etc.)

The database user must pass all three checks to be considered read-only. If any write privilege is detected, Databasus will warn you.

Databasus suggests creating read-only users for you with proper permissions:

  • Grants SELECT on all current and future tables
  • Grants USAGE on schemas (but not CREATE)
  • Explicitly revokes all write privileges

Result: Even if Databasus is compromised, server is hacked, secret key is stolen and credentials are decrypted, attackers cannot corrupt your database.

🛡️ Security & reliability engineering

Databasus works with sensitive data, so preventing vulnerabilities, unauthorised access and data leaks is a primary concern. We invest in this on both sides of the system: in the code itself (permission checks, encryption, careful handling of secrets) and in the infrastructure around it (dependency analysis, CVE response, DevSecOps practices). The pipeline below runs automatically on every commit and PR — no single layer is enough on its own, but together they reduce the chance of vulnerable code, unsafe dependencies, broken images, or non-restorable backups reaching a release.

Static analysis

Static analysis runs in several independent passes. CodeQL scans the full codebase for security issues. CodeRabbit reviews every PR and runs gitleaks for secret scanning and semgrep for security rules inline. Dockerfiles and CI workflows get extra rules of their own (pinned action references, least-privilege permissions, suspicious base images), so insecure patterns are flagged before they ever merge.

On top of these per-PR checks, Codex Security from OpenAI runs regular, deeper audits of the whole codebase. It is a separate program that catches architectural and cross-cutting issues which narrow PR-time scans miss.

Dependency management

Dependabot watches all of our dependencies against the GitHub Advisory Database and surfaces CVEs within minutes of publication. Updates run through a cooldown so newly-published versions get a chance to mature before we adopt them — a deliberate defence against compromised-package incidents like supply-chain attacks.

The Dependency Review Action blocks any PR that introduces a new HIGH or CRITICAL CVE outright.

Container & CI hardening

  • Container images are scanned with Trivy on every build.
  • A separate Trivy pass on the Dockerfile catches misconfigurations before they make it into an image.
  • All GitHub Actions are pinned to full commit SHAs rather than floating tags like @v4 or @main, which have been an active attack vector in 2025.
  • Workflows default to least-privilege permissions and only elevate per-job when genuinely needed.

Testing & verification

Critical paths are covered by both unit and integration tests, run against real database containers for every supported engine and major version.

Restore is the path that matters most for a backup tool, so we test it explicitly: every PR runs full backup-then-restore cycles against those same real containers, verifying that backups can actually be restored end-to-end — not just written successfully.

The rest of the CI/CD pipeline runs lint, type-check, the full test suite, image smoke tests and multi-architecture builds on every PR. A release only ships if all of it passes.

Reporting a vulnerability

Found a vulnerability? Report it via the GitHub Security tab — see SECURITY.md. Security reports are the highest-priority work queue.