concept Updated 2026-10-06

The CAVET Method

Component Analysis & Vulnerability Enumeration Technique — the ontology and workflow behind Nimbus Vault.

What CAVET is

CAVET — Component Analysis & Vulnerability Enumeration Technique — is a systematic approach to offensive security testing. It answers one central question:

What components are present, what properties do they have, and which attacks do these enable?

Where defensive frameworks model what could go wrong during design, CAVET models what is testable during an engagement: it is evidence-based, built from observations of the running system.

The five components

CAVET's ontology is the same one Nimbus Vault's component library is built on. Each type isn't just a category — it plays a distinct role in how vulnerabilities come to exist.

Technologies — the constraint space. The frameworks, languages, platforms, and infrastructure a target runs on. More than "what it's built with": technologies define the universe of what is possible and impossible — the constraint space attacks must live inside.

Functionalities — trust boundaries. The discrete things the app does for users: login, upload, search, payments. Each is a boundary where the application accepts external input and makes a promise about what it will do with it. Vulnerabilities are broken promises.

Gadgets — unintended capabilities. Mechanisms built for legitimate purposes that can be repurposed: innerHTML, eval(), postMessage bridges, deserialization, URLs the server fetches. Gadgets are the force multipliers that escalate simple bugs into impact.

Vectors — the application's perception system. How attacker-controlled input reaches the application and how responses travel back: parameters, headers, cookies, bodies, file metadata. Vectors are the lenses through which the app sees the world — the same payload behaves differently depending on which lens it arrives through.

Quirks — emergent properties and ground truth. What testing reveals about how the components actually behave: reflects input without encoding, no CSRF token present, accepts __proto__, CSP blocks inline scripts. Quirks are what is — and they come in two directions: enabling and mitigating.

The workflow

The ontology is half of CAVET. The other half is the order of operations:

  1. Observe — map the technologies, functionalities, gadgets, and vectors systematically.
  2. Probe — test the observed surface to discover its quirks.
  3. Reason — match the confirmed context against known attack patterns.
  4. Test — execute against the patterns that the context supports, and only those.

The order is not a suggestion. You cannot reason about which attacks apply without knowing the quirks; you cannot probe for the properties of something you haven't observed. Skipping or rearranging the stages is what produces guesswork — payloads sprayed at inputs that were never contextualized.

And the cycle repeats: testing produces new observations, probing confirms new quirks, and the context gets sharper every pass.

From theory to practice

CAVET wasn't always this formal. It began as "contextual hacking" — a way of describing how experienced hunters actually work — and only later acquired its ontology and workflow. The formalization is what makes it teachable:

  • Map write-ups into components. Deconstructing a public report into technologies, functionalities, gadgets, vectors, and quirks is the fastest way to internalize the ontology.
  • A missed quirk is the tell. If a write-up's decisive detail was a behavior you hadn't considered, the gap is in your probing, not your payloads.
  • Synthesis is the goal. The final skill is constructing a hypothetical bug from components alone — before you have seen it.

How Nimbus Vault implements it

  • The Component Library is the mapping layer — observations structured by the five types.
  • The Threat Library is the knowledge layer — playbooks that encode attack patterns in the same language.
  • The Nexus Engine is the logic layer — deterministic matching that connects the two.

That correspondence is the point: the tool is not a companion to the methodology, it is the methodology made operational.

What's next