Security

1. Overview

Security is a core design principle at Testhide, not an afterthought. As a platform that processes CI/CD pipelines, test results, and LLM evaluation outputs for engineering teams, we hold a position of trust that we take seriously.

2. Encryption

In Transit

• All traffic between clients and Testhide is encrypted using TLS 1.2 or TLS 1.3
• HTTP Strict Transport Security (HSTS) is enforced — plain HTTP is redirected to HTTPS
• API endpoints reject connections using deprecated cipher suites
• Internal service-to-service communication is also encrypted

At Rest

• All customer data stored on disk is encrypted using AES-256
• Database backups are encrypted before being written to storage
• Passwords are never stored — only bcrypt hashes are kept
• Sensitive credentials (SMTP passwords, API keys stored by users) are encrypted using a hardware-backed key management system

3. Authentication & Access Control

User Authentication

• Passwords must meet minimum complexity requirements
• Rate limiting and lockout protection against brute-force login attempts
• Sessions use cryptographically secure, short-lived tokens

API Authentication

• All API calls are authenticated using RS256-signed JSON Web Tokens
• Tokens have short expiry windows; refresh tokens are rotated on use
• API keys can be scoped and revoked individually from the dashboard

Internal Access

• Production access requires multi-factor authentication
• Role-based access control (RBAC) limits what each team member can access
• All privileged access is logged with timestamps and actor identity
• Access is reviewed and revoked when no longer needed

4. Infrastructure Security

• Hosted on reputable cloud infrastructure with SOC 2 Type II certification
• Private networking — database and internal services are not exposed to the public internet
• Firewalls and security groups enforce strict ingress/egress rules
• Automated patching for OS and runtime dependencies
• DDoS protection at the network edge
• Automated database backups with tested restore procedures
• Uptime monitoring with automated alerting — status published at testhide.com/status

5. Application Security

Secure Development Practices

• OWASP Top 10 threats are addressed in our development process
• Django's built-in protections: CSRF tokens, SQL injection prevention (ORM), XSS escaping, clickjacking protection headers
• Dependencies are scanned for known CVEs on every build
• Security-focused code review before all production deployments

API Security

• All endpoints enforce authentication and authorisation — no unauthenticated data access
• Rate limiting is applied per user and per IP
• Input validation on all API parameters
• Strict CORS policy — only approved origins may make cross-origin requests

Agent & Runner Security

• Docker-based agents run in isolated containers with no host network access by default
• Agents communicate with the control plane over mutually-authenticated, encrypted channels
• Agent credentials are short-lived and automatically rotated

6. Data Isolation

Testhide is a multi-tenant platform. We enforce strict logical isolation between organisations:

• Every database query is scoped to the authenticated organisation — cross-tenant data access is prevented at the ORM layer
• Build logs, test results, LLM evaluations, and pipeline configurations are never shared between organisations
• Node pools and Docker agents are not shared between organisations

7. Incident Response

We maintain a documented incident response plan covering:

• Detection — automated alerting for anomalous behaviour, failed authentication spikes, and unusual API patterns
• Containment — ability to isolate affected components without full service disruption
• Assessment — determining scope, impact, and affected customers within the first hour of an incident
• Notification — affected customers are notified within 72 hours of a confirmed data breach, with a clear description of what happened and what data was involved
• Remediation — root cause analysis and published post-mortem for significant incidents

Service status and incident history are published at testhide.com/status.

8. Vulnerability Disclosure

We welcome responsible disclosure of security vulnerabilities. If you discover a potential security issue in Testhide, we ask that you:

1. Report it to us privately at thuesdays@gmail.com with the subject line "[Security] Vulnerability Report"
2. Provide enough detail for us to reproduce and assess the issue (steps, environment, screenshots or PoC if applicable)
3. Allow us a reasonable time (up to 90 days) to investigate and patch before public disclosure

In return, we commit to:

• Acknowledge receipt within 2 business days
• Provide a status update within 10 business days
• Not pursue legal action against researchers who act in good faith
• Credit you (if you wish) in our disclosure once the issue is resolved

9. Sub-processors

We use the following third-party sub-processors that may handle customer data:

• Stripe — payment processing. Certified PCI DSS Level 1.
• Cloud hosting provider — servers, databases, and object storage. SOC 2 Type II certified.
• Error monitoring — aggregated, anonymised crash reports only. No personal data.

We do not use sub-processors for advertising, marketing analytics, or any purpose unrelated to delivering the Service.

10. Security Contact

For all security-related enquiries — vulnerability reports, questions about our practices, or data breach notifications:

• Email: thuesdays@gmail.com
• Subject line for vulnerability reports: [Security] Vulnerability Report

For general questions about privacy and data handling, see our Privacy Policy. For usage terms, see our Terms of Service.