Threat Modeling Without the Brake Pedal: Turning Policies into Guardrails, Checks, and Proofs

The modernization sprint that didn’t derail the audit

We were mid-migration from ECS to EKS for a fintech client with a SOC 2 Type II window open and a GDPR DPIA breathing down our necks. Classic rock-and-hard-place: ship a payments API in two sprints, but don’t violate regulated-data constraints. The team had been burned by big-bang threat modeling before—sticky notes, never-read PDFs, and a pile of “to-dos” that never made it into Jira.

So we did it differently: we baked a lightweight threat model into the PR flow, translated policy into policy-as-code, and generated automated proofs as part of CI. Two weeks later the service shipped, the auditor got the evidence package, and no one pulled an all-nighter to redact screenshots.

Translate policy into guardrails engineers actually feel

Policies don’t fail because they’re wrong; they fail because they’re invisible until a change board says “no.” Turn each line from the PDF into a control you can test. A few common mappings we use at GitPlumbers:

• “Encrypt data at rest” → pre-approved IaC modules + OPA rules that reject unencrypted resources

• “No public buckets with PII” → OPA checks on Terraform + runtime drift detection

• “Rotate credentials” → Vault dynamic secrets + TTLs enforced in CI and Terraform

• “Log access to regulated data” → standardized sidecar/agent pattern pre-wired for your SIEM

Here’s a small rego example to enforce encryption and data classification on S3 via Conftest:

package terraform.s3

deny[msg] {

  input.resource_changes[_].type == "aws_s3_bucket"

  some rc

  rc := input.resource_changes[_]

  rc.type == "aws_s3_bucket"

  not rc.change.after.server_side_encryption_configuration

  msg := sprintf("S3 bucket %s missing SSE", [rc.address])

}



deny[msg] {

  some rc

  rc := input.resource_changes[_]

  rc.type == "aws_s3_bucket"

  classification := rc.change.after.tags.data_classification

  not classification

  msg := sprintf("S3 bucket %s missing data_classification tag", [rc.address])

}



deny[msg] {

  some rc

  rc := input.resource_changes[_]

  rc.type == "aws_s3_bucket_public_access_block"

  not rc.change.after.block_public_acls

  msg := sprintf("Public ACLs not blocked for %s", [rc.address])

}

And a Terraform snippet for an approved module that bakes in the good defaults so engineers don’t have to remember:

module "paved_s3" {

  source = "git::ssh://git@github.com/org/infra-modules.git//s3-paved?ref=v1.7.0"

  name   = "payments-pii"

  tags = {

    data_classification = "pii"

    owner               = "payments"

  }

  block_public_access = true

  force_sse            = true

  kms_key_alias        = "alias/org/pii"

}

The combo is the win: paved roads for 80% of use cases; policy-as-code to catch the rest.

Put checks in the developer path, not at the release gate

Stop making security a late-stage boss battle. Run fast checks in PRs, and reserve gates for high-risk violations. This GitHub Actions job catches the most common modernization misses without adding minutes to the build:

name: policy-and-security

on: [pull_request]

jobs:

  checks:

    runs-on: ubuntu-latest

    permissions:

      contents: read

      id-token: write

    steps:

      - uses: actions/checkout@v4



      # Static app and IaC scans

      - name: Semgrep

        uses: returntocorp/semgrep-action@v1

        with:

          config: p/ci



      - name: Checkov (Terraform/K8s)

        uses: bridgecrewio/checkov-action@v12

        with:

          directory: .

          framework: terraform,kubernetes



      - name: Conftest (OPA)

        uses: open-policy-agent/conftest-action@v1

        with:

          files: |

            terraform.plan.json

            k8s/

        # terraform plan -out and show -json should run earlier



      - name: Secrets scan

        uses: trufflesecurity/trufflehog@v3



      # Supply chain: verify SBOM + provenance

      - name: Install cosign

        uses: sigstore/cosign-installer@v3



      - name: Verify image attestation

        run: |

          cosign verify-attestation \

            --type spdx \

            --certificate-oidc-issuer https://token.actions.githubusercontent.com \

            --certificate-identity "repo:${{ github.repository }}:ref:refs/heads/${{ github.head_ref }}" \

            $IMAGE_REF

This pattern scales: fast feedback in PR; heavier gates (penetration tests, chaos drills) on release candidates or behind feature flags. If you’re on Kubernetes, pair this with OPA Gatekeeper or Kyverno so noncompliant manifests never hit the cluster.

Automated proofs: evidence that writes itself

If you’ve ever burned a week building an audit packet after the fact, you know the pain. Don’t screenshot dashboards—emit proofs as part of the pipeline and store them immutably.

• Attestations: cosign attest SBOMs and build provenance; push to a transparency log.

• Decision logs: OPA emits allow/deny decisions; ship to your SIEM with request metadata.

• Artifact integrity: sign container images and IaC bundles; verify before deploy.

• Change traceability: link Jira tickets to PRs and include the threat model delta.

Example: create SBOM + provenance and attach as attestations:

# Build image and SBOM

docker build -t ghcr.io/org/payments:${GIT_SHA} .

syft packages ghcr.io/org/payments:${GIT_SHA} -o spdx-json > sbom.json



# Sign and attest

cosign sign ghcr.io/org/payments:${GIT_SHA} --yes

cosign attest --type spdx --predicate sbom.json ghcr.io/org/payments:${GIT_SHA} --yes



# Record OPA decisions (Conftest)

conftest test terraform.plan.json --output json > evidence/opa_decisions.json



# Bundle evidence per release

jq -n \

  --arg sha "$GIT_SHA" \

  --arg time "$(date -Iseconds)" \

  --slurpfile opa evidence/opa_decisions.json \

  '{commit:$sha, time:$time, opa:$opa}' > evidence/release_${GIT_SHA}.json

We publish evidence to an immutable bucket with object lock or an append-only Git repo. Auditors love that it’s push-button repeatable, not a bespoke ritual.

Lightweight threat modeling that keeps up with sprints

The trick is to version the model with the code and focus on deltas. We drop a threatmodel.yaml at the repo root, scoped to the service. Engineers update it as part of the PR when they change data flows or exposed surfaces. CI then checks that high-severity threats have mapped mitigations.

service: payments-api

owner: payments

data_assets:

  - name: card_tokens

    classification: pii

  - name: logs

    classification: operational

trust_boundaries:

  - name: internet

  - name: cluster

  - name: pci_segment

flows:

  - from: internet

    to: payments-api

    protocol: https

    notes: TLS 1.2+ only

  - from: payments-api

    to: token-vault

    protocol: mTLS

    notes: Vault transit engine

threats:

  - id: STRIDE-REP-1

    type: spoofing

    description: Caller identity spoofed on public endpoint

    severity: high

    mitigations:

      - oauth2_m2m

      - rate_limit

      - WAF_ip_allowlist

  - id: STRIDE-DISC-2

    type: information_disclosure

    description: Logs accidentally capture PAN

    severity: high

    mitigations:

      - structured_logging_no_pii

      - sampling_and_redaction

tests:

  - control: oauth2_m2m

    check: semgrep

    ref: ci/semgrep.yml

  - control: structured_logging_no_pii

    check: unit

    ref: tests/log_redaction.spec.ts

Then a tiny script in CI fails PRs that add a high-severity threat without a mitigation:

#!/usr/bin/env bash

set -euo pipefail

missing=$(yq '.threats[] | select(.severity=="high") | select((.mitigations | length)==0) | .id' threatmodel.yaml)

if [[ -n "$missing" ]]; then

  echo "High-severity threats missing mitigations:"

  echo "$missing"

  exit 1

fi

I’ve seen teams waste days drawing perfect DFDs that go stale in a sprint. This YAML stays current because it lives in the same PR as the change.

Regulated data without freezing delivery

GDPR, HIPAA, PCI—pick your poison. The answer isn’t heroics; it’s encoding constraints into infra and app layers so devs can’t accidentally cross the streams.

• Classify at the edge: Tag every resource with data_classification and region. Drive ABAC policies from tags, not spreadsheets.

• Short-lived credentials: Use Vault dynamic creds and transit/transform for tokenization. Example:

# Tokenize PII with Vault Transform

curl -s --header "X-Vault-Token: $VAULT_TOKEN" \

  --request POST \

  --data '{"value": "4111111111111111"}' \

  $VAULT_ADDR/v1/transform/encode/card_pii

• Row-level security: Keep regional data from crossing boundaries at the database, not in app if/else spaghetti. Postgres makes this clean:

-- Classify and constrain by region

ALTER TABLE customers ENABLE ROW LEVEL SECURITY;

CREATE POLICY pii_by_region ON customers

  USING (region = current_setting('app.region', true))

  WITH CHECK (region = current_setting('app.region', true));



-- App sets region on connection

SET app.region = 'eu';  -- set via connection string or pooler

• Paved data patterns: Pre-approved connectors with TLS/mTLS, private networking, and logging already wired. Anything else needs a waiver.

These constraints speed you up because they remove decision fatigue. Engineers don’t debate; they consume the paved road.

Waivers, SLOs, and the “grown-up” loop

You’ll still hit edge cases. The key is to make exceptions explicit, temporary, and auditable.

Track waivers in-repo and make CI enforce expiry:

# .waivers/allow-public-egress.yaml

id: NET-EX-124

control: outbound_egress_restricted

risk: medium

owner: network-team

jira: SEC-482

reason: Partner IP allowlist pending

expires: 2025-12-15

And a tiny CI check to block expired waivers:

for f in .waivers/*.yaml; do

  exp=$(yq '.expires' "$f")

  if [[ $(date -d "$exp" +%s) -lt $(date +%s) ]]; then

    echo "Expired waiver: $f ($exp)"

    exit 1

  fi

done

Then measure what matters:

• MTTR for critical vulns (goal < 7 days)

• Policy drift (resources violating guardrails)

• Waiver SLA (percent of waivers expiring on time)

• Evidence freshness (attestations and SBOMs present for N% of releases)

We publish these to the same Grafana board product looks at. If the trendline is red, it’s everyone’s problem.

A two-week playbook that holds up in the real world

If you’re staring at a modernization sprint with regulated data in the blast radius, here’s a sequence that’s worked for us repeatedly:

1. Day 1: Add threatmodel.yaml and PR template; tag resources with data_classification and region.

2. Day 2: Wire Conftest, Checkov, Semgrep, and TruffleHog into PR checks; add fast-fail high-risk gates.

3. Day 3-4: Swap ad-hoc IaC for paved modules (encrypted storage, private networking, KMS).

4. Day 5: Turn on Postgres RLS (or your DB’s equivalent); prove reads are region-scoped in tests.

5. Day 6: Add Vault dynamic creds + transform for tokenization. Rotate any long-lived keys.

6. Day 7: Emit SBOMs and build provenance; sign and verify artifacts in CI.

7. Day 8-9: Backfill mitigations for any high-severity threats in YAML; add missing tests.

8. Day 10: Ship behind a feature flag; collect automated evidence and link to the release ticket.

It’s not magic. It’s a set of habits that let you move fast without betting the company on luck.