How we test, review, and harden

At a glance

The numbers below are the ones we actually track. We've written this page to be honest about what we do and don't yet do — see "What we're still building" at the end.

Tested continuously

Every change to the platform runs through an automated test suite before it ships — 300+ tests across more than 40 test files, executed on every push and pull request. The tests run against real PostgreSQL and Redis, not mocks, so they exercise the system the way it actually runs in production.

A meaningful share of that suite is security-specific. We keep dedicated tests for the things most likely to leak data or grant unauthorized access:

• Multi-tenant isolation — no district can ever query, view, or export another district's data
• Access control & role enforcement — every role sees only what it should
• IDOR protection — you can't reach another record by guessing or editing an ID in the URL
• SSRF defenses — server-side fetches can't be tricked into reaching internal or cloud-metadata hosts
• Admin impersonation controls — time-boxed, flagged, and fully audit-logged
• Encrypted secure notes, audit logging, and CSV formula-injection protection

Reviewed at full scope

Beyond the automated suite, the platform undergoes end-to-end security reviews that cover the full attack surface:

• Authentication and authorization
• Injection, cross-site scripting (XSS), and cross-site request forgery (CSRF)
• Access control and tenant isolation
• Dependency and secret hygiene (including scans of source and git history)
• Container and deployment configuration, security headers, and file uploads
• K-12 and FERPA-aligned data handling

When a review does surface something, each finding is tracked individually and remediated by severity, with the fix tested and deployed on its own. That's how we work through them: top-down, one verified fix at a time.

A hardened supply chain

Most real-world breaches come in through a dependency, not the application code. We treat the software supply chain accordingly:

• Hash-pinned dependencies. Production images install from a fully-resolved lockfile with cryptographic hash verification — a tampered or substituted package fails the build.
• Continuous vulnerability scanning. Every code change is scanned for known-vulnerable dependencies, and automated tooling proposes updates to our libraries, container images, and CI actions each week.
• Pinned build automation. Every step in our automated pipeline is pinned to an immutable version, so the pipeline itself can't be silently swapped out from under us.

Privacy built for schools

Security and student-data privacy are the same job in K-12. The platform is designed around that:

• Row-level tenant isolation so districts are separated at the data layer, not just the interface.
• Student accounts are gated behind a signed data-privacy agreement. Automated roster and directory sync — OneRoster/ClassLink, Microsoft Entra, and Google Workspace — won't create new student accounts until your DPA with us is in place. The gate is closed by default for every district.
• AI is off by default and only turns on when a district administrator opts in. Customer data is never used to train any AI model.
• Encryption of sensitive configuration at rest, and audit logging of security-relevant actions that survives deployments.

For the full data-handling picture, see our Data Privacy Agreement, Subprocessors list, and Privacy Policy.

Reporting a vulnerability

If you've found a security issue, we want to hear about it. We publish a coordinated-disclosure policy with defined response timelines — we acknowledge reports within two business days and provide an initial assessment within five.

Report privately through GitHub's private vulnerability reporting or by email to [email protected]. Please don't file a public issue for a security bug. Full details are in our security policy.

What we're still building

We'd rather tell you where we're headed than imply we're already there. In the spirit of the rest of our documentation:

Have a security questionnaire, or want to talk through your district's requirements? Email [email protected] — you'll reach the people who built the system.