ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat

ASVS is a set of application verification requirements. The OWASP project identifies 5.0.0 as the stable release and recommends versioned requirement identifiers because numbering can change. A report saying ASVS tested without edition, level, applicable requirement set and application scope cannot be repeated. Record source revision, deployed artifact, environment, interfaces and exclusions. A single passing requirement is not an assessment of an entire ASVS level.

This guide uses v5.0.0-1.2.5, the OS command-injection requirement in chapter V1 (/asvs/5.0/v1/), as a concrete verification target. The explanation here paraphrases its intent: untrusted values must not become unintended operating-system command syntax. The scope is Cedar's thumbnail worker and its two subprocess call sites, not every service in the organization. The exercise supplies one safe-looking candidate and one overlooked legacy path. That makes coverage visible instead of letting one successful test stand for the whole application.

OWASP released ASVS 5.0.0 on 30 May 2025 with 345 requirements in the 17 chapters below. Each requirement has one level. Level 1 is the first layer of defense, 70 requirements or about 20%; most applications should aim for level 2, which brings the total to about 70%; level 3 adds the remaining 30% for applications that must show the highest assurance.

The numbering is new. Of the 286 requirements in version 4.0.3, only 11 survive unchanged, 109 were deleted, deduplicated or merged, and even unchanged requirements moved. A record that says “ASVS 4.0.3 V5.3.8” cannot be compared with a 5.0.0 result without remapping each requirement.

A useful verification argument names the hazard, mechanism and expected observation. For command injection, the hazard is that a user-controlled filename or label becomes shell syntax. A subprocess argument list with the shell disabled separates arguments from shell interpretation; it does not stop the invoked program from treating a filename that begins with a dash as an option. The program’s argument semantics and permitted inputs still need review.

The evidence chain therefore includes a call-site inventory, code and configuration review, and behavior tests. In the code below, Cedar’s S1 path runs a fixed executable with an argument list, no shell and a server-generated output name; the legacy S2 path builds a shell command by concatenating a user label. A happy-path thumbnail test exercises neither the dangerous label nor the legacy route. The assessor should identify the uncovered path and require a change plus regression before marking the scoped requirement satisfied; /fix/command-injection/ shows that fix and its test in several stacks.

import subprocess
import uuid
from pathlib import Path

CONVERT = "/usr/bin/convert"
OUTPUT = Path("/scratch/thumbnails")


def thumbnail_legacy(upload_path, label):
    # S2, fails v5.0.0-1.2.5: the shell parses the user's label as command syntax.
    subprocess.run(
        f"{CONVERT} {upload_path} -resize 200x200 {OUTPUT}/{label}.png",
        shell=True,
        check=True,
    )


def thumbnail(upload_path, convert=CONVERT):
    # S1: fixed executable, argument list, no shell, and a server-generated output name.
    # The label stays display metadata; it never reaches the command line.
    target = OUTPUT / f"{uuid.uuid4().hex}.png"
    subprocess.run(
        [convert, str(upload_path), "-resize", "200x200", str(target)],
        check=True,
        timeout=60,
    )
    return target

A record should include requirement ID, applicability reason, test ID, artifact/source identity, environment, input, expected behavior, actual observation, evidence location, evaluator, time and result. Use pass, fail, not tested and not applicable as different outcomes. Not applicable needs a reason tied to product behavior; the absence of a test is not that reason. Preserve failing observations as well as the retest so reviewers can see what changed.

The fixture provides transcript E31, showing the legacy path created a harmless marker file in a disposable scratch directory, and E32, showing the argument-list path did not. These are fictional supplied observations, not results generated by this page. Their evidence IDs function as links within the training dossier. In a real report use immutable accessible records with sanitized inputs and outputs. Do not include live credentials, private customer data or an unverifiable screenshot as the sole proof. A test that cannot be located or tied to the artifact should be reported as missing evidence.

The /labs/release-evidence/ lab practices the same rule in code: test evidence from an older artifact must not decide the release of a newer one.

The result for the release is fail because one in-scope call site remains unsafe. S1 can be described as verified for the path tested; closure needs S2 fixed, both paths retested and the tested artifact identified. This is more useful than an overall percentage that hides a decisive failure. A risk owner may choose a bounded exception under organizational policy, but the technical verification result remains fail; acceptance does not turn the requirement into a pass.

Reports should distinguish requirement satisfaction from confidence and coverage. A carefully examined call-site inventory plus representative negative tests is stronger than one unexplained scanner result, yet it still depends on the inventory's completeness and environment fidelity. New subprocess calls, changed executable options or deployment configuration invalidate parts of the argument. Write those reopening conditions into the record. The purpose is a test another engineer can repeat and challenge, not a claim of certification from one laboratory example.

Repair the code

Release evidence lab: Keep stale test evidence out of a release decision

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP ASVS 5.0.0 release. 30 May 2025.
2. OWASP ASVS 5.0.0, V1 Encoding and Sanitization (requirement 1.2.5). Version 5.0.0.
3. OWASP OS Command Injection Defense Cheat Sheet
4. Python documentation: subprocess security considerations
5. NIST SP 800-218: SSDF 1.1, final. Version 1.1 (February 2022).

Reference information

Tags

Security testingSecure development lifecycleCompliance and assurance evidence

SDLC phase

TestingSecurity program

Role

AppSec engineersSecurity leaders

ASVS 5.0.0 requirements

v5.0.0-1.2.5

Download this guide as Markdown

Continue exploring