Vet’s checks map to specific OWASP ASVS (Application Security Verification Standard) control IDs. This document explains what ASVS is, how it’s structured, and which controls vet covers.

What is ASVS?

The OWASP Application Security Verification Standard is a framework of security requirements for designing, developing, and testing web applications. It defines ~280 controls organized into 14 categories, each specifying a testable security property.

ASVS is not a tool or a scanner. It’s a checklist. Tools like vet automate the testable subset of that checklist.

Verification levels

ASVS defines three levels of verification depth:

CASA Tier 2 maps to ASVS Level 2. Vet targets the automatable subset of Level 2 controls.

ASVS category structure

ASVS organizes controls by category prefix:

Not all categories are automatable. V1 (architecture) and V11 (business logic) require human judgment. Vet focuses on the categories that can be tested by sending HTTP requests and inspecting responses.

How to read vet’s control IDs

Every check in vet’s output has an id field that maps to an ASVS control:

V9.1.1
│ │ │
│ │ └─ Specific requirement (1st check in subcategory)
│ └─── Subcategory (Security Headers)
└───── Category (V9 = Communication)

Vet uses its own numbering within each subcategory to keep IDs stable across versions. The mapping is consistent but not always 1:1 with the ASVS spec numbering — vet groups some checks differently for practical testing reasons.

Which ASVS categories vet covers

V5 — Validation, Sanitization and Encoding

Vet tests input validation by sending attack payloads and malformed data to every discovered endpoint.

What vet can detect: Error-based SQL injection, reflected XSS, basic path traversal, crash-inducing malformed input.

What vet can’t detect: Blind SQL injection, stored XSS, DOM-based XSS, second-order injection, business logic bypass through input manipulation.

V7 — Error Handling and Logging

Vet checks that error responses don’t leak internal information.

Vet triggers errors by sending: path traversal in query params, malformed JSON, non-existent paths, path traversal in URL, and invalid bearer tokens.

V8 — Data Protection (planned)

Will test that tokens don’t appear in redirect URLs, error messages, or GET parameters.

V9 — Communication

The largest category in vet. Covers security headers, HTTP methods, TLS, and CORS.

V9.1.x — Security Headers:

V9.2.x — HTTP Method Enforcement:

V9.3.x — TLS/SSL:

V9.4.x — CORS:

V10 — Malicious Code / Webhook Security (planned)

Will test webhook signature validation: missing signature rejected, invalid signature rejected, replayed timestamp rejected.

V13 — API and Web Service / Rate Limiting (planned)

Will test that rate limits are enforced and return structured 429 responses.

V2 — Authentication / OAuth (planned)

Will test OAuth-specific flows: state replay, code replay, redirect_uri enforcement, PKCE, missing client_secret.

Coverage summary

Total implemented: 38 unique check types, each run per discovered endpoint. A scan of an app with 10 endpoints produces ~300+ individual checks.

What ASVS doesn’t cover

ASVS focuses on application-level security. It does not cover:

• Infrastructure security (firewall rules, network segmentation)
• Physical security
• Social engineering
• Supply chain attacks (dependency vulnerabilities)
• Privacy regulations (GDPR, CCPA)

These are out of scope for both ASVS and vet.