OWASP ASVS Without the Spreadsheet

The OWASP ASVS is the most useful security standard most engineering teams never finish. Everyone agrees it is the right checklist for a web application or API. Then someone opens the requirement list, sees several hundred rows, and the assessment becomes a spreadsheet that is out of date the week after it is filled in.

The problem is not the standard. It is the method. A questionnaire answered once a year cannot keep up with code that changes every day, and a lot of that code is now written by agents.

This post explains what OWASP ASVS asks for, why spreadsheet assessments decay, and how to assess continuously from evidence you already collect, without pretending that evidence answers questions it cannot.

What OWASP ASVS is

The OWASP Application Security Verification Standard is an open list of security requirements for web applications and APIs, maintained by the OWASP Foundation. The current release is ASVS 5.0.0, and the source lives on GitHub.

Its value is precision. A policy says "encode output safely". ASVS says, in requirement 1.2.5 of version 5.0.0, that output encoding for an HTTP response, HTML document or XML document must fit the context it is used in. You can hold a codebase to that.

Levels

ASVS defines three assurance levels, and they are cumulative. Each level contains everything in the one below it.

• Level 1. The baseline for any application.
• Level 2. Applications that handle sensitive data or transactions. In practice, most business software.
• Level 3. The highest-assurance applications, where a breach would be severe.

Chapters

Requirements are grouped into chapters by subject: encoding and sanitization, validation and business logic, web frontend, API and web service, file handling, authentication, session management, authorization, self-contained tokens, OAuth and OIDC, cryptography, secure communication, configuration, data protection, secure coding and architecture, logging and error handling, and WebRTC. Chapters are usually how teams decide what to work on first.

Requirement keys

A key like v5.0.0-11.3.1 reads as version, chapter and requirement. Keep the version in the key. An assessment recorded against 4.0.3 means something different from one against 5.0.0, and requirement numbers moved between the two.

Why spreadsheet assessments decay

A spreadsheet ASVS assessment usually fails in the same four ways.

• It is a snapshot. The answer to "do we have unauthenticated endpoints" was true on the day someone checked. A merge the next week changes it and nobody updates the row.
• It is self-reported. A row marked "yes" is a statement, not evidence. Two teams answer the same requirement with different standards of proof.
• It is per application, by hand. Assessing one flagship application is feasible. Assessing every application in a portfolio is not, so the portfolio view never exists.
• It treats silence as a pass. If nobody found a problem, the row gets a tick. But nobody looking is not the same as nothing there.

Continuous assessment from evidence

A large part of ASVS can be answered by things a security program already measures. Static analysis findings, dependency vulnerabilities, secrets, endpoint authentication, SBOM coverage, CI/CD configuration and enforced pull-request checks all speak to specific requirements. Mapping those signals to requirements turns part of the standard into something that updates when the code does.

The mapping is the hard part, and it has to be conservative. Three rules matter most.

Evidence decides, where there is evidence

If a requirement asks for parameterized queries and static analysis shows SQL built from user input, the requirement is violated. A person cannot attest their way past that. Evidence outranks assertion.

Absence of evidence is not evidence

This is the rule most tools get wrong. A repository that has never been scanned has no findings. A manifest that was never resolved has no vulnerable dependencies. Read naively, both look clean, and an assessment built that way awards its best scores to the code nobody examined.

Coverage has to come first. A code root with no recent scan is uncovered, not verified. An endpoint whose authentication cannot be determined is neither protected nor exposed. Improving coverage will sometimes lower a score, because newly scanned code shows violations that were always there. That is the assessment becoming accurate.

Most of ASVS needs a person, and that is fine

Many requirements ask about things no scanner can observe. Is the session timeout appropriate for this application? Does the business logic enforce the right authorization on this workflow? An honest assessment marks those as manual rather than guessing, and a fresh assessment will have a large manual count. That is the standard working as designed.

Which evidence speaks to which chapter

It helps to see the mapping concretely. These pairings are where automated evidence carries the most weight.

• Encoding and sanitization, validation. Static analysis findings for injection, cross-site scripting and unsafe deserialization, traced from an entry point to a sink.
• Authentication and authorization. An endpoint inventory that shows which routes enforce authentication, and which are reachable from the internet without it.
• Cryptography and secure communication. Findings for weak algorithms, disabled certificate validation, cleartext transport and predictable randomness.
• Configuration. Secrets in the repository or CI, debug settings left on, and CI/CD configuration that trusts untrusted input.
• Secure coding and architecture. Known vulnerable and end-of-life components, an SBOM that covers every direct dependency, and remediation inside a defined deadline.

Session management, business logic and much of data protection sit mostly on the manual side. A scanner can find a session cookie without the Secure flag. It cannot tell you whether your timeout suits the application's risk.

Attestations, with an expiry

Manual requirements still need an answer for an auditor. The answer is an attestation: a person states that the requirement holds, records what was checked and where the evidence lives, and sets a date to review it again.

Good attestations follow a few rules:

• An attestation applies only where there is no automated signal. It never overrides evidence.
• An attestation is never counted as verified. It is shown as attested.
• Every attestation has a re-review date. After it passes, the requirement returns to manual until someone checks again.
• "Not applicable" needs a written justification, and it is a decision a reviewer can challenge.

Choosing a target level per application

Not every application needs Level 3, and holding a marketing site to Level 2 wastes effort. Tie the target level to how critical the application is. A reasonable default:

• The most critical applications, the ones that handle money, identity or regulated data, target Level 2 or higher.
• Internal tools and lower-tier services target Level 1.
• When an application's criticality changes, its target level changes with it.

Assess every application at every level anyway. It costs nothing extra once the mapping exists, and it shows how far an application is from the next level.

From measuring to enforcing

Some ASVS requirements are practices rather than properties: "use a secret scanner", "do not merge code with known injection flaws". A pull-request check that blocks the merge is the enforced version of that practice. An enabled check with a matching rule is good evidence for the repositories in its scope.

This closes a loop. The assessment tells you which requirements you can enforce, and enforcing them turns manual rows into verified ones.

What an auditor wants from you

When a customer security review or an auditor asks about ASVS, they want three things.

1. The requirement text, word for word, with the version.
2. A status per requirement that distinguishes verified from evidence, violated, manual, attested and not applicable.
3. The method: which requirements were checked from automated evidence, and which were stated by a person.

A report that blurs verified and attested will not survive a careful reviewer. One that separates them usually does.

How Heeler assesses against ASVS

Heeler assesses every application against OWASP ASVS 5.0.0 as part of Compliance and audit-readiness.

• Each requirement lands in one of six states: Verified, Violated, Partial, Manual, Attested or Not applicable.
• Evidence comes from signals Heeler already collects, including SAST findings, dependency vulnerabilities, secrets, endpoint authentication, SBOM coverage, scan cadence, SLOs, end-of-life components, OpenSSF Scorecard checks and enforced guardrails.
• Coverage is required before a clean result counts. Unscanned code is uncovered, not verified.
• The target level follows the application's tier by default, and can be set per application or for the organization.
• Administrators record attestations and not-applicable decisions with a statement, a reference URL and an optional re-review date.
• Guardrail bundles turn the enforceable parts of a level into PR Guardrails, without duplicating guardrails you already have.
• A standards report exports as PDF for a reader, with the methodology, or as CSV with one row per requirement.

Read more in the OWASP ASVS and Assessments documentation.

Getting started without a spreadsheet

1. Map repositories to applications first. An assessment is only as good as its scope.
2. Set target levels by criticality, not by ambition.
3. Fix coverage before reading scores. Unscanned code hides violations.
4. Work violated requirements by chapter, starting where the most applications fail.
5. Enforce what can be enforced at the pull request.
6. Attest the rest, with evidence links and a re-review date.

FAQ

What is OWASP ASVS?

OWASP ASVS is the Application Security Verification Standard, an open list of security requirements for web applications and APIs, organized into three cumulative assurance levels. Version 5.0.0 is the current release.

Which ASVS level should we target?

Level 1 is the baseline for every application. Level 2 fits most applications that handle sensitive data or transactions. Level 3 is for applications where a breach would be severe.

Can a tool fully automate an ASVS assessment?

No. Automated evidence can answer part of the standard. Many requirements ask about design and business logic that no scanner can observe, and those need a person's attestation.

Why did our score go down after we scanned more code?

Because newly scanned code can reveal violations that were always there. An assessment that counts unscanned code as clean overstates your position.

See your portfolio against ASVS

Heeler assesses every application against OWASP ASVS from the evidence it already collects, and tells you which requirements still need a person. Get a demo.