Guide 016 explanation

Why a valid code citation does not prove a vulnerability

Learn why an exact source-code citation is only one part of a vulnerability claim and what evidence connects a line to real harm.

A valid citation proves a narrower fact: the named source range exists at the stated revision and says what the report claims it says. It does not, by itself, prove that an attacker can reach the code, bypass the relevant controls, affect a protected asset, or encounter that code in production. The decision changes when those missing links are supported by independent evidence. An AppSec reviewer should treat the cited line as the start of an investigation, then record the actor, entry point, control path, effect and deployment assumptions before approving a finding. A source-traced path is still different from an executed exploit.

This distinction matters because a precise line number can make a weak claim feel settled. NIST's Secure Software Development Framework describes automated code analysis together with human review and triage of reported issues, rather than treating a tool warning as its own final verdict. The reviewer's job is to test the interpretation around the line.

A location, a path and an effect are three different claims

Suppose an alert says “cross-tenant document disclosure” and cites a handler that reads documentId from a request. The citation may be exact. The vulnerability conclusion still depends on separate questions:

Claim Evidence that would support it What the citation alone cannot settle
The operation exists Pinned repository, revision, path and source range Whether the code is called
The proposed actor can reach it Route mapping, caller and authentication context Whether another entry point has different checks
The actor controls the relevant input Data flow from request to lookup Whether the ID is replaced with a server-derived value
The required control is absent or ineffective Review of middleware, service and data access on this path Whether a deeper resource check blocks the request
A harmful effect follows Response or state-change path to a protected asset Whether the operation returns only the caller's own data
The path matters in the assessed deployment Artifact or deployment evidence for the pinned revision Whether a dormant helper is shipped or enabled

For an API that accepts an object ID, OWASP API1:2023 explains that access to the endpoint is distinct from permission to act on that particular object. OWASP's Authorization Cheat Sheet calls for permission checks on every request. These are review criteria; they do not decide whether a specific application satisfies them.

Sort an evidence packet by what it proves

Use this constructed exercise to separate authenticity from meaning. Harbor Notes has an alert alleging that an ordinary user can download another organization's document. No repository, request or review was executed for this example. The packet contains five artifacts:

Artifact Strongest justified statement What remains open
A: immutable source link at r42 showing documents.load(id) This revision calls the loader with the selected ID. Loader semantics, caller authority, returned object and deployment.
B: screenshot of a successful request to /documents/D7 The image depicts a success response. Whether it is authentic, which build/user/object produced it, and whether that user was unauthorized.
C: build record mapping digest H42 to r42 The record associates that artifact with the source revision, if its issuer and provenance are trustworthy. Whether H42 is deployed; how the code behaves.
D: source for the bound adapter requiring document ID and trusted organization in one query The shown adapter constrains both fields. Whether this handler actually uses this adapter in the assessed artifact.
E: route/provider map for H42 selecting adapter D This artifact binds the handler to that adapter. Other routes, other artifacts and unexamined runtime dependencies.

A valid citation and an authentic build record answer different questions. Neither becomes stronger by being repeated in three report sections. The useful combination is A + D + E: the call exists, its actual implementation enforces organization scope, and the selected artifact binds them. If the deployment record also identifies H42, the production-applicability question can be scoped to it.

An impressive screenshot can be irrelevant

Now supply the request's missing fixture record:

user: U-A, current organization A
requested document: D7, stored organization A
response: success

Even if screenshot B is authentic, it shows permitted access. It does not demonstrate a cross-organization read. Replacing the URL with a foreign ID in a written report does not change the request that produced the screenshot. Ask for the actual method, identity context, authoritative owner, environment and result, using synthetic data and authorized access if dynamic validation is needed.

Conversely, a screenshot of a denial does not prove the adapter is compulsory across every route. It may reflect a nonexistent document, wrong session or different build. It can challenge a particular hypothesis when those conditions are recorded; it cannot replace the source and binding evidence.

The final exercise decision is: citation A remains valid, but the alleged read through the H42 handler is defeated by the compulsory scoped adapter. Screenshot B contributes no evidence of unauthorized access. Preserve the rejection for that path and keep exports or other providers outside it. This is a conclusion about supplied artifacts, not a claim of an actual independent assessment.

Authenticate the artifact before using its conclusion

A hash identifies bytes when you have a trusted value to compare. It does not tell you who produced those bytes or whether their content is true. A timestamp printed inside a JSON file is a claim by the file's author. A signed record can help establish its issuer and integrity under a checked trust relationship; it still does not prove the issuer assessed the correct object or that the artifact is currently deployed.

For Harbor, imagine two files both titled “H42 route map.” One was exported from the selected build process; the other was copied from a developer's proposed configuration. Their text may be equally readable. Request their provenance and the link to the exact artifact before using either to settle E. If the binding cannot be established, keep applicability unresolved even though A and D are authentic source files.

A compact review note can say:

Accepted: A establishes the call; D establishes a scoped implementation. Pending: E's provenance must bind that implementation to H42. Excluded from proof: B lacks unauthorized-actor/object evidence. Next artifact: the provider map produced for H42 with its build record. Current result: implementation counterevidence is strong; deployment rejection is not yet justified.

When the trustworthy binding arrives, change that one unresolved premise and record the decision. Do not rewrite the citation or manufacture a runtime result. For checking whether references themselves resolve and match an AI report, use the exact-source citation audit; this exercise concerns the inference each artifact can support.

What a citation cannot tell you about coverage

A single cited range also says nothing about the rest of the repository. The tool may have indexed a file without reviewing its control flow, skipped a generated route, or assessed only one revision. A clean result in one route cannot be generalized to all object reads. The OWASP Web Security Testing Guide's reporting guidance calls for explicit scope and limitations, alongside technical details that help readers understand a finding. Carry that discipline into a source-based review note: name what was examined and what was not.

Audit the inference one sentence at a time

A reliable citation review can be done as a short argument audit. Underline the factual verbs in the report: reads, accepts, checks, returns, deploys and permits. For each verb, identify the artifact that supports it and the scope of that artifact. This exposes conclusions that borrow authority from an adjacent citation without actually following from it.

For Harbor Notes, compare these three sentences:

Sentence What must support it Appropriate correction if evidence is missing
The handler calls documents.load(id) Pinned handler source and call Keep the narrow source observation.
The call loads documents globally The actual bound loader implementation and applicable policy Mark loader semantics unresolved.
Any signed-in user can obtain another organization's document Actor access, object selection, absent effective denial, delivery and deployment applicability Break the statement into supported and unknown premises.

The first can be true while the other two are false. A report that repeats citation A after all three sentences does not gain three pieces of evidence. It repeats one location. The reviewer should request the missing loader and binding, not ask the author to add more references to the same handler.

A useful exercise is to remove the conclusion and reconstruct it from the artifacts alone. Read A, D and E in order. Can you identify which organization reaches the adapter, where it came from and what happens when it does not match the document? If the answer depends on a variable name such as trustedOrganization, inspect its origin. Names are useful navigation, but they do not establish authority.

Handle incomplete excerpts without inventing missing controls

Reports often contain short source excerpts because full files are sensitive or large. A short excerpt can support a local statement while leaving surrounding control flow unknown. If the visible lines omit the caller or return path, describe those gaps explicitly. Do not assume an omitted guard exists, and do not infer its absence from an excerpt chosen to highlight the sink.

The bounded request is simple: provide the caller, adapter binding and relevant denial/delivery branches at the same revision. It does not require publishing the entire repository. Authorized reviewers can inspect those artifacts through restricted access and retain a source-free summary of the result.

If two excerpts come from different revisions, reconcile them before joining their logic. A new safe adapter cannot defeat an old handler's production claim unless the selected artifact actually includes it. An old unsafe helper cannot support a current finding if the handler now uses a different enforced query. Source continuity is part of the argument, not administrative decoration.

Finally, explain why a citation correction matters. A wrong line number with the right immutable function may be a repairable reference problem. A citation to the wrong provider can change the conclusion. Keep those cases separate so a formatting defect does not become a false-positive verdict, and a substantive binding error does not get dismissed as formatting. The output of the audit is a stronger or narrower argument, with exactly the missing premises still visible.

Consider how the report will be quoted. An executive summary may retain “foreign-account download” while dropping the sentence that says the deployed adapter is unknown. Put that limitation next to the conclusion itself: “Possible foreign-account download; deployment binding remains unverified.” Detailed citations can support the statement, but they cannot repair a headline that claims more than the evidence does.

When the missing adapter arrives, revise the conclusion and preserve the earlier version. If it enforces the trusted account predicate, record the precise reason the candidate fails. If it is the unrestricted provider, continue the path review rather than assuming the harmful effect from provider identity alone. This makes the citation audit an aid to deciding the claim, instead of a formatting exercise whose completion is mistaken for verification.

For the next disputed alert, ask the analyst to produce the six-row evidence table above and one counterevidence attempt before presenting the claim as confirmed. Then put the outcome through a repeatable false-positive review process. If the path is supported, use the finding triage guide to prepare the developer handoff.