Runtime testing should remain central to an application pentest because it proves deployed behaviour and impact. Add focused source-code review when code visibility can answer high-risk questions faster or expose hidden paths, shared controls and root causes. The right design is usually source-assisted dynamic testing, not a choice between code review and runtime evidence.
A full secure-code audit is a different engagement. Define which repositories, components and hypotheses source access will support, how findings are validated dynamically, and what the final coverage claim includes.
What runtime testing does best
- Shows the controls actually deployed in the target environment.
- Captures framework, gateway, configuration and integration effects.
- Exercises authentication, authorization and workflow state end to end.
- Provides reproducible attacker-visible evidence.
- Tests client, API and asynchronous interactions across components.
Runtime work can miss dormant code, rare branches and systemic patterns that are difficult to discover from the outside. Access and state setup also consume time in complex systems.
What focused source review adds
- Trace authorization and tenant context across layers.
- Find alternate routes and unsafe fallback branches.
- Inspect cryptographic, parsing and deserialization decisions.
- Identify repeated unsafe APIs and shared root causes.
- Understand background jobs and service-to-service trust.
- Target runtime tests at consequential code paths.
Source observations alone may not reflect reachable production behaviour. Build configuration, feature flags, middleware and deployment topology can change the conclusion.
Add source assistance when the assurance question justifies it
Complex authorization and tenancy
Inspect where policy is evaluated, how object ownership is loaded, how tenant context propagates and which routes bypass shared middleware. Then test representative paths with controlled identities.
Hidden and asynchronous attack paths
Review webhook handlers, queue consumers, scheduled jobs, imports and administrative utilities that discovery may not reveal. Validate reachable triggers and downstream effects dynamically.
Security-sensitive custom code
Use focused review for token handling, signing, encryption, sandboxing, file processing and interpreters. Confirm attacker control, configuration and impact in the deployed system.
Systemic remediation questions
When one finding may exist across many routes, search for the root pattern and select sibling paths for runtime verification. This supports an architectural fix and bounded blast-radius assessment.
Runtime-only may be appropriate when
- The primary objective is attacker-realistic external exposure.
- The target is narrow and reachable with supplied accounts.
- Source access is unavailable or creates disproportionate data risk.
- The engagement is an independent validation of a deployed third-party system.
- A separate internal code-review program already covers the relevant components.
Even in runtime-only work, provide architecture, API and identity context when it improves coverage. Black-box purity should not waste most of a limited window unless discovery itself is the objective.
Define a source-assisted workflow
- Begin with threat objectives and a bounded runtime discovery phase.
- Identify high-risk components, controls and unresolved hypotheses.
- Grant least-privilege access to relevant source snapshots or repositories.
- Trace control flow and find candidate sibling paths.
- Validate candidates through runtime requests and state evidence.
- Report source observations separately from confirmed vulnerabilities.
- Use root-cause insight to define remediation and retest breadth.
Prevent source access from narrowing the tester
Source can bias attention toward readable components and known patterns. Preserve time for unscripted runtime exploration, exposed asset discovery and cross-component chaining. Ask testers to record supplied assumptions they challenged.
Control repository and evidence access
- Limit repositories, branches and history to the agreed need.
- Remove unrelated credentials, customer data and proprietary components.
- Use named accounts, logging and time-bounded access.
- Restrict local clones, AI tools and subcontractor access by policy.
- Define retention, deletion and incident notification.
The codebase is sensitive intellectual property and may contain secrets. Access controls should be part of scoping and vendor due diligence.
Set finding evidence standards
A code path becomes a confirmed reportable finding when the tester establishes reachability, attacker influence, failed control and credible impact under the engagement rules. When dynamic validation is unsafe or impossible, label the result as source-confirmed with explicit assumptions and limitations.
- File, component and relevant code path.
- Runtime entry point and attacker-controlled data.
- Deployed configuration and feature conditions.
- Reproduction or safe validation evidence.
- Observed impact versus code-based inference.
Keep coverage claims accurate
Focused source assistance does not mean the entire codebase received secure-code review. State repositories, components, commit, techniques and sampling. Likewise, runtime evidence applies to the tested build and environment.
Compare cost by decision value
Source familiarization adds effort but can reduce blind discovery and accelerate root-cause analysis. Use it where it increases confidence in consequential controls. For broad low-risk code, continuous internal SAST and review may be more economical than external manual inspection.
The testing techniques in the OWASP Web Security Testing Guide can structure runtime work, while source context helps testers choose and deepen the techniques relevant to the actual implementation.
The practical decision
Keep runtime testing as the proof layer. Add targeted source review for complex authorization, hidden paths, custom security code and systemic root-cause questions. Bound the code scope, protect access, validate findings dynamically and describe coverage precisely.
Design a source-assisted application pentest with WIMD that combines code-informed hypotheses with independent runtime evidence.