Security Scanning
What answerLoops does to ship secure releases, and what you should check when self-hosting.
Every answerLoops release goes through automated dependency, secret, and code-level security scanning before it merges — you're deploying code that's already been checked. This page covers what that means for you as a self-hoster, and the security practices worth following in your own deployment.
What's already covered before you deploy
Every change to the codebase is scanned for known-vulnerable dependencies, leaked credentials, and common code-level security issues (injection, insecure crypto, missing auth checks) before it's merged. You don't need to run anything yourself to benefit from this — it's already reflected in the code you git clone or docker pull.
The scanners themselves — Trivy (dependencies, secrets, image), Semgrep (SAST), and Zizmor (GitHub Actions workflow audit) — run at pinned versions, and Dependabot opens a PR whenever a newer version is released, so the tooling stays current without silently changing under CI.
What you're responsible for in your own deployment
Security fixes ship as regular releases. See Upgrading — pull the latest image or git pull + rebuild regularly rather than pinning to an old version indefinitely.
AI provider API keys and bot tokens are encrypted at rest using AES-256-GCM, keyed by ENCRYPTION_KEY. A production build (NODE_ENV=production) refuses to save a credential without it, rather than falling back to plaintext — see Environment Variables. Generate one with openssl rand -hex 32 and never commit it to source control.
Auth.js signs and encrypts session tokens with AUTH_SECRET. Generate a unique value per deployment — never reuse the example value from .env.local.example.
Terminate TLS in front of answerLoops (Railway, Fly.io, and most PaaS providers do this automatically; if you're running raw Docker on your own box, put a reverse proxy like Caddy or nginx in front of it). OAuth callbacks and webhook signature checks assume the deployment is reachable over HTTPS.
GITHUB_WEBHOOK_SECRET, SLACK_SIGNING_SECRET, RESEND_WEBHOOK_SECRET, and BOT_SECRET all guard inbound webhook endpoints against forged requests. Treat them the same as API keys — never commit them, never log them.
Postgres should not be reachable from the public internet. If you're using Neon, Railway, or a managed provider, this is the default — if you're self-managing Postgres, firewall it to only the app and bot services.
Reporting a vulnerability
If you find a security issue in answerLoops itself, open an issue on GitHub or reach out through the contact info in the repo. Please don't include working exploit details in a public issue for anything that looks exploitable in a live deployment — flag it first so it can be triaged privately.