State exactly what the code supports, then name the runtime fact that would change the verdict. A useful source-only report says who may control the input, which path appears to carry it, what control is missing or uncertain, the potential effect, the selected revision, and the deployment or behavior still to check. It should assign an owner and a safe validation method. If the available source already justifies a bounded repair or reversible containment, start that work while gathering runtime evidence; the missing observation limits the claim, not every response action. Do not call an unobserved exploit “confirmed,” and do not dismiss a credible path merely because a dynamic test has not yet been performed.
The answer changes when source evidence itself resolves the path or when independent deployment evidence proves a relevant control. Static review can be enough to reject a claim if a server-side check demonstrably blocks it on every applicable path. It can also support a strong defect finding where the code and active configuration are both known. But if the selected deployment, middleware, identity mapping or client behavior is unknown, keep the effect conditional. NIST SP 800-115 distinguishes security examinations and testing techniques and emphasizes their benefits and limits; a source examination is not an executed penetration test.
Commission the missing observation, not an open-ended attack
All names, records, revisions and returned results below are synthetic. No request was performed. Cedar Ledger's handler at CL-38 accepts a report ID, loads the report and returns its summary. It checks login but has no visible account-ownership predicate. A gateway or data adapter might supply that control; the reviewer has neither selected deployment configuration nor runtime access.
The source claim is: “A signed-in Cedar member may receive a Harbor report summary if no upstream or data-layer rule binds this lookup to Cedar.” The missing fact is object-level enforcement on the exact deployed route. “Run a pentest” is unnecessarily broad for this decision. Request the smallest evidence that can settle it, starting with selected gateway and adapter artifacts.
A concrete validation request could read:
| Field | Filled request |
|---|---|
| Evidence question | Does report lookup/output enforce the authenticated account on this route? |
| Source scope | CL-38, GET /reports/{id}, handler and adapter citations attached |
| Environment | Authorized isolated staging deployment S12; service artifact and gateway policy must be recorded before use |
| Fixtures | Cedar member Mira, Cedar report C17; Harbor member Jo, Harbor report H21; harmless unique marker in each summary |
| Expected positive control | Mira can receive C17's marker; Jo can receive H21's marker |
| Expected negative control | Mira requesting H21 receives no Harbor content, title or metadata |
| Additional evidence | Selected route mapping, authoritative account context, adapter query and decision trace with secrets omitted |
| Stop condition | Wrong build/account, real customer data, unexpected side effect or unavailable scope boundary |
| Return format | Artifact IDs, fixture ownership, request correlation IDs, response shape/content decision and enforcement location |
This is a bounded handoff example, not authorization to test an environment. The organization supplies the actual owner, approved scope and credentials. Do not include live tokens or private report text in the request packet. The NIST testing guide supports defining assessment scope and limits; this table is an application-specific example.
Reject an invalid packet before interpreting its denial
The first synthetic return says:
environment S12; service CL-37; gateway GW-12
Mira → C17: 401
Mira → H21: 401
This does not show an object-ownership control. The positive control failed, and the service does not match the cited revision. Return the packet as inconclusive with two concrete corrections: establish the intended authenticated fixture and identify the relationship between CL-37 and CL-38. Repeating the same denied request would add little information.
The owner corrects fixture authentication and supplies S13 running CL-38. The new packet includes:
Mira → C17: 200, Cedar marker only
Jo → H21: 200, Harbor marker only
Mira → H21: 404, generic body; no Harbor marker/title
gateway GW-13 trace: account Cedar bound to request
adapter trace: lookup constrained by account Cedar + report H21
This is meaningful counterevidence for the selected route. The positive controls establish that both fixtures exist and the feature works. The adapter evidence explains the denial rather than inferring it solely from a 404. Inspect the generic body as well: a forbidden response containing Harbor's title would still disclose data.
The source-only handler omission is now explained by a mandatory scoped adapter. Reject the original cross-account-read claim for this route at the supplied configuration, and preserve that control evidence. Do not extrapolate to exports, batch endpoints or another adapter caller.
Handle the other two possible returns
A different valid packet could show Mira receiving H21's harmless marker, with CL-38 and fixture ownership established. That supports a controlled cross-account-read observation in S13. The report should name the exact summary fields received and the actor prerequisites. It should not turn two synthetic accounts into “all customers exposed” or infer historical access. Production applicability requires mapping the relevant service, gateway and data configuration to the selected production release.
A third packet might show a mandatory gateway rule denying foreign objects while the data adapter remains unscoped. That can defeat the current route's deployed path if all entrances are covered, but it leaves a narrower architectural weakness or alternate-path question. Record where enforcement occurs. A disabled route is another legitimate applicability result: it does not mean the underlying code was repaired.
| Returned evidence | Updated status | Next work |
|---|---|---|
| Wrong build or failed positive control | Inconclusive | Correct packet; preserve original source concern |
| Matched path with enforced scoped lookup and no foreign output | Rejected for reviewed route/configuration | Preserve counterevidence; do not broaden scope |
| Matched path returns foreign synthetic content | Controlled observation supports defect | Contain or repair as warranted; review bounded impact and deployment mapping |
| Route absent from selected deployment | Not applicable to that deployment | Track code/other deployments separately if relevant |
Close the handoff with a decision the developer can use
For the actual synthetic return above, the reviewer writes:
CL-38 / S13 / GW-13: source concern resolved by the mandatory account-scoped adapter. The first packet was invalid because authentication and build did not match. The corrected packet included working own-account controls and a foreign-account denial with no protected metadata. Original route claim rejected. Export adapter and production rollout mapping were outside this request and remain unassessed.
The record links the returned artifacts and dates without rewriting the earlier uncertainty as if it had never existed. OWASP's reporting guidance emphasizes scope, evidence and limitations; the useful product of this handoff is the changed decision and its bounded basis.
Choose whether runtime evidence is actually the next dependency
The phrase “needs runtime proof” can become an unhelpful instruction to reproduce every allegation. Start by asking what fact remains unresolved. If the missing adapter source establishes a mandatory account predicate and every relevant caller, obtaining that source may settle the exact claim without a request. If the question is which build is deployed, a reliable artifact-to-source mapping may be the decisive evidence. If the question is whether a gateway preserves or overrides context, a controlled observation may be appropriate.
For Cedar Ledger, the first handoff asks for selected gateway and adapter artifacts because those could answer the account-binding question directly. The bounded staging comparison then adds evidence about the actual route under a named configuration. This ordering avoids spending effort on an observation that cannot distinguish the competing explanations.
A useful dependency note has four parts: the missing fact, the possible values of that fact, the decision each would change, and the owner able to establish it. For example, “If the adapter always scopes by the verified account, reject this route claim; if it performs a global lookup, continue through response delivery and repair the missing decision.” That is more actionable than “security needs more evidence.”
Separate the repair decision from the claim's evidence level
An owner may choose a low-risk account-scoping repair before runtime evidence arrives. The ticket should explain why the change is justified and preserve the original uncertainty. It should not claim that the repair itself proves an unauthorized read previously occurred. After the patch, the team still needs to establish what changed and whether the relevant deployment uses it.
A precautionary feature restriction follows the same discipline. Record the suspected consequence, the authorized operational choice, and the evidence that would permit reversal. If the later adapter packet rejects the original path, revise the incident or release discussion accordingly. A temporary action should not fossilize into a permanent “confirmed breach” label.
If the owner chooses to wait for a specific artifact, name a checkpoint and the person responsible. The waiting state should reflect a concrete dependency, not an indefinite demand for an exploit demonstration. A complete source-supported defect deserves a repair path even when an active test would be impractical or unnecessary.
Make the returned packet reproducible without exposing fixtures
The reviewer needs enough information to understand the controlled observation: the actor's intended role, the resource ownership, the environment and build, the operation, and the relevant response or state change. They do not need live credentials or full report contents in a general ticket. Synthetic marker identifiers and restricted artifact references can preserve the reasoning with less sensitive material.
Keep the positive and negative cases adjacent. A foreign request denied while the own-account request fails authentication is an invalid authorization comparison. A foreign request denied after content was already placed in a generated artifact is incomplete protection. Ask the operator to identify the enforcement point and any side effect relevant to the original claim, rather than returning only an HTTP status.
A packet can also contain contradictory evidence. Suppose the response is generic but the adapter trace shows a global read followed by a correct output check. That may defeat the claimed disclosure while raising a separate concern about unnecessary data access or another caller. The reviewer should state the conclusion supported by the actual path, not force the evidence into the initial hypothesis.
Keep a changed environment from rewriting the old assessment
S13's result belongs to CL-38 and GW-13. If a later deployment changes the gateway, record a new applicability decision. If the code defect is fixed in CL-39, attach new acceptance evidence to that revision. Preserve the old packet so the team can distinguish a rejected allegation, a repaired defect, and a deployment that never contained the affected path.
This is particularly important when several services have independent revisions. They need a documented deployed relationship, not identical commit strings. The handoff should identify which service and policy versions formed the observed route. Without that relationship, a successful staging result cannot establish the production conclusion the team is trying to make.
If the returned evidence instead supports the defect, the developer gets an equally precise repair target and a later reassessment request using the same fixtures at the fixed revision. Evidence status, potential impact and practical difficulty remain separate fields. The general distinction between source and runtime evidence explains why the methods differ; this article provides the complete request, rejection, return and decision loop.