DEV Community: Shieldly

4 IAM Misconfiguration Patterns That Keep Showing Up in Real AWS Accounts

Shieldly — Wed, 15 Jul 2026 13:21:13 +0000

I spend a lot of time looking at IAM policies. Real ones — from production accounts, staging environments, CI/CD pipelines. After a while, the same mistakes keep appearing. Not because teams are careless. Because IAM's policy language is expressive enough that you can write something that looks reasonable and still be wrong.

Here are four patterns I keep finding, why they're dangerous, and how to catch them.

1. `Action: ""` with `Resource: ""`

This is the obvious one, but it hides in less obvious places. It's not always AdministratorAccess. Sometimes it's a Lambda execution role that started as a placeholder during development. Six months later it's still there, running in production, with full access to every service.

What to check: Does this role actually need to touch DynamoDB? SQS? KMS? If the Lambda only writes to CloudWatch Logs and reads from one S3 bucket, scope it to those two services.

The fix isn't Action: "s3:*" — that still gives the role permission to delete every bucket in the account. Narrow it to the specific actions the function calls: s3:GetObject, s3:PutObject.

2. `iam:PassRole` without conditions

PassRole is the permission that says "this principal can pass a role to an AWS service." It's what lets a Lambda function assume its execution role, or an EC2 instance launch with an instance profile.

Without conditions, PassRole with a wildcard resource means the principal can pass any role in the account. A developer with PassRole on * can launch an EC2 instance with the account's admin role attached.

What to check: Every PassRole statement should have a Resource field that lists specific role ARNs, and ideally a Condition with iam:PassedToService scoping which services can receive the role.

3. `s3:GetObject` on `*` in a role's policy

A role that can read any S3 object in any bucket. Including the bucket where your CloudTrail logs land. Including buckets owned by other teams that might contain customer data.

This often happens because someone created a role to read from one specific bucket, typed "Resource": "*" to get it working, and never came back to tighten it.

What to check: Every s3:GetObject statement should list specific bucket ARNs. If the role needs access to multiple buckets, list them explicitly. The extra thirty seconds of typing saves you from a blast radius problem later.

4. Missing condition keys on broad permissions

A role with ec2:TerminateInstances on * is a role that can terminate every EC2 instance in the account. Add "Condition": {"StringEquals": {"aws:ResourceTag/Environment": "staging"}} and suddenly that same permission only applies to instances tagged Environment: staging.

Condition keys like aws:ResourceTag, aws:PrincipalTag, and aws:SourceIp are how you write policies that are broad where they need to be and tight everywhere else. But most policies I see don't use them at all.

What to check: For any Action that includes Delete* or Terminate*, look at whether a resource tag condition would reduce the blast radius. ABAC (attribute-based access control) isn't just a buzzword — it's how teams with 200+ roles keep permissions manageable.

How to catch these systematically

Manual review works for one role. It doesn't scale to fifty. And it definitely doesn't work when policies change across deploys and nobody reviews the diff.

The Shieldly free demo at shieldly.io/app/iam runs AI-Powered analysis on any IAM policy and flags wildcard actions, missing conditions, overly broad resources, and PassRole risks — no signup needed. Paste a policy and get findings with remediation steps.

For teams: the CLI (@shieldly/cli) and GitHub Action slot into CI/CD. The CDK Construct (@shieldly/cdk-guard) catches issues before deployment. And the VS Code extension flags them while you're writing the policy.

I built Shieldly because I spent too many Friday afternoons staring at JSON policy documents wondering which wildcard was the problem. If these patterns look familiar, give the demo a try.

The Hidden Cost of Manual IAM Review

Shieldly — Wed, 15 Jul 2026 00:10:34 +0000

The Hidden Cost of Manual IAM Review

Most teams don't track how long they spend reviewing IAM policies. When I started measuring it on my own team, the numbers were worse than I expected.

A thorough manual review of one IAM policy takes 10 to 15 minutes. Not a quick scan. A real review: read every statement, trace every cross-account trust, verify every condition key, check for privilege escalation paths, confirm the resource ARNs match what you think they should.

At 4 engineers touching IAM once a week, that's 4 hours a month. 48 hours a year of senior engineers reading JSON documents.

And that's the optimistic case. Add a security incident. Add an audit. Add the emergency Friday-afternoon policy change that needs review before deploy. The real number is higher.

What manual review misses

The problem isn't just the time. It's that humans are bad at repetitive structured-data review, especially under time pressure.

Here are the things I've seen slip through manual IAM reviews on production systems:

iam:PassRole with no condition. This is the big one. PassRole lets a principal pass a role to a service â€” and if there's no iam:PassedToService condition, that role can be passed to any service that accepts roles. Including services the attacker controls. The reviewer saw the action, mentally categorized it as "role stuff," and moved on. It was statement 47 of 52 â€” the reviewer had already been reading policies for 40 minutes.

Wildcard resource with sensitive actions. s3:* on Resource: "*" is obvious. s3:GetObject on "arn:aws:s3:::*-backup/*" with a wildcard in the bucket name â€” that's subtle. The reviewer reads it as "restricted to backup buckets" and moves on. But the wildcard means any bucket ending in -backup, including ones in other accounts if cross-account access is configured.

Missing aws:SourceArn on Lambda invocation permissions. When you grant another service permission to invoke your Lambda function, you need aws:SourceArn to prevent the confused deputy problem. Without it, any principal in the trusted service's account can invoke your function through that service. This one gets missed because the reviewer focuses on the principal, not the condition block.

CloudFormation-generated role names that don't match the policy's intent. A policy grants dynamodb:PutItem on a table called prod-users. But the resource ARN references a table with a CloudFormation-generated suffix like prod-users-AB12CD34EF. The reviewer sees "prod-users" in the logical name and confirms. The physical resource is a different table entirely.

The pattern: fatigue degrades quality

Everyone starts a review session sharp. The first policy gets 100% attention. By the third policy, you're skimming condition blocks. By the fifth, you're checking actions and resources and hoping nothing weird is in the conditions. This isn't incompetence â€” it's how human attention works on repetitive structured-data tasks.

The worst-case scenario: the reviewer is 3 tickets behind on a Friday at 4pm. They have a deploy waiting on their approval. They scan the policy in 2 minutes, see nothing obviously wrong, and approve. That's the moment iam:PassRole with no condition gets through.

What automation changes

Automated IAM analysis doesn't get tired. It doesn't have a Friday afternoon. It checks every condition on every statement on every review, regardless of how many policies came before it.

For our team, switching from manual-only review to automated-first changed two things:

Review time dropped from 10-15 minutes to 30 seconds per policy. The tool flags issues; the human verifies the flags. The human spends time on judgment (is this intentional? does the context justify this wildcard?) instead of discovery (does this policy have a wildcard somewhere?).
Catch rate improved. Not because the tool is smarter than a human â€” it's not. Because it doesn't skip statement 47.

Try it yourself

You can test this on your own policies. Paste any IAM policy into Shieldly's free analyzer at shieldly.io/app/iam â€” no signup, no credit card. It'll show you every wildcard, every missing condition, every PassRole without a service restriction, every resource mismatch. Same engine that runs on the paid plans.

If you want to automate it: Builder ($19/mo) adds API access and the Cost Advisor. Pro ($49/mo) adds the Compliance Panel for audit readiness. Team ($99/mo) adds automated scanning, Slack alerts, and supports up to 10 engineers.

The math on manual IAM review isn't complicated. 48 hours of senior engineer time per year, plus whatever gets through on Friday afternoons. It's just uncomfortable to calculate.

I built Shieldly â€” AI-Powered Security Analysis for AWS. This is real math from measuring my own team's review time, not a benchmark.

Catch Risky IAM in Your CDK App Before cdk deploy

Shieldly — Mon, 13 Jul 2026 13:19:00 +0000

You ship a CDK stack. One IAM role has a wildcard because you copy-pasted a gist eight months ago. That role is now your blast radius.

Most CDK pipelines have linting. They have type checking. They have cdk diff to preview changes. But nobody's checking IAM policies for overpermissions at synth time.

@shieldly/cdk-guard fills that gap. It runs AI-Powered security analysis on every synthesized stack: risky IAM policies and CloudFormation misconfigurations get flagged before anything hits CloudFormation.

Disclosure: I work on Shieldly.

What it catches

The patterns that manual review misses:

Action: "*" or "*:*": the obvious one, but easy to miss when buried in a 200-line stack
iam:PassRole with a wildcard resource and no conditions: lets a compromised principal hand privileged roles to services it controls
s3:* on a role that only needs GetObject: permission inflation that grows over time
Missing condition keys: no aws:SourceArn, no aws:PrincipalOrgID, no constraints at all

None of these are obscure. They're the patterns that show up in every post-incident review.

Setup

npm install --save-dev @shieldly/cdk-guard

Simplest path is the CLI wrapper: it runs cdk synth, then analyzes all synthesized stacks. Works with any CDK language:

npx @shieldly/cdk-guard

Or add the construct-style guard in a JavaScript/TypeScript CDK app. It analyzes cdk.out/ automatically when the process exits, no explicit call needed:

import * as cdk from 'aws-cdk-lib';
import { ShieldlyGuard } from '@shieldly/cdk-guard';

const app = new cdk.App();

new ShieldlyGuard({
  failOn: 'High',  // Critical | High | Medium | Low | none
});

new MyStack(app, 'MyStack');

If findings at or above failOn severity come back, the process exits non-zero and your deploy stops.

You'll need an API key (SHIELDLY_API_KEY env var, keys are on the Builder plan and above); without a key it runs against the free demo endpoint with a scan limit. Privacy note: your CDK templates are never logged, cache keys are one-way SHA-256 hashes.

CI/CD integration

Block bad policies before they reach main:

# GitHub Actions example
- name: CDK security check
  run: npx @shieldly/cdk-guard
  env:
    SHIELDLY_API_KEY: ${{ secrets.SHIELDLY_API_KEY }}

There's also a cdk.json hook variant ("afterSynth": ["npx", "@shieldly/cdk-guard", "--no-synth"]) if you want it to run on every synth regardless of who invokes it.

What it costs

API keys start on the Builder plan ($19/mo, 150 analysis units/day). There's also a free tier (20 analysis units/day) and a keyless demo mode with a scan limit, so you can try it before paying anything.

The package is on npm. Source is on GitHub.

Why "Request a Demo" Is the Wrong First Step for IAM Security Tools

Shieldly — Fri, 10 Jul 2026 13:18:29 +0000

I built an IAM policy analyzer. The most common first question wasn't about features. It was "what happens to my policies after I paste them?"

Fair question. You're handing over your infrastructure's permission model to a text box. If the vendor can't answer that question clearly, you shouldn't trust them with anything else.

But there's a second problem most security tools create: they gate the answer behind a demo call.

The Demo Call Problem

"Request a demo" means:

You fill out a form
Someone emails you a Calendly link
You spend 30 minutes on a screen share with a sales engineer
They show you a sandboxed environment with synthetic data
Your actual IAM policy never touches the product

You walk away knowing how the tool looks, not how it works on your infrastructure.

Real demo mode â€” the kind where you paste an actual policy and get real findings â€” answers three questions immediately:

Does this tool find issues I actually have? Not curated examples. Your policies.
What does the output look like? Is it actionable or a wall of text?
Is the analysis fast enough to fit into my workflow? Or do I need to context-switch and come back?

A sales demo answers none of these.

What Real Demo Mode Requires

Building a tool anyone can use without signing up means solving a few problems:

Input privacy. Your policies can't be logged. Shieldly uses a one-way SHA-256 hash of your input as a cache key. The plaintext never hits a log, never lands in a training set, never sits in an analytics database. The hash lets us return cached results for identical policies without storing the policies themselves.

Rate limiting that doesn't break the experience. You need enough free analyses to evaluate the tool (20 analysis units per day on the free tier) without opening a vector for abuse. Server-side caps, not localStorage counters that anyone can clear.

Real analysis, not a reduced model. Some tools run a lighter model for demo traffic. Shieldly runs the same analysis pipeline whether you're signed in or not â€” Standard AI for free users, Advanced and Enterprise for paid tiers. The demo isn't a downgraded experience. It's the real thing, just gated by a daily cap.

Evaluating a Security Tool Without a Demo Call

If a tool has real demo mode, you can test it in 5 minutes:

Paste a policy you already reviewed manually. You know what the issues are. Does the tool catch them? Does it find things you missed?
Paste a policy you know is clean. Does it produce false positives? A tool that flags s3:ListBucket as a finding on a read-only reporting role isn't useful.
Check the findings format. Are findings grouped by severity? Does each one explain why it's a problem and how to fix it? If the output is just "this policy has 7 issues" with no detail, you'll need a second tool to actually remediate.

Try It With Your Own Policy

Shieldly's IAM analyzer is free at shieldly.io/app/iam. No signup, no credit card. Paste any IAM policy â€” resource policy, identity policy, SCP â€” and get real findings in seconds.

The free tier gives you 20 analysis units per day. Builder ($19/mo) adds API access and Cost Advisor. Pro ($49/mo) adds a compliance panel. Team ($99/mo) adds auto-scanning and Slack alerts for up to 10 engineers.

If you paste a policy and the findings aren't useful, that's honest feedback I want to hear. If they are useful, you just evaluated a security tool in less time than a demo call would have taken.

AWS IAM Privilege Escalation: Real Attack Paths DevOps Engineers Need to Know

Shieldly — Tue, 07 Jul 2026 13:16:20 +0000

You've locked down your AWS accounts. MFA is enforced, no wildcard IAM policies in production, and you've got a service control policy (SCP) boundary that's tighter than a production change freeze. Feels safe, right?

Then someone on your team grants iam:PassRole to a Lambda function, and a junior engineer accidentally leaves iam:CreatePolicyVersion on a developer role. Two harmless-looking permissions. One breach.

IAM privilege escalation in AWS rarely comes from obvious admin access. It comes from chains — individually reasonable permissions that, when combined, let an attacker with a foothold pivot to full account compromise. Here are the escalation paths I've seen pop up in real AWS environments, what they look like in practice, and how to shut them down without breaking your team's workflow.

Path 1: `iam:PassRole` → Lambda → `sts:AssumeRole`

This is the most common escalation I encounter during reviews. It's deceptively simple.

The dangerous permission set:

{
  "Effect": "Allow",
  "Action": ["iam:PassRole", "lambda:CreateFunction", "lambda:InvokeFunction"],
  "Resource": "*"
}

On its own, iam:PassRole lets an IAM principal attach an existing IAM role to an AWS service. It doesn't grant any permissions on that role's policies — just the ability to attach it. Engineers add this to Lambda execution roles all the time so CI/CD pipelines can deploy functions.

The escalation:

An attacker who compromises a principal with those three permissions can:

Find a high-privilege IAM role in the account (e.g., AdminRole, DeploymentRole, BreakGlassRole).
Create a Lambda function with that role attached via iam:PassRole.
Write a one-liner in the function that calls sts:AssumeRole on itself — or, more destructively, calls iam:CreateAccessKey on an admin user.
Invoke the function, extract the credentials, and own the role.

# payload.py — deployed as Lambda, attached to the victim role
import boto3, json

def handler(event, context):
    sts = boto3.client('sts')
    # Just long enough to exfil
    creds = sts.get_session_token(DurationSeconds=900)
    return {'status': 'done', 'access': creds['Credentials']['AccessKeyId']}

The mitigation isn't "never use iam:PassRole" — that's impractical. The fix is resource constraints on iam:PassRole to limit what roles can be passed, and lambda:CreateFunction to restrict what functions can be created. Pair this with a permissions boundary on Lambda execution roles, and the path collapses.

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::*:role/ci-cd-*",
  "Condition": {
    "StringEquals": {"iam:PassedToService": "lambda.amazonaws.com"}
  }
}

Path 2: EC2 Instance Profile Chaining

EC2 instance profiles are the original IAM escalation vector, and they're still widespread. The mechanics are different from the Lambda path but the endgame is the same: hijacking an attached role's identity.

The setup:

Your CI/CD runners live on EC2. Each runner gets an instance profile role — say EC2-CI-Runner — with permissions to pull from ECR, write to CloudWatch, and access an S3 bucket for build artifacts. Standard stuff.

Someone adds ec2:AssociateIamInstanceProfile to a developer role so the team can attach profiles to test instances during development. That's the crack in the door.

The escalation:

An attacker with ec2:AssociateIamInstanceProfile (and ec2:RunInstances or access to an existing instance) can:

Launch a new EC2 instance (or hijack an existing stopped one they can ec2:StartInstances).
Detach the low-privilege instance profile from the target instance.
Associate a high-privilege instance profile — one attached to a production service or a data pipeline — onto their instance.
SSH in (via SSM or a key they control) and retrieve the instance metadata credentials at http://169.254.169.254/latest/meta-data/iam/security-credentials/.

One curl command later, they have AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN for the production role.

# On the attacker-controlled EC2 instance
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

The fix:

Never grant ec2:AssociateIamInstanceProfile without a resource constraint on the instance profile ARN, not just the instance. Lock it down to specific profiles:

{
  "Effect": "Allow",
  "Action": "ec2:AssociateIamInstanceProfile",
  "Resource": [
    "arn:aws:ec2:*:*:instance/*",
    "arn:aws:iam::*:instance-profile/development-*"
  ]
}

Better yet, add a Condition key checking that the profile isn't tagged as production, or apply a service control policy that blocks instance profile association for non-admin roles entirely.

Path 3: `iam:CreatePolicyVersion` — The Nearly Silent Takeover

This one flies under the radar because it's one permission — no chaining required.

iam:CreatePolicyVersion lets you create a new version of an existing customer-managed policy. If the policy is attached to a user, group, or role, the new version can be set as default, instantly granting new permissions to every principal under that policy.

The scenario:

A security-conscious team grants iam:CreatePolicyVersion to a handful of trusted engineers so they can iterate on policy changes without going through a full deployment pipeline. The policy in question, SupportEngineerPolicy, is attached to 40 support engineers who need read-only access to CloudWatch and limited EC2 describe permissions.

An attacker compromises one support engineer's credentials — phishing, leaked token, compromised workstation — and discovers they can create policy versions. They craft a new version of SupportEngineerPolicy that adds "Effect": "Allow", "Action": "*", "Resource": "*" and set it as default.

# One API call to own the environment
aws iam create-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/SupportEngineerPolicy \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}' \
  --set-as-default

Every principal attached to that policy — 40 engineers — now has full administrative access. The attacker exfiltrates data, creates backdoor users, and the blast radius is enormous. The worst part? No new IAM users or roles were created. No obvious anomalies in CloudTrail if you're not watching CreatePolicyVersion events.

The mitigation:

Block iam:CreatePolicyVersion with an SCP for all non-admin roles. Use iam:SetDefaultPolicyVersion as a sensitive action that triggers an alert in your SIEM. Treat policy version management the same way you treat IAM user creation — it's a privileged operation, not a convenience feature.

{
  "Effect": "Deny",
  "Action": [
    "iam:CreatePolicyVersion",
    "iam:SetDefaultPolicyVersion",
    "iam:DeletePolicyVersion"
  ],
  "Resource": "*",
  "Condition": {
    "ArnNotLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:role/admin-*"
    }
  }
}

Putting It Together: Defense in Depth for IAM

If there's one lesson from years of AWS IR, it's this: IAM permissions are directional. You can't audit them in isolation. A permission that's harmless in role A becomes critical when paired with role B's pass-role target or role C's policy attachment.

What works in practice:

SCP boundaries first. Deny iam:PassRole for cross-account roles, deny iam:CreatePolicyVersion broadly, and restrict instance profile associations at the organization level. You can't accidentally grant what SCPs already block.
Resource-level constraints on everything. "Resource": "*" on pass-role or create-function is a risk acceptance, not a policy. Scope every actionable IAM permission to specific ARN patterns.
Alert on the escalation primitives. CloudWatch Events on CreatePolicyVersion, PassRole to non-standard services, and AssociateIamInstanceProfile on production-tagged instances. Don't wait for a breach to find out your monitoring had a gap.
Audit with an adversarial mindset. Don't ask "does this role have too many permissions?" Ask "if this role is compromised, what can the attacker reach from here?" Map the chains, not just the leaf permissions.
Use permissions boundaries. Every role your team creates should have a permissions boundary that caps its effective permissions regardless of what policies get attached later. It's the IAM equivalent of a circuit breaker.

IAM privilege escalation isn't a vulnerability in AWS — it's a vulnerability in how we compose IAM permissions day to day. The tools themselves are fine. The chains we build with them are the problem.

Know your chains. Test them before an attacker does.

9 AWS IAM Privilege Escalation Methods You Can Check in 5 Minutes

Shieldly — Mon, 06 Jul 2026 10:19:37 +0000

Most AWS IAM breaches do not start with a zero-day. They start with a policy that
granted one permission too many — and that single permission turned out to be a path to
administrator. Here are nine real privilege-escalation methods, what each one needs, and
how to close it. Each links to a deeper write-up with an example vulnerable policy and the
exploit command.

Self-service to admin

These need nothing but a permission on your own identity:

iam:AttachUserPolicy — attach AdministratorAccess to your own user.
iam:PutUserPolicy — write an inline "Action": "*" policy on yourself.
iam:UpdateLoginProfile — reset the console password of a more-privileged user and sign in as them (unless they have MFA).
iam:AttachGroupPolicy / iam:PutGroupPolicy — attach or inline admin onto a group you belong to; every member inherits it.

Role-based, if you can assume the role

iam:AttachRolePolicy / iam:PutRolePolicy — grant admin to a role you can assume.

PassRole + a compute service

iam:PassRole is the most abused permission on AWS because it is the bridge between
"I can configure a service" and "that service runs as a privileged role":

ECS — register a task definition whose task role is privileged, run it, read the credentials from the task metadata endpoint.
Lambda event source mapping — create a function with a privileged execution role and trigger it from a stream, no lambda:InvokeFunction required.

Already on the box

ssm:SendCommand — run commands on an EC2 instance that already holds a privileged instance-profile role, and use its credentials off-box. No iam:PassRole needed.

The common fix

Across all of these the pattern is the same: scope iam:PassRole with an
iam:PassedToService condition and a role allowlist, restrict the policy/role-management
actions to administrators, and apply a permissions boundary so an attached admin policy
can never exceed the boundary.

You can paste a policy into Shieldly and get AI-Powered
analysis of exactly which of these paths it opens and the conditioned fix — free, no signup.
The full reference of escalation methods is at
shieldly.io/iam.

Disclosure: I help build Shieldly.

Gate Insecure AWS IAM in Pull Requests with a Free GitHub Action

Shieldly — Sun, 05 Jul 2026 13:15:02 +0000

Originally published at shieldly.io/blog.

Most IAM problems are not caught by a clever attacker. They are caught â€” eventually â€” by an audit, months after a wildcard shipped because a deploy was blocked at 6pm. The fix is to move the check left: review the policy in the pull request, automatically, before it merges.

Why the PR Is the Right Place

By the time a misconfiguration reaches a quarterly security review, it has been live for a quarter. The PR is the moment the author has full context, the change is small, and tightening a policy costs one comment instead of a migration project.

A CI gate also takes the awkward human conversation off the table â€” the bot flags it, consistently, every time.

Add the Action in 3 Lines

# .github/workflows/shieldly.yml
name: IAM Security Analysis
on: [pull_request]

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shieldly-io/action@v1
        with:
          fail-on-severity: HIGH
        env:
          SHIELDLY_API_KEY: ${{ secrets.SHIELDLY_API_KEY }}

The Action scans changed IAM policies, resource-based policies, and CloudFormation templates in the PR, posts findings as a review comment with the why and the suggested fix, and fails the check on HIGH or CRITICAL findings so risky access cannot merge unnoticed.

What It Catches

Wildcard Action: * and Resource: *
Privilege escalation paths (PassRole chains, CreatePolicyVersion, AttachUserPolicy abuse)
Trust policy misconfigurations (Principal: *, missing ExternalId)
CloudFormation roles with AdministratorAccess
iam:PassRole on Resource: *
NotAction + Effect: Allow patterns

Configuration Options

- uses: shieldly-io/action@v1
  with:
    paths: "**/*.json,**/*.yaml,cdk.out/**/*.template.json"
    fail-on-severity: HIGH   # CRITICAL, HIGH, MEDIUM, LOW
    comment-on-pr: true      # Post findings as PR comment (default: true)

Free Tier

The Action works on the free plan â€” no credit card, no per-seat charge. Each PR scan uses analysis units from your daily quota. The free plan includes 20 analysis units/day.

Launch offer: code 90Off2M â€” 90% off first 2 months. Builder from $1.90/mo, includes 150 analysis units/day and priority scan queuing.

Install: github.com/shieldly-io/action

Catch IAM risks automatically â€” paste a policy into Shieldly's free AI-Powered analysis. No signup, no credit card.

AWS STS ExternalId and the Confused Deputy Problem: A Practical Guide

Shieldly — Wed, 01 Jul 2026 13:20:01 +0000

Originally published at shieldly.io/blog.

Cross-account IAM roles are the standard mechanism for granting third-party services access to your AWS account. The problem is that naming an entire AWS account as the trusted principal is not specific enough. Any identity authenticating from that account can call sts:AssumeRole on your role. This is the confused deputy problem, and ExternalId is the condition that closes it.

What the Confused Deputy Problem Is

The confused deputy is a class of vulnerability where a privileged program is tricked by a less-privileged caller into performing actions on the caller's behalf.

In AWS: a SaaS provider has a trusted AWS account. Customers create cross-account roles naming the SaaS provider's account as the trusted principal:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::VENDOR-ACCOUNT:root"
  },
  "Action": "sts:AssumeRole"
}

Any identity in the vendor's account can call sts:AssumeRole on any customer's role — because from AWS's perspective, the call originates from the correct trusted account. Customer A can potentially assume Customer B's role if they know B's role ARN. The SaaS provider is the confused deputy.

How ExternalId Fixes It

When a vendor requires ExternalId as a condition on sts:AssumeRole, they generate a unique secret value per customer and store it. When their service assumes your role, it passes that value:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::VENDOR-ACCOUNT:root"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "sts:ExternalId": "a7f3b2c9-unique-per-customer"
    }
  }
}

A different customer cannot assume your role because they do not know your ExternalId — even if they use the same vendor account.

Implementing It Correctly

The ExternalId must be:

Unique per customer-vendor relationship — not shared across customers
Unguessable — a UUID or similar high-entropy value, not a predictable string like a customer name or account ID
Generated by the vendor — not chosen by the customer (a customer-chosen ID is potentially guessable by other customers of the same vendor)

Also verify that you cannot pass an arbitrary ExternalId to the vendor's service. If the vendor accepts any value you provide, the control is ineffective.

Red Flags in Third-Party Integration Docs

Watch for these in vendor setup instructions:

No mention of ExternalId
Instructions to trust arn:aws:iam::VENDOR-ACCOUNT:root with no condition
A fixed, static ExternalId shared across all customers (defeats the purpose)

Catch confused deputy risks automatically — paste a cross-account trust policy into Shieldly's free AI-Powered analysis. No signup, no credit card.

Launch offer: code 90Off2M — 90% off first 2 months. Builder from $1.90/mo. shieldly.io/pricing

The 7 IAM Misconfigurations We See in Almost Every AWS Account

Shieldly — Wed, 01 Jul 2026 02:33:59 +0000

Originally published at shieldly.io/blog.

After analyzing a lot of IAM policies, the same seven patterns show up again and again. Here is each one, why it is dangerous, and the fix.

1. Action: * on Resource: *

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

This is administrator access by another name. If you see it outside a dedicated, tightly controlled admin role, treat it as a critical finding. Fix: enumerate the exact actions the workload needs.

2. s3:* on Resource: *

Even scoping to one service is too broad. s3:* includes s3:DeleteObject, s3:DeleteBucket, and s3:PutBucketPolicy. Fix: list only the specific actions (s3:GetObject, s3:PutObject, etc.) on the specific bucket ARN.

3. iam:PassRole on Resource: *

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*"
}

PassRole is harmless until paired with a service launch. On Resource: * it lets a principal pass any role in the account to any service — including admin roles. Fix: scope to specific role ARNs and add the iam:PassedToService condition key.

4. Trust policy Principal: *

{
  "Principal": "*"
}

Any AWS identity in the world can attempt to assume the role. Almost always unintentional. Fix: replace with explicit account or role ARNs, and add an ExternalId condition for cross-account access.

5. Missing ExternalId on third-party cross-account roles

Without ExternalId, any customer of the same vendor can assume your role (the confused deputy problem). Fix: require a unique ExternalId condition on every cross-account trust policy.

6. Inline policies on IAM users

Inline policies do not appear in the IAM managed policy list and are easy to miss in audits. They also travel with the user — if the user is deleted and a new one created with the same name, they do not transfer. Fix: move to customer-managed policies attached to roles, not users.

7. sts:AssumeRole on Resource: *

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "*"
}

A principal with this permission can assume any role in the account whose trust policy allows it. That includes roles with administrator access. Fix: scope to specific role ARNs.

Catch all seven automatically — paste a policy into Shieldly's free AI-Powered analysis. No signup, no credit card.

Launch offer: code 90Off2M — 90% off first 2 months. Builder from $1.90/mo. shieldly.io/pricing

Securing S3 Bucket Policies: Public Access, Conditions, and Common Mistakes

Shieldly — Thu, 25 Jun 2026 12:24:23 +0000

Originally published at shieldly.io/blog.

S3 bucket policies are written once and forgotten. They survive team changes, architecture pivots, and migration projects — and they accumulate permissions that nobody intended to leave open. S3 misconfigurations have been behind some of the largest cloud data breaches on record.

Why S3 Bucket Policies Matter

Bucket policies are resource-based policies attached to the bucket itself. They can grant access to principals that have no IAM permissions at all — including anonymous callers — if the policy allows it. A single misconfigured statement can override months of careful IAM work.

The Three Most Dangerous Patterns

1. Principal: * with no condition

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

An unconditioned wildcard principal means any AWS account, any IAM entity, and any unauthenticated caller can invoke the allowed actions. On a public S3 endpoint this is the open internet.

Fix: Add a condition — aws:PrincipalOrgID, aws:SourceArn, or aws:PrincipalArn:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalOrgID": "o-yourorgid123"
    }
  }
}

2. Missing s3:SecureTransport condition

Without aws:SecureTransport: true, the policy permits access over unencrypted HTTP. Credentials and data travel in plaintext. Add this to every Allow statement:

"Condition": {
  "Bool": {
    "aws:SecureTransport": "true"
  }
}

3. Overly broad Action grants

"Action": "s3:*"

s3:* includes s3:DeleteObject, s3:PutBucketPolicy, and s3:DeleteBucket. A policy intended to share read access becomes a full-control grant. Replace with the exact actions needed:

"Action": ["s3:GetObject"]

S3 Block Public Access Interaction

Block Public Access (BPA) settings at the account and bucket level override bucket policies. But they only block policies that grant access to Principal: * — a policy granting access to a specific external account bypasses BPA entirely. BPA is not a substitute for correct bucket policy authoring.

What a Secure Bucket Policy Looks Like

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/my-app-role"
      },
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" }
      }
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    }
  ]
}

Explicit principal, scoped actions, HTTPS enforced, deny-on-HTTP for belt-and-suspenders.

Analyze S3 bucket policies automatically — paste into Shieldly's free AI-Powered analysis. No signup, no credit card.

Launch offer: code 90Off2M — 90% off first 2 months. Pro from $1.90/mo. shieldly.io/pricing

Catching Risky IAM in CloudFormation Templates Before You Deploy

Shieldly — Thu, 25 Jun 2026 12:23:09 +0000

Originally published at shieldly.io/blog.

Most IAM security conversations center on the AWS console or raw JSON policy documents. But a significant share of production IAM misconfigurations originates in CloudFormation templates. By the time a CF stack is deployed, the IAM roles and policies inside it are live — and unless you reviewed the template before running cdk deploy or aws cloudformation create-stack, you may not have noticed what you just granted.

Why CloudFormation IAM Risk Is Different

In a CloudFormation template, IAM roles are buried alongside compute resources, storage buckets, and networking config. Reviewers focused on architecture often skim past the Properties.Policies block on a Lambda execution role.

A single CloudFormation template may create five roles, two managed policy attachments, and three inline policies — all in a single deploy. The blast radius of an overly-permissive role is multiplied by every resource that role is attached to.

The Most Common CF IAM Mistakes

AdministratorAccess on Lambda execution roles. Tempting during development. In production it grants Action: * on Resource: * to every invocation:

# DO NOT SHIP THIS
Type: AWS::IAM::Role
Properties:
  ManagedPolicyArns:
    - arn:aws:iam::aws:policy/AdministratorAccess

Action: * in inline policies. Inline policies defined inside an AWS::IAM::Role resource are easy to overlook:

Policies:
  - PolicyName: InlinePolicy
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: "*"       # Admin access, probably unintentional
          Resource: "*"

Missing permission boundaries on auto-created roles. Without a boundary, any policy attached to the role later is unconstrained.

Wildcard Resource on DynamoDB and S3. Scoping actions correctly but leaving Resource: *:

Statement:
  - Effect: Allow
    Action:
      - dynamodb:GetItem
      - dynamodb:PutItem
    Resource: "*"   # applies to every table in the account

Fix: replace with the specific table ARN.

How CDK Makes It Easier to Slip Up

CDK provides escape hatches — addToRolePolicy, addOverride, raw PolicyStatement objects — that let developers bypass guardrails. A single escape-hatch call can inject an Action: * statement into an otherwise well-scoped role, and nothing in the CDK build output will flag it.

Catching It Before Deploy

1. Analyze the synthesized template. cdk synth produces the CloudFormation JSON/YAML. Analyze that output before any deploy command runs.

2. Policy review gates in CI. Add a template analysis step to your CI pipeline that runs on every PR touching infrastructure files. Fail the pipeline on HIGH or CRITICAL IAM findings.

# .github/workflows/shieldly.yml
- name: Analyze CloudFormation IAM
  uses: shieldly-io/action@v1
  with:
    paths: cdk.out/**/*.template.json
    fail-on-severity: HIGH
  env:
    SHIELDLY_API_KEY: ${{ secrets.SHIELDLY_API_KEY }}

Analyze CF templates automatically — paste a template into Shieldly's free AI-Powered analysis. No signup, no credit card.

Launch offer: code 90Off2M — 90% off first 2 months. Pro from $1.90/mo. shieldly.io/pricing

AWS IAM NotAction vs Deny: The Misread Statement That Grants Everything

Shieldly — Thu, 25 Jun 2026 11:57:10 +0000

Originally published at shieldly.io/blog.

NotAction is one of the most misunderstood IAM elements. Its name suggests denial but it does not deny anything. When paired with Effect: Allow, it grants access to every action in all of AWS except the ones you listed.

What NotAction Actually Means

NotAction inverts the Action element. Instead of listing what a statement covers, you list what it excludes — and the statement covers everything else.

{
  "Effect": "Allow",
  "NotAction": ["iam:*", "sts:*"],
  "Resource": "*"
}

This allows every action across every AWS service except IAM and STS. That includes s3:DeleteObject, ec2:RunInstances, rds:CreateDBSnapshot, lambda:InvokeFunction, and everything else. The author almost certainly meant to restrict IAM access — they accidentally granted everything else.

The One Legitimate Use Case

NotAction with Effect: Deny is the one safe pattern. It is commonly used in Service Control Policies to create a "deny all except break-glass" control:

{
  "Effect": "Deny",
  "NotAction": [
    "iam:CreateLoginProfile",
    "sts:AssumeRole"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalArn": "arn:aws:iam::123456789012:role/BreakGlassRole"
    }
  }
}

This denies everything except the listed break-glass actions, for everyone except the break-glass role.

How to Rewrite the Dangerous Pattern

If you wrote NotAction + Effect: Allow trying to deny specific actions, replace it:

Instead of this (grants everything except IAM):

{
  "Effect": "Allow",
  "NotAction": "iam:*",
  "Resource": "*"
}

Write this (allows only what you need):

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-bucket/*"
}

Then add an explicit Deny for anything you want blocked:

{
  "Effect": "Deny",
  "Action": "iam:*",
  "Resource": "*"
}

Effect: Deny with an explicit action list is not the same as NotAction Allow — the former creates a hard deny, the latter creates a broad allow. They are opposite things.

Catch IAM statement mistakes automatically — paste a policy into Shieldly's free AI-Powered analysis. No signup, no credit card.

Launch offer: code 90Off2M — 90% off first 2 months. Pro from $1.90/mo. shieldly.io/pricing

DEV Community: Shieldly

4 IAM Misconfiguration Patterns That Keep Showing Up in Real AWS Accounts

1. Action: "*" with Resource: "*"

2. iam:PassRole without conditions

3. s3:GetObject on * in a role's policy

4. Missing condition keys on broad permissions

How to catch these systematically

The Hidden Cost of Manual IAM Review

The Hidden Cost of Manual IAM Review

What manual review misses

The pattern: fatigue degrades quality

What automation changes

Try it yourself

Catch Risky IAM in Your CDK App Before cdk deploy

What it catches

Setup

CI/CD integration

What it costs

Why "Request a Demo" Is the Wrong First Step for IAM Security Tools

The Demo Call Problem

What Real Demo Mode Requires

Evaluating a Security Tool Without a Demo Call

Try It With Your Own Policy

AWS IAM Privilege Escalation: Real Attack Paths DevOps Engineers Need to Know

Path 1: iam:PassRole → Lambda → sts:AssumeRole

Path 2: EC2 Instance Profile Chaining

Path 3: iam:CreatePolicyVersion — The Nearly Silent Takeover

Putting It Together: Defense in Depth for IAM

9 AWS IAM Privilege Escalation Methods You Can Check in 5 Minutes

Self-service to admin

Role-based, if you can assume the role

PassRole + a compute service

Already on the box

The common fix

Gate Insecure AWS IAM in Pull Requests with a Free GitHub Action

Why the PR Is the Right Place

Add the Action in 3 Lines

What It Catches

Configuration Options

Free Tier

AWS STS ExternalId and the Confused Deputy Problem: A Practical Guide

What the Confused Deputy Problem Is

How ExternalId Fixes It

Implementing It Correctly

Red Flags in Third-Party Integration Docs

The 7 IAM Misconfigurations We See in Almost Every AWS Account

1. Action: * on Resource: *

2. s3:* on Resource: *

3. iam:PassRole on Resource: *

4. Trust policy Principal: *

5. Missing ExternalId on third-party cross-account roles

6. Inline policies on IAM users

7. sts:AssumeRole on Resource: *

Securing S3 Bucket Policies: Public Access, Conditions, and Common Mistakes

Why S3 Bucket Policies Matter

The Three Most Dangerous Patterns

1. Principal: * with no condition

2. Missing s3:SecureTransport condition

3. Overly broad Action grants

S3 Block Public Access Interaction

What a Secure Bucket Policy Looks Like

Catching Risky IAM in CloudFormation Templates Before You Deploy

Why CloudFormation IAM Risk Is Different

The Most Common CF IAM Mistakes

How CDK Makes It Easier to Slip Up

Catching It Before Deploy

AWS IAM NotAction vs Deny: The Misread Statement That Grants Everything

What NotAction Actually Means

The One Legitimate Use Case

How to Rewrite the Dangerous Pattern

1. `Action: ""` with `Resource: ""`

2. `iam:PassRole` without conditions

3. `s3:GetObject` on `*` in a role's policy

Path 1: `iam:PassRole` → Lambda → `sts:AssumeRole`

Path 3: `iam:CreatePolicyVersion` — The Nearly Silent Takeover