A taxonomy is useful when it shapes the work. Pentrova organises attack chains into five classes — Injection, Access Control, Crypto, Infra, and AppSec — and each one exists because it maps cleanly to a coverage area and to a shared review discipline.
This post names the five classes, shows how each one shares a structural shape, and explains why operational clarity matters more than a perfect mapping to CWE.
Why classify chains at all?#
Before this taxonomy existed, findings tended to live as a flat list ranked by severity. A flat list is hard to own: nobody can reason about “all 400 findings” at once, and a severity number tells you nothing about who should fix a bug or how it should be reviewed. Grouping by class gives the work a shape — engineers reason about one class at a time, auditors map one class to one control family, and the catalog grows in blocks rather than as an ever-longer list.
The five classes#
Injection#
Injection chains share a shape: user input reaches an evaluation context. The evaluator differs across SQL, templates, XML, and scripting sinks, but the chain structure and the evidence look similar enough that a single team can own the class. and both live here despite very different payloads.
Access Control#
Access Control chains share a different shape: a caller accesses an object the policy should have refused. The confirmation is always a cross-role replay with a diff. Coverage differs between REST, GraphQL, and session-based apps, but the evidence standard is identical — which is exactly what the Authorization Matrix is built to produce.
Crypto#
Crypto chains turn on weak or misapplied cryptography — predictable tokens, broken signature verification, downgradeable transport. The shape is “a guarantee the system assumed turns out not to hold”.
Infra#
Infra chains exploit the platform beneath the application — exposed metadata services, misconfigured storage, reachable internal endpoints. SSRF reaching cloud metadata is the canonical example.
AppSec#
AppSec is the catch-all for application-specific logic — workflow bypasses, race conditions, business-rule violations. These are the findings only the application can define, and the ones a generic checklist never reaches.
Why operational clarity beats CWE accuracy#
The point of the taxonomy is not accuracy against CWE — the product carries a CWE cross-walk inside for anyone who needs the formal mapping — but operational clarity. The five classes let engineers reason about one class at a time, let auditors map one class to one control family, and let the catalog grow in blocks. The classes let the work move, which is what a taxonomy is for.
This grouping also feeds the escalation catalog: chains compose across classes (an Injection finding escalating through an Infra path), and naming the classes makes those cross-class chains legible.
Key takeaways#
- Pentrova uses five chain classes: Injection, Access Control, Crypto, Infra, AppSec.
- Each class shares a structural shape and a shared review discipline, so a team can own it.
- The taxonomy optimises for operational clarity, not CWE precision; a CWE cross-walk lives in the product.
- Classes let the catalog grow in blocks and make cross-class escalation chains legible.
FAQ#
Does this taxonomy replace CWE or OWASP categories? No. It is an operational grouping for ownership and review. Pentrova carries a CWE cross-walk internally, so a finding still maps to its formal CWE for compliance and reporting.
Why five classes and not more? Five is enough to give the work a shape without fragmenting ownership. More classes would split teams too finely; fewer would lump unrelated review disciplines together.
How does a chain that spans classes get categorised? By its escalation path. A chain that starts with Injection and pivots through Infra is legible precisely because both classes are named — the catalog records the cross-class sequence.
Read how chains compose across classes in the docs.