Technologies
The frameworks, servers, languages, and platforms a target is built with.
What a technology is
A technology is something a target is built with or runs on: a language runtime (Node.js, PHP), a web server or proxy (Caddy, nginx), a datastore (PostgreSQL, Redis), a framework (Laravel, Rails), a platform (Android, Cloudflare Workers).
In CAVET terms, technologies define the constraint space — the universe of what is possible on this target and what is not.
Why they matter
Technologies are the anchor for everything version-, configuration-, or runtime-specific. A quirk almost never applies "everywhere on the asset" — it applies to a specific technology in a specific state. Linking the technology gives those observations a place to live and gives the engine a scoping anchor.
How they link
Usually directly to the asset — a technology is a property of the thing you are testing. Behavior specific to it is captured as scoped children:
- a quirk inside the technology (
Prototype pollutioninsideNode.js) - a vector inside the part of the stack it affects
A quirk scoped to a technology scores more specifically than the same quirk floating on the asset, and playbooks that require the pairing can only match when the structure is right.
Library hygiene
One entry per technology, kept stable and undated. Node.js is knowledge you keep forever; prototype pollution is a quirk scoped to it; the version condition is a detail on that observation. When you are tempted to create "Apache 2.4.49 path traversal" as a technology, you are really looking at three separate components.
In the app
Create one from Technologies in the sidebar with Add Technology:
| Field | Required | Notes |
|---|---|---|
| Name | Yes | Autocompletes from the technology catalogue — picking a match fills category, description, and logo |
| Category | Yes | e.g. Backend Framework; suggestions come from categories already in use |
| Description | No | What the technology does |
| Vendor | No | Who makes or maintains it |
| Logo URL | No | Optional branding for tables and cards |
| Tags | No | Comma-separated (backend, node, wip) |
The technology notespace carries a Components tab no other type has: default quirks, common vectors, and common gadgets that assets inherit when they link this technology. Each default carries an Inheritance Level (Asset or Component), an Inheritance Mode (Auto or Manual), and — for quirks — a Default Polarity (Present / Absent). "This stack usually exhibits prototype pollution" becomes one link instead of dozens. When you link a technology to an asset and know the version, record it in the link's Version field — it feeds version-constrained playbook requirements.
What's next
Functionalities — what the stack does for users.