Skip to content

Security

How Sutra protects the data it handles, and how to tell us about a problem.

Reporting a vulnerability

To be confirmed: A security contact address has not been configured (set SITE_SECURITY_EMAIL). Until then, use the contact page and avoid posting exploit details in public issues.

To be confirmed: Response-time commitments, safe-harbour wording and any bounty. None are promised here.

What is implemented

  • Server-side role-based authorisation on every API route, checked by an automated test; viewers are read-only and see redacted check configuration.
  • Session cookie that is HttpOnly, Secure and SameSite=Lax; idle and absolute session timeouts; a cap on sessions per account; password change revokes sessions.
  • Login throttling per email and IP, designed so an attacker cannot lock out the real user, and no timing difference for unknown emails.
  • CSRF protection on state-changing API calls through same-origin checks.
  • SSRF protection for user-supplied URLs: private and internal ranges are blocked when saved and again when connecting, with redirects re-validated.
  • Stored secrets encrypted at rest with AES-256-GCM and never returned by the API.
  • Append-only audit log of sign-ins, state changes and log reads, enforced by database triggers.
  • Agents authenticate with random, expiring, rotating credentials stored hashed, and run under a restricted systemd sandbox with strictly validated commands.
  • TLS termination, HSTS, request limits and security headers (including a Content-Security-Policy and frame blocking) at the reverse proxy.

To be confirmed: That the production deployment uses the reference reverse proxy configuration these items describe.

Known limitations

  • Multi-factor authentication is not implemented yet; it is designed but not built.
  • No security or compliance certification (such as SOC 2 or ISO 27001) is held or claimed.
  • The agent runs with elevated privileges on monitored servers to restart services; this is mitigated, not eliminated. Commands are not cryptographically signed.
  • The Content-Security-Policy still allows inline scripts and styles.
  • Teams webhooks can acknowledge a message that is later rejected, so delivery of an alert is not guaranteed.

Your part

Use strong unique passwords, give people the lowest role they need, keep encryption keys backed up outside the server, and rotate webhook URLs and credentials if they are ever exposed. See the Privacy Policy for how data is handled.