OWASP ASVS for Enterprise Application Security Verification

Overview

OWASP Application Security Verification Standard (ASVS) is a structured catalog of security requirements for web applications and APIs. It gives enterprises a common language for defining what "secure enough" means at design time, during implementation, and before production release.

Organizations adopt ASVS because it maps security controls to verification activities and maturity levels. In practice, it helps AppSec, platform engineering, auditors, and delivery teams align on measurable requirements, reduce subjective reviews, and enforce policy in CI/CD.

ASVS levels in practice

• Level 1: Baseline controls for all applications
• Level 2: Recommended for applications processing sensitive data
• Level 3: High assurance for critical systems, regulated workloads, and high-risk transactions

Architecture

ASVS is not a runtime product; it is a verification model integrated into enterprise delivery processes.

Core components

• ASVS control set: Requirement categories such as authentication, access control, validation, cryptography, and logging
• Policy mapping: Internal standards mapped to ASVS chapters and control IDs
• Evidence pipeline: SAST, DAST, SCA, IaC scanning, code review, and penetration testing results linked to ASVS requirements
• Release gates: CI/CD checks that fail builds or block promotion when mandatory controls lack evidence
• Exception workflow: Risk acceptance with expiration, owner, and compensating controls

Deployment models

• Centralized AppSec: A core security team owns the ASVS baseline and reporting
• Federated DevSecOps: Shared policy with product teams implementing controls locally
• Platform-driven: Golden pipelines and templates embed ASVS checks by default

Data flow

1. Product classification assigns an ASVS level.
2. Requirements are mapped into backlog items and non-functional controls.
3. CI/CD runs scanners and policy checks.
4. Evidence is stored in Git, ticketing systems, and security dashboards.
5. Release decisions are made from control coverage and exception status.

Implementation Guide

1. Clone the ASVS source and select a version

git clone https://github.com/OWASP/ASVS.git
cd ASVS
git checkout v4.0.3

2. Create an internal policy mapping file

asvs_version: "4.0.3"
application:
  name: payments-api
  classification: critical
  target_level: 3
required_controls:
  - V1
  - V2
  - V3
  - V4
  - V5
  - V7
  - V8
  - V9
  - V10
  - V13
release_gate:
  block_on_missing_evidence: true
  max_open_high_findings: 0
  max_open_medium_findings: 3
exceptions:
  require_expiry: true
  max_days: 30

3. Enforce ASVS in CI with Open Policy Agent

mkdir -p policy
cat > policy/asvs.rego <<'EOF'
package cicd.asvs

default allow = false
allow {
  input.target_level >= 2
  input.sast.high == 0
  input.sca.critical == 0
  input.dast.high == 0
  input.missing_evidence == 0
}
EOF

opa eval -i build-input.json -d policy 'data.cicd.asvs.allow'

4. Add a pipeline job

stages:
  - test
  - security
asvs_gate:
  stage: security
  image: openpolicyagent/opa:latest
  script:
    - opa eval -f pretty -i build-input.json -d policy 'data.cicd.asvs.allow'
  allow_failure: false

5. Track evidence and exceptions

Store evidence artifacts per release: SAST SARIF, DAST reports, dependency scan output, penetration test references, and signed exception records. Tie each artifact to ASVS control IDs in Jira, Azure Boards, or ServiceNow.

Code Examples

Example 1: Build input for an ASVS release gate

{
  "app": "payments-api",
  "target_level": 3,
  "sast": {"high": 0},
  "sca": {"critical": 0},
  "dast": {"high": 0},
  "missing_evidence": 0
}

Example 2: GitLab CI security gate

security_asvs:
  stage: security
  script:
    - test -f reports/sast.sarif
    - test -f reports/sca.json
    - test -f reports/dast.json
    - opa eval -i build-input.json -d policy 'data.cicd.asvs.allow' | grep true

Example 3: Python evidence validator

import json, sys
required = ["sast.sarif", "sca.json", "dast.json"]
files = sys.argv[1:]
missing = [f for f in required if f not in files]
result = {"missing_evidence": len(missing), "missing_files": missing}
print(json.dumps(result))
if missing:
    sys.exit(1)

Security Hardening

• Protect evidence integrity with signed build artifacts, immutable object storage, and retention policies
• Encrypt reports at rest using KMS-backed storage and in transit with TLS 1.2+
• Restrict access through RBAC: developers view project findings, AppSec manages policy, auditors get read-only access
• Separate duties so exception approvers are not the same users merging code
• Harden scanners and runners by pinning container digests, disabling privileged mode, and isolating runners per trust zone
• Audit everything: policy changes, gate overrides, exception approvals, and release decisions

Comparison

Troubleshooting

1. Policy evaluation fails on missing input

Log sample:

openpolicyagent/opa: eval error: 1 error occurred: policy/asvs.rego:6: rego_type_error: undefined ref: input.sast.high

Fix: Ensure build-input.json contains the expected schema and validate JSON before policy execution.

2. Pipeline blocks due to absent evidence artifact

Log sample:

$ test -f reports/dast.json
ERROR: Job failed: exit code 1

Fix: Publish the DAST artifact in the prior stage and verify artifact paths are preserved across jobs.

3. Scanner results not mapped to ASVS controls

Log sample:

2025-02-11T09:14:22Z appsec-gateway WARN control_mapping_missing control_id=V4.3 source=SAST rule=java/sql-injection

Fix: Maintain a central control mapping registry that links scanner rule IDs to ASVS chapters and review it quarterly.

Best Practices

Do

• Classify applications early and assign ASVS level during intake
• Use golden pipelines so every service inherits the same minimum controls
• Map findings to control IDs for auditability and trend reporting
• Time-box exceptions with compensating controls such as WAF rules or feature flags

Don't

• Do not treat ASVS as a checklist-only exercise; require evidence, not just attestation
• Do not apply Level 3 everywhere; risk-tier applications to avoid delivery friction
• Do not rely on a single scanner; combine SAST, DAST, SCA, and manual review
• Do not leave exceptions open-ended; expired exceptions should fail release gates automatically