Loading today’s stories
Build1 distinct publisher3 min readPublished
A developer read every IAM check in Prowler and found none that ask whether a policy requires MFA at the moment of the call. The gap is one rule wide; the lesson about check counts is wider.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The distinction here is about when, not whether. A registered MFA device is a property of a principal. `aws:MultiFactorAuthPresent` is a property of a statement, evaluated when the API call actually arrives, and AWS documents it as a separate control for that reason [11]. Prowler's MFA checks read the first kind of fact: `iam_user_mfa_enabled_console_access`, `iam_administrator_access_with_mfa` and `iam_root_mfa_enabled` all ask whether a device is registered against a user or role [8]. So an account can pass every one of them while a policy attached to a user, or to a role that user can assume, permits `iam:CreateAccessKey` or `sts:AssumeRole` with no condition attached at all [10].
The code that closes that gap is not clever. It reads `Condition`, confirms it is a dict, and walks the operator blocks looking for the key [7]. That is the interesting part. The missing check is cheap, and it is missing because it runs across the grain of how the existing checks are organised, which is by the state of enumerable resources rather than by the text of a policy document.
Worth being precise about the size of what was found. iam-lint has seven rules [2]. The post names six of them and returns a Prowler verdict on four [14]. It also says two rules were already well covered and then lists three identifiers under that heading [16]. The two wildcard rules never get a comparison at all. Read strictly, the result is one gap found in the 48 checks that one reader worked through in a single directory [4], not one gap proven to exist in the project.
It is also unconfirmed. The author did not send a patch. He filled in Prowler's New Check Request template, reasoning that a new check drags compliance framework mappings behind it and that he was not close enough to the project to judge those effects [12]. That is the right shape for the proposal, and it also means the finding currently has one witness [9], from someone who calls Prowler the tool he would reach for if he were doing this for real [13].
What survives the caveats is the failure mode, and it does not depend on Prowler specifically. A scanner that enumerates identity configuration will report on registered devices and policy attachments, because those are the objects it can list. Whether a statement gates the call is a question about text. If nothing in the toolchain reads the text, then the count of passing checks is measuring inventory, and iam-lint's own value proposition is the boring one: it exits non-zero on findings and speaks JSON, so it sits in a pipeline next to the big scanner rather than instead of it [3].
Ranked by verification strength, evidence, and original report placement.
The author began with a Python function written as Cloud Security Engineer interview prep, scanning an AWS IAM policy document for wildcard actions, wildcard resources and unrestricted iam:PassRole.
That exercise became iam-lint, a tested, CLI-installable IAM policy scanner with seven rules, each backed by tests.
The author read through all 48 of Prowler's IAM checks, located in prowler/providers/aws/services/iam/.
iam-lint exits with code 1 when there are findings and 0 when the policy is clean, so it can act as a CI policy gate, and it has a --format json flag for machine-readable output.
iam-lint's FULL_ADMIN_ACCESS rule overlaps with Prowler's iam_*_no_administrative_privileges family, which has separate checks for attached, inline and customer-managed policies.
iam-lint's PRIVILEGE_ESCALATION_RISK and PASSROLE_UNRESTRICTED rules overlap with Prowler's iam_policy_allows_privilege_escalation, which implements all roughly 21 documented AWS privilege escalation methods from Rhino Security Labs' research; the author calls his own four-action check a reasonable simplification and would rather point people to Prowler's version.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific but single-source and self-audited
The post is unusually concrete for a personal build log: it shows the detection function, names the overlapping Prowler check families, names the three MFA checks it compared against, gives the filed issue number and the three duplicate-search terms used. All of it, however, comes from one author auditing his own tool against a codebase he read manually, with no version pin for the 48-check baseline, no citation for the AWS documentation invoked, and no third-party or maintainer corroboration. The load-bearing finding is an absence claim, the hardest kind to verify from a single reader's pass.
Pre-adoption: one tool, one issue in triage
The only adoption facts disclosed are that iam-lint exists as an installable CLI and that a check request was filed against Prowler as issue #12559 and remains untriaged. There are no installs, stars, downstream users, CI integrations, maintainer acceptance, or shipped Prowler check. Adoption is therefore measurable but near the floor.
Mildly overstated headline, notably modest body
The framing 'found a real gap' asserts more than the post establishes: the gap is unconfirmed by any maintainer, the audit skips two of seven rules, and the summary of overlapping rules miscounts. Offsetting that, the body is markedly self-limiting - it concedes that Prowler's privilege-escalation implementation is better, directs readers there, rates the proposed check only medium severity as defence-in-depth, and calls the issue's rejection useful feedback. Net drift is positive but small.
Disclosed portfolio and job-search incentive
The author states the work began as Cloud Security Engineer interview preparation, and the post showcases his own tool while linking it as a reference implementation inside an upstream proposal - a clear personal-visibility and hiring incentive. That incentive is openly disclosed rather than hidden, and it is partly counterweighted by the author steering readers to Prowler over his own rules, so distortion pressure is moderate rather than severe. No vendor sponsorship, funding, or commercial relationship is disclosed in the source.
Moderate-low: one self-reported source, key finding unresolved
Confidence is limited by cluster shape more than by internal contradiction: one publisher, one author, one self-audit, and the decisive question - whether Prowler genuinely lacks a policy-level MFA-condition check - is pending maintainer triage. Claims about the author's own tool and about the has-MFA-versus-requires-MFA distinction are well specified and internally consistent; claims about Prowler's coverage, its market position, and AWS documentation are uncorroborated.
build
Cloud security POCs have no control group. A Terraform fixture with 30 known bugs is one attempt.1 distinct publisher
build
Glue 6.0's 30% cut is version-gated, and the discount arrives with a Spark 4.1 migration bill1 distinct publisher
build
Force the tool call, then hand Lightsail a long-lived key1 distinct publisher
build
A cache hit is a quota refund: semantic caching with trigrams and no vector database1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 26, 2026