Blast radius: limit what one breach can reach

Why this area matters

Most large breaches are not one bug but a chain: a foothold in one service, then credentials or network access that reach far more than that service needed. Least privilege (CWE-250, CWE-269) and segmentation are what break the chain, and both are now largely written as code — IAM policies, Kubernetes RBAC, network policies, service credentials.

Scanners flag a wildcard in an IAM policy, but can't tell whether it belongs to a break-glass admin role or a worker that only needs one bucket. The blast-radius agent reads what the code actually does with the credential and compares it to what it was granted.

What goes wrong in real applications

• Over-privileged service credentials

  A worker with Action "*" on Resource "*" turns any bug in that worker into control of the whole account.

• Shared credentials across services

  One key used by many services means a leak from the least important one exposes all of them, and rotation breaks everything at once.

• Bulk data access paths

  Export-all endpoints and unscoped database users let a single compromised session or token copy entire datasets.

• Flat networks

  Without network policies or security-group boundaries, a compromised pod or host can reach every database and internal API directly.

Sample: the risky pattern and the fix

resource "aws_iam_role_policy" "thumbnail_worker" {
  role = aws_iam_role.thumbnail_worker.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = "*"
      Resource = "*"
    }]
  })
}

resource "aws_iam_role_policy" "thumbnail_worker" {
  role = aws_iam_role.thumbnail_worker.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = ["s3:GetObject", "s3:PutObject"]
      Resource = "arn:aws:s3:::acme-uploads/thumbnails/*"
    }]
  })
}

The thumbnail worker only reads and writes images in one prefix, but the policy grants every action on every resource, so a bug in an image library becomes full account access. The fix grants the two actions it uses on the one path it touches.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• IAM policies, Kubernetes RBAC and service accounts with wildcard actions or resources
• Long-lived admin or root credentials referenced from application code
• The same credential reused across services and environments
• Bulk-export and "all records" endpoints, and database users without scoping
• Missing network policies or security-group boundaries in IaC

Scope and limits

• It reviews permissions as declared in code and IaC. It doesn't enumerate live cloud accounts, test lateral movement or simulate an intrusion.
• Permissions granted outside the repository — console changes, organization policies, inherited roles — aren't visible.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Blast radius & data exposure — Assesses how much damage a compromise of this code could cause, and how to shrink it.
• Cloud security — Checks cloud resources for public exposure, wildcard IAM and long-lived keys.
• Secrets & data exposure — Judges whether a flagged value is really a secret and whether sensitive data leaks through logs or errors.