Secure development process
Scope and principles
The process covers the web application, database migrations, server-side functions, third-party integrations, build artefacts, and production operations. It follows these principles:
- security requirements are considered with functional requirements;
- tenant isolation and least privilege are preserved through every change;
- secrets and privileged service credentials stay outside public source and browser code;
- database changes are reviewable, reversible migrations rather than undocumented live edits;
- evidence is retained for design decisions, implementation, verification, deployment, and rollback;
- unresolved security risk is recorded and accepted by an authorised owner rather than silently treated as complete.
Current lifecycle
| Phase | Implemented control | Open action |
|---|---|---|
| Requirements and design | Feature documentation, business context, architecture decisions, and change-specific acceptance criteria are retained with the project | Enforce one security-requirements and threat-modelling record for every high-risk change |
| Planning and risk | Higher-risk database and authorization work includes explicit scope, invariants, preconditions, staging checks, rollback steps, and deferred-risk decisions | Apply the same risk record and approval gate to every security-relevant change |
| Implementation | Code-formatting and correctness rules are configured; authentication, tenant context, database policies, and trusted server checks form the security boundaries | Keep the linter as a correctness control and retain Snyk Code as the dedicated SAST control |
| Source and secret handling | Local environment files and build credentials are excluded from source control; privileged credentials remain server-side or in deployment configuration | Add deterministic secret scanning to pull requests and repository history |
| Peer review | Non-draft pull requests trigger automated code and security review; Codex review is active, and CodeRabbit is used for selected reviews | Require human approval and designated ownership for security-sensitive paths; enforce the rule through protected-branch configuration |
| Build and functional verification | Snyk Open Source and Snyk Code run on pull requests; production builds, formatter/linter checks, manual QA, and browser-assisted testing are retained when performed | Add required build, non-mutating lint, and automated test checks that block merge on failure |
| Database change control | Changes are represented as migrations, reviewed before deployment, tested against role and tenant invariants where risk requires it, and accompanied by rollback or restoration guidance | Record production deployment approval and post-deployment verification for every migration |
| Release and deployment | Cloudflare Pages builds the web application; protected build configuration handles monitoring source maps without placing them in the public artefact | Document required approval, environment separation, rollback authority, and a completed rollback exercise |
| Monitoring and feedback | Production exceptions and selected performance traces reach the monitoring platform; activity records preserve implementation and validation history | Assign security-event ownership, escalation routing, and measurable acknowledgement targets |
| Vulnerability response | Internal security assessments, Snyk results, AI-assisted review, and provider advisories identify weaknesses | Operate one vulnerability register from discovery through verified closure and retain independent retest evidence where required |
Security requirements by change type
Every security-relevant change records the applicable requirements before implementation.
| Change type | Minimum security considerations |
|---|---|
| Authentication or session | Account eligibility, credential handling, session expiry, token storage, logout behaviour, abuse controls, and MFA impact |
| Authorization or tenant scope | Allowed actors, denied actors, cross-tenant negative cases, direct API access, row-level policy behaviour, and privileged server checks |
| Personal or policy data | Data minimisation, field validation, access scope, retention, export, logging, encryption, and deletion behaviour |
| Database migration | Forward compatibility, schema preconditions, grants, row-level policies, function execution rights, backfill safety, backup dependency, verification query, and rollback |
| Server-side function | Caller authentication, tenant and role revalidation, input bounds, replay or idempotency handling, secret access, external-call failure, and auditability |
| Third-party integration | Data shared, purpose, credentials, authentication, callback validation, timeout and retry policy, incident dependency, and supplier change monitoring |
| Frontend or build | Input/output encoding, client-exposed configuration, dependency impact, source-map handling, content security assumptions, and production-build verification |
Required change evidence
A security-relevant change retains, as applicable:
- requirement and business owner;
- security impact and data-flow change;
- design decision or threat assessment for high-risk work;
- code-review outcome and unresolved findings;
- build, lint, automated-test, and manual-test results;
- negative authorization and cross-tenant test results;
- migration preconditions and post-deployment verification;
- deployment identifier, operator, and approval;
- rollback procedure and recovery dependency;
- monitoring, vulnerability, or incident follow-up.
The change record identifies every unavailable test and failed validation explicitly. Absence of a tool or environment is recorded as incomplete evidence, not a passing result.
Database and backend safeguards
- Browser requests use the authenticated user context; privileged service credentials remain inside trusted execution and are absent from public clients.
- Exposed application tables use row-level security, with grants controlling whether an API role can reach an object and policies controlling the rows it can access.
- Privileged database functions and server-side operations require explicit caller, tenant, role, and target validation.
- Migration verification includes anonymous, normal user, management, leadership, mapped-scope, cross-tenant, and service-operation cases where relevant.
- Security-advisor output is reviewed as a point-in-time signal. The current review found outstanding advisories, so advisor execution is not presented as a clean or automated release gate.
- Provider changelog review is required before platform, client-library, authentication, database, or deployment changes.
Current gaps and improvement plan
| Priority | Required improvement | Completion evidence |
|---|---|---|
| High | Add required CI checks for a clean production build and non-mutating lint validation | Checks execute on every pull request and block merge on failure |
| High | Add automated secret scanning and prevent privileged credentials from entering commit history | Pull-request and repository-history scans pass; response procedure is documented |
| High | Expand Snyk Code coverage, confirm required-check settings, retain dependency-scan evidence, and introduce risk-based DAST | Item 14 contains configuration evidence, dated results, triage, remediation ownership, and authorised DAST scope |
| High | Establish protected-branch rules, required human approval, and security ownership for sensitive paths | Source-control settings and approval evidence are retained |
| High | Add an automated test runner beginning with authentication, authorization, tenant isolation, and critical business workflows | Tests run in CI and include negative security cases |
| Medium | Commit and enforce one supported dependency lockfile and define an update cadence | Reproducible clean installation and scheduled dependency review are demonstrated |
| Medium | Standardise security requirements and lightweight threat modelling for high-risk changes | Pull requests link to the completed risk record |
| Medium | Document Cloudflare Pages release approval, environment separation, rollback, and recovery verification | A dated release and rollback exercise is retained |
| Medium | Define vulnerability severity, remediation targets, exception approval, and retest rules | Findings can be traced from discovery through verified closure |
| Medium | Track Supabase security advisories to triage or accepted risk | Each relevant advisory has an owner, decision, and review date |
Framework alignment
The process is organised around the four outcome groups in the NIST Secure Software Development Framework: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities. OWASP SAMM is used as a maturity reference across governance, design, implementation, verification, and operations.
The reviewed process demonstrates useful controls but does not yet satisfy a mature, fully automated DevSecOps release gate. The improvement plan above is therefore part of the documented posture.