Skill Being Reviewed
Skill name: access-review
Skill path: skills/identity/access-review/
False Positive Analysis
Benign-looking access review packet that can be over-scored as least-privilege compliant:
review_campaign: Q2-access-certification
user: analyst@example.com
direct_groups:
- finance-readonly
certifier_decision: approved
transitive_groups: not_collected
dynamic_groups: not_collected
cloud_inherited_bindings: not_collected
application_local_roles: not_collected
Why this is a false positive:
The current skill inventories entitlement sources and asks certifiers to approve user-entitlement pairs, but it does not require evidence that the review expanded nested groups, dynamic groups, inherited cloud IAM bindings, app-local roles, database grants, or resource-level ACLs before certification.
A user can look clean in direct IdP group membership while receiving privileged access through a nested group, dynamic membership rule, inherited org/folder/project binding, local SaaS role, or database grant. Certifying only the direct assignment can therefore overstate least privilege and miss SoD violations.
Coverage Gaps
Missed variant 1: nested group grants privileged access
user: alice
certified_direct_group: engineering-readonly
nested_membership:
engineering-readonly -> breakglass-admins -> production-admin
expanded: false
Why it should be caught:
Access review evidence should include the transitive membership path and final effective permissions, not just the visible direct group.
Missed variant 2: dynamic group rule silently adds users to sensitive access
dynamic_group: finance-exporters
rule: department == "Finance" and country == "US"
user_department: Finance
certifier_saw_rule: false
permission: export_pii_reports
Why it should be caught:
Dynamic/birthright access needs rule evidence, owner, review cadence, and sample members. Otherwise reviewers approve outcomes without knowing why users are included.
Missed variant 3: cloud inherited binding bypasses app review
cloud: gcp
project_role_reviewed: none
folder_binding:
principal: group:data-platform@example.com
role: roles/bigquery.admin
inherited_to_project: payments-prod
Why it should be caught:
Cloud IAM can be inherited from org/folder/subscription/account scopes. A local project or app-only review misses effective access unless inherited bindings and policy-analysis results are included.
Edge Cases
- Nested group expansion can loop or exceed depth limits; the review should record maximum depth, unresolved groups, and source system.
- Dynamic group membership can change after certification; the review should record rule version and sample timestamp.
- Resource-level ACLs, database roles, SaaS local admins, and emergency access assignments may sit outside the IdP group graph.
- A certifier may approve a friendly group name without seeing the effective permissions or SoD conflict created downstream.
Remediation Quality
Recommended output fields:
| Field |
Purpose |
| Principal |
User, service account, guest, group, or workload identity being reviewed. |
| Direct entitlement |
Group, role, permission set, app role, or grant assigned directly. |
| Transitive path |
Nested group or inheritance path that produces access. |
| Dynamic rule / birthright source |
Rule, HR attribute, SCIM source, or policy that adds the principal. |
| Effective permission |
Final privilege granted after expansion. |
| Source of authority |
IdP, cloud IAM, app admin console, database, directory, or SaaS. |
| Certifier visibility |
Whether the reviewer saw the effective permission and path. |
| Decision |
Approve, revoke, modify, exception, or Not Evaluable. |
Comparison to Other Tools
| Tool / Framework |
Catches this? |
Notes |
| Microsoft Graph transitive membership APIs |
Partial |
Can enumerate indirect group membership, but the review must require the evidence. |
| Google Cloud Policy Analyzer |
Partial |
Can analyze which principals have what access, but only if the review includes inherited policy analysis. |
| AWS IAM Access Analyzer |
Partial |
Can surface unused or external access; access review still needs identity graph and certification evidence. |
| IGA platforms |
Partial |
Often support certification, but campaigns can still omit app-local roles or inherited cloud bindings. |
Overall Assessment
Strengths:
- The skill has a strong review workflow for scope, certification, orphaned accounts, role explosion, SoD, evidence retention, and reporting.
- It already calls out certifier visibility and service/guest account inclusion.
Needs improvement:
- The review can certify direct entitlements without proving the complete effective access graph.
- It does not require transitive group paths, dynamic group rule evidence, inherited cloud IAM bindings, or app-local role reconciliation.
- It should classify missing expansion as Not Evaluable rather than allowing a pass based on direct group review.
Priority recommendations:
- Add an effective entitlement expansion gate before certification decisions.
- Require direct, transitive, dynamic, inherited, and local-app/database access evidence.
- Add output fields for transitive path, dynamic rule, effective permission, certifier visibility, and unresolved graph nodes.
- Add edge-case fixtures for nested groups, dynamic/birthright access, inherited cloud bindings, and app-local admin roles.
Sources Checked
This review is distinct from #1159/#1164/#1168 because it focuses on the effective entitlement graph before certification, not certifier independence or delegation evidence. It is distinct from #889 because it expands the access graph itself before SoD analysis rather than focusing on SoD rule provenance.
Bounty Info
Skill Being Reviewed
Skill name:
access-reviewSkill path:
skills/identity/access-review/False Positive Analysis
Benign-looking access review packet that can be over-scored as least-privilege compliant:
Why this is a false positive:
The current skill inventories entitlement sources and asks certifiers to approve user-entitlement pairs, but it does not require evidence that the review expanded nested groups, dynamic groups, inherited cloud IAM bindings, app-local roles, database grants, or resource-level ACLs before certification.
A user can look clean in direct IdP group membership while receiving privileged access through a nested group, dynamic membership rule, inherited org/folder/project binding, local SaaS role, or database grant. Certifying only the direct assignment can therefore overstate least privilege and miss SoD violations.
Coverage Gaps
Missed variant 1: nested group grants privileged access
Why it should be caught:
Access review evidence should include the transitive membership path and final effective permissions, not just the visible direct group.
Missed variant 2: dynamic group rule silently adds users to sensitive access
Why it should be caught:
Dynamic/birthright access needs rule evidence, owner, review cadence, and sample members. Otherwise reviewers approve outcomes without knowing why users are included.
Missed variant 3: cloud inherited binding bypasses app review
Why it should be caught:
Cloud IAM can be inherited from org/folder/subscription/account scopes. A local project or app-only review misses effective access unless inherited bindings and policy-analysis results are included.
Edge Cases
Remediation Quality
Recommended output fields:
Comparison to Other Tools
Overall Assessment
Strengths:
Needs improvement:
Priority recommendations:
Sources Checked
This review is distinct from #1159/#1164/#1168 because it focuses on the effective entitlement graph before certification, not certifier independence or delegation evidence. It is distinct from #889 because it expands the access graph itself before SoD analysis rather than focusing on SoD rule provenance.
Bounty Info