OWASP ASVS

Verify AI-assisted code against ASVS Level 1, 2, and 3.

VibeReview's threat model identifies which ASVS chapters apply to your repo. Guardrails enforce the verification requirements at prompt time. PR review logs evidence per verification ID. The coverage report names every V1 through V14 chapter you ship code against.

14-day free trial · No card required

You prompting Cursor · app/api/auth/reset.py

"Add a password-reset endpoint. Email a link, accept the token, set the new password."

VibeReview matched 3 ASVS verifications · invisibly
  • V2.2.1 — rate-limit reset requests per account
  • V3.2.2 — single-use token with > 64 bits entropy
  • V7.1.1 — audit reset attempts, never log the token
app/api/auth/reset.py
@app.post("/auth/reset/request")
@limiter.limit("3/hour", key=email)
def request_reset(email: str):
    token = secrets.token_urlsafe(48)
    db.execute(
        "INSERT INTO reset_tokens "
        "(email, token_hash, expires_at) "
        "VALUES (?, ?, ?)",
        (email, sha256(token), now() + 30),
    )
    audit.log("reset.requested", email=email)
    mailer.send_reset_link(email, token)

✓ Rate-limited, hashed token, audit-logged. Verifications V2.2.1, V3.2.2, V7.1.1 satisfied on the first prompt.

MODEL

Threat model → in-scope ASVS chapters.

Auth endpoints surface V2 and V3. Server-side data handling surfaces V5 and V8. Crypto paths surface V6. The model tells you which chapters apply to this repo.

ENFORCE

Guardrails → ASVS verification requirements.

Each guardrail names the verification IDs it enforces. JWT lifetime, password storage, output encoding, TLS configuration, log injection. Verifications fire at prompt time.

EVIDENCE

PR review → verification log per change.

Each diff that touches an in-scope path runs the verifications. Audit log records the verification ID, the file, the author, and the outcome.

REPORT

Coverage report → V1 through V14.

Per-chapter, per-verification coverage. Levels 1, 2, or 3 indicated. Hand to your assessor with the SoA.

WHAT'S COVERED

ASVS chapters and the VibeReview controls behind them.

Coverage is repo-dependent. Your mapping report names the verifications enforced for your stack.

  • V1 Architecture, Design and Threat Modeling: VibeReview generates the threat model itself. Trust boundaries, data flows, and AI failure modes documented per repo.
  • V2 Authentication: Guardrails enforce password storage, MFA hooks, credential lifecycle, and session binding policies on every auth-related prompt.
  • V3 Session Management: JWT lifetime ceilings, rotation, scope, and revocation checks enforced at the IDE and verified at the PR.
  • V4 Access Control: Object-level authorization, role checks, and tenant isolation rules per data model.
  • V5 Validation, Sanitization and Encoding: Input validation, output encoding, parameterized queries, and SSRF protections enforced per entry point.
  • V6 Stored Cryptography: Algorithm allow-lists, key management, KDF parameters, and random-source rules per crypto module.
  • V7 Error Handling and Logging: Structured logs, no secret leakage in errors, log-injection mitigation, and audit-event coverage.
  • V8 Data Protection: Sensitive-data classification, cache-control headers, memory-clearing patterns, and retention enforcement.
  • V9 Communication: TLS configuration, certificate pinning hooks, and outbound-call allow-listing.
  • V10 Malicious Code: Dependency policy, package pinning, supply-chain checks, and AI-generated backdoor detection patterns.
  • V11–V14 (Business Logic, Files, API, Config): Repo-specific guardrails per endpoint, per upload path, per API contract, and per config surface.

Get the ASVS mapping report for your repo.

We run the threat model, generate the per-chapter coverage, and walk you through it. Bring your assessor.