Imagine you're securing a house.
You wouldn't only ask, "Who has the keys?"
You'd also check every possible way someone could get in.
The front door.
Windows.
Garage.
Balcony.
Even that small back door nobody thinks about.
Now think about something we use every day: online banking.
Your banking app doesn't operate alone.
It communicates with servers, APIs, authentication systems, payment infrastructure, and other services.
Some of these systems have to trust each other for everything to work.
But from a security perspective, that creates two important questions:
Who is trusted?
And where could an attacker potentially get in?
This is where Trust Mapping and Attack Surface Analysis come in.
While reading the independent security audit of @canton_loop, developed by @FiveNorthHQ, I noticed the auditors used both as part of understanding the wallet before going deeper into testing.
Trust Mapping helps identify where trust exists between users, components, services, and external systems, and what could happen if one of those trusted relationships fails.
Attack Surface Analysis looks at the other side:
Every point where someone could potentially interact with or attack the system.
Think APIs, authentication flows, dApp connections, frontend and backend services, and other exposed interfaces.
Put simply:
Trust Mapping asks:
"Who trusts whom?"
Attack Surface Analysis asks:
"Where could someone get in?"
Together, they give auditors a clearer picture of where security matters most before they start trying to break anything.
Because sometimes the biggest risk isn't hidden deep inside the code.
It can be sitting in a trusted connection or an entry point nobody paid enough attention to.
Next: Manual Code Review.
