Path Roles and Outcome Classes

Module 2 introduced primitive families as reusable capability abstractions. That gets you one important step forward, but it is still not enough to describe an exploit path cleanly.

Knowing what kind of capability you have does not automatically tell you what job that capability is doing in the route, and it does not automatically tell you what state the path ultimately reaches.

That is the problem Module 3 solves.

The same primitive can play different roles in different paths. A disclosure capability might serve as an initial foothold in one case, but as a leverage gain in another. Likewise, the same path can survive toward different levels of consequence depending on the environment.

If the course stopped at primitive families, it would still leave too much compositional reasoning buried inside the learner's intuition. Module 3 makes that structure explicit.

A path role describes the function a capability serves inside a route.

This is not the same thing as the primitive family itself. A primitive tells you what kind of capability exists. A role tells you what that capability is doing in the path right now.

Some common roles are:

• foothold
• leverage gain
• boundary crossing
• privilege bridge
• execution trigger

That distinction matters because two capabilities with the same family label can still matter differently depending on where they sit in the route.

A disclosure primitive that reveals credentials may act as leverage gain. A disclosure primitive that exposes the first useful internal object may function more like a foothold. The capability type may stay similar, but the role changes the meaning of the step.

That is why path roles help with prioritization and reasoning. They tell you how a capability contributes to route survival rather than merely what it technically resembles.

An outcome class describes the security-relevant state reached if a path survives far enough.

This is the consequence layer, not the capability layer.

Examples include:

• disclosure
• privileged action
• remote code execution
• local code execution
• privilege escalation
• lateral movement
• denial of service
• persistence

The important distinction is simple:

• primitive family: what capability exists
• path role: what that capability is doing in the route
• outcome class: what state the route reaches if it succeeds

Without outcome classes, consequence stays vague. Without path roles, route function stays vague. Module 3 exists to stop both of those ambiguities from contaminating later analysis.

This lesson works only if the three layers stay clean:

• primitive family
• path role
• outcome class

One way to see the distinction is to ask three different questions:

• what capability is present?
• what job is that capability doing in the path?
• what state does the path reach if it survives?

Those are related questions, but they are not interchangeable.

For example:

• primitive family: reference control
• path role: boundary crossing
• outcome class: remote code execution

If you collapse those into one label, the route becomes harder to compare, harder to teach, and harder to validate consistently.

This is one of the main reasons Exploit Paths needs a middle layer at all. Explicit representation is not paperwork. It is how the reasoning stops disappearing into unstructured expert intuition.

Not every plausible outcome is a validated outcome.

An exploit path can suggest a strong consequence without proving it yet. That is still useful, but it should not be confused with a route that has survived real environmental checks.

So the distinction here is:

• potential outcome: plausible if key conditions hold
• validated outcome: demonstrated under the relevant conditions

This is not the full validation-loop lesson. That comes later. Module 3 only needs the distinction so learners stop treating every imaginable consequence as if it were already real.

That discipline matters because outcome classes are more useful when they stay honest. The point is not to inflate a path. The point is to describe what the route may reach, and then later separate what survives from what does not.

Use Apache HTTP Server again as the clean route example for this module.

The visible weakness is path traversal. In Module 2, that issue helped show how a weakness can be normalized into the primitive family reference control.

Module 3 takes the next step:

• primitive family: reference control
• path role: boundary crossing or leverage gain, depending on what the route reaches
• outcome class: disclosure if the route stays at file access, or remote code execution if the same route survives toward CGI-enabled execution

That is the point of the distinction. The primitive tells you the kind of capability. The role tells you what function it is serving in the route. The outcome tells you what state becomes reachable if the path holds together.

For the full grounded case, see Apache HTTP Server: path traversal to execution.

Choose one public case or CVE and classify it across three layers:

1. primitive family
2. path role
3. outcome class

Use this sequence:

1. identify the weakness briefly
2. describe the capability created
3. assign the best-fit primitive family
4. identify the role that capability plays in the route
5. identify the strongest plausible outcome class
6. mark the outcome as potential or validated
7. explain which environmental conditions affect the route

The goal is not to produce a perfect exploit narrative. The goal is to practice disciplined classification so that capability, route function, and consequence stop blurring together.

Suggested deliverable shape:

• Weakness
• Primitive family
• Path role
• Outcome class
• Validation status
• Key preconditions
• Why this classification fits

Double check that you can now:

• distinguish primitive family, path role, and outcome class cleanly
• explain why the same primitive can serve different roles in different routes
• describe why outcome class is not the same thing as capability
• separate potential outcomes from validated ones
• classify a real route using all three layers without collapsing them together

If those distinctions still feel slippery, reread Module 2 and compare the examples against the middle-layer sections of the paper.

Module 4 formalizes the middle layer.

That matters because once primitive families, path roles, and outcome classes are clear separately, the next step is to see how they fit together as one reusable analytical bridge between weaknesses and outcomes.

Continue to Module 4 when you are ready.

This module borrows from adjacent public work on attack patterns, attacker objectives, and multi-step flow representation, then pushes the argument toward a cleaner internal vocabulary for exploit-path composition.

• CAPEC
• MITRE ATT&CK data and tools
• MITRE Attack Flow