Assume role support #474
Merged
Assume role support #474
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Surface compute service assumability findings at the role level to provide better visibility into roles that can be assumed by EC2, ECS, EKS, or Lambda services, helping security teams identify potential privilege escalation paths through compute services.
Surface cross-account assumability findings at the role level to provide better visibility into roles that can be assumed by principals from other AWS accounts, helping security teams identify potential attack surface expansion beyond organizational boundaries.
Add a new command line flag --flag-trust-policies that allows users to control whether trust policy findings are included in role detail output, providing more granular control over which security findings are reported.
Surface roles that can be assumed by any principal (*) or any AWS account root to provide critical visibility into the most dangerous trust policy configurations, helping security teams immediately identify roles that present the highest risk of unauthorized access from any AWS account.
Surface roles that can be assumed by any principal (*) or any AWS account root when conditions are present to provide enhanced visibility into potentially dangerous trust policy configurations. While conditions may appear to provide security controls, they can be overly permissive or contain logical flaws, helping security teams identify roles that require careful review to ensure conditions adequately restrict access and prevent unintended privilege escalation.
… positives Allow users to specify known AWS account IDs in the exclusions configuration to filter out trusted accounts from cross-account assumability findings, reducing noise from legitimate organizational accounts and third-party vendor accounts while maintaining security visibility for unknown external principals.
|
Thanks for the contribution! Before we can merge this, we need @bhendo to sign the Salesforce Inc. Contributor License Agreement. |
Provide documentation for the three new trust policy findings (AssumableByCrossAccountPrincipal, AssumableByAnyPrincipal, and AssumableByAnyPrincipalWithConditions) to help security teams understand the risks associated with each type of role assumption configuration and provide actionable guidance for remediation and review.
bhendo
force-pushed
the
assume-role-support
branch
from
1733a48 to
47dcc00
Compare
gruebel
reviewed
Sep 25, 2025
Collaborator
gruebel
left a comment
gruebel
left a comment
There was a problem hiding this comment.
overall change looks good, great job 🍻
Streamlined the trust policy aggregation to eliminate repeated loops over statements and cache the severity filter before building findings to improve performance.
Contributor
Author
|
@gruebel I added some additional logic to cover shortened account id principals (something I'd previously overlooked) in 0ca67ef |
gruebel
approved these changes
Sep 26, 2025
Trust policies can list 12-digit account IDs in addition to arns ARNs. Normalizing principals through a shared helper (and exercising exclusions/current-account filtering in tests) keeps --flag-trust-policies from missing those roles that are assumable from other accounts when only the account ID is supplied.
bhendo
force-pushed
the
assume-role-support
branch
from
0ca67ef to
14dcd6e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Adds support for flagging risky trust policies in IAM roles, enhancing the tool's ability to detect cross-account and overly permissive role assumptions. The changes introduce a new
flag_trust_policiesoption to both single-account and multi-account scan commands, propagate this flag through the scanning pipeline, and implement logic to identify risky trust policy configurations.These changes make it easier to identify and flag IAM roles with risky trust policies, improving the security posture of scanned AWS environments.
New trust policy risk detection:
--flag-trust-policies(with shorthand-t) to bothscanandscan_multi_accountcommands, allowing users to enable detection of risky trust policies in IAM roles.flag_trust_policiesflag through all relevant functions and classes in the scanning pipeline, includingscan,scan_multi_account,scan_accounts,scan_account,scan_account_authorization_details,AuthorizationDetails, andRoleDetails.Trust policy analysis logic:
AssumeRolePolicyDocumentandAssumeRoleStatementclasses to analyze trust policies, including detection of cross-account principals, wildcard principals, and conditions, enabling identification of risky configurations.What gif best describes this PR or how it makes you feel?
Completion checklist
make test,make lint,make security-test,make test-js)