Security

Effective 8 October 2026

Weave holds your source code and the history of who changed what and why. This page describes how we protect it and how to report a vulnerability. Weave is in early access; we have not yet completed an independent certification such as SOC 2 or ISO 27001.

Found a vulnerability? Email security@weave.directory. See our disclosure policy below. Our security.txt follows RFC 9116.

1. Infrastructure

  • The web platform runs on Vercel. The Weave server runs on Google Cloud Run in us-central1 behind a Google Cloud HTTPS load balancer, with its Postgres database on Cloud SQL and repository files in Cloud Storage. Providers are listed on our Subprocessors page.
  • The Weave server's cloud infrastructure is defined as code (Terraform).
  • The Cloud SQL database accepts only encrypted connections and has no authorised public networks; the Weave server reaches it through the Cloud SQL connector.

2. Encryption

  • In transit: all traffic to www.weave.directory and api.weave.directory uses TLS. Plain HTTP requests to the API are redirected to HTTPS, and the CLI warns you if it is pointed at an insecure server URL.
  • At rest: databases, object storage and backups are encrypted at rest by our cloud providers (AES-256 on Google Cloud).
  • Application-level encryption: two-factor authentication secrets and repository secrets are encrypted with AES-256-GCM before they are stored.

3. Accounts and credentials

  • Passwords are stored only as bcrypt hashes.
  • Personal access tokens, system tokens and password-reset tokens are stored only as SHA-256 hashes. A token is shown once, when you create it. Password-reset links expire after one hour.
  • Time-based one-time password (TOTP) two-factor authentication is available to everyone and required for organisation owners and admins. Turning 2FA off requires a valid code.
  • Sign-in, sign-up, password reset, 2FA and our public forms are rate-limited per account and per IP address. Rate-limit records store only hashes of IP addresses and email addresses and are discarded after about a day.
  • Data exports never include password hashes, 2FA secrets or token hashes.

4. Access control

  • Organisations have owner, admin, member and read-only roles; repositories grant read, write or admin access. Every request to the Weave server is authenticated, and the server checks the caller's permission for the repository on every operation.
  • Symbol ownership adds a second layer: changes to a symbol you do not own go to its owner as a suggestion or change request rather than straight in.
  • The operation log is hash-chained, so entries cannot be silently altered or removed.
  • Infrastructure secrets (database credentials, API keys, signing keys) are kept in Google Secret Manager or our hosting provider's encrypted environment settings, never in source code.
  • Service accounts follow least privilege; for example the web platform's service account has read-only access to repository storage.
  • Production access is limited to the small number of Anterra personnel who need it, using accounts protected by multi-factor authentication [TO CONFIRM: personnel access controls].

5. Backups and resilience

  • The Weave server database has daily automated backups and point-in-time recovery.
  • Repository storage keeps previous versions of objects so that accidental overwrites or deletions can be recovered.
  • Every Weave checkout is a working copy on your machine, so your code is never only in our hands.

6. AI providers

Only symbol names, docstrings, decision-thread text and your queries are sent to our AI provider, never credentials or whole files. See the AI section of our Privacy Policy.

7. Incident response

We investigate security events promptly, contain and fix them, and notify affected customers without undue delay — and the ICO within 72 hours where the law requires — as described in our Privacy Policy.

8. Vulnerability disclosure policy

We welcome reports from security researchers. Email security@weave.directory with a description of the issue, the steps to reproduce it, the affected URL or component, and its likely impact. Please do not include sensitive data beyond what is needed to show the issue.

What we commit to

  • acknowledge your report within 3 working days;
  • give you an initial assessment within 10 working days and keep you updated until it is fixed;
  • credit you when we publish a fix, if you would like.

In scope

  • www.weave.directory and api.weave.directory;
  • the Weave CLI and watcher distributed from weave-cli.com.

Rules

  • Only test against accounts and data you own or have permission to use. Do not access, modify or delete other users' data; if you encounter it, stop and tell us.
  • No denial-of-service testing, spam, social engineering of our staff or users, or physical attacks.
  • Avoid degrading the Service; automated scanning must be rate-limited.
  • Give us reasonable time to fix the issue before disclosing it publicly — we suggest 90 days, or sooner by agreement.

Out of scope

  • reports from automated tools without a demonstrated impact;
  • missing security headers or best-practice settings without a demonstrated exploit;
  • vulnerabilities in third-party services we use (please report them to the provider);
  • self-XSS, clickjacking on pages without sensitive actions, and attacks requiring a compromised device.

Safe harbour

If you make a good-faith effort to follow this policy, we will consider your research authorised, will not pursue or support legal action against you (including under the Computer Misuse Act 1990 or for breach of our Terms of Service in respect of the research), and will make clear that you acted in line with this policy if a third party takes action against you. This does not cover conduct that breaks the law in other ways or that harms our users. We do not currently run a paid bug bounty programme.