Security Policy

1. Overview

WeaveSeq Engineering takes the security of our platform, infrastructure, and your data seriously. This Security Policy describes the technical and organizational measures we employ to protect the confidentiality, integrity, and availability of the WeaveSeq platform and the data entrusted to us by our clients.

This policy is intended for current and prospective clients, security researchers, and partners who wish to understand our security posture. If you have questions not addressed here, please contact us at security@weaveseq.com.

2. Data Encryption

2.1 Encryption in Transit

All data transmitted between your browser and our servers is encrypted using Transport Layer Security (TLS) 1.3, with TLS 1.2 as a fallback for older clients. We enforce HTTPS across the entire Site — plaintext HTTP connections are automatically redirected to HTTPS. HSTS (HTTP Strict Transport Security) headers are configured with a long-durationmax-age directive and include subdomains.

Internal service-to-service communication within our infrastructure (e.g., between the Next.js application server and the PostgreSQL database) occurs over TLS-encrypted connections. We do not transmit sensitive data over unencrypted channels.

2.2 Encryption at Rest

• Application database: PostgreSQL data is encrypted at rest using AES-256 encryption provided by our database provider (the specific cipher suite depends on the provider, e.g., Neon or Supabase; both default to AES-256 for data at rest).
• File uploads (S3-compatible storage): PDB and CIF structure files uploaded by clients are stored in S3-compatible object storage with server-side encryption enabled (AES-256). Access to stored objects is governed by signed URLs with time-limited expiration.
• Secrets management: API keys, database credentials, and other secrets are stored as environment variables and never committed to source control. In production, secrets are injected via the hosting platform’s encrypted environment variable store (Vercel Environment Variables, encrypted at rest and in transit during deployment).
• Backups: Database backups (where configured) are encrypted at rest using the provider’s default storage encryption.

3. Authentication Security

WeaveSeq uses Auth.js v5 (NextAuth.js v5) for authentication, supporting two authentication methods:

3.1 Password-Based Authentication

• Passwords are hashed using bcrypt with a per-user randomly generated salt and a work factor of at least 12 rounds. Plaintext passwords are never stored, logged, or transmitted in any form other than the initial TLS-encrypted registration and login requests.
• Session tokens are issued as cryptographically signed JWTs (JSON Web Tokens) with short expiration periods. Session cookies are configured with the HttpOnly, Secure, and SameSite=Lax attributes by default through Auth.js.

3.2 Microsoft Entra ID OAuth

• Organizations with Microsoft Entra ID (formerly Azure AD) can authenticate using their existing identity provider. This enables enforcement of organizational security policies including multi-factor authentication (MFA), conditional access policies, and device compliance checks at the identity provider level.
• WeaveSeq receives only the user’s name and email address from the identity provider. We do not request or receive access to organizational directory data, email content, or files.

3.3 Brute-Force Protection

• Login endpoints and intake form submissions are protected by rate limiting via Upstash Redis. Repeated failed authentication attempts from a single IP address or account trigger progressively longer rate-limit windows.
• Account lockout (temporary) is triggered after a threshold number of consecutive failed login attempts for a given account.

4. Infrastructure Security

4.1 Hosting Platform

WeaveSeq is hosted on Vercel, which provides:

• SOC 2 Type II and ISO 27001 certified infrastructure.
• DDoS protection at the edge via Vercel’s global content delivery network.
• Automatic TLS certificate provisioning and renewal via Let’s Encrypt.
• Isolated serverless execution environments per request (containerized function execution), so no request context leaks between users or organizations.

4.2 Containerized Execution

Application code executes in containerized environments on Vercel’s serverless platform. Each HTTP request — whether a page render, an API route, or a server action — runs in its own isolated execution context. No shared filesystem, memory space, or runtime state persists between requests across different users or sessions. This architecture limits the blast radius of any potential vulnerability.

4.3 Dependency Management

• Dependencies are pinned to specific versions in package.json and locked via package-lock.json.
• Automated dependency scanning (via Dependabot or equivalent) is configured to detect known vulnerabilities in third-party packages.
• The application uses a minimal set of carefully chosen dependencies. Every dependency in the production bundle is reviewed before addition.

4.4 Network Security

• The PostgreSQL database is not exposed to the public internet; it accepts connections only from authorized application IP ranges or via the provider’s connection-pooling proxy.
• Upstash Redis instances are accessed via REST API over HTTPS with token-based authentication, not via raw TCP connections.
• Firewall rules and IP allowlists (where supported by infrastructure providers) restrict administrative access to production resources.

5. Application Security Practices

• Content Security Policy: CSP headers are configured to restrict the sources from which scripts, styles, and other resources can be loaded, reducing the risk of cross-site scripting (XSS) attacks.
• Cross-Site Request Forgery protection: Auth.js v5 includes built-in CSRF protection for authentication flows. State-changing operations use per-session tokens validated on each request.
• Input validation: All user-supplied data (intake forms, file uploads, API parameters) is validated and sanitized on the server side before processing. File uploads are validated for type (PDB or CIF only) and size limits.
• Server-side rendering security: The Next.js App Router architecture ensures that sensitive logic and database queries execute exclusively on the server. Client components receive only the data explicitly passed to them. Secrets are never exposed to the client bundle.
• SQL injection prevention: All database access is mediated through Prisma ORM, which uses parameterized queries. Raw SQL is not used in the application.

6. Data Isolation Between Organizations

WeaveSeq maintains logical separation of data between different client organizations:

• Each client’s project data, intake submissions, and computational results are associated with the client’s organization identifier in the database. Authorization checks enforce that users can only access data belonging to their organization.
• Uploaded structure files are stored with organization-scoped prefixes in S3-compatible storage, and access is governed by the organization-level authorization in the application layer.
• Serverless execution contexts are ephemeral and per-request — there is no shared in-memory state between requests from different organizations.
• WeaveSeq does not use client data from one organization to train, fine-tune, or improve models used for another organization’s projects without explicit consent.

7. Responsible Disclosure

WeaveSeq welcomes the responsible disclosure of security vulnerabilities discovered in our platform by security researchers and the broader community. We are committed to working with the security community to verify and address legitimate vulnerabilities.

7.1 How to Report

Please send vulnerability reports to security@weaveseq.com. Include the following information to help us triage and reproduce the issue:

• A clear description of the vulnerability.
• Steps to reproduce the issue, including affected URLs, parameters, or API endpoints.
• The impact of the vulnerability (e.g., what an attacker could achieve).
• Any supporting material, such as screenshots, proof-of-concept code, or HTTP request/response traces.

7.2 What We Ask of Researchers

• Give us a reasonable amount of time to investigate and address the vulnerability before publicly disclosing it. We request a disclosure window of at least 90 days from the date of our acknowledgment.
• Do not access, download, or modify data belonging to other users. If a vulnerability provides unintended access to data, stop testing and report the vulnerability with only the minimum information needed to demonstrate the access path.
• Do not degrade the performance of the Site or Services, perform denial-of-service testing, or use automated scanners at high request rates.
• Act in good faith and comply with applicable laws.

7.3 Our Commitment

• We will acknowledge receipt of your report within 5 business days.
• We will provide an initial assessment and estimated timeline for remediation within 14 business days.
• We will keep you informed of our progress as we investigate and fix the issue.
• We will not pursue legal action against researchers who act in good faith and comply with this responsible disclosure policy.
• We are happy to publicly acknowledge your contribution upon resolution, with your consent.

8. Compliance Posture

WeaveSeq is an early-stage computational protein engineering company. We are building our security program with the following frameworks and principles as our guide:

• Infrastructure certifications: Our infrastructure providers (Vercel, Upstash, Resend) maintain SOC 2 Type II and ISO 27001 certifications. WeaveSeq leverages these certified platforms rather than operating its own physical infrastructure.
• GDPR: We maintain a Privacy Policy describing our data processing activities and have implemented mechanisms for data subject access requests. Our processors offer Data Processing Agreements incorporating the EU Standard Contractual Clauses. See our Privacy Policy for details.
• CCPA: We do not sell personal information and provide California residents with rights to know, delete, and access their data, as described in our Privacy Policy.
• Data minimization: We collect and retain only the data necessary to deliver our Services and operate our platform. We regularly review our data collection practices to ensure they remain aligned with this principle.
• Incident response: We maintain an incident response plan. In the event of a confirmed data breach involving personal data, we will notify affected clients and relevant supervisory authorities within the timeframe required by applicable law.

WeaveSeq has not yet completed a formal SOC 2 or ISO 27001 audit. We are transparent about this and are committed to pursuing independent security attestations as we scale. In the interim, we are happy to complete security questionnaires from prospective enterprise clients.

9. Operational Security

• Access control: Access to production systems, databases, and infrastructure consoles is restricted to authorized personnel and follows the principle of least privilege. Access is reviewed periodically.
• Code review: All changes to the codebase undergo review before deployment. Security-sensitive changes receive additional scrutiny.
• Deployment: Production deployments are performed through Vercel’s Git-integrated deployment pipeline with preview deployments for review before promotion to production.
• Logging and monitoring: Application logs and Vercel access logs are monitored for anomalous activity. Security-relevant events (failed logins, rate-limit triggers, file upload anomalies) are logged and reviewed.
• Employee security: Team members with access to production data are subject to confidentiality obligations. Multi-factor authentication is enforced on all accounts with access to production infrastructure.

10. Contact

For security-related inquiries, vulnerability reports, or to request a security assessment questionnaire, please contact: