Security and Policy Patterns

Five patterns that underlie every security posture: defense-in-depth, policy-as-code, least-privilege, threat-modeling, and secrets-lifecycle.

Five patterns from the security discipline. Touched in Y2 Phase 12 (auth); deepens through Y3 Phase 27 (secrets + Kyverno).

Patterns in this category

PatternFirst touchedDEEP target
defense-in-depthY3 Phase 27Y3 end (mesh + secrets + policy)
policy-as-codeY3 Phase 27 (Kyverno)Y3 end
least-privilegeY2 Phase 12 + Y3 Phase 23 (IAM)Y3 end
threat-modelingY2 Phase 12Y3 (cross-cutting)
secrets-lifecycleY3 Phase 27Y3 end (Vault + ESO operational)

Why this category exists

Security patterns survive specific attack classes. Defense-in-depth is the layered-protection pattern that assumes any single layer can fail. Policy-as-code is the discipline that makes “we have a policy” verifiable rather than aspirational. Least-privilege is the foundational identity pattern that scopes every credential to what it actually needs. Threat-modeling is the systematic way to ask “what could go wrong” before code ships. Secrets-lifecycle is rotation + revocation + audit + encrypted-at-rest as a continuous discipline rather than a one-time setup.

These five are the load-bearing security primitives every platform team eventually formalizes. Individual tools come and go — SPIFFE, OPA, Kyverno, Vault, Sealed Secrets, External Secrets Operator — but the patterns beneath them stay stable. A platform engineer who understands the five patterns can evaluate any new security tool by mapping it back to which patterns it implements and which trade-offs it makes.

The category is scoped tightly. Only five patterns because security is a domain where breadth without depth is dangerous. Better to have five patterns operated at DEEP than fifteen at OUTLINE. The remaining security concerns (compliance frameworks, incident response, audit trails) sit closer to observability-and-ops or to operational documentation, not to the pattern library.

How to read this category

Two patterns first-fire in Y2. Three first-fire in Y3.

Y2 entry points: threat-modeling and least-privilege. Both first-fire at Phase 12 (auth). Threat-modeling as a design-time discipline; least-privilege as the concrete scope-your-tokens practice. Read STUB entries before Phase 12; OUTLINE by end of Y2.

Y3 deepening triad: defense-in-depth, policy-as-code, secrets-lifecycle. These three fire together at Phase 27, when the security posture goes from “auth works” to “the whole platform enforces layered protection.” All three should be DEEP by Y3 end.

Cross-cutting: threat-modeling returns in almost every year. Every OSS launch (Y3 terralabs, Y5 llm-gateway, Y5 Studio) needs a threat model. The pattern deepens through repetition, not through a single phase.

How the patterns connect

The five patterns compose as concentric rings.

  • threat-modeling is the design-time input. It generates the list of what needs protection and from whom.
  • defense-in-depth is the response. It structures protection into layers so a single failure doesn’t compromise the system.
  • least-privilege is the identity primitive that constrains what each participant can do at each layer.
  • secrets-lifecycle is the operational discipline that keeps least-privilege real over time (rotation prevents credentials from accumulating trust).
  • policy-as-code is the verification pattern that makes all of the above continuously enforceable.

The composition matters. Skipping policy-as-code means you can claim defense-in-depth without proving it. Skipping secrets-lifecycle means your least-privilege scopes decay into wildcard-privilege scopes. Skipping threat-modeling means you’re defending against generic attacks instead of the ones your system actually faces.

Where these show up in /root

  • Y2 Phase 12 — threat-modeling and least-privilege first-fire through auth: OAuth2 scopes, JWT claims, token expiry, refresh vs access tokens. The Phase 12 threat model becomes the first entry in your security notes.
  • Y3 Phase 23 — least-privilege deepens through cloud IAM. AWS IAM roles, GCP service accounts, policy documents. This is where the pattern becomes operational discipline rather than a design principle.
  • Y3 Phase 25 — least-privilege and defense-in-depth compose through Cilium mesh: mTLS between pods (mesh layer), NetworkPolicies (network layer), RBAC (K8s API layer), IAM (cloud layer). Four layers, one workload.
  • Y3 Phase 27 — the security-focused phase. All five patterns fire. Vault + External Secrets Operator for secrets-lifecycle. Kyverno for policy-as-code. Defense-in-depth as the framing that ties them together.
  • Y5 Phase 46 — least-privilege and secrets-lifecycle return in llm-gateway: rate limits per caller, scoped API keys, prompt-injection defenses at the mediator layer.
  • Y5 Phase 49 — defense-in-depth and threat-modeling return for AI-specific attacks: prompt injection, jailbreaks, data exfiltration through model outputs, supply-chain attacks on model weights.

By Year 5 you’ve done at least one threat model per OSS launch, operated Vault for two years, and enforced Kyverno policies against 100+ workloads. All five patterns are DEEP.

Anti-patterns

Anti-patternWhy
Threat-modeling once and never revisitingThe threat surface changes as the system grows. Every new integration, every new user role, every new external dependency shifts the model. Revisit at each phase; annotate what changed.
Policy-as-code without a break-glass procedureKyverno policies that block deployments must have a documented override for legitimate exceptions. A policy without a break-glass is a policy that eventually gets bypassed by disabling the tool.
Least-privilege at IAM but wildcard at the app layerCloud IAM scoped to the pod’s service account, then the app inside the pod runs as root. The IAM discipline was theatrical; the pod is the effective privilege boundary.
Secrets-lifecycle without auditRotation without an audit log is unverifiable. If you can’t prove which caller used which secret at which time, you can’t prove the rotation actually reduced blast radius.
Defense-in-depth as marketingIf every “layer” is enforced by the same policy engine reading the same data, they’re not independent layers — they’re one layer painted three colors. Real defense-in-depth requires independent failure modes at each layer.

Cross-references