Security Overview built to be audited.

Corrigio is a developer tool that reads your source code and writes pull requests on your behalf. That is a high-trust position, and we treat it accordingly. This document describes, in concrete terms, how we earn and keep that trust — what we encrypt, what we log, who can touch production, and how we respond when something goes wrong.

1. At a glance

2. Architecture & trust boundaries

Corrigio is split into three trust zones, each with its own authentication, logging, and blast radius:

• Web tier — the Next.js application hosted on Vercel. Handles authentication, dashboard, and the public site. Never holds long-lived GitHub tokens.
• Agent tier — the TypeScript agent that diffs OpenAPI specs, searches consumer code, and generates patches. Runs in ephemeral containers with no inbound network access. Each run gets a fresh, isolated filesystem.
• Data tier — Postgres hosted on Supabase. Stores workspace metadata, audit logs, and patch artifacts. Encrypted at rest; row-level security enforced per workspace.

Communication between zones is mutually authenticated over TLS. The agent tier cannot reach the data tier directly; it goes through a signed, scoped API gateway that enforces per-workspace authorization on every request.

3. Data protection

3.1 Encryption

• In transit: TLS 1.2+ for all external traffic, TLS 1.3 where supported. HSTS is enabled with preload, includes subdomains, and a one-year max-age.
• At rest: AES-256 encryption on all database volumes, object storage, and backups. Encryption keys are managed in a managed KMS with quarterly rotation.
• Field-level encryption: Sensitive fields (workspace API keys, webhook secrets) are encrypted a second time with envelope encryption before being written to the database.

3.2 Isolation between customers

Customer data is logically isolated by workspace ID, enforced by Postgres Row-Level Security policies that are evaluated on every query. We do not offer single-tenant hosting in early access, but enterprise customers can opt for a dedicated database cluster.

4. Secrets & token handling

Corrigio never sees or stores your GitHub password. Authentication is brokered by Clerk, which exchanges an OAuth code for a GitHub token. For GitHub App installations, we exchange a signed JWT for a short-lived installation token on demand, with a maximum lifetime of one hour.

Internal secrets (database credentials, signing keys, third-party API keys) are stored in a managed secrets vault and injected into services at runtime. No secrets are committed to source control; pre-commit hooks and CI checks scan for accidental leaks.

5. Access control & SSO

• Identity: All Corrigio employees authenticate to all systems via a single identity provider with hardware-backed MFA (FIDO2 / WebAuthn). Password-only authentication is not permitted for any production system.
• Authorization: Role-based access control with least-privilege defaults. Access to production data is granted on request, time-boxed, and reviewed quarterly.
• Just-in-time access: Production shell access requires an approved, logged, time-boxed elevation that automatically expires.
• Audit: Every access to production is logged to an append-only store with a 13-month retention. Logs are reviewed monthly and on alert.
• Offboarding: Access is revoked within 4 hours of an employee or contractor leaving, via automated deprovisioning.

6. Infrastructure & hosting

All production infrastructure runs in regions configurable per workspace (US East, EU Frankfurt). Backups are encrypted, stored in a separate region from the primary, and tested monthly.

7. Dependency & supply-chain

• Lockfiles: All projects use committed lockfiles (package-lock.json) with integrity hashes. CI refuses to install if the lockfile is out of sync.
• Continuous scanning: Dependabot opens version-bump PRs; Snyk blocks merge on critical advisories; npm audit runs on every CI build.
• Minimum release age: New dependencies must be at least 7 days old on the public registry before they can be merged, to reduce exposure to yanked malicious packages.
• Provenance: We prefer packages with provenance attestations (sigstore) and avoid floating ranges such as latest or unbounded >=.
• SBOM: A Software Bill of Materials is generated on every release and is available to enterprise customers on request.

8. Secure development lifecycle

1. Strict typing. TypeScript with strict: true, noUnusedLocals, noUnusedParameters, and noImplicitReturns. Type errors fail the build.
2. Pre-commit hooks. Local hooks run lint, format, and a secret scanner. CI re-runs the same checks; nothing reaches production without passing both.
3. Code review. All changes require at least one approving review from a code owner. The main branch is protected; direct pushes are disabled.
4. Static analysis. CodeQL runs on every PR. ESLint with security-focused rules is enforced.
5. Testing. Unit and integration tests run on every PR. The self-healing demo (npm run demo:full) is executed in CI to verify end-to-end behavior.
6. Threat modeling. New features that touch authentication, authorization, secrets, or the agent tier require a written threat model reviewed by the security team.

9. Monitoring & incident response

We monitor the Service 24/7 for availability, error rate, and security signals. Alerts page an on-call engineer within 5 minutes. Our incident response process follows the standard NIST lifecycle:

1. Detect — automated alerts + user reports.
2. Triage — on-call assigns severity within 15 minutes.
3. Contain — affected systems isolated; tokens rotated if needed.
4. Eradicate — root cause identified and removed.
5. Recover — services restored from clean state.
6. Communicate — affected customers notified within 24 hours of a confirmed breach.
7. Postmortem — blameless review published internally within 7 days; customer-facing summary within 30 days for SEV-1 incidents.

10. Compliance posture

11. Subprocessors & vendor risk

The full list of subprocessors is published in our Privacy Policy. We assess each vendor before onboarding and annually thereafter, reviewing their SOC 2 reports, security questionnaires, and breach history. New subprocessors that handle customer data are announced at least 30 days in advance, with an opt-out for enterprise customers.

12. Business continuity & backups

• Backups: Database snapshots every 6 hours, retained for 14 days. Point-in-time recovery is available for the last 7 days.
• Restore drills: Monthly restore tests verify that backups are usable and meet our 4-hour RTO and 1-hour RPO.
• Multi-region failover: The web tier is deployed globally via Vercel's Edge Network. Database failover to a standby region is automated and tested quarterly.
• Disaster recovery plan: Documented, tested annually, and reviewed after any major architectural change.

13. Responsible disclosure

If you believe you have found a security vulnerability in Corrigio, we want to hear from you. We operate a coordinated disclosure program with the following terms:

1. Report vulnerabilities to support@corrigio.tech. For sensitive reports, encrypt with our PGP key (fingerprint 9F3A 1C2D 4E5F 6A7B 8C9D 0E1F 2A3B 4C5D 6E7F 8A9B, available on our keyserver and below).
2. We acknowledge reports within 72 hours and provide an initial assessment within 7 days.
3. We work with you on a coordinated disclosure timeline, typically 90 days from acknowledgment or sooner for critical issues.
4. We do not pursue legal action against good-faith reporters who respect these terms and avoid accessing data that is not their own, degrading the Service, or disclosing the issue publicly before we have shipped a fix.
5. We recognize contributors in our Hall of Thanks (with permission and after the fix is deployed) and offer rewards for confirmed vulnerabilities based on CVSS severity.

14. Security contact

For any security-related question — due diligence requests, vendor questionnaires, vulnerability reports, or to request a copy of our SOC 2 report under NDA — contact support@corrigio.tech.

For urgent security incidents affecting live customer data, mark your email subject with [URGENT SECURITY] so it is triaged ahead of the queue. We aim to acknowledge urgent reports within 4 hours, day or night.