The unified security taxonomy 🧠

This taxonomy is an analytical reading of this series, not a new OWASP Top 10. It normalizes failures that recur across domains while preserving differences in mechanism and control. Its entire value is here: holding together what really is the same and carefully annotating what only looks like it.

The method is simple: start from a fundamental security property (authorization, data integrity, availability), see how its failure manifests across domains, and trace back to the OWASP categories that name it. Normalization is not simplification: it is a compression that loses only what you can reconstruct by returning to the domain.

Ten cross-cutting concepts 🔟

1. Authorization and access control: who can do what to which resource.
2. Identity and authentication: who or what is actually acting.
3. Input and injection: untrusted content altering an interpreter or flow.
4. Output and downstream execution: output becoming code, query, or action.
5. Supply chain and provenance: components, data, and artifacts whose origin and integrity are not verified.
6. Cryptography and secrets: protection and lifecycle of sensitive information.
7. Hardening and configuration: defaults, policy, and exposed surfaces.
8. Resources and availability: consumption, limits, and resilience.
9. Telemetry and exceptions: ability to see, understand, and handle failure.
10. Autonomous logic and agency: decisions or tools with power beyond the intended boundary.

Every concept violates a specific property, and that is what you should cite when explaining the priority to the business:

    flowchart TD
    A[Security property] --> B[Normalized concept]
    B --> C[Domain manifestation]
    C --> D[OWASP category and controls]
  

Two complete examples 🧪

Access control. Follow concept number 1: on the Web it is a reachable route without a check (A01); in an API it splits into three granularities — object (API1 BOLA), property (API3), and function (API5 BFLA) — because an API directly exposes the object graph; in Kubernetes it becomes permissive RBAC declared in the manifest (K03); in an agent it becomes the distinction between “how much this non-human actor can do” and “does this request pass the check” (LLM08). The principle is related; the verification is not, and writing a single test suite hoping to cover them all is a mistake.

Injection. Concept 3 has two faces that must NOT be flattened. Classic injection (A05, S1, M4) abuses a well-defined grammar — SQL, shell, XML — and a fix exists: parameterization and escaping against that grammar. Prompt injection (LLM01) does not abuse a grammar: it puts hostile content in the same channel used for legitimate instructions, and there is no equivalent of parameterization for natural-language instruction. Calling them “the same thing” makes you choose the wrong controls for both.

Cryptography and secrets. Concept 6 has the most diverse postures: the Web treats it as cryptographic failure (A04), Mobile splits it into three entries — poorly stored credentials (M1), sensitive data on insecure storage (M9), weak primitives (M10) — Kubernetes calls it secret management (K08: Base64 in etcd, not encryption), and CI/CD sees it as credential hygiene (CICD-SEC-6). Four postures for the same principle; the norm, not the exception.

Supply chain. Follow concept 5 and you descend the entire delivery chain: dependencies (A03 and SCA), opaque mobile SDKs (M2), images and charts (K02), build actions and artifacts (CICD-SEC-3/8/9), down to model weights and datasets (LLM05). A single concept; the boundary of what must be verified changes at every layer jump.

Using it correctly 🧭

Take a property, follow the concept, then return to the domain. The taxonomy prevents gaps between teams and tools: a privilege policy must cover users, service accounts, pipelines, and agents. It does not replace OWASP documentation for the technology being assessed.

Three usage rules:

• One taxonomy row is not a verdict. Locate where the concept lives in your system and verify the controls cover that specific domain.
• Do not confuse projections with duplicates. The matrix you will use next exists precisely to tell them apart.
• Update with the editions. The taxonomy is as living as the lists that feed it: the arrival of A10 (exceptional conditions) and LLM08 (agency) in 2025/2026 changed the real weight of concepts 9 and 10.

The limits to declare ⚠️

Normalization has sharp boundaries. Language models violate the classical assumption that instructions and data are separable: that is why concept 3 is a family, not an identity. Smart contracts run on economic invariants (reentrancy, precision, oracles) that do not map cleanly onto A01-A10: if your domain is Web3, the taxonomy helps less than the dedicated list. And some lists are so immature that they offer no “manifestation” to connect, only an intuition to annotate.

The taxonomy is a lens, not a bible. When it forces the picture, the picture is right.

Read the cross-reference matrix to apply these concepts across domains.