attack-tree-construction

Overview of attack-tree-construction skill

What attack-tree-construction does

The attack-tree-construction skill helps an agent build structured attack trees for Threat Modeling: a root attacker goal, decomposed sub-goals, and leaf attack steps linked with AND and OR logic. It is best used when you need a clear picture of how an attacker could reach a target outcome, not just a flat list of threats.

Who should use this skill

This attack-tree-construction skill fits security architects, appsec engineers, red teamers, developers doing design review, and technical leads who need to explain attack paths to others. It is especially useful when a system is complex enough that ordinary brainstorming produces scattered, duplicate, or poorly prioritized threats.

The real job-to-be-done

Most users do not just want “more threats.” They want a model they can act on:

• see multiple ways an attacker can achieve one goal
• distinguish alternative paths from required chained steps
• find weak controls and single points of failure
• support review, testing, and mitigation planning

That is where attack-tree-construction for Threat Modeling is stronger than a generic prompt asking for “security risks.”

What makes it different from a generic threat prompt

The main differentiator is structure. The skill centers on attack tree mechanics:

• a single root goal
• explicit AND vs OR branching
• leaf-level attack steps
• attack attributes such as cost, time, skill, detection, and impact

That structure improves traceability and makes the output easier to critique, expand, or turn into test cases.

What to know before you install

The repository signal is simple: this skill is primarily contained in SKILL.md, with no helper scripts or support files. That makes attack-tree-construction install lightweight, but it also means output quality depends heavily on the context you provide. If your system description is vague, the tree will be generic too.

How to Use attack-tree-construction skill

Install context for attack-tree-construction

Install the skill from the wshobson/agents repository:

npx skills add https://github.com/wshobson/agents --skill attack-tree-construction

Because the skill lives as a single markdown workflow, there is no extra runtime setup or dependency chain to manage.

Read this file first

Start with:

• plugins/security-scanning/skills/attack-tree-construction/SKILL.md

That file contains the core model: when to use the skill, attack tree structure, node types, and attack attributes. Since there are no supporting references or scripts in this skill folder, reading SKILL.md is enough to understand the intended workflow.

Best input shape for attack-tree-construction usage

For strong attack-tree-construction usage, provide:

• the system or feature being modeled
• the attacker goal as one sentence
• trust boundaries and entry points
• major assets and sensitive actions
• known controls already in place
• assumptions and scope limits

Good example input:

• System: multi-tenant SaaS admin portal
• Root goal: gain unauthorized tenant-wide admin access
• Entry points: login, password reset, SSO callback, support impersonation flow, public API
• Assets: session tokens, admin role assignment, tenant data export
• Existing controls: MFA for admins, audit logs, rate limiting on login
• Constraints: exclude physical access and insider abuse

This is much better than “make an attack tree for my web app,” because it gives the skill enough material to branch realistically.

Turn a rough request into a strong prompt

Weak prompt:

• “Use attack-tree-construction to analyze my platform.”

Stronger prompt:

• “Use the attack-tree-construction skill to build an attack tree for the goal ‘extract customer PII from the billing service.’ Use AND and OR nodes explicitly, stop at leaf attacks that are concrete enough to test, and annotate leaves with cost, time, skill, detection difficulty, and impact. Consider web app, API, CI/CD secrets, and support workflows. Exclude nation-state capabilities.”

The stronger version improves:

• root goal clarity
• decomposition depth
• branch quality
• prioritization value

Choose the right root goal

A common mistake is making the root too broad, such as “compromise the company.” Better roots are specific attacker outcomes:

• obtain privileged console access
• exfiltrate payment data
• deploy malicious code to production
• bypass tenant isolation
• disable logging before fraud

A precise root gives the attack-tree-construction guide a cleaner tree and fewer mixed threat categories.

Use AND and OR nodes deliberately

This skill is most useful when you force branching logic to be explicit:

• use OR when any one path is enough
• use AND when multiple conditions or steps are required

Example:

• Root: steal user account
  • OR: credential stuffing
  • OR: session token theft
  • AND: reset password + control email inbox

Without this distinction, the output becomes a bullet list rather than a real attack tree.

Ask for leaf nodes that are testable

Tell the agent to stop decomposition when a leaf is:

• concrete enough to validate
• distinct from sibling leaves
• not just a restatement of a parent node

Good leaves:

• reuse leaked credentials against admin login
• exploit missing auth check on role-update endpoint
• steal support agent session via phishing

Weak leaves:

• break security
• exploit vulnerability
• get access somehow

Testable leaves make the skill more useful for red teaming, architecture review, and mitigation mapping.

Request attack attributes for prioritization

The skill includes attack attributes, so ask for them. Useful leaf annotations include:

• cost
• time
• required skill
• detection likelihood or detection difficulty
• impact

These attributes help turn a tree into a decision tool. If two branches reach the same goal, teams usually care most about the cheapest, fastest, least detectable path first.

Suggested workflow in practice

A practical attack-tree-construction usage flow:

1. Define one attacker goal.
2. Provide architecture and scope context.
3. Generate the first tree.
4. Remove duplicate or hand-wavy branches.
5. Add attributes to leaves.
6. Review branches against existing controls.
7. Pick the top paths for mitigation or testing.

Do not start by asking for “all possible attack trees” across the entire environment. One root goal per pass produces much better output.

Where this skill fits in Threat Modeling

attack-tree-construction for Threat Modeling works best after you understand the system at a high level and before you finalize mitigations. It is particularly good for:

• drilling into one high-risk abuse case
• explaining why a control matters
• comparing alternate attack paths
• selecting scenarios for security testing

It is less suited to broad asset inventories or compliance-style control checklists.

Practical tips that change output quality

To improve attack-tree-construction usage immediately:

• include non-technical paths like support workflows or password reset
• list controls already present so the tree reflects bypass attempts
• separate cloud, app, identity, and human attack surfaces
• ask the model to note assumptions when evidence is missing
• cap tree depth if the first result gets noisy

One of the biggest quality gains comes from naming interfaces and privileged actions explicitly instead of describing the system in marketing terms.

attack-tree-construction skill FAQ

Is attack-tree-construction good for beginners

Yes, if you already understand the system being modeled. The structure helps beginners avoid random threat lists. But beginners still need to supply scope, assets, and attacker goals; the skill does not replace system knowledge.

When should I use attack-tree-construction instead of a normal prompt

Use attack-tree-construction when you need branching logic, attack path comparison, and a model you can review with others. A normal prompt is fine for quick brainstorming, but it often mixes preconditions, actions, and outcomes without clear relationships.

Is this only for application security

No. The attack-tree-construction skill can be used for infrastructure, identity, CI/CD, insider-adjacent workflows, and operational abuse cases, as long as you can define a root attacker objective and meaningful sub-goals.

When is attack-tree-construction a poor fit

It is a poor fit when:

• your scope is still undefined
• you need a full threat enumeration across many unrelated goals
• you want compliance mapping rather than attacker reasoning
• the system description is too vague to support concrete leaf nodes

In those cases, do scoping or high-level threat modeling first.

Does the skill include automation or templates

Not much. Based on the repository structure, the skill is document-driven and lives in SKILL.md without helper scripts or reference assets. That keeps adoption simple, but it means your prompting discipline matters more than tool support.

Can I use attack-tree-construction for stakeholder communication

Yes. This is one of its better uses. Attack trees communicate risk more clearly than long prose because they show how alternative and chained paths lead to the same business-impacting outcome.

How to Improve attack-tree-construction skill

Give better system context, not more words

The fastest way to improve attack-tree-construction results is to provide structured facts:

• components
• users and roles
• trust boundaries
• sensitive operations
• entry points
• existing defenses

A short, specific system brief beats a long generic description every time.

Narrow the objective before expanding the tree

If the first output feels shallow or chaotic, the root goal is usually too broad. Split “compromise the platform” into narrower objectives, then run the attack-tree-construction skill separately for each one.

Push the model to include overlooked paths

Many first-pass trees over-focus on direct technical exploits. Ask explicitly for branches covering:

• identity and access workflows
• credential recovery
• third-party integrations
• CI/CD and secrets handling
• admin or support tooling
• misconfiguration abuse

This often surfaces more realistic paths than vulnerability-only trees.

Remove vague nodes and force concrete decomposition

Common failure modes:

• parent and child say nearly the same thing
• leaves are not actionable
• branches mix attacker goals with mitigations
• the tree stops before useful specificity

Fix this by asking:

• “Rewrite vague leaves into concrete attacker actions.”
• “Separate preconditions from exploit steps.”
• “Stop only when each leaf can be tested or mitigated directly.”

Add control-aware iteration after the first draft

A strong second pass is:

• mark which branches current controls already weaken
• identify branches with no meaningful control
• estimate which low-cost paths remain viable
• propose mitigations at the branch or leaf level

This turns attack-tree-construction for Threat Modeling from analysis into prioritization.

Compare trees across attacker assumptions

If the result seems unrealistic, vary the attacker model:

• opportunistic external attacker
• authenticated low-privilege user
• malicious integrator
• phishing-capable attacker

The best way to improve the attack-tree-construction guide in practice is to generate separate trees per attacker profile instead of forcing one tree to cover every threat actor.

Use the output as a living review artifact

The highest-value teams do not generate one tree and stop. They update it when:

• architecture changes
• new controls ship
• incidents reveal missed branches
• pen tests validate or eliminate paths

That iterative use is where the attack-tree-construction skill becomes more valuable than a one-off prompt.