Built for the data schools can’t afford to lose.

Our security program is operational, not aspirational. These practices are part of how the platform ships — every release, every dependency, every deploy.

• Internal vulnerability assessments. Regular scanning of our codebase, infrastructure, and exposed surfaces. Findings flow into the same backlog as everything else, prioritized by severity.
• Dependency & package validation. Every third-party library is reviewed before it lands and continuously monitored for new CVEs. Out-of-date or compromised packages are patched on a rolling schedule.
• Zero-trust access model. Services authenticate to each other; users authenticate to services. No implicit trust based on network position. Permissions are scoped to the smallest role that still does the job.
• Monitoring & alerting. Around-the-clock observability across the platform — latency, error rates, anomalous access patterns. Alerts route directly to on-call engineers.

We welcome responsible disclosure of potential security vulnerabilities. If you’ve found something, please reach out before going public — we’ll move fast.

• A clear description of the issue and what it allows.
• Affected URL, endpoint, or component — the more specific, the faster we can reproduce.
• Reproduction steps, expected vs actual behavior.
• Proof-of-concept details when available (screenshots, payloads, logs).

We want researchers to feel safe reporting issues. If you act in good faith and within the expectations below, we won’t pursue legal action.

• Avoid privacy violations — don’t access personal data beyond what is necessary to demonstrate the issue.
• Avoid service disruption — no denial-of-service testing against production.
• Avoid data destruction — never modify or delete data you don’t own.
• Keep findings confidential until we’ve confirmed remediation or agreed on disclosure timing.

If something is wrong, you’ll see it on the status page before you have to ask. Every incident is logged with a public post-mortem once resolved.