How do OWASP ASVS and the OWASP Proactive Controls differ in what they give a team?

### Two catalogs, two jobs A threat model produces sentences like "an attacker could read another tenant's invoice" or "the import job could be fed a hostile document". Those are **threats**: statements of what could go wrong. To close one you need a **control** (something you build) and, if anyone other than the author is ever going to believe the control exists, a **verification requirement** (something someone can test). The two OWASP catalogs named here sit on opposite sides of that line. **The OWASP Proactive Controls** are a short, ordered list of defensive techniques written for developers, in developer language, to be applied *while designing and building*. The list is deliberately small — around ten items — so that a working engineer can hold it in their head: enforcing access control, validating input and handling exceptions, using cryptography correctly, protecting data in transit and at rest, keeping components current, secure-by-default configuration, security logging and monitoring, and defining security requirements early. The exact membership and ordering has been revised across editions, which matters less than the shape: it is guidance about *what to build*, not a list of vulnerabilities and not a list of products. Nothing in it is a tool you install. **The OWASP Application Security Verification Standard (ASVS)** is the verification side. It is a large catalog of requirements grouped into topic chapters — architecture, authentication, session management, access control, input handling and encoding, cryptography, error handling and logging, data protection, communications, business logic, files and resources, configuration — and each requirement is phrased as a testable statement beginning "Verify that…". Requirements are graded into **three cumulative verification levels**: a baseline level, a standard level appropriate for applications handling sensitive data or transactions, and a top level for the highest-assurance systems. Cumulative means the middle level contains the baseline's requirements and the top level contains both — they are floors stacked on one another, not three alternative checklists. Many requirements also carry a **CWE** mapping, which gives the underlying weakness a name that is not local to your document. ### Why the difference matters in a threat-modeling session When you finish enumerating threats, you are holding a column of "what could go wrong" and an empty column beside it. The Proactive Controls help you fill the second column with a *class of defence* in language your engineers already use. ASVS then lets you rewrite that entry as something a tester, a reviewer or an auditor can check independently of the person who wrote it. "Handle errors so they do not leak internals" is Proactive-Controls-shaped advice; "Verify that the permit-lookup endpoint returns a generic message on failure and never includes a stack trace, SQL text or internal hostname in the response body" is ASVS-shaped, and it is falsifiable. That difference — advisory versus falsifiable — is the whole point of pulling a published catalog into a threat model. It also removes an argument: the requirement's wording came from a public standard rather than from the loudest person in the room, and the level attached to it says who is expected to meet it. ### What neither one is Neither catalog enumerates threats for you. ASVS knows nothing about your trust boundaries, your tenancy model, your payment flow or the one internal service that everybody trusts implicitly. It is a generic baseline: passing every requirement at a level says the application meets a published bar of hygiene, not that the design is safe against an adversary who understands your business logic. This is the most common misuse — a team adopts ASVS *instead of* modeling, and then finds that the weakness that hurt them was an authorization rule nobody had written down. The catalogs complement a model; they do not generate one. Neither is a regulation, either. Nothing obliges anyone to meet a level unless a contract says so, and a claim to meet one carries no weight without evidence of scope and assessment. ### Where CWE fits CWE is the third piece of vocabulary and the smallest one to explain here: it is a catalog of *weakness types*, and its role in this workflow is as the shared name for the defect your threat would exploit. Attaching one to a modeled threat means that the threat, the ASVS requirement that addresses it, and any detection rule someone writes later are all talking about the same thing, even though three different teams wrote them. It also collapses duplicates — the same weakness found in four services is one weakness class with four instances, which is a very different backlog conversation from four unrelated findings. ### The practical answer Reach for the Proactive Controls when the question is "we have this threat, what do we build?" and you want an answer in a builder's vocabulary. Reach for ASVS when the question is "how will anyone know we built it?" and you need wording someone can test against, with a level that states how hard you are trying. Use both, on the same row of the same table, and the threat model stops being a document and starts being a set of commitments.