What ASVS is, in one paragraph
The OWASP Application Security Verification Standard (ASVS) is a catalogue of security requirements for web applications, organised into 17 chapters (V1 through V17) and 3 verification levels (L1: basic hygiene, L2: most applications, L3: high-value targets). Version 5.0.0 defines 348 individual requirements. It is a checklist for humans and processes as much as for tools — most requirements describe an outcome ("verify that X is enforced"), not a code pattern, which is precisely why a purely static scan cannot mechanically verify every line of it.
The honest number: 44 of 348
StaticCodeAudit maps 44 ASVS v5.0.0 requirements to at least one detection rule — about 13% of the full standard. That is not a marketing rounding error; it is the real count from the mapping file shipped with the scanner, and it shows up identically in every generated report's compliance section.
| Chapter | Covered |
|---|---|
V1Encoding, Sanitization and Sandboxing |
16 / 30 |
V3Web Frontend Security |
11 / 31 |
V6Authentication |
4 / 48 |
V11Cryptography |
4 / 25 |
V4API and Web Service Security |
3 / 16 |
V5File Handling |
2 / 13 |
V9Self-contained Tokens |
2 / 7 |
V12Secure Communication |
1 / 12 |
V16Security Logging and Error Handling |
1 / 17 |
Why the other 8 chapters show zero
V2 (Business Logic), V7 (Session Management), V8 (Authorization), V10 (OAuth and OIDC), V13 (Configuration), V14 (Data Protection), V15 (Secure Coding and Architecture) and V17 (WebRTC) have no requirement mapped to a rule today. That is not an oversight — most of what those chapters ask for is not visible as a source-code pattern: whether an authorization check is correct for a given business rule, whether an OAuth flow is configured with the right scopes on the identity provider, whether a session timeout is set appropriately for the sensitivity of the data — these require understanding intent and runtime configuration, not just parsing syntax. Static analysis is one input to an ASVS assessment, not a substitute for the human review those chapters call for.
How a requirement maps to a real rule
Nine examples, straight from the mapping file — the actual rule identifiers that produce a finding when triggered:
| Requirement | Level | What it verifies | Rule(s) |
|---|---|---|---|
| 1.2.4 | L1 | SQL queries use parameterized queries or ORM | sql_injection_fstring, sql_injection_concat… |
| 1.5.1 | L1 | XML parsers are configured to prevent XXE | xxe_injection, xxe_injection_csharp, xxe_injection_php |
| 3.4.3 | L1 | CSP header is configured | missing_csp_header |
| 3.5.1 | L1 | CSRF protections are enabled | django_csrf_exempt, spring_csrf_disabled |
| 6.3.3 | L2 | MFA is available for sensitive operations | missing_mfa_python, missing_mfa_javascript… |
| 9.1.2 | L1 | JWT "none" algorithm is rejected | jwt_none_algorithm |
| 11.3.1 | L1 | Strong cryptographic algorithms are used | weak_crypto, weak_crypto_java… |
| 11.5.1 | L1 | Cryptographically secure random generators are used | weak_random_java, insecure_random… |
| 12.2.1 | L1 | All connections use TLS | http_no_tls, unencrypted_transfer |
Level column is ASVS's own classification (L1 = basic, L2 = standard, L3 = high-assurance) — StaticCodeAudit does not assign it, it is read directly from the OWASP specification.
Where this shows up in the report
Every scan's HTML report includes an "OWASP ASVS v5.0.0 Compliance" section with a per-requirement matrix: each of the 44 mapped requirements shows as covered-and-clean, covered-with-findings, or not-covered — not just a single percentage. A requirement with an active HIGH finding (say, an MD5 hash triggering 11.3.1) is visually distinguished from one that is covered and passes clean, so a reviewer does not have to guess which 13% actually matters for a given codebase.
Generate it yourself
No separate flag — the ASVS matrix is part of every standard HTML report:
./staticcodeaudit-linux-x86_64 /path/to/project --fail-on-highThe same run also produces the ISO 27001 Annex A and NIST CSF 2.0 matrices side by side. See the full standards coverage page for the interactive breakdown of all four frameworks.
Frequently asked questions
Does 44/348 mean StaticCodeAudit is only 13% ASVS-compliant?
No — that framing conflates two different things. 44/348 is how much of the ASVS checklist a source-code scan can mechanically verify, not how much of it your application satisfies. A codebase can be fully compliant with a given ASVS requirement without any tool detecting it (e.g. a correctly configured session timeout), and the remaining 304 requirements simply are not the kind of thing static analysis checks.
Will the 44 number go up over time?
It has moved before and can move again as new rules are added — it's read from a mapping file shipped with the scanner, not hardcoded into marketing copy. Check the changelog for when compliance-mapping updates ship.
Does ASVS coverage differ by ASVS level (L1/L2/L3)?
Yes — the level shown in the matrix is the level defined by OWASP for that specific requirement, not something the scanner decides. Most of the 44 covered requirements are L1 (basic hygiene); a handful, like MFA availability (6.3.3), are L2. Nothing at L3 is currently mapped, consistent with L3 requirements skewing toward architecture and process review.
Can this replace a manual ASVS assessment?
No, and it is not positioned as one. It is a fast, repeatable, offline first pass on the requirements that are actually visible as code patterns — useful evidence to attach to a manual assessment, not a substitute for the human review that chapters like Authorization or Business Logic require.
See the full compliance matrix on real code
Open the live demo report and scroll to the OWASP ASVS section — no install, no signup.
Open the live report Download the demo binary