Threat objective
An attack tree starts with one attacker goal and decomposes it into paths that are sufficient alone or steps that must occur together. The tree is a reasoning model. It does not predict likelihood or prove that every path is present.
Build the tree
Name a concrete root goal such as "change production access policy without approval." Split it into alternatives: compromise an administrator, compromise the delivery identity, alter a trusted artifact, exploit the control plane, or use an unreviewed emergency path. Split each branch until leaves can be observed, prevented, or tested.
Mark OR branches when any child can achieve the parent. Mark AND branches when all children are required. Add identity, credential, route, application, dependency, and recovery paths that cross trust boundaries.
Use the result
Connect leaves to preconditions, evidence, controls, owners, tests, and residual risk. Find shared leaves that defeat several controls, such as one signing key or administrator identity. Use the tree to select negative tests and to compare designs.
Failure and residual risk
A tree reflects its scope and authors. It can omit unknown paths, model a control as stronger than it is, or split one path inconsistently. A large tree can become an inventory without decisions. Review it after architecture, identity, route, threat, or recovery changes.
Pomerium boundary
Pomerium can mediate and record configured access paths. An attack tree must also include identity-provider administration, configuration delivery, direct upstreams, application permissions, credentials, and recovery. Pomerium does not discover every branch automatically.
Evaluation checklist
- Is the root one concrete attacker goal and consequence?
- Are OR and AND relationships explicit?
- Do branches include identity, control-plane, direct, application, and recovery paths?
- Does each testable leaf have evidence, control, owner, and residual risk?
- Which shared dependency defeats several branches at once?
