Platform Security Guardrails

Platform security guardrails are automated, policy-driven constraints that ensure consistent and secure infrastructure and application deployments across a platform. They are enforced at build, deploy, and runtime, catching security drift before it becomes a breach. They matter when multiple teams deploy to shared environments, when onboarding new developers, or when scaling systems beyond a single team’s ownership.

Enforcing Security Policies at Build Time

Build-time guardrails validate that code and configuration meet security requirements before artifacts are published. They run during CI, often as a dedicated step in a workflow.

Validate Container Images with Trivy

Trivy is a real, widely adopted scanner for container images. It produces structured output and is used across platforms.

trivy image --exit-code 1 --severity HIGH,CRITICAL --light --format json \
  --output /tmp/trivy-report.json \
  myapp:latest

• --exit-code 1: fail the build if any HIGH or CRITICAL vulnerability is found.
• --light: reduce output size by omitting details not needed for CI.
• --format json: enables integration with downstream tools.

The output includes a list of vulnerabilities, each with VulnerabilityID, Severity, PkgName, InstalledVersion, FixedVersion, and CVSS scores.

A common failure: missing --severity HIGH,CRITICAL causes builds to pass despite a critical flaw. The default severity in Trivy is UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL, but the --severity flag is case-sensitive and expects comma-separated values.

Enforce Image Provenance with Cosign

Cosign signs container images with cryptographic signatures, binding image content to metadata.

cosign verify --certificate-oidc-issuer https://auth.example.com \
  --certificate-oidc-claim sub=platform-admins \
  myapp:latest

• --certificate-oidc-issuer: verifies that the signing certificate was issued by a trusted identity provider.
• --certificate-oidc-claim sub=platform-admins: ensures the signer is a member of the platform-admins group.

A common failure: the --certificate-oidc-claim flag expects the claim to be sub (subject), but many use sub or subject interchangeably. The real OIDC claim is sub, and subject is not automatically mapped.

The verification succeeds only if:

• The image has a signature (cosign.sig) in the image layer.
• The signature is signed by a certificate chain that includes the issuer and the claimed subject.
• The signature is not expired.

A missing cosign.sig file leads to a silent failure: Error: no signature found.

Enforcing Security Policies at Deploy Time

Deploy-time guardrails validate that a deployment manifest aligns with security policies. They run during the deployment pipeline, typically after build and before rollout.

Validate Kubernetes Manifests with OPA Gatekeeper

OPA Gatekeeper is a real, open-source policy engine for Kubernetes.

Define a policy in Rego:

package kubernetes.policies

violation[message] {
  input.review.object.kind == "Deployment"
  input.review.object.spec.template.spec.containers[_].image == ""
  message := "Deployment must specify container image"
}

violation[message] {
  input.review.object.kind == "Deployment"
  container := input.review.object.spec.template.spec.containers[_]
  container.image == "alpine:latest"
  container.securityContext.runAsUser == 0
  message := "Deployment uses alpine:latest as image but runs as root"
}

Apply the policy via kubectl:

kubectl apply -f - <<EOF
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-team-label
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Deployment"]
  parameters:
    labels: ["team", "environment"]
EOF

The constraint applies to all Deployment objects and requires team and environment labels.

A common failure: the match block expects apiGroups and kinds as top-level keys, but developers often nest them under kinds as a single list. The correct structure is:

match:
  kinds:
    - apiGroups: ["apps"]
      kinds: ["Deployment"]

Failure to use apiGroups instead of groups or apiGroup causes the policy to not apply.

Another failure: parameters.labels expects a list of strings. A map instead of a list leads to a validation error:

{
  "error": "Invalid parameter: labels must be an array of strings",
  "expected": ["team", "environment"],
  "actual": {
    "team": true,
    "environment": true
  }
}

Enforcing Security Policies at Runtime

Runtime guardrails monitor deployed systems and enforce policies dynamically. They run continuously, often as part of a control plane.

Enforce Service Mesh Security with Istio

Istio enforces mutual TLS, traffic policies, and security configurations across a service mesh.

Define a PeerAuthentication resource to enforce mTLS between all services:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT
  selector:
    matchLabels:
      app: backend

• mode: STRICT: requires all inbound and outbound traffic to use mTLS.
• selector.matchLabels.app: backend: applies to all services labeled app: backend.

A common failure: the selector block expects matchLabels, but developers often use matchLabels or selector.labels. The correct key is matchLabels, and labels is ignored.

Another failure: the mode field accepts STRICT, PERMISSIVE, DISABLE, but STRICT is case-sensitive. Using strict or Strict causes the policy to not apply.

A silent failure occurs when a service has a Service object but no Deployment. The PeerAuthentication applies only to Deployment objects, but Istio uses app labels from Deployment to match Service objects. If the Deployment does not have app: backend, the mTLS is not enforced.

Enforce Secrets Management Policies

Secrets are a primary attack vector. Platform guardrails ensure secrets are correctly provisioned and managed.

Validate Secrets in Vault with curl and jq

Vault is a real, widely adopted secrets management system.

A deployment pipeline checks that all required secrets exist and have the correct structure:

curl -s \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  https://vault.example.com/v1/secret/database \
  | jq -e '
    .data.data.password
    | .data.data.host
    | .data.data.port
    | .data.data.ssl
  '

• jq -e: exit with code 1 if any check fails.
• data.data.password: ensures password is a top-level field in the secret.

A common failure: the pipeline assumes the secret is stored at secret/database, but the actual path is secret/data/database. The data field is missing, causing the pipeline to fail silently.

Another failure: the secret contains password, host, port, but ssl is optional. The pipeline expects ssl to be present, but ssl is true or false, and the key is ssl in the JSON, not ssl_enabled.

A silent failure occurs when the Vault server returns a 403 Forbidden but the pipeline logs only "Success" from curl. The jq command fails on data.data.ssl, but the curl exit code is 0 due to the response body.

Enforce Infrastructure-as-Code (IaC) Compliance

IaC guardrails ensure that infrastructure configuration files meet security and operational standards.

Validate Terraform Code with tflint

tflint is a real, command-line tool for validating Terraform configurations.

tflint --config-file .tflint.hcl \
  --module \
  --module-path ./modules \
  --module-depth 3

• --config-file .tflint.hcl: customizes rule sets and thresholds.
• --module: enables module-level validation.
• --module-path: sets the path to look for modules.
• --module-depth: limits how many levels deep to validate.

The .tflint.hcl configuration file might look like:

plugin "terraform" {
  enabled = true
  version = "0.15.0"
}

rule "terraform" {
  enabled = true
  severity = "error"
  config = {
    required_version = ">= 1.0.0"
    required_providers = {
      aws = ">= 4.0.0"
      azure = ">= 2.0.0"
    }
  }
}

A common failure: the required_providers block expects a map of provider names to version constraints, but developers often use a list of objects. The correct structure is:

required_providers = {
  aws = ">= 4.0.0"
  azure = ">= 2.0.0"
}

Using a list:

required_providers = [
  { name = "aws", version = ">= 4.0.0" },
  { name = "azure", version = ">= 2.0.0" }
]

causes tflint to fail with:

Error: Invalid configuration for required_providers
Expected: map[string]string
Actual: list(object({name, version}))

Another failure: --module enables module validation but does not recursively validate nested modules unless --module-depth is set. Without --module-depth 3, only the top-level module is validated.

Responding to Guardrail Failures

A guardrail failure is not just a build failure. It must be actionable.

When a Trivy scan fails:

{
  "errors": [
    {
      "id": "CVE-2023-1234",
      "severity": "CRITICAL",
      "package": "openssl",
      "installed": "3.0.1",
      "fixed": "3.0.2",
      "cvss": 9.8,
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1234"
    }
  ]
}

The CI system should:

• Mark the build as failed.
• Attach the Trivy report.
• Comment on the PR with a summary:
• "Critical vulnerability: CVE-2023-1234 in openssl (3.0.1). Upgrade to 3.0.2."
• Link to the NVD entry.

When a Gatekeeper policy fails:

• The status field in the ValidatingWebhookConfiguration includes results with message, details, severity, and error.

A failure like:

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "123456789",
    "allowed": false,
    "status": {
      "message": "Deployment must specify container image",
      "code": 400,
      "details": {
        "name": "Deployment.backend-app",
        "group": "apps",
        "kind": "Deployment",
        "causes": [
          {
            "type": "Required",
            "message": "container.image is required"
          }
        ]
      }
    }
  }
}

is consumed by the CI system to:

• Fail the deployment.
• Log the message and details to the deployment dashboard.
• Trigger a ticket in the incident management system.

Summary

Platform security guardrails are not a one-off policy. They are integrated into the CI/CD pipeline, the deployment process, and runtime monitoring. They require attention to detail: exact command flags, correct configuration keys, and awareness of silent failures. They are only as effective as the precision with which they are defined and monitored.

This page was rewritten on 18 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.