Compliance Isn't Optional — It's Just Unwritten

A platform should make it easy to deploy compliant software and impossible to deploy non-compliant software. That’s the whole job.

The problem

Every engineer deploying a service has a mental checklist. It might be formal — “NIST 800-53 requires encrypted transit” — or it might be informal — “all services must declare their dependencies” or “images must be signed before they hit production.” Either way, there’s a set of rules that the deployment should follow.

The word for that is compliance. Not the quarterly-audit, fill-out-a-spreadsheet kind. The “this is how things are done here” kind.

The gap: nothing enforces it. The checklist lives in someone’s head, or in a wiki page that hasn’t been updated in two years, or in a Slack thread that three people saw. A new engineer joins, deploys a service, skips the checklist — not out of malice, but because they didn’t know it existed. The service works. It’s in production. It’s missing network policies, it’s using a tag instead of a digest, and it’s pulling secrets from a hardcoded path instead of the platform’s secret backend.

Nobody notices until the audit. Or the incident.

The insight

There is no such thing as “no compliance.” Every organization has rules about how software should be deployed. The question is whether those rules are:

1. Implicit — in someone’s head, enforced by code review and tribal knowledge
2. Documented — in a wiki, enforced by honor system
3. Codified — in the platform, enforced by the compiler

Most organizations are at level 1 or 2. They have compliance. They just can’t prove it, and they can’t prevent violations.

The platform’s job is to move rules from implicit to codified. Not all at once — incrementally, starting with the rules that matter most.

What “codified compliance” looks like

A rule in someone’s head: “all services should have network policies.”

Documented: a wiki page says “add a NetworkPolicy to your deployment.” Some teams do. Some don’t. Nobody tracks who’s compliant.

Codified: the derivation pipeline produces a CiliumNetworkPolicy for every service, derived from its dependency declarations. There is no “add a NetworkPolicy” step because the developer never writes one. The platform produces it. The rule isn’t a guideline — it’s a property of the system.

In the same way a compiler turns high-level code into safe machine instructions, the platform turns developer intent into compliant infrastructure. The developer writes “I need a service with these dependencies.” The platform derives the NetworkPolicies, the AuthorizationPolicies, the ExternalSecrets, the mTLS configuration — all the resources that make the deployment compliant. The developer doesn’t skip the compliance step because there is no compliance step. It’s built into the compilation.

graph LR
    A["In someone's head\n(hoped for)"] --> B["In a wiki\n(sometimes followed)"]
    B --> C["In code review\n(caught maybe)"]
    C --> D["In the platform\n(guaranteed)"]
    style A fill:#4a1a1a,stroke:#888
    style B fill:#4a3a1a,stroke:#888
    style C fill:#3a4a1a,stroke:#888
    style D fill:#1a4a2a,stroke:#888

The further right you are on this spectrum, the fewer surprises you get during audits — and the fewer incidents caused by someone skipping a step they didn’t know about.

This applies at every level

Formal compliance (NIST 800-53, SOC 2, CIS benchmarks). The platform maps controls to features. AC-4 (Information Flow Enforcement) maps to bilateral agreements and default-deny network policies. SC-8 (Transmission Confidentiality) maps to mTLS via the mesh. The compliance controller probes these continuously — not once a quarter, but every hour.

Internal policy. “All images must be signed.” The DeployImage Cedar gate (Cedar is a policy-as-code engine — think OPA but with a forbid-overrides-permit model) enforces this at derivation time. An unsigned image doesn’t produce a Deployment. The rule isn’t documented — it’s compiled.

Team conventions. “Every service must declare its dependencies.” The bilateral agreement model enforces this — if you don’t declare an outbound dependency, default-deny blocks the traffic. You can’t quietly call a service you didn’t declare. The convention isn’t “please list your dependencies in a wiki” — it’s a structural requirement of the compilation model. Skip it and your service can’t talk to anything.

Unwritten norms. “Services should have health checks.” The derivation pipeline adds default liveness and readiness probes if the developer doesn’t specify them. The norm isn’t unwritten anymore — it’s a default.

The real objection

“This sounds like bureaucracy encoded in software.”

Fair. And the answer is: yes, that’s exactly what it is. The question is whether you prefer your bureaucracy to be enforced consistently by a compiler, or inconsistently by humans who are busy, tired, and context-switching between six other things.

Every organization has rules. The ones that are enforced by tooling get followed. The ones that are enforced by process get followed sometimes. The ones that are enforced by nothing get followed until someone’s in a hurry — which, in production, is always.

The platform doesn’t create compliance requirements. It codifies the ones that already exist. The senior engineer who “knows better” — who always adds the NetworkPolicy, always uses a digest, always configures the health check — is the person whose knowledge the platform captures. The platform is that engineer’s judgment, automated.

The spectrum, not the binary

This isn’t all-or-nothing. You don’t need to codify every rule on day one. Start with the rules that cause the most incidents when violated:

• Network policies. A service without them is reachable by everything in the cluster.
• Image signing. An unsigned image is an unverified image.
• Secret routing. A hardcoded secret is a secret that can’t be rotated.
• mTLS. Plaintext internal traffic is traffic anyone on the network can read.

These four cover most of the “someone skipped a step and it burned us” incidents. Codify them first. Add more as the platform matures and the team identifies the next most common violation.

The goal isn’t to build a cage. It’s to pave a road. The paved road is compliant by default — you follow it and everything works. Escape hatches exist for the edge cases, so teams that need to deviate don’t bypass the platform entirely. But the escape hatches are visible, auditable, and require explicit authorization. Deviation is possible. Accidental deviation is not.

Key takeaways

• Every organization has compliance requirements — most are just unwritten. The platform’s job is to codify the rules that already exist in engineers’ heads, wikis, and Slack threads.
• Codified rules are enforced by the compiler, not by humans. A NetworkPolicy that’s derived from dependency declarations can’t be skipped. A wiki page that says “add a NetworkPolicy” absolutely can.
• Start with the rules that cause the most damage when violated. Network policies, image signing, secret routing, mTLS. Codify these first, expand later.