Developers should fix validated critical or release-blocking findings during the penetration test when evidence has been preserved and the change can be coordinated safely. Lower-priority findings usually benefit from waiting for the consolidated draft and root-cause review. The right approach is a controlled live-remediation workflow—not an absolute rule to fix everything immediately or wait for the final PDF.
Early fixes can shorten exposure and closure time. Uncoordinated fixes can also change the assessed build, destroy reproduction evidence, hide related variants or consume the test window. Engineering and the tester need one version record, one triage route and explicit retest decisions.
Classify findings before deciding
Fix during testing
- Validated critical exposure or credible active abuse path.
- Release blocker with a small, well-understood correction.
- Unsafe configuration or credential issue that can be contained immediately.
- Finding whose remediation will not destabilize the remaining test surface.
Wait for consolidated review
- Multiple symptoms may share a systemic root cause.
- The finding is valid but lower priority and the fix needs design work.
- Changing the component would invalidate large parts of ongoing coverage.
- Evidence, severity or affected scope still requires technical review.
This classification is about workflow, not whether the finding matters. Every valid risk still receives an owner and disposition.
Preserve evidence before changing the build
The tester should record the affected version, identities, preconditions, requests, responses or state changes, impact and known variants. Engineering should be able to reproduce the original issue in an authorized environment. Once that record exists, a coordinated fix can proceed without erasing the basis for the finding.
Do not ask the vendor to delete a valid finding because the team fixed it quickly. The report should show the original result and the verified closure, which is stronger evidence for leadership and customers.
Use one live-remediation channel
- Tester submits a validated finding through the agreed secure route.
- Technical coordinator assigns the owning engineer and confirms release context.
- Security, product and engineering decide emergency fix, mitigation, planned fix or acceptance.
- Engineer records the corrective control and build identifier.
- Tester schedules a focused retest and continues unaffected scope.
- Closure status is appended without overwriting the original evidence.
Avoid direct messages from several testers to several developers. A single route prevents duplicate work, protects sensitive evidence and keeps the assessment record coherent.
Protect the integrity of the remaining test
A mid-test deployment can change endpoints, authentication, workflow state or shared libraries. Before deploying, identify which completed tests may need regression and which planned tests depend on the old behaviour. The vendor should state the schedule effect rather than quietly reducing coverage.
For large changes, create a controlled fix branch or separate environment. For small configuration corrections, record the exact time and value changed so telemetry and evidence remain interpretable.
Fix the root cause, not the proof payload
Early pressure can encourage narrow blocking rules. An input-filter patch may stop one payload while leaving unsafe query construction. A route-specific authorization check may leave the same missing policy elsewhere. Ask what security property failed and where the shared control belongs.
- Test same-control endpoints and alternate clients.
- Add negative authorization and input-handling regression tests.
- Search for repeated patterns across the codebase or configuration.
- Use temporary mitigation only with an owned durable fix.
When a temporary mitigation is appropriate
A feature flag, route restriction, WAF rule, credential rotation or monitoring control may reduce immediate exposure while engineering develops a durable fix. Record what the mitigation blocks, what it does not block, how long it remains and what will replace it. Retesting a mitigation is not the same as verifying root remediation.
Retest discipline
- Use the build and environment intended for closure.
- Verify the original path and the failed security property.
- Check reasonable bypass variants and shared-control paths.
- Confirm intended legitimate behaviour still works.
- Record partial, mitigated and verified outcomes separately.
If fixes arrive repeatedly throughout the engagement, group retest windows. Constant context switching can reduce both testing and engineering quality. Urgent issues are the exception; routine fixes can wait for scheduled checkpoints.
A practical schedule
Daily critical-risk checkpoint
Review only validated urgent issues, access blockers and planned deployments. Keep it short and decision-oriented.
Midpoint coverage review
Confirm tested surfaces, material findings, scope changes and whether one systemic fix should wait for the draft.
Draft technical readout
Resolve facts, group root causes and translate findings into owned engineering work.
Planned retest window
Validate completed corrections together, then issue the closure record.
Common failure modes
- Developers patch unvalidated scanner observations.
- The assessed build changes without notifying testers.
- A quick fix destroys evidence or hides other affected paths.
- Every issue is treated as an emergency and the sprint collapses.
- No retest is reserved, so “fixed” means only developer-reported.
- Valid findings disappear from the final report after remediation.
The practical decision
Fix validated material risk during testing when early action reduces exposure and the change can be controlled. Preserve evidence, coordinate the build, protect remaining coverage and retest the security property. Consolidate lower-priority work so engineering can address root causes instead of reacting to a stream of isolated symptoms.
Design a live remediation and retest workflow with WIMD before the testing window begins.