Trust & Security

Security at TerraWatch

Everything your security team needs to evaluate TerraWatch before approving it for production use.

Questions? hello@terrawatch.dev

GitHub permissions

TerraWatch requests the minimum permissions required to do its job. Here is exactly what we request and why:

Permission Access level Why we need it
pull_requests Read & write Read PR metadata (title, branch, commit SHA) and post bot comments with findings and fix suggestions.
contents Read Download the changed .tf files from the PR diff. Used only during scanning; contents are never stored.
checks Read & write Create and update GitHub check runs to report pass/fail status and block merges when critical findings are detected.
metadata Read Required by GitHub for all GitHub Apps. Provides access to basic repository information (name, visibility).

We do not request access to your Actions secrets, environment variables, deploy keys, webhooks configuration, or any other repository settings.

How scanning works

✓

Your source code is never stored. Terraform file contents exist in our process memory only for the duration of the scan, then are garbage-collected. Nothing is written to disk or any database.

When a pull request is opened or updated on a repository where TerraWatch is installed, the following sequence occurs:

  • GitHub sends a pull_request webhook event to TerraWatch.
  • We fetch only the files changed in the PR diff that have a .tf extension, using the GitHub Contents API.
  • The file contents are loaded into process memory and parsed by our Terraform analysis engine.
  • All 29 security rules are evaluated against the parsed resource graph in memory.
  • Findings (rule ID, severity, resource name, file path, line number) are stored in our database.
  • File contents are discarded from memory. No source code leaves our process heap.
  • A GitHub check run is created and a PR comment is posted with any findings and suggested fixes.

The entire scan process completes in under 30 seconds for typical pull requests.

Data in transit

All communication between TerraWatch and external services is encrypted in transit:

  • HTTPS (TLS 1.2+) is enforced for all inbound and outbound connections. HTTP connections are automatically redirected to HTTPS.
  • Webhook payloads from GitHub are verified using HMAC-SHA256 signatures before processing.
  • All API calls to GitHub are made over HTTPS using signed JWT tokens issued by the GitHub App.
  • Communication between our application layer (Railway) and our database (Supabase) uses TLS-encrypted connections.

Data at rest

The following data is persisted in our Supabase database (EU region):

  • Account data — your GitHub user ID, username, and email address.
  • Repository associations — names of repositories where you have installed TerraWatch.
  • Scan findings — rule ID, severity level, resource name, file path, and line number for each detected issue. Never the file contents themselves.
  • PR metadata — PR number, title, branch name, and scan status, used to power your security dashboard.

All data at rest is encrypted using AES-256 encryption by Supabase at the storage layer.

🗑️

All data associated with your account is permanently deleted within 30 days of account deletion. Email hello@terrawatch.dev to request deletion.

Infrastructure

Application hosting
Railway
EU region (Frankfurt). Containerised deployment with automatic TLS.
Database
Supabase
EU region (Frankfurt). PostgreSQL with row-level security enabled.
Network
HTTPS only
TLS 1.2+ enforced on all endpoints. HTTP redirects to HTTPS.
Code storage
Never persisted
Terraform source processed in-memory only. Not written to disk or any storage layer.

Responsible disclosure

If you discover a security vulnerability in TerraWatch, we ask that you report it to us privately before disclosing it publicly. This gives us the opportunity to investigate and issue a fix before the issue is known to potential attackers.

To report a vulnerability, email hello@terrawatch.dev with the subject line Security Disclosure. Please include:

  • A description of the vulnerability and its potential impact.
  • Steps to reproduce or a proof of concept.
  • Your contact details so we can follow up.

We will acknowledge receipt within 24 hours and provide an initial assessment within 72 hours. We aim to issue a fix within 14 days of a confirmed vulnerability.

We do not currently offer a bug bounty programme, but we will credit researchers in our security advisories if they wish.

Certifications roadmap

TerraWatch is a young product. Here is where we stand on formal security certifications:

  • SOC 2 Type II — on our roadmap for 2026. We are implementing the controls required and will engage an auditor once the service reaches sufficient scale.
  • GDPR — we operate under GDPR requirements as our infrastructure is based in the EU. Users can request data access or deletion at any time.
  • Penetration testing — planned for H1 2026. Results will be shared under NDA with enterprise customers on request.

If your organisation requires a security questionnaire or vendor review, email hello@terrawatch.dev and we will work with your team directly.