Skip to content

IAM Blast Radius post: rephrase the closing line #91

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rivassec merged 1 commit into from
Oct 10, 2026
Merged

IAM Blast Radius post: rephrase the closing line #91

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions content/iam-blast-radius-github-action.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
Title: IAM Blast Radius in CI: Designing a Gate That Fails Closed
Date: 2026-10-09
Modified: 2026-10-09
Modified: 2026-10-10
Author: Oliver Rivas
Category: DevSecOps
Tags: aws, iam, github-actions, ci-cd, devsecops, cloud-security
Expand All @@ -13,7 +13,7 @@

Most IAM risk does not arrive as one obviously dangerous policy. It accumulates: the wildcard added "temporarily", the `iam:PassRole` without an `iam:PassedToService` restriction, the trust policy that quietly gains another account. Each change looks reasonable on its own. Combined with the permissions and trust relationships already in place, it can substantially expand what a compromised identity could reach.

The problem is not that engineers cannot read JSON. It is that reviewing individual permissions is not the same as reasoning about their consequences.

Check warning on line 16 in content/iam-blast-radius-github-action.md

View workflow job for this annotation

GitHub Actions / scan markdown 

antithesis-period-split: is not that engineers cannot read JSON. It is

The [IAM Blast Radius analyzer](/tools/iam-blast-radius/) does that reasoning in a browser tab, without sending the policy anywhere. That helps when someone already suspects a policy. It does nothing for the change nobody looked at twice. So the same engine now ships as a GitHub Action on the [GitHub Marketplace](https://github.com/marketplace/actions/iam-blast-radius), and the analysis moves into the pull request.

Expand Down Expand Up @@ -133,7 +133,7 @@

This does not replace the architecture work. As I argued in [IAM Blast Radius Is an Architecture Problem, Not a Policy Problem](iam-blast-radius-architecture-problem.html), most of the risk is decided before anyone opens a JSON file: account boundaries, trust relationships, which pipeline can reach production. A policy gate cannot fix a flat account structure.

What it can do is hold the line on drift, in the place where drift happens. It does not promise that every passing policy is safe, and it cannot guarantee that every risky change is detected. It promises something narrower and more useful: an enforceable, auditable check that names potential permission risk during review, and refuses to approve what it could not analyze.
What it can do is hold the line on drift, in the place where drift happens. The promise is deliberately narrow: an enforceable, auditable check that names potential permission risk during review, and refuses to approve what it could not analyze. It does not certify that a passing policy is safe, or that every risky change gets caught.

## Try it

Expand Down
Loading