Threat Modeling at Sprint Speed: Turn Policy into Guardrails, Checks, and Attestations

The migration that burned three sprints

I watched a payments team lift-and-shift from EC2 autoscaling groups to EKS. Architecture looked clean. We had IaC, GitOps, canaries—the whole playbook. Then security rolled in with a 30-page threat model in Word, a spreadsheet of controls, and a review queue. Three sprints later, morale was toast and the backlog was growing barnacles.

I’ve seen this fail at unicorns and at banks. The fix isn’t a tiger team or a magical platform. It’s treating threat modeling like a sprint ritual and translating policy into code so the pipeline proves compliance for you. If you can ship a feature behind a feature flag, you can ship a control behind a guardrail—without slowing a damn thing down.

Turn policies into code (not meetings)

Your auditors speak in control IDs; your engineers speak in pipelines, Deployments, and terraform plan. Bridge the gap by mapping each policy to a machine-checkable rule, and run those rules in CI/CD.

• Map frameworks to rules:
  • SOC 2 CC6.6 → no public S3 buckets (checkov:CKV_AWS_20)
  • HIPAA 164.312(a)(2)(iv) → encryption at rest (OPA rule on terraform plan)
  • ISO 27001 A.12.4 → log redaction (semgrep rule to block PII logs)
• Put control IDs in rule metadata so audit trails write themselves.

Enforce data classification as a first-class label. Make it unavoidable in code and clusters.

# kyverno: require data-classification tags on k8s resources
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-data-classification
spec:
  validationFailureAction: enforce
  rules:
  - name: require-label
    match:
      resources:
        kinds: ["Namespace","Deployment","StatefulSet","Job","CronJob"]
    validate:
      message: "metadata.labels.data-classification must be one of public|internal|restricted"
      pattern:
        metadata:
          labels:
            data-classification: "?^(public|internal|restricted)$"

Check Terraform plans with OPA/Conftest so bad infra never lands.

# policy/terraform/enc.rego
package policy.terraform

deny[msg] {
  some i
  rc := input.resource_changes[i]
  rc.type == "aws_s3_bucket"
  not encrypted_bucket(rc)
  msg := sprintf("Bucket %v missing SSE-KMS", [rc.name])
}

encrypted_bucket(rc) {
  rc.change.after.server_side_encryption_configuration.apply_server_side_encryption_by_default.sse_algorithm == "aws:kms"
}

deny[msg] {
  some i
  rc := input.resource_changes[i]
  rc.type == "aws_db_instance"
  not rc.change.after.storage_encrypted
  msg := sprintf("RDS %v missing storage_encrypted=true", [rc.name])
}

Kill PII-in-logs at review time with Semgrep.

# semgrep.yml
rules:
- id: pii-log
  languages: [python]
  message: "Don't log request bodies; potential PII. Use structured redaction. (HIPAA-164.312(b))"
  severity: ERROR
  patterns:
    - pattern: logging.$LEVEL($MSG)
    - metavariable-pattern:
        metavariable: $MSG
        patterns:
          - pattern: request.$ANY()

Sprint ritual: a 60-minute threat model that sticks

Don’t schedule a committee. Do this, per epic, inside the sprint.

1. Diff the data flow: what systems, networks, or third parties changed? Update a quick diagram (C4 or a simple README.md SVG).
2. Flag trust boundaries: authN, authZ, data egress, secrets, storage, logs.
3. Classify data touched: public, internal, restricted (PII/PHI/PCI). One label drives policy.
4. Write 2–4 abuser stories: how would an attacker abuse this path?
5. Convert abuser stories into acceptance criteria you can test.
6. Wire the checks: link rule IDs to CI jobs that must pass.

Make it visible in the PR. Don’t hide it in Confluence.

# .github/pull_request_template.md

### Threat Model Delta
- Data classification touched: [ ] public [ ] internal [x] restricted
- Trust boundary changes: API -> Warehouse added
- Abuser story addressed: "Exfiltrate PII via logs"

### Security Acceptance Criteria
- [x] No PII in logs (`semgrep:pii-log` green)
- [x] S3 buckets encrypted (policy: CT-001)
- [x] Services labeled with data-classification (kyverno: require-data-classification)

Tag endpoints with data classification so the linter knows what to enforce.

# openapi.yaml
paths:
  /users:
    get:
      summary: List users
      x-data-classification: restricted
      responses:
        '200':
          description: OK

If it’s not in the PR, it won’t make the sprint review. Keep the model where the code lives.

Automated proofs and attestations, or it didn’t happen

Auditors don’t want promises; they want evidence tied to a change. Generate it automatically in CI.

• Reusable workflow per repo (or org-level) that runs policy scans.
• Emit JSON with rule IDs, pass/fail, and control mappings.
• Sign the results and attach as an attestation to the image or commit.
• Upload to an immutable evidence bucket.

# .github/workflows/policy.yml
name: security-policy
on:
  workflow_call:
    inputs:
      data_classification:
        required: true
        type: string
jobs:
  policy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Terraform plan
        run: |
          terraform -chdir=infra init -input=false
          terraform -chdir=infra plan -out=plan.out
          terraform -chdir=infra show -json plan.out > plan.json
      - name: Conftest
        uses: instrumenta/conftest-action@v0.3
        with:
          files: plan.json
          policy: policy/terraform
      - name: Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: semgrep.yml
      - name: Collect results
        run: |
          jq -n '{controls: ["CT-001","CT-002"], results: {opa: "pass", semgrep: "pass"}}' > policy-results.json
      - name: Cosign attest
        env:
          COSIGN_EXPERIMENTAL: "true"
        run: |
          echo "$COSIGN_KEY" > cosign.key
          cosign attest \
            --predicate policy-results.json \
            --type gitplumbers.policy.v1 \
            --key cosign.key \
            ${{ github.sha }}
      - name: Upload evidence
        run: |
          aws s3 cp policy-results.json \
            s3://compliance-evidence/${{ github.repository }}/${{ github.sha }}/policy-results.json \
            --sse aws:kms --sse-kms-key-id $KMS_KEY

Now your deploy has a signed proof that controls CT-001/CT-002 passed. When audit asks “show me encryption at rest for release 2025-10-01,” you point at the attestation and the evidence bucket. Conversation over.

Regulated data without killing velocity

The fastest way to lose weeks is to treat all data like PHI. Classify once and let guardrails do the rest.

• public: permissive defaults, broad egress, standard logging.
• internal: authenticated access, no public buckets, moderate logging.
• restricted (PII/PHI/PCI): encryption by default, private networks, no raw logs, DLP checks.

Drive it from tags and labels in code.

# terraform: encrypted S3 for restricted data
resource "aws_kms_key" "pii" {
  description = "PII at rest"
}

resource "aws_s3_bucket" "pii" {
  bucket = "acme-pii-${var.env}"
  tags = {
    data-classification = "restricted"
    owner               = "data-platform"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "pii" {
  bucket = aws_s3_bucket.pii.id
  rule {
    apply_server_side_encryption_by_default {
      kms_master_key_id = aws_kms_key.pii.arn
      sse_algorithm     = "aws:kms"
    }
  }
}

Augment with runtime guardrails:

• Kubernetes: Kyverno policy above + NetworkPolicies that deny egress by default in restricted namespaces.
• CI: Block app images without SBOMs (Trivy) when data-classification=restricted.
• Data: Use synthetic data (Tonic.ai/Gretel/Delphix) for dev/test; detect drift with gitleaks and aws macie in scheduled jobs.
• Secrets: Centralize in HashiCorp Vault with short TTLs, annotate access in evidence logs.

You’re not slowing teams—you’re letting data-classification select the right preset and letting automation do the nagging.

Measure delivery and security together

If security wins and delivery loses, you still lose. Track both.

• DORA: deployment frequency, lead time for changes, change fail rate, MTTR.
• Security posture: policy pass rate per PR, mean time to evidence, number of blocking vs advisory checks, % repos enrolled in reusable workflow.
• Regulated-data KPIs: % restricted workloads with encryption and private egress, % services with mandatory labels, PII-in-logs incidents.

Targets we’ve hit without slowing teams:

• 95% policy pass rate on first PR within 4 weeks.
• Mean time to compliance evidence < 2 minutes per build.
• Change fail rate unchanged or improved due to early detection.

Report this in the same weekly you use for burn-up charts. Security stops being a moral victory and starts being an engineering metric.

What we automate in week one (so you don’t have to)

When GitPlumbers parachutes into a modernization sprint, we don’t start with a workshop series. We ship the guardrails and the proof pipeline.

• A mapped control matrix with rule IDs tied to SOC2/ISO/HIPAA.
• A central security-policy GitHub Action you can call from any repo.
• A library of OPA/Kyverno/Semgrep/Checkov rules with clear owners.
• Evidence plumbing: signed attestations (Sigstore/cosign), immutable S3 bucket, index by commit/SHA/environment.
• Lightweight threat model templates for PRs and epics.

You end up with fewer meetings, faster merges, and audit answers that take seconds—not weeks.

If you want help wiring this into your stack without halting your roadmap, bring us into one sprint and we’ll leave you with working guardrails, not a slide deck.