Mark the source review complete only for what it actually examined, and mark the control conclusion inconclusive when decisive evidence lives elsewhere. A repository can show a call to a secrets service, a checked-in gateway policy or an authorization helper. It cannot, by itself, prove which secret store is active, which gateway rules are deployed, or whether every path uses the helper. Name the missing evidence, its owner and the next method of verification. “Not seen in source” is not “not applicable,” and “no alert” is not “passed.” The decision changes when reliable deployment, runtime or organizational evidence arrives for the same dated scope.
OWASP ASVS 5.0.0 is a set of requirements to verify application controls. Its IDs should include the version, as OWASP recommends. A source-only review can contribute evidence to several requirements, but ASVS does not turn the existence of a code pattern into an application-wide assurance claim.
Use separate labels for work done and conclusion reached
For each requirement and component, keep these four fields separate:
| Field | Allowed working labels | Question it answers |
|---|---|---|
| Applicability | Applicable; not applicable with reason; unknown | Is this requirement relevant to this component and selected scope? |
| Review method | Source review; configuration review; controlled runtime check; another stated method | What evidence and procedure were selected? |
| Progress for that method | Not started; partial; blocked; complete within declared scope | What work was actually performed? |
| Control conclusion | Supported within stated scope; appears unmet; inconclusive; not assessed | What can the evidence justify today? |
The phrases are a suggested reporting taxonomy, not official ASVS status values. Keep the method field separate from progress: for example, method=source review, progress=complete, conclusion=inconclusive for deployment. That avoids using “source reviewed” and “blocked” as competing labels when only the configuration work is blocked. Local assurance programs may use different fields. The important rule is that “source reviewed” can coexist with “inconclusive.” If the reviewer has no access to the deployment setting on which the decision depends, state that directly. If evidence points to a failure, describe the observed failure or candidate finding and still name the unverified assumptions. Reserve “not applicable” for a reasoned scope decision, such as a requirement about a feature the architecture confirms does not exist in the assessed product.
Repair four disputed rows in an assessment register
These synthetic incoming records use local labels. None of the status words below is presented as official ASVS terminology. The assessor's task is to repair the evidence claim without rewriting what work occurred.
| Incoming row | Why the label is wrong or defensible | Corrected record | Exact next request |
|---|---|---|---|
| Provider secret-store access: “N/A; setting unavailable” | Lack of access does not remove a relevant backend-secret obligation | Applicable; configuration review blocked; conclusion inconclusive | Redacted current access policy and deployment binding from platform owner |
| Invoice worker: “Pass; helper found in source” | Existence of helper does not establish caller use or deployed behavior | Applicable; limited source work complete; conclusion inconclusive | Mandatory caller trace and current worker artifact map |
| Selected Level 2 plan excludes a Level 3 contextual control: “Tool unsupported” | Scope choice and tool capability are different reasons | Outside chosen target; no assessment conclusion | Ask decision owner whether actual business risk requires adding it |
| Browser cookie question for a confirmed headless service: “N/A” | Architecture and interface inventory establish no browser-session cookie in this service boundary | Not applicable with evidence and re-entry trigger | Revisit if a browser session or embedded web interface is introduced |
The last row is a local control question used to illustrate applicability, not a claimed catalog-wide exemption. A real ASVS row must use the exact versioned requirement and assess its conditions. The ASVS catalog remains the governing criterion.
Resolve the disagreement instead of changing the color
The product owner objects that “blocked” makes the secret-store row sound like a vulnerability. The assessor keeps two fields: work is blocked by unavailable configuration; control effectiveness is unknown. No finding is asserted solely from that access limit. Calling it N/A would instead tell the reader that the control is irrelevant, which the architecture contradicts.
The worker developer says the helper is shared by all services. The assessor asks for the worker's mandatory invocation and trusted context, not another screenshot of the helper definition. If those arrive, they can change the source conclusion; deployment remains its own binding. This is an evidence request with a stopping rule, not a vague demand for “more validation.”
The Level 3 row needs a management decision. A target-level exclusion can be transparent and legitimate. If the control addresses a material intermediary-service risk, choosing a lower level does not make that risk disappear. Record the added obligation or the explicit scope decision separately from whether a scanner supports it.
Apply one returned artifact without erasing history
On 21 October in the synthetic register, platform supplies a current policy export and deployment binding for the secrets service. Its source-free summary identifies which service role can retrieve the named secret and which unrelated role is denied. The assessor accepts it for the access-scope question. The row changes from blocked/inconclusive to reviewed/supported for that declared access-policy scope.
It does not automatically settle whether secrets were included in every build artifact, whether all secrets use the service, or whether the rotation process works. If the original row represented the entire v5.0.0-13.3.1 obligation, keep that larger conclusion inconclusive until its other evidence is present. Splitting an overly broad row is preferable to awarding a pass from one narrow export.
The change log records: old labels, correction reason, returned artifact subject, accepted proposition, remaining work and reviewer/date. The customer summary becomes “One previously blocked secret-access question now has current configuration support; worker deployment and the broader secret-management obligation remain unresolved.” That is both more informative and less alarming than one unexplained amber badge.
Split a broad control before assigning its final label
A single “secret management” row often contains several propositions: the application obtains secrets through the intended service, the running role has appropriate read authority, source and build artifacts omit literal credentials, and operational rotation reaches the relevant consumers. Those propositions may need different methods and owners. If one row cannot express which part is supported and which part remains unknown, split it into evidence questions beneath the versioned requirement. Keep the parent requirement visible so the split does not make unfinished work disappear.
For the synthetic register, a more useful structure is:
| Evidence question | Work state | Current conclusion | Owner of remaining evidence |
|---|---|---|---|
| Does the reviewed component call the intended secret accessor? | Source trace complete | Supported for the named caller | Application owner for any new caller |
| Which deployed role can read the secret? | Current configuration reviewed | Supported for the supplied policy scope | Platform owner for changes |
| Do all relevant build outputs avoid embedded credentials? | Artifact population incomplete | Inconclusive | Release owner supplies artifact scope |
| Do replacement credentials reach each consumer? | Operational method not performed | Not assessed | Credential/service owner |
The table does not define the full content of an ASVS requirement. It shows how an assessor can expose the actual evidence questions rather than attach a green badge to a broad heading. The governing versioned requirement still determines which evidence is necessary and how the final conclusion is made.
A parent conclusion should not be calculated by majority vote. Three supported questions do not outweigh a failed question that is necessary to the required outcome. Nor does one unavailable low-relevance artifact automatically negate an independently established narrow source conclusion. Write the relationship in plain language: “Access-policy scope supported; overall secret-management conclusion remains inconclusive because the supplied artifact population is incomplete.”
Decide what to do while a label remains inconclusive
“Inconclusive” is an evidence state, not an instruction to stop work. The AppSec lead should ask what decision is waiting on the missing fact. If a potentially active credential appears in a supplied artifact, its owner can restrict the authority while the artifact mapping is resolved. If a customer merely asks for broad assurance and the evidence is unavailable, narrow the claim and name the follow-up. These are different responses to uncertainty.
For the invoice worker, an incomplete deployment map may justify requesting a bounded current configuration export. It does not establish an exploitable authorization failure. At the same time, a source-supported repair can proceed when its behavior and compatibility are understood. Keep the repair decision separate from the claim that the original path was confirmed in production. This allows useful risk reduction without forcing the reviewer to choose a stronger label than the evidence supports.
Set the next checkpoint according to the decision's urgency and the owner who can supply the fact. A blocked row with a named policy export and service owner is actionable. A row marked “needs validation” with no requested artifact is just a renamed backlog item. If the owner cannot provide the evidence, record that limitation and escalate the scope or assurance decision to the person accountable for it.
Keep terminology stable across teams
The development team may use “done” to mean its source analysis finished. Procurement may interpret the same word as the control working in production. Write a small glossary beside the register and show an example of the mixed state: source method complete, configuration method blocked, deployed-control conclusion inconclusive. Avoid changing the terms to make a dashboard look more reassuring.
When exporting the register, retain the method and scope fields. A spreadsheet that keeps only the final color loses the reason the conclusion was bounded. The customer-facing summary can be shorter, but it should preserve the material distinction: the relevant source was reviewed, and a named deployed setting remains unverified. It does not need every internal task state to be accurate.
Review stale rows by their assumptions rather than their age alone. A policy export from last week may still describe the current configuration if its binding is established. A new export from the wrong environment does not answer the question. Likewise, a source review tied to the previous worker version may remain useful background while being insufficient for the new deployment. Ask which subject the evidence actually describes before choosing its label.
Finally, preserve who made the conclusion and by which method. An automated rule, a model-generated analysis and a person's review can all contribute evidence, but they are not interchangeable activities. A stored response is evidence that an analysis ran; it is not automatically a completed control assessment or independent verification. The register should let the reader see that difference without requiring private source access.
After the artifact arrives, inspect its date and relationship to the deployed build, update the requirement row, and leave the earlier source-only conclusion traceable. If it never arrives, report the control as inconclusive in the final scope statement. Continue with the evidence mapping walkthrough, then use the partial assessment report template for the customer handoff.