The build
is the breach.

Your CI has more power than your CTO.

GitHub Actions, OIDC, and the contents:write problem

A GitHub Actions workflow runs with the permissions you give it. Almost nobody gives it the right ones. The default is too much. The common fix — federating into AWS via OIDC — is correct, and then half of teams attach a role that can do things the workflow has no business doing.

The pattern I see most: a deploy role with s3:* on the artifact bucket, ecr:* on every repo, and iam:PassRole on a wildcard. A compromised third-party action now has all of that, for as long as the OIDC token lives. Which is short, yes, but long enough.

What the workflow should say

# .github/workflows/deploy.yml
permissions:
  id-token: write     # OIDC
  contents: read      # the default write is wrong

jobs:
  deploy:
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::...:role/deploy-specific-service
          aws-region: us-east-1
          role-session-name: gh-${{ github.run_id }}

What the role should say

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::...:oidc-provider/token.actions.githubusercontent.com" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"
      }
    }
  }]
}

The sub claim is the piece everyone gets wrong. Without it, any workflow in any repo in your org can assume this role. Including the fork someone opened to demo a typo fix.

Pin by SHA. Not by tag. Not by branch.

Mutable references are a supply-chain invitation

A tag is a label someone can move. A branch is obviously a moving target. A commit SHA is the one thing nobody can rewrite without producing a different SHA. This is the entire thing.

# wrong — the maintainer, or someone who compromised them, can point v4 anywhere.
- uses: actions/checkout@v4

# right — this cannot change under you.
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1

The objection is always the same: "We'd have to update SHAs when new versions come out." Yes. Use Dependabot or Renovate with SHA pinning enabled. It opens a PR with the new SHA. You review it. You merge it. This takes less time than one incident.

Cache poisoning is a first-class attack now.

The build cache is a write surface you probably forgot about

If your CI caches node_modules, the Go module cache, Docker layers, or a Bazel remote cache, that cache is writable by any job that can populate it. A malicious job writes a poisoned artifact under the cache key. Every subsequent job on that key reads it. Nothing got rebuilt. The diff in your PR is clean. Production got a different binary.

I don't have a clean detection for this. I'll say so. The best you can do is:

• Scope cache keys so jobs from different branches don't share them. The default in most CI systems is too wide.
• Treat the cache as untrusted input. If you're pulling a cached dep, verify its hash against a lockfile that's in the source tree.
• For anything that ships to production: do a fresh build from a clean cache at least weekly, compare the output, and raise hell if it differs.

An SBOM nobody verifies is a receipt for a crime.

SBOMs, signatures, and the step you probably skipped

A software bill of materials lists what went into a build. Signing the SBOM and publishing it is table stakes now. The step most teams skip is verifying the signature at deploy time. If you don't verify, the SBOM is decorative. A determined attacker will produce a plausible one.

The pattern that works:

• Build produces artifact + SBOM + signature. Signing uses Sigstore, keyed to the workflow's OIDC identity.
• Registry (ECR, GHCR, whatever) stores all three.
• Deploy-time admission controller verifies the signature against an expected identity before letting the artifact run. In Kubernetes this is policy-controller or Kyverno.
• If verification fails, the pod doesn't start. This is the whole point.

Admission policy example

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: signed-by-our-ci
spec:
  images:
    - glob: "ghcr.io/your-org/*"
  authorities:
    - keyless:
        identities:
          - issuer: "https://token.actions.githubusercontent.com"
            subject: "https://github.com/your-org/your-repo/.github/workflows/release.yml@refs/heads/main"

DNS is an exfil channel. Still. Forever.

Route 53 Resolver logs & the shape of a slow leak

If an attacker can resolve DNS from inside your environment, they can exfiltrate data over DNS. Encode the payload into subdomain labels, send queries to an authoritative server they control, reassemble on the other side. It's slow. It works. It bypasses most egress controls because DNS is the one thing that always has to work.

The detection isn't exotic. The signal is: very long subdomains, very high query volume to one domain, entropy in the labels.

Detection query (Route 53 Resolver logs)

SELECT query_name, COUNT(*) AS n, AVG(LENGTH(query_name)) AS avg_len
FROM resolver_logs
WHERE query_timestamp > current_timestamp - interval '1' hour
GROUP BY query_name
HAVING AVG(LENGTH(query_name)) > 40
    AND COUNT(*) > 100
ORDER BY n DESC;

Tune the thresholds to your environment. Legitimate CDNs and analytics vendors produce long subdomains. You'll need an allowlist. Building that allowlist is the actual work; the query is easy.

IR under regulatory pause.

The clock starts when legal says it starts

This one isn't technical. It's the lesson the novel spends the most time on and the one practitioners know least about until they're in it.

When you have a confirmed breach with customer data involved, the incident-response clock you care about isn't the one in your runbook. It's the one your regulator cares about. GDPR gives you 72 hours from awareness. Some U.S. state laws are shorter. SEC rules for public companies are four business days after materiality determination. Your legal team will tell you when awareness or materiality is officially established — and that moment is when the clock starts, not before.

Practical consequences:

• Your IR documentation is now legal documentation. Write it like someone will read it in court. Timestamps, sources, decisions, who made them.
• There will be a period between "we think something happened" and "we officially know something happened" where your team needs to keep investigating but can't act in a way that constitutes confirmation. Your legal team will define the line. Ask them in advance.
• The attacker may still be in the environment during this period. You may be asked to watch and not evict. This is legal strategy and it is agonizing.