A pentest vendor should show the exact request, sanitized payload and causal application path needed to reproduce a finding, but the precision of the code-path claim depends on access. Runtime-only testing can prove reachable behaviour and impact; logs, traces and source assistance can identify the route, service and control that failed. The report must label observed facts, strong inferences and confirmed code evidence separately.
Define the architecture question before testing
Developers need enough detail to recreate the result without receiving live tokens, customer data or an unbounded exploit kit. Ask the vendor to preserve causal fields, identity relationships and state while sanitizing secrets and minimizing sensitive data.
Write the expected security invariant and the prohibited outcome in language that engineering, security and operations interpret the same way. Name the identity, trust transition, protected asset and authoritative state. That statement becomes the basis for scope, evidence and retesting.
Build the minimum evidence pack
- A current component and trust-boundary diagram for the environment under test.
- Identity, credential, network and data-flow details relevant to the decision.
- Representative accounts, workloads and synthetic records with known ownership.
- Logs or traces that follow the action through every material control point.
- Explicit safety limits, stop conditions, owners and restoration steps.
Collect tested endpoint and build, full ordered requests, headers with redaction, body and variables, response and timestamps, actor and object relationships, correlation IDs, gateway and service traces, authoritative state, source snapshot where authorized, handler and policy references, repeatability and cleanup.
Capture the request as executed
Copying a scanner template or reconstructed curl command can omit encoding, ordering, cookies or transport details that mattered.
- Export the exact method, URL and query.
- Preserve relevant headers and content type.
- Include raw or structured body safely.
- Record redirect and retry behaviour.
- Redact credentials without changing causal fields.
Provide a controlled request collection or code snippet that uses placeholders and synthetic identifiers. State if a proxy transformed the request.
Capture setup and application state
The payload may work only after a role change, object creation, workflow state or race setup.
- List account, role and tenant relationships.
- Record object ownership and state.
- Include prior workflow actions.
- Name flags and environment assumptions.
- Explain reset and repeatability.
The setup is part of the proof. A request without its state preconditions is not reproducible evidence.
Show the response and authoritative effect
The HTTP response can mislead when work commits asynchronously or error handling masks success.
- Record status, relevant headers and sanitized body.
- Compare expected and actual policy result.
- Inspect data or object state.
- Follow jobs, files and integrations.
- Capture a correlation timeline.
Make clear whether impact was directly observed or inferred from response behaviour.
Trace the route through deployed components
Gateway rewrites, service meshes and version routers can make the source handler different from the public route.
- Correlate edge and gateway IDs.
- Identify normalized route and upstream.
- Follow service and database spans.
- Record policy decision and error source.
- Check retries and asynchronous consumers.
If tracing is unavailable, label the likely component as inference. Do not accuse a code owner from naming alone.
Use source evidence proportionately
With authorized source access, the tester can identify control flow, missing policy calls and related consumers, but suspicious code still needs deployed proof.
- Tie source snapshot to deployed artifact.
- Name function, module and policy helper.
- Explain tainted input or missing decision.
- Search for sibling pattern instances.
- Avoid unnecessary code excerpts.
Quote only the minimum proprietary code required. Mark unreachable or unverified instances as review observations, not exploitable findings.
Protect secrets and exploit material
Developer usability does not justify placing tokens, personal data or powerful payloads in broad tickets.
- Replace secrets with clear placeholders.
- Use synthetic records in examples.
- Store sensitive attachments with least access.
- Separate executive summary from technical proof.
- Set retention and deletion rules.
Confirm the sanitized proof still runs when valid test credentials are inserted through secure means.
Connect code path to closure
The evidence should guide a durable fix and provide a retest oracle without dictating one risky patch.
- State failed invariant and owning layer.
- Identify likely related consumers.
- Define original and pattern-level retest.
- Require positive workflow regression.
- Link fixed artifact to retest result.
Closure connects request, source or configuration change, deployed build and observed outcome. A merged pull request alone is not sufficient.
Execute as controlled hypotheses
- Establish the legitimate baseline and capture authoritative state.
- Change one trust variable—identity, route, scope, object, time or environment.
- Observe the decision at each layer rather than relying only on the response.
- Stop at the minimum proof that demonstrates or rejects the hypothesis.
- Restore test state and record residual uncertainty or blocked coverage.
Capture evidence during validation while state and traces are available. Use dedicated test identities and synthetic data. Invite engineering clarification without letting intended behaviour override observed unauthorized impact.
Report the architectural consequence
Provide a layered evidence appendix: request and state, authoritative effect, trace, and code confirmation where available. Use confidence labels consistently and keep sensitive artifacts controlled.
Separate observed evidence from inference. State prerequisites, repeatability, blast radius and the shared component responsible for the decision. When multiple findings have one architectural cause, keep the individual proofs but group the remediation around the common control.
Required closure evidence
- The original proof no longer succeeds.
- A legitimate workflow still succeeds under the intended identity and route.
- Alternate consumers of the same pattern enforce the same invariant.
- Telemetry records both allowed and denied decisions with useful context.
- The architecture record and threat assumptions reflect the new control.
Remediate at the durable control point
Fix the policy or data boundary identified by the complete path, inspect sibling consumers and add regression using the sanitized proof. Preserve trace and audit context for future diagnosis.
Retest the invariant, not just the payload
Replay the exact request sequence against the fixed build, inspect final state and sample a related path. Confirm legitimate behaviour and record deployed artifact evidence.
Use the NIST Technical Guide to Information Security Testing and Assessment for assessment planning and evidence discipline, and the OWASP Web Security Testing Guide for relevant application techniques. Adapt both to the system-specific trust decision described here.
The architecture decision
Developers can reasonably expect exact runtime proof and causal context. They should expect an exact code path only when traces or source access support it—and the vendor should say which evidence level each claim represents.
Ask WIMD for evidence from request to root cause with secure artifacts, explicit confidence and deployment-level retesting.