How to use OWASP ASVS 5 without treating it as a scanner score

Use OWASP ASVS 5 as a list of security requirements to investigate, not as a percentage a scanner can award. First pin the standard's version and the application boundary. Then decide which requirements apply to which components and what evidence each needs. Record applicability, review progress and the control conclusion as separate facts. A code scanner can provide useful leads or source evidence, but a rule mapped to an ASVS ID does not show that the control works throughout a deployed application. The method changes when the scope changes: a new API, hosting configuration or identity provider can add obligations or invalidate an earlier conclusion.

This gives an AppSec lead something better than an unexplained “82% compliant” badge: a list of decisions with owners, evidence, gaps and dates. OWASP describes ASVS as security requirements for building and verifying web applications and services. This guide pins 5.0.0; OWASP recommends versioned references such as v5.0.0-8.2.2 because identifiers can change between versions. Record the version in every worksheet and customer report.

Decide what the assessment is meant to answer

An ASVS assessment is most useful when it answers a bounded question: “For this invoice API at this revision and deployment, which selected security requirements have evidence, which appear to fail, and which still need work?” A scanner's alert count answers a different question. Zero alerts may mean the tool did not detect a pattern in the material it processed. It says little about an identity provider setting, a missing service, an untested route or a business authorization rule.

Write the scope before mapping controls:

• Application and assets: the API, browser app, worker, identity provider, tenant data and relevant integrations.
• Revisions and environments: immutable code revision, deployed build, environment and date. A repository branch name is not enough to identify the reviewed code.
• Selected requirement set: ASVS v5.0.0, selected levels and any documented additions. Preserve excluded levels as excluded; do not count them as passed.
• Assessment methods: source review, configuration inspection, authorized runtime testing, architecture interview and document review, as actually performed.
• Known boundaries: unreceived repositories, inaccessible provider settings, unsupported file formats, skipped paths and time or budget limits.

The versioned OWASP ASVS catalog gives the actual requirement text and levels. Keep that text available to reviewers. An ID alone is a poor test instruction.

Put four dimensions on the same five rows

Use a small synthetic ledger whose rows can all be inspected. Harbor's assessment has three ASVS-linked questions plus two local review questions. The local questions illustrate the accounting model; they are not invented ASVS requirement IDs or substitutes for selecting the exact catalog text.

The table separates four decisions. Applicability asks whether the rule belongs here. Progress says which work finished. Conclusion says what that evidence supports. Finding state governs a particular suspected defect. These are local reporting fields, not official ASVS status vocabulary.

The third row is particularly useful: completed review can produce an apparently unmet control. It should increase the work-completed count without increasing an assurance-success count. The second row shows the reverse trap: completing a source trace does not settle the worker's deployed behavior. The final row is a justified applicability decision, not a hidden pass or a way to remove an inaccessible service.

The versioned ASVS configuration chapter supplies the actual secrets requirement; the artifact and credential in this example are fictional. Its exact conditions still govern a real assessment. Do not reduce the whole requirement to a search for one string.

Shared code does not multiply evidence automatically

Harbor's shared authorization helper is reviewed once. The API invokes it with a trusted account and stored invoice relationship. The worker imports the same package but calls a lower-level repository operation that bypasses it. The shared implementation evidence can be reused; the API caller evidence cannot be reused for the worker by association.

A meaningful next step is therefore to inspect the worker's mandatory call chain and obtain its deployment identity. Reviewing the helper again would add little decision value. Similarly, obtaining the collector's event-routing evidence changes the logging conclusion more than searching another hundred source files for logger calls.

This is how ASVS becomes a work plan: the requirement defines the security outcome, and the ledger identifies the evidence that can change a particular conclusion. It never turns “five rows touched” into “100% secure.”

Choose the evidence that fits the requirement

ASVS requirements are verification questions, not all scanner patterns. Some are answerable mostly from code; others require runtime settings, architecture, operational records or a controlled test. OWASP's secure code review guidance puts review in the context of architecture, authorization and business logic, rather than treating automation as the entire assessment.

For the invoice example, trace from the caller to the effect. Map the user or service identity, the entry point, the invoice identifier, each authorization decision, the query, and the returned data. If the handler calls a common authorizeInvoiceRead service, inspect the service and all applicable callers. A JavaScript button hidden from the user does not prove server authorization. ASVS v5.0.0-8.3.1 specifically addresses enforcing authorization at a trusted service layer; v5.0.0-8.2.2 addresses data-specific access. Keep each requirement's conclusion separate even if one control contributes evidence to both (ASVS 5.0.0).

Now ask where the source stops. The repository may show an API gateway configuration file, but that file may differ from the deployed gateway. The code may call a hosted identity provider, but the real tenant claim mapping may live in provider settings. The worker may have a privileged service identity whose permissions are set outside the repository. Each unobserved boundary becomes an evidence request or an explicit unknown, rather than a favorable assumption.

Expand the unresolved worker row into a handoff

Keep the five-row ledger compact, but attach enough detail for its owner to act. Harbor's worker row expands as follows:

The API's supported outcome stays on its own row. The missing worker evidence does not retroactively make the reviewed API path unexamined, and the API result does not clear the worker. Store restricted evidence links and exact source identities behind the row; the customer summary can state its conclusion and gap without publishing source.

Handle level selection without laundering omissions

ASVS has levels that organize verification rigor. Choose a target level based on the application's risk, contractual commitments and available assessment method, and record who approved the choice. Read the versioned standard for the exact requirement level: levels and requirement numbers can change between releases. Do not copy a level choice from a different product simply because both are SaaS.

An unselected requirement remains outside the declared assessment target. An applicable requirement in the target that could not be assessed remains unknown or blocked. A requirement that genuinely does not apply gets a reason and evidence. These three cases should appear as separate lines in a summary. If a customer contract asks for a broader level than the team can examine this month, report the partial scope and the plan to close it; do not translate the limited run into the contract's full claim.

Turn tool output into review work

A scanner can help find where to look, especially across a large codebase. Start with the exact input revision and inventory. Record discovered paths, acquired content, indexed material, material actually sent to a model if relevant, and files or ranges a reviewer actually examined. Those sets are not interchangeable. A search hit in authorizeInvoiceRead does not show that the PDF worker or another endpoint was reviewed. A clean run cannot convert unvisited code into a positive control conclusion.

For each alert, ask the reviewer to name the actor, input, entry, control and effect, then seek counterevidence. Which permissions does the caller already have? Does a downstream repository query enforce tenant ID? Is a feature flag off only in staging or also in production? Has another code path escaped the same guard? Mark unresolved context. If independent review finds no credible path, reject the candidate and retain the reasoning. If the path is supported, route it through the team's verification and approval process; do not call an unverified model or rule output a confirmed vulnerability.

Choose the next evidence by the decision it can change

Harbor has three immediate actions. The credential owner promptly checks and restricts potentially exposed authority while the reviewer verifies the artifact and its scope. Containment need not wait for completion of the ASVS finding workflow. The worker owner supplies the matching deployment and caller path because the central customer-data question remains unresolved. Operations supplies one source-free failed-access event trace because source review cannot show arrival at the responder.

Those priorities come from potential consequence and missing evidence, not from maximizing a completion percentage. A reviewed failure may demand more action than ten unstarted low-consequence rows. A blocked provider setting may be the only fact separating a useful narrow conclusion from an unsupported product-wide claim.

Reuse evidence at the level it was established

Harbor can save work by maintaining a shared-control record, but that record needs a precise subject. The authorization helper's implementation, its expected trusted inputs and the reviewed version form reusable evidence. Each consuming API or worker still needs its own binding: which version it uses, how it obtains the account and object context, and whether another path bypasses the helper.

When the helper changes, the ledger identifies dependent obligations that may need reassessment. When only one caller changes, review that caller and its contract before reopening unrelated services. This makes a standards-based program sustainable without turning reuse into an automatic pass. The work plan follows changed security assumptions, while the historical record preserves what earlier evidence actually established.

The same approach works for a deployment policy or provider configuration shared by several components. Reuse the policy observation where its scope applies, then keep component-specific assumptions and missing evidence visible.

For external reporting, preserve the same dimensions but summarize them around the customer's action. The full ledger is the internal source of truth; the partial report guide shows how to communicate its limits. Selecting a target level remains a planning decision until the applicable obligations have adequate outcomes.

For the next step, use the requirement-to-evidence mapping guide. When the boundary remains incomplete, use the partial assessment report template.