Security Patterns

Problem

Security review happens after code is written and often after it is deployed, so defects are found when they are expensive to change and the release is already committed.

Pattern

Run automated checks in the developer's environment and in the merge request, with fast, specific, actionable output. Security becomes part of the definition of done rather than a later gate.

Implementation

• Pre-commit hooks for secret detection and formatting.
• SAST and dependency scanning on every merge request, scoped to changed files where possible.
• Findings reported inline in the merge request, not in a separate portal.
• Security review focused on design changes, informed by a lightweight threat model.

Problem

Scanners produce findings but nothing decides whether a release may proceed, so results are ignored or negotiated case by case.

Pattern

Define machine-evaluated thresholds per stage. Failures block promotion, and exceptions are explicit, owned and time-bound.

Implementation

• Standardise on machine-readable scan output.
• Encode thresholds as policy evaluated in the pipeline.
• Start with fixable critical findings only, then tighten.
• Record exceptions with owner, justification and expiry.

Problem

Any individual control can be misconfigured, bypassed or blind to a novel technique.

Pattern

Place independent controls at each layer — code, dependency, build, artefact, admission, network, runtime — such that each assumes the previous one may have failed.

Implementation

• Code and dependency scanning at commit.
• Signing and provenance at build.
• Admission verification at deploy.
• Network segmentation and runtime detection in production.

Problem

Standing broad privileges mean any compromised identity yields extensive access, and permissions accumulate over time.

Pattern

Derive access from workload or human identity, issue short-lived credentials, scope to specific resources, and review against actual usage.

Implementation

• OIDC federation for pipelines instead of stored cloud keys.
• One service account per workload with narrow role bindings.
• Dynamic database credentials with short leases.
• Periodic access review driven by usage data.

Problem

Perimeter-based trust means anything inside the network is implicitly trusted, so one foothold enables broad lateral movement.

Pattern

Every request carries a verifiable identity and is authorised at the point of access. Network position confers no privilege.

Implementation

• mTLS between services with workload identity certificates.
• Per-request authorisation using token claims.
• Default-deny network policy with explicit allows.
• Device and user posture checks for human access.

Problem

In-place patching produces configuration drift, undocumented state and hosts that cannot be reproduced.

Pattern

Build a versioned image, deploy it, and never modify running instances. Changes mean a new image and a rollout.

Implementation

• Golden images built in CI and scanned before promotion.
• Read-only root filesystems where the workload allows it.
• Rolling replacement instead of remote configuration changes.
• SSH access removed or heavily restricted and audited.

Problem

A deployed artefact usually cannot be traced back to a specific commit and build, so tampering is undetectable.

Pattern

Verified source, hermetic build, signed artefact with provenance, and verification enforced at deployment admission.

Implementation

• Protected branches and required review on the source repository.
• Ephemeral, pinned build environments.
• Signatures, SBOMs and provenance attestations per artefact.
• Admission policy that rejects unverified images.

Problem

Written standards are inconsistently applied and cannot be tested, so compliance is assessed manually and late.

Pattern

Encode each rule as a policy evaluated by an engine at multiple enforcement points, with the same rule used in CI and at admission.

Implementation

• Store policies in git with review and unit tests.
• Evaluate in CI against manifests and plans.
• Enforce at admission in clusters.
• Export violation reports as compliance evidence.

Problem

Direct cluster access for deployments means changes bypass review, and drift between intent and reality goes unnoticed.

Pattern

All desired state lives in git. A reconciler applies it and reverts manual changes. Humans lose direct write access to production.

Implementation

• Reconciler with narrow, namespace-scoped permissions.
• Protected branches and required review on the state repository.
• Encrypted secrets in git or references to an external secret store.
• Drift alerts when live state diverges from the declared state.

Problem

Compliance is assessed in periodic audits with manually collected evidence, which is expensive and only reflects a single point in time.

Pattern

Map each control to an automated check that runs on a schedule and stores dated, machine-readable evidence with defined retention.

Implementation

• Control-to-check mapping maintained in version control.
• Scheduled scans across cloud accounts, clusters and hosts.
• Evidence stored immutably for the audit retention window.
• Exception register with owners and expiry dates.

Problem

Each scanner has its own console, findings are duplicated across tools, and nobody owns closure.

Pattern

Normalise all scanner output into one system, deduplicate by component and asset, prioritise with exploitability data, and track ageing against SLAs.

Implementation

• Pipelines push results to a central aggregation platform.
• Assets carry ownership metadata for routing.
• Prioritisation combines severity, KEV/EPSS data and exposure.
• Dashboards track ageing and closure rate rather than open counts.