Platform Engineering 10 - Security and Governance

Guardrails vs Gates

Traditional security processes operate as gates. Developers build something, submit it for security review, wait three weeks, receive findings, fix the issues, resubmit, and wait again. Because verification happens all at once at the end of the process, it inevitably becomes slow and creates bottlenecks.

Platform engineering transforms these gates into guardrails. Instead of blocking at the end, the approach guides developers throughout the entire process.

When guardrails are properly built, the safe way becomes the easiest way. Developers don't need to consciously think about security -- simply following the golden path naturally satisfies security requirements.

Shift-Left Security

Shift-left means moving security checks from the later stages of the development lifecycle to the earlier stages.

Traditional:  code --> build --> test --> deploy --> security review (too late)
Shift-left:   security checks <-- <-- <-- <-- embedded at every stage

In concrete terms, IDE linters detect secret leaks before code is even committed. Pre-commit hooks block credentials from entering version control. At the CI stage, dependency scanning, static analysis (SAST), and image scanning run automatically. At deployment time, admission controllers enforce policies.

Because the entire process is fast and automated, security issues can be discovered and fixed in seconds rather than days. Considering that the cost of fixing a problem grows exponentially the later it is found, it becomes clear why shifting left matters so much.

Policy as Code

Manual reviews do not scale as teams and services grow. There is a physical limit to how many deployments a person can individually review.

Policy as code solves this by expressing security rules as executable code that runs automatically. OPA (Open Policy Agent) is a general-purpose policy engine applicable across diverse environments, while Kyverno is a Kubernetes-native policy tool specialized for cluster environments.

# Kyverno: no container runs as root
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root
spec:
  rules:
    - name: check-runAsNonRoot
      match:
        resources:
          kinds: [Pod]
      validate:
        message: "Containers must not run as root"
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

Once a rule is written as code, it applies automatically from that point forward. There is no longer a need to rely on human memory or checklists. Because the rules are code, they can be version-controlled, their change history can be tracked, and they can go through review and testing before deployment.

Supply Chain Security and Secret Management

No matter how secure the code you write is, if a dependency contains a vulnerability, the entire system is at risk. Your code is only as secure as its dependencies.

SBOM (Software Bill of Materials) generates a complete list of all components at build time, providing transparency into what is included. Image scanning catches known vulnerabilities before deployment. Cosign verifies through cryptographic signatures that images have not been tampered with, and dependency pinning explicitly locks versions to prevent supply chain attacks.

Secret management is another critical area that the platform must address. Secrets must be stored in a secure store and must never be included in code. Vault is the most widely used centralized secret storage solution. Sealed Secrets allows secrets to be stored in Git in encrypted form. External Secrets Operator automatically syncs secrets from external stores into Kubernetes.

When the platform team embeds all of these tools into the standard pipeline, each team works in a security-hardened environment by default without having to configure anything themselves.

RBAC

Environment-level access control is another area the platform should provide by default. Dev and staging environments allow free deployment, while production requires an approval process. Each team has access only to its own namespaces, preventing accidental impact on other teams' resources.

When a new team onboards, namespaces and roles should be created automatically -- through the platform's self-service capabilities, not through an infrastructure request ticket sitting in a queue for a week.

Next Up

A security model that depends on developers remembering the right thing to do every time will inevitably fail as an organization scales. When scanning, policy enforcement, and secret management are embedded in the golden path by default, compliance is achieved without friction.

In the next post, we cover how to build a platform team.