Secure Development Lifecycle

Owner: Security Officer · Approved by leadership · Version 1.0 · Effective 27 May 2026 · Next review 27 May 2027

1. Purpose

This procedure describes how Glassbreak develops, reviews, tests, releases, operates, and retires software in a way that preserves the confidentiality, integrity, and availability commitments in the Information Security Policy. It is the controlled SDLC procedure referenced by Annex A.8.25–8.34 of the Statement of Applicability and by the corresponding criteria of SOC 2 (CC8) and NIST SP 800-53 (SA, SI, CM families).

2. Scope

This procedure applies to all software developed and operated by Glassbreak, including the application code under api/common/ and the provider-specific adapters under api/scaleway/, api/aws/, the web application under web/, the mobile application under mobile/, the database schema and migrations under api/schema/, the infrastructure-as-code under infra/, the disaster-recovery test harness under dr-tests/, the supporting scripts under scripts/, and any internal tooling.

3. Principles

  • Security is part of every change. No code change ships without security consideration; no infrastructure change applies without OpenTofu plan-and-review.
  • Threat modelling at design. Any feature that touches authentication, authorisation, cryptography, cross-vertical sync, or customer data flow is threat-modelled before implementation.
  • Defence in depth. Controls are layered so that the failure of any single one does not breach the invariants.
  • Least privilege. Every credential, interface, and runtime principal operates with the minimum permissions necessary.
  • Reproducibility. Builds and deployments are reproducible from source; manual production changes are prohibited.
  • Continuous evidence. The daily security-posture snapshot publishes the operating state of security-relevant invariants to /trust only when measured green for 30+ consecutive days.

4. Lifecycle phases

4.1 Plan

  • Each change starts from a written description (issue, PR description, or design note) stating the intent and the expected user-visible behaviour.
  • Material changes reference the architectural intent in docs/architecture.md; deviation from the target architecture requires an explicit decision in the plan stage with a recorded rationale.
  • Material changes are categorised against the information classes in /policies/isms-scope section 6; changes that touch Class CT or Class K trigger a threat-modelling step in the design phase.

4.2 Design

  • Threat modelling. For features touching authentication, authorisation, cryptography, cross-vertical sync, or customer-data flow, a STRIDE-style threat-modelling pass is performed in the design note. The output enumerates: assets touched, trust boundaries crossed, threats considered, and controls applied or relied on.
  • Secure design review. Designs that change the trust boundary, the cryptographic surface, the sync semantics, or the customer-data flow are reviewed by the Security Officer before implementation begins. The review is recorded in the design note.
  • Privacy by design. Any new collection of personal data is considered against the lawful-basis and minimisation principles in the DPA; a DPIA-style assessment is performed for any new high-risk processing.
  • Backwards compatibility. Schema and API changes are designed to be forward-compatible and reversible; breaking changes follow a deprecation cycle with an explicit migration plan.

4.3 Implement

  • Source control. All code is version-controlled in the GitHub repository. Direct commits to main are blocked by branch protection. Work happens on feature branches with PRs opened against main.
  • TypeScript strict mode. Strict type-checking is enforced across the API, web, and mobile codebases.
  • Input validation. Every public route boundary validates inputs against a Zod schema; outputs are likewise typed against the response schema.
  • Secrets. Production secrets are held in approved secret stores only; never committed to source control; never sent over chat or email. A pre-commit hook and CI scan check for committed secrets.
  • Cryptography. All cryptographic operations use the Noble libraries; algorithm choices are recorded at /technology/encryption. The Wycheproof vector corpus is vendored and runs against every supported primitive in CI.
  • Per-organisation isolation. All database queries on customer data carry an organisation predicate enforced at the query client layer; isolation is tested in the endpoint-test suite.

4.4 Review

  • Mandatory peer review. Every PR requires review by an authorised reviewer before merge. Branch protection enforces this.
  • Security-sensitive change review. PRs touching authentication, authorisation, cryptography, cross-vertical sync, audit log, or admin actions are reviewed by the Security Officer in addition to the standard reviewer.
  • OpenTofu plan-and-review. Every infrastructure change is opened as a PR with the OpenTofu plan attached; the plan is reviewed before apply. Apply runs only via CI; no operator runs tofu apply directly against production state.
  • SAST and lint. ESLint and TypeScript-strict checks run on every PR; failures block merge. Where SAST tooling identifies a new finding, the PR addresses it or explicitly records the rationale for a non-fix in the PR description.
  • Dependency review. Lockfile changes are reviewed; new dependencies are reviewed for licence, maintainership, and supply-chain hygiene per the Supply Chain Risk Management Plan.
  • Migration safety. Schema migrations are reviewed against the standard-migration-safety checklist (additive first, backfill in a separate step, dual-write when required, rollback plan recorded) and DR scenario 20 exercises migration safety in CI.

4.5 Test

  • Unit tests. Run on every PR; coverage expectations are highest on the cryptography, authentication, authorisation, and sync code paths.
  • Endpoint tests. Integration suite that spins up the application against a real Postgres and exercises HTTP routes end-to-end; per-organisation isolation is asserted at the endpoint boundary.
  • Auth-security tests. Rate-limit, replay, refresh-token reuse-family detection, JWT verify-map boundary, and impersonation-audit tests run on every PR.
  • Cryptographic correctness tests. Wycheproof vectors run on every PR for every cryptographic primitive in production use.
  • DR scenarios. 22 DR scenarios in dr-tests/ run nightly in CI against a real two-vertical Postgres + Hono topology; failures open a deduplicated GitHub issue.
  • Visual regression and smoke tests. Smoke tests against every production surface run every 30 minutes with an auto-deduplicated issue on sustained failure.

4.6 Release

  • CI-only deployment. Production deploys run only from a green build on main via CI; manual production installs are prohibited.
  • Per-vertical release. The two compute stacks deploy independently; canary verification on one vertical can precede roll-out to the other.
  • Signed releases. Release artefacts are built reproducibly; the release pipeline is the only principal authorised to push to production.
  • OpenTofu apply. Infrastructure apply runs via CI against approved plans only; OpenTofu state is held encrypted with restricted access.
  • Release notes. User-visible behaviour changes are captured in release notes; security-relevant changes are noted in the changelog reviewed by the Security Officer.

4.7 Operate

  • Observability. OTLP traces, structured logs, and RED metrics are exported to Grafana Cloud; three SLO alerts (5xx rate, p95 latency, apex probe) are wired with runbooks at docs/observability.md.
  • Daily security-posture snapshot. 16+ runtime and code-state controls are verified daily; only controls measured green for 30+ consecutive days are published to the public trust page.
  • Smoke tests. 30-minute heartbeat against every production surface; deduplicated GitHub issues on sustained failure.
  • Incident response. Incidents are handled per /policies/incident-responsewith post-mortems for SEV-1 and SEV-2.
  • Vulnerability management. Dependabot on every repository; advisories triaged against the severity classification in the IR policy; reviewed at the monthly operational cadence.
  • Privileged action audit. Every state-changing admin action is logged to the admin-action audit log; the log is retained per the Audit-log Retention Policy.

4.8 Retire

  • Controlled deprecation. Features scheduled for removal are announced to affected customers, marked deprecated in the codebase, and removed after the published deprecation window.
  • Data minimisation on retirement. On retirement of a feature or system, data held solely for that feature is deleted on the published retention schedule; cryptographic material is destroyed.
  • Infrastructure decommissioning. Retired infrastructure is removed from IaC; cloud-side resources are destroyed via OpenTofu apply; secrets are rotated to invalidate any access that depended on the retired component.
  • Sub-processor retirement. Sub-processors removed from service are documented in the sub-processor list with a removal date; customer notice is given per the DPA.

5. Environment separation

  • Development, staging, and production environments are operated in separate cloud accounts / namespaces with separate credentials.
  • Production data is never copied into development or staging; test data is synthetic.
  • Developer access to production is read-only by default, elevated only via the documented just-in-time path with audit logging.

6. Tooling baseline

  • Source: GitHub (with hardware-key 2FA on admin accounts; branch protection on main).
  • CI/CD: GitHub Actions (third-party Actions pinned to commit hashes; scoped tokens).
  • Lint and static analysis: ESLint, TypeScript strict.
  • Test: Vitest for unit and integration; Wycheproof for cryptographic correctness; the DR scenario harness in dr-tests/.
  • Infrastructure-as-code: OpenTofu (with encrypted state).
  • Dependency hygiene: lockfiles (npm) on every workspace, Dependabot, SBOM generation on the Q3 2026 plan.
  • Observability: OpenTelemetry SDKs, Grafana Cloud (Tempo, Loki, Mimir).

7. Records

  • PR history, review approvals, and CI status checks are retained in the git repository indefinitely.
  • OpenTofu plans are recorded against the PRs that approved them.
  • Release artefacts, build logs, and deployment events are retained in CI for at least 12 months and in operational archives for longer where required.
  • Security-relevant design notes and threat-modelling outputs are retained in the repository alongside the relevant PRs.

8. Roles

  • Engineering. Implement and operate the procedure on every change; raise design notes for material changes; participate in review.
  • Security Officer. Reviews security-sensitive designs and PRs; owns this procedure; reviews threat models; approves cryptographic changes.
  • Code authors. Hold individual accountability for the quality and security of the code they author; respond to review feedback.
  • Code reviewers. Hold individual accountability for the changes they approve; reject changes that do not meet the bar.

9. Compliance and enforcement

  • Compliance with this procedure is mandatory for all workforce members contributing to Glassbreak software.
  • Bypass or circumvention (for example, force-pushing past branch protection, applying infrastructure without a reviewed plan, committing secrets) is a violation of the Information Security Policy and is handled per the Sanctions & Disciplinary Policy.

10. Exceptions

Exceptions to this procedure require written approval by the Security Officer, recorded with a recorded expiry date and compensating controls. Open exceptions are reviewed at every annual policy review.

11. Review

This procedure is reviewed at least annually and after every material change to tooling, release pipeline, or the threat landscape. The next scheduled review is 27 May 2027.

12. Related documents

Counter-signed PDF copy available on request to compliance@glassbreak.io.

Stay Updated

Get product updates and security insights. No spam, unsubscribe anytime.

We respect your privacy. See our privacy policy.