Secure development

Code review

Changes are reviewed by a peer before they merge to the main branch, with a higher bar for anything security-relevant.

• Peer code review is required before a change merges to the main branch.
• Security-relevant changes — authentication, authorization, transport, and data handling — receive additional review.
• Review focuses on correctness, least privilege, and tenant isolation, not just style.

CI/CD

Every change is built, vetted, and tested in continuous integration before it can be released.

• Continuous integration builds the backend and clients on every change.
• Automated tests and security scans run in the pipeline as gating checks.
• A change that fails a required check cannot proceed to release.

Automated testing

Tests exercise the parts of the system where a defect would matter most, and they gate changes.

• Backend unit tests cover authentication, authorization, tenant isolation, and multi-factor authentication.
• An integration test harness runs against a real database and cache to exercise end-to-end behavior.
• Shared mobile-library tests protect networking, models, and auth used across the apps.
• These tests gate changes in continuous integration.

Dependency scanning

We track and remediate known vulnerabilities in the third-party code we rely on.

• Dependabot monitors dependencies and proposes updates.
• Vulnerability scanners run against both Go and JavaScript dependencies.

Secret scanning

Credentials should never live in source. Automated scanning enforces that.

• Automated secret scanning blocks credentials from entering the codebase.

Vulnerability management

Automated scanning supplements human judgment — it does not replace an independent assessment.

• A documented vulnerability-management process with severity-based remediation targets.
• Automated scanning supplements, but does not replace, independent testing.
• An independent penetration test is planned before production PHI use — not yet completed.

Release process

Releases are versioned and repeatable, and schema changes move in one direction.

• Builds are versioned so a release can be identified and traced.
• iOS apps are distributed through TestFlight.
• Database migrations run forward-only.

Control status