A developer-ready penetration-test finding should let an engineer reproduce the vulnerability without guessing: affected build and environment, exact preconditions, actor and tenant relationship, request or action sequence, sanitized payload, relevant response, authoritative final state, business impact, root-cause hypothesis and safe retest criteria. It should be concise enough to execute and complete enough to survive handoff.
Define the architecture question before testing
The report must answer what the tester did, why it should have been denied, what actually changed and how the developer can prove the fix. A screenshot or CVSS score cannot replace identity, state and sequence.
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.
Require stable finding ID, title and severity rationale; target build and environment; role, tenant and object relationships; prerequisites and cleanup; exact requests or UI steps; sanitized artifacts; timestamps and correlation IDs; authoritative effect; scope; root-cause cues; remediation options and retest success criteria.
Anchor the finding to the tested state
Developers cannot reproduce evidence against an unknown build, flag set or route version.
- Record URL, method and API version.
- Name build, commit or artifact when available.
- List security-relevant flags and environment.
- State staging-production differences.
- Identify gateway, mobile or direct path.
If exact artifact identity is unavailable, disclose the uncertainty. Do not imply the finding applies to every environment without evidence.
Describe identities and object relationships
Authorization findings depend on who acted and who owned the target. “User” is rarely precise enough.
- Name source role and tenant.
- Name target owner and tenant.
- State sharing, invitation or delegation.
- Record privilege and session changes.
- Use synthetic identifiers and redact secrets.
A compact relationship table often explains more than pages of raw HTTP. Include the expected allow or deny decision.
Provide ordered, minimal reproduction
Give the shortest reliable sequence from clean state to prohibited outcome, including setup steps that affect business state.
- Number requests or UI actions.
- Separate baseline from exploit.
- Include required headers without live tokens.
- Show variables and modified fields.
- State repeatability and reset.
Remove accidental noise but preserve every causal precondition. If a race is involved, include timing and concurrency.
Show authoritative impact
A response difference may be suspicious but developers need to know whether protected data or state actually changed.
- Compare before and after data.
- Inspect file, export or storage effects.
- Follow queue and worker completion.
- Record notification or integration effect.
- Separate observed impact from inference.
Use canary records and sanitized excerpts. Do not include customer secrets or unnecessary personal data.
Explain the failed invariant and likely owner
Root-cause context helps developers avoid a narrow response-code patch.
- State the security rule in plain language.
- Identify missing or inconsistent policy layer.
- Name sibling routes or consumers.
- Distinguish application, gateway and platform responsibility.
- Offer options and trade-offs, not unsupported code mandates.
Label root cause as confirmed or hypothesized. Source-assisted evidence can increase confidence but runtime proof remains central.
Define fix verification before implementation
Developers and testers should agree what success means: prohibited effect blocked, legitimate workflow preserved and related pattern sampled.
- Repeat original proof.
- Test positive owner or admin case.
- Test peer and foreign tenant variants.
- Inspect authoritative state.
- Sample shared helper consumers.
A new 403 is one signal, not closure. Tie the oracle to the invariant and final effect.
Keep evidence usable and controlled
Rich evidence can contain credentials, customer data or reusable exploit detail. Developers need access without uncontrolled distribution.
- Redact bearer tokens and secrets.
- Use controlled evidence storage.
- Limit ticket-system copies.
- Provide sanitized request collections.
- Define retention and deletion.
The report should remain reproducible after redaction through synthetic fixtures, stable IDs and correlation references.
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.
Validate the finding with a second reviewer before delivery. Use a standard template but adapt it to workflow, race, cloud and authorization cases. Offer a remediation call for high-complexity issues and correct evidence promptly when developers identify an inconsistency.
Report the architectural consequence
Lead with invariant, preconditions, proof and impact; follow with root-cause context and remediation. Provide a coverage and limitation statement so developers know whether the issue may recur beyond the demonstrated path.
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 owning policy or domain control, search for sibling consumers, add positive and negative regression and preserve build traceability. Avoid matching only the reported payload or route.
Retest the invariant, not just the payload
The tester repeats the original proof, verifies authoritative state, tests a representative related path and confirms legitimate use. Closure cites build, environment, date and remaining limitation.
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
A good finding is an executable engineering artifact, not a security verdict. If a developer cannot reproduce it safely and understand the failed invariant, the vendor has not finished the evidence work.
Ask WIMD for developer-ready finding evidence with exact reproduction, root-cause context and retest criteria.