Secure code review can see control decisions that an external tester must infer: route registration, authorization helpers, data flows, cryptographic use, deserialisation, background consumers, feature flags and privileged integrations. Its advantage is visibility, not proof that every suspicious line is reachable or exploitable in the deployed system.

Runtime penetration testing supplies that missing context. It establishes deployed configuration, identity, state, reachability and authoritative impact. The strongest workflow uses source review to form precise hypotheses, validates high-value paths in the running application, and feeds runtime discoveries back into code tracing.

The purpose is not to maximise findings from two tools. It is to reduce blind spots and locate durable root causes. A code pattern repeated across services may explain several runtime findings; a safe runtime test may show that suspicious code is dead, protected or deployed differently.

Choose code boundaries that match the assessment decision

Inventory repositories, services, branches, generated code, infrastructure definitions and deployed versions. Prioritise security-critical components instead of reading every line equally: authentication, authorization, tenant filters, payments, uploads, parsers, templates, cryptography, secrets and outbound requests.

Agree how source is accessed, retained and referenced in evidence. Use least-privilege read access, protect proprietary details and record commit identifiers so later retesting can determine whether the reviewed code reached the tested environment.

  • Repository, branch, commit and mapping to deployed services.
  • Authentication, authorization, tenant and object-ownership enforcement.
  • Input-to-sink data flows for queries, templates, commands, parsers and fetchers.
  • Secrets, cryptography, token lifecycle and sensitive logging.
  • Queues, jobs, webhooks, integrations, feature flags and administrative paths.

Code-review areas that produce high-value runtime hypotheses

Prioritise code that owns security decisions or crosses trust. For each suspicion, record the route, identity, data and deployment conditions needed for validation.

Authorization and tenant scoping

Checks may exist in controllers but disappear in background jobs, repository helpers, exports or alternate APIs. Trace policy from entry point to authoritative query or mutation, then test paired users and tenants against the deployed path.

Evidence standard: Link the code decision to the exact request and prohibited object or state result.

Input reaching dangerous interpreters

User-controlled data can reach SQL, templates, commands, deserialisers, URLs or file paths through indirect helpers. Build a source data-flow hypothesis, confirm deployed reachability with harmless payloads and observe the authoritative sink safely.

Evidence standard: Show source, transformations, sink and runtime outcome without publishing unnecessary weaponised payloads.

Cryptography and token lifecycle

Correct algorithms can be undermined by key handling, nonce reuse, broad claims, fallback verification or failure to revoke. Review primitives and lifecycle, then test token issuance, rotation, audience, expiry and revocation through supported interfaces.

Evidence standard: Record the policy failure and observed acceptance; never place private keys or reusable tokens in the report.

Asynchronous and integration paths

Queues, webhooks and jobs may trust data that was validated only in the initiating request or lose actor and tenant context. Trace message construction and consumers, then trigger synthetic workflows and inspect final state, retries and signatures.

Evidence standard: Connect initiating identity to consumer action and authoritative side effect.

Security logging and error behaviour

Logs may disclose secrets, accept client-forged fields or omit critical actions, while errors reveal internal data or create fail-open decisions. Review log and exception paths, exercise representative failures and verify redaction, attribution and monitoring.

Evidence standard: Use synthetic values and show the trusted field source, redaction result and alerting limitation.

Why code review and runtime testing disagree

Differences often reveal deployment or architecture facts: a vulnerable branch is not deployed, a gateway blocks a path, a feature flag differs, a helper is bypassed in another service, or generated code changes behaviour.

Resolve disagreement rather than choosing the more alarming conclusion. Record version evidence, environmental controls and remaining uncertainty. A compensating control may reduce exploitability without fixing the code-level defect.

  • Reviewing the default branch while production runs a different commit or service.
  • Treating static-analysis matches as manually confirmed source findings.
  • Ignoring framework middleware, generated routes or policy configuration.
  • Validating only the happy-path web controller while jobs and APIs share lower-level data access.
  • Reporting dead or unreachable code as an active vulnerability.
  • Assuming a gateway permanently compensates for an unsafe service implementation.
  • Closing a runtime finding after a local code change without deployed retesting.

Evidence that supports a defensible conclusion

Maintain a traceable chain from commit and code location to route, identity, payload class, runtime response and authoritative state. Keep proprietary snippets minimal; explain control logic in prose where possible. Distinguish code weakness, deployed vulnerability, defence-in-depth recommendation and unvalidated hypothesis.

  • Repository, commit, service and environment mapping.
  • Minimal code location and control-flow explanation.
  • Runtime preconditions, identity and reproducible action.
  • Authoritative data or side-effect result with sensitive values redacted.
  • Compensating controls, limitations and confidence.
  • Fix commit, deployment evidence and retest outcome.

How WIMD would combine source-assisted and runtime testing

WIMD would threat-model the product, review the code that implements high-value trust decisions, and maintain a hypothesis register. Testers would validate prioritised hypotheses against the deployed system using appropriate identities and synthetic data.

Runtime discoveries would trigger targeted code tracing to find the shared root cause and sibling paths. The final report would label every conclusion by evidence type and preserve a safe path for developers to reproduce it.

  1. Map deployed services and commits to the in-scope application and APIs.
  2. Identify security-critical decisions, data flows and privileged integrations.
  3. Record source hypotheses with preconditions and expected authoritative outcomes.
  4. Validate high-value paths in the running environment using paired identities and safe payloads.
  5. Trace confirmed failures to durable root causes and search sibling implementations.
  6. Retest the deployed fix and add focused regression cases for recurrence.

Fix shared controls and prove deployed behaviour

Move authorization and validation into reusable server-side policy points, use safe framework APIs, simplify cryptographic and token choices, preserve actor context across jobs, and make logs trustworthy. Avoid endpoint-specific patches that leave sibling paths exposed.

Review the fix diff for bypasses, deploy it to the assessed environment, replay the original exploit and sample related routes. Confirm legitimate roles and workflows still succeed.

  • Add negative unit and integration tests around the security invariant.
  • Search for direct calls that bypass the corrected helper or policy.
  • Remove obsolete fallback and compatibility paths when possible.
  • Verify configuration and feature flags in the deployed environment.
  • Track recurrence to improve libraries, review checklists and threat models.

Decide when source review adds material value

Source access is especially useful for complex authorization, multi-tenant SaaS, cryptography, custom protocols, parsers, background workflows and rapid root-cause analysis. A runtime-only test may be adequate for a small black-box decision, but its coverage limitations should be explicit.

Budget source review around risk rather than lines of code. Ask what repositories and decisions will be reviewed, how hypotheses will be validated, and how code will be protected.

  • Does the assessor know which commit is deployed?
  • Will review focus on security decisions and trust boundaries?
  • Are static tool results manually analysed before reporting?
  • Will suspected code paths be validated at runtime where feasible?
  • Will confirmed findings be traced to sibling paths and retested after deployment?

Questions security, engineering and assurance teams ask

Does secure code review replace penetration testing?

No. It provides visibility into implementation and root cause, while runtime testing validates deployment, identity, state and impact. They answer related but different questions.

Is SAST the same as secure code review?

No. SAST can find patterns at scale, but expert review adds architecture, business policy, data-flow and exploit-context reasoning. Tool results still require triage and validation.

Must the report include source code?

Usually not. A minimal file and location reference plus a clear control-flow explanation can guide remediation while protecting proprietary code. Sensitive snippets should be tightly controlled.

How should a source-informed finding be closed?

Review the fix, confirm the corrected commit is deployed, repeat the original runtime path and test sibling implementations that share the control.

Authoritative and technical references

Use source visibility to improve evidence quality

The best source-assisted assessment produces fewer ambiguous findings, clearer root causes and stronger regression tests. It keeps code suspicion and runtime impact honest.

Preserve the hypothesis and evidence links so engineering can revisit them when shared libraries, deployment topology or trust rules change.

Ask WIMD to combine secure code review with runtime validation for your highest-risk application and API boundaries.