Skip to main content

Secure Development Policy (A.8.25)

Document ID: secure-development-policy
Version: 1.0
Effective from: 2025-01-01
Owner: ISMS owner
Review cycle: Annual

note

This document is aligned to ISO/IEC 27001:2022 Annex A as a self-assessment. SigmaShake holds no ISO 27001 certification.

Purpose​

Define security requirements embedded throughout the software development lifecycle (SDLC) for SigmaShake's cloud-native TypeScript, Go and Elixir codebase.

Secure-by-default principles​

  1. No secrets in code — No secret lives in source code. Secrets live in the SigmaShake vault service, in Cloudflare Secrets Store bindings, or as Cloudflare Worker secrets (see sigmashake-compliance/wrangler.toml). The governance hook (ssg hook eval) blocks template-literal SQL interpolation (no-sql-interpolation in ts_write_safety.rules) and hardcoded secret patterns (secrets-guard.rules) at write time.
  2. Input validation — All API inputs validated at route entry before reaching application logic. External data treated as untrusted.
  3. No eval — Cloudflare Workers block eval at runtime.
  4. Dependency pinning — The lockfiles that exist are committed: bun.lock (TypeScript), go.sum (Go) and mix.lock (Elixir). The dep-vulns collector polls GitHub Dependabot alerts daily.

Development workflow​

Branch protection​

  • Target: main takes changes by pull request (PR) with one review. No verified control enforces this today, and direct pushes to main are not blocked. The monorepo uses a trunk workflow. The target limits direct pushes to the ISMS owner and the emergency category (attested). As of 2026-10-11 the branch protection state is not yet verified (open action). See the Change Management Policy, section on branch protection.
  • GitHub branch protection is intended to require PR review. The branch-protection collector records the observed GitHub settings daily as evidence only. It does not enforce the rule and opens no gap.
  • Signed commits encouraged

Code review checklist​

Before merging any change (the PR step applies only where a PR is used):

  • No secrets or PII in diff
  • SQL queries use parameterised bindings (.bind())
  • New external inputs validated
  • No new any types without justification
  • Evidence collectors updated if controls change

Dependency management​

  • dep-vulns collector runs daily and reports Dependabot alerts
  • Patch deadlines follow the severity table in the Vulnerability Management Procedure: Critical within 72 hours, High within 7 days, Medium within 30 days
  • Dependencies reviewed for licence compatibility before adoption

Pre-commit governance​

The ssg hook eval daemon evaluates every Write/Edit/Bash tool call against .sigmashake/rules/ governance rules. This provides a per-operation compliance gate for AI-assisted development.

Active rules:

  • no-sql-interpolation (in ts_write_safety.rules) — blocks raw SQL template literals
  • ts_write_safety — blocks dangerous TypeScript patterns
  • secrets-guard — blocks hardcoded API keys and private keys in written files, and reads of secret files

Threat modelling​

Architecture decisions are captured in THREAT_MODEL.md. Significant changes to data flows or trust boundaries require updating the threat model (A.8.27, architecture-review attestation).

Security testing​

  • Static analysis: TypeScript typecheck (bun run typecheck) run locally before merge. No CI runs on pull requests, so no automated per-PR gate exists
  • Dependency scanning: dep-vulns collector (polls Dependabot alerts)
  • Security testing: AI-assisted internal security review (Claude Opus 4.8, Anthropic) — not a third-party penetration test. An annual external pentest is planned but has not yet been performed (see pen-test-report collector).

Evidence​

CollectorCadenceControl
branch-protectionDailyA.8.25, A.8.26, A.8.31
dep-vulnsDailyA.8.7, A.8.8, A.8.26, A.8.29
rule-eval-integrityDailyA.5.36, A.8.28
merge-activityDailyA.8.25, A.8.32
pen-test-reportQuarterlyA.5.35, A.8.29 — planned; no third-party penetration test performed yet.