Cross-account trust to an unidentified AWS account

Severity: high. Medium when organizations:ListAccounts was denied, since membership of your own organization could not be checked.

What it means

A role trusts an AWS account that is neither in your organization nor one frontdoor can match to a known vendor. It is the "who is that?" finding.

Most accounts here turn out to be legitimate — a vendor whose id we do not carry, a partner, an old sandbox. The value of the finding is not that it is alarming; it is that somebody has to be able to say what it is, and if nobody can, that itself is the answer.

What an attacker does

Nothing, if the trust was intended. If it was not — a vendor you stopped using, a contractor's account, a proof of concept from 2019 — then whoever controls that account has standing access to everything the role grants, and nothing in your account will ever show it as unusual.

How to fix it

1. Find out whether it is used at all. CloudTrail, filtered to AssumeRole on that role ARN. An account that has not called in a year is a decision somebody can make quickly.

2. If it is a vendor, add it to a vendors file so future scans label it instead of flagging it:

   json

   { "111122223333": { "name": "Acme MSP", "source": "internal ticket OPS-42" } }

   bash

   frontdoor scan --aws --vendors partners.json

   A pull request adding the id to the built-in list is welcome too — include the vendor's own documentation URL. We do not add ids we cannot cite.

3. If nobody can say what it is, remove the statement. Re-adding it takes a minute if somebody complains, which is itself the fastest way to find out who owns it.

About the vendor labels

frontdoor labels the accounts it can identify, and every built-in entry cites the vendor doc it came from. Vendors that provision per-tenant accounts — Wiz, Orca, Snyk — cannot be covered by a static map at all. Those get a possibly label matched on the role name, and FD014 still fires, because a guess from a name is not an identification.