Security Engineering¶

Status: 🟢 Active  |  Owner: Security Engineering  |  Last Reviewed: 2025-Q4

Introduction¶

Security is not a layer applied on top of software — it is a property of how software is designed, built, and operated from the very beginning. Organisations that treat security as a phase-gate activity, reviewed only before production releases, consistently discover vulnerabilities late, fix them expensively, and repeat the cycle. Organisations that embed security into every stage of the development lifecycle find vulnerabilities earlier, fix them cheaply, and build a cumulative advantage in security posture over time.

This section documents the security standards and requirements that apply to all software development at this organisation. They are the product of collaboration between the Security Engineering team, legal and compliance, platform engineering, and engineering guilds. They reflect both regulatory obligations and hard-won lessons from our own incident history.

The Multi-Stage Security Model¶

Security checks are layered across five distinct stages. No stage replaces any other. Each catches a different class of issue at the earliest point it can be effectively detected. The cost of finding and fixing a vulnerability drops by roughly an order of magnitude with each stage it is found earlier.

┌──────────────┬──────────────┬──────────────┬──────────────┬──────────────┐
│   STAGE 1    │   STAGE 2    │   STAGE 3    │   STAGE 4    │   STAGE 5    │
│  Design &    │  Developer   │   Commit &   │  CI Pipeline │  Runtime &   │
│ Architecture │   Machine    │   Pre-Push   │ (Build/Test) │  Production  │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ Threat model │ SonarLint    │ Pre-commit   │ SAST (full)  │ DAST         │
│ STRIDE       │ Snyk IDE     │ hooks        │ SCA (full)   │ Pen testing  │
│ ASR meeting  │ Secret scan  │ Gitleaks     │ Container    │ CSPM         │
│ Security     │ Dep checks   │ IaC lint     │ scan (Trivy) │ Runtime mon  │
│ requirements │ (local)      │ Signed       │ SBOM gen     │ Audit logs   │
│              │              │ commits      │ Licence gate │              │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ Hours or     │ Seconds      │ Seconds at   │ Minutes per  │ Continuous   │
│ days before  │ during       │ commit       │ PR / merge   │ in           │
│ first line   │ development  │              │              │ production   │
│ of code      │              │              │              │              │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ Cost to fix: │ Cost to fix: │ Cost to fix: │ Cost to fix: │ Cost to fix: │
│ Minutes      │ Minutes      │ Minutes      │ Hours        │ Days–weeks   │
└──────────────┴──────────────┴──────────────┴──────────────┴──────────────┘

Stage 1 — Design & Architecture (the highest leverage)¶

Security engagement at the design phase is the most valuable activity in the entire lifecycle. Architectural decisions that introduce structural weaknesses — an unauthenticated internal API, a shared credential, unnecessary PII collection — are exponentially cheaper to correct in a design document than in deployed code.

Every new service, new external API surface, new authentication system, and every feature handling PII or payment data requires a formal Architecture Security Review before implementation begins. The ASR is a structured threat modelling session (STRIDE) that produces concrete, testable Security Requirements committed to the ADR and the Jira epic. It is mandatory input for the Architecture Review Board.

Stage 2 — Developer Machine (fast, context-rich feedback)¶

Security checks during active development provide the fastest feedback loop of any automated tool. Issues caught by the IDE take seconds to fix — the developer has full context, the change is in working memory, and no PR or CI run is needed.

Required IDE tools on every engineering workstation: SonarLint (real-time SAST, synced with CI ruleset), Snyk IDE extension (dependency CVE alerts inline in pom.xml, package.json, pyproject.toml), and local gitleaks hook. These are not optional enhancements — they are the first line of automated defence.

Stage 3 — Commit & Pre-Push (the last gate on the developer machine)¶

Pre-commit hooks enforce a consistent set of security checks on every git commit. They run in under 10 seconds and prevent security-sensitive content from ever leaving the developer's machine. The pre-commit framework is configured in every repository with required hooks for secret detection, IaC security linting, Dockerfile linting, and dependency auditing. Commits to main are additionally required to be cryptographically signed.

Stage 4 — CI Pipeline (comprehensive scanning of the full artefact)¶

The CI pipeline performs the deepest automated security scanning. Unlike IDE linting (file-level) and pre-commit hooks (staged changes, seconds), CI scans the fully assembled artefact — the complete dependency tree, the compiled binary, the container image — using full rulesets and live vulnerability databases. Security stages run in parallel with functional tests to avoid adding to pipeline duration. A security stage failure blocks merge to main with no exceptions.

CI security stages include: full Gitleaks + TruffleHog secret scan across commit history, SonarQube SAST with security quality gate, Snyk SCA with licence policy enforcement, Trivy container image scan (OS + application layers), Cosign image signing, and Syft SBOM generation.

Stage 5 — Runtime & Production (what automation cannot catch pre-deployment)¶

Runtime security monitoring catches exploitation attempts, anomalous behaviour, and vulnerabilities discovered after deployment. DAST runs against every staging deployment. Penetration testing is conducted annually and after significant architectural changes. Cloud Security Posture Management (CSPM) continuously assesses infrastructure configuration. Security-relevant events (authentication, authorisation decisions, privilege changes, bulk data access) are instrumented in all services and routed to an extended-retention security log stream.

Core Principles¶

Shift Left — Find Issues at the Earliest Possible Stage¶

Every security issue caught in Stage 1 or 2 avoids the cost of a CI failure, a PR rework, a vulnerability ticket, and potentially a production incident. The multi-stage model is designed to push detection as early as possible: architectural weaknesses caught in design, coding mistakes caught by the IDE, secrets caught at commit, dependency CVEs caught at build, configuration drift caught continuously.

Security by Default¶

Security controls must be the path of least resistance. Approved framework integrations handle authentication and encryption correctly out of the box. CI templates include all security scanning without any team configuration. Pre-commit hooks are installed automatically during onboarding. When the secure path is the easy path — and the insecure path is blocked by tooling — security posture improves without requiring engineers to make security-conscious decisions on every change.

Security in Architecture Reviews Is Mandatory, Not Optional¶

Threat modelling and security review are not activities that happen "when there's time" or "for sensitive features". They are required inputs to every significant architectural decision. The Architecture Security Review process defines exactly when a formal review is required, how to run it, and what it must produce. The Architecture Review Board will not approve an ADR without a completed ASR for systems that meet the mandatory trigger criteria.

Compliance Through Engineering, Not Paperwork¶

GDPR, SOC 2, and HIPAA impose real engineering requirements — on data handling, access control, incident management, and audit trail retention. This section translates those requirements into concrete engineering practices so that compliance is achieved as a side-effect of good engineering, not as a separate parallel activity.

What You Will Find Here¶

Last reviewed: 2025-Q4  |  Owner: Security Engineering