Choose SAST to inspect code paths before the application runs, DAST to probe a running application through its exposed interfaces, and a manual penetration test when a person needs to investigate a defined attacker objective and combine evidence across controls. The three methods can overlap, but their evidence is different. SAST can point to a risky source path without showing that it is deployed. DAST can observe a running response without seeing the full source path. A penetration test is a scoped human-led investigation, not a certificate that every route is safe. The right mix changes with the asset, release stage, available source, test environment and consequence of a missed flaw.
The OWASP Developer Guide describes automated testing and manual expert testing as complementary activities. Its DAST explanation emphasizes that a dynamic scanner interacts with a running web application and lacks source access. OWASP's SAST overview describes source or compiled-code analysis. NIST's testing and assessment guide treats technique choice, scope, limitations and mitigation as part of a planned assessment.
Compare the evidence, not the names
| Method | Input and action | Strongest ordinary output | Important blind spot | Typical owner |
|---|---|---|---|---|
| SAST | Pinned source or compiled artifact; analyze supported code without running the application. | File, line, rule and sometimes a source-to-operation trace for a candidate weakness. | Deployment, hidden controls, unscanned code and application-specific intent. | Development or AppSec team. |
| DAST | Authorized running target, accounts and routes; send requests and inspect responses. | Observation of behavior through the tested interface, with request and response evidence. | Unreachable or undiscovered routes, missing roles, code paths never exercised, and root cause in source. | AppSec or platform team with test-environment control. |
| Manual penetration test | Agreed target, threat model, accounts, time window and rules of engagement; investigator pursues selected objectives. | A reasoned chain of observations, prerequisites, impact and limits for the assessed objectives. | Anything outside scope or time, and paths the tester did not examine. | Authorized tester plus service and security owners. |
“Manual penetration test” does not mean every test uses a destructive exploit or starts with no knowledge. A tester may have source, architecture details or test accounts, and rules of engagement may require stopping before an action that could cause damage. What makes the activity distinct here is an authorized person investigating attacker goals in a defined running or otherwise assessable system, choosing the next step from evidence. The OWASP Web Security Testing Guide introduction discusses source review, testing and their different strengths; NIST discusses bounds and safety in test planning. None of the three labels proves a particular depth of work without the engagement record.
Illustrative case: a bulk export before release
Invented case; no exploit was performed: ArborPay, a fictional B2B billing service, is about to release a bulk invoice export. A standard account user can submit an export request; administrators can download the completed archive. The security policy says an export must contain only invoices belonging to the requesting account, and a standard user must never receive an administrator's archive. The CTO has three weeks and one AppSec engineer.
The code review question is, “Does any route or worker accept an account ID from the request and use it to select invoices without binding it to the caller's current account?” A SAST run might flag a direct object lookup or unsafe query. A reviewer still needs to follow the handler, queue payload, worker and storage link. If the tool emits nothing, that business rule does not become proven. OWASP notes that access-control problems are difficult to automate in its SAST strengths and weaknesses.
The running-system question is, “When two synthetic accounts request exports in an authorized staging environment, can one obtain the other's archive through the public interface?” A DAST tool can explore routes and inspect responses, but it needs appropriate authentication, known routes and safe state-reset procedures. If its account never reaches the asynchronous download path, its clean report does not cover that path. The test owner must record which roles and transitions were actually exercised.
The human-led objective is broader: “Can an ordinary account obtain an invoice archive it should not be able to see, including through worker status, signed download links or a changed account context?” A tester may combine code review, controlled runtime requests and architecture questions. The scope must state whether the worker, object store, identity switch and signed links are included. A credible test result says what was tried and observed, plus what was excluded. It does not convert a three-week review into assurance about every future deployment.
The three activities can therefore produce different, compatible answers: SAST finds a suspicious lookup, DAST cannot reach the worker path, and a scoped manual review identifies a missing archive-owner check. The DAST result is not a rebuttal to the source path because the test did not exercise it. Equally, the source path does not prove another account received an archive until the downstream checks and deployment are resolved.
Spend the three weeks on unanswered questions
ArborPay has one AppSec engineer, and realistic staging will not be available until day 10. The calendar below is an illustrative allocation of 15 working days, not an industry benchmark or promised assessment duration.
| Work | Days | Concrete output |
|---|---|---|
| Establish scope, actors and fixtures with engineering | 2 | Standard-user/admin policy, two synthetic accounts, exact export/download paths |
| SAST setup and review of selected source paths | 4 | Completed-scope receipt; traced handler→queue→worker→delivery chain; disposition of relevant alerts |
| Prepare authorized dynamic checks while staging is built | 2 | Known routes, role credentials, safe reset plan and expected outcomes |
| Investigate the account-boundary objective in matching staging | 3 | Own/foreign archive observations, including queued completion and direct download |
| Repair review and targeted recheck | 2 | Evidence for changed controls and any remaining limits |
| Final decision and contingency reserve | 2 | Release recommendation tied to actual scope; explicit unresolved work |
The order uses source while source is available. It does not fill the first week with a dynamic crawler pointed at an environment that cannot yet exercise the feature. Nor does it spend all 15 days configuring scanners and leave no time to resolve alerts.
The scoped human investigation is the decision-making activity during those three staging days. Automated dynamic discovery can assist it. If the asynchronous export requires a particular role and a later completion event, a crawler that only follows the logged-in homepage may miss it. The engineer must establish that the workflow was actually exercised before using a quiet result in the release decision.
Re-plan when staging arrives late
At the end of working day 10, suppose staging is available but uses the old worker build. Five full working days remain; earlier environment coordination has already consumed part of the contingency allowance. The source review has already found that the new worker trusts an account selector from the queue. A manual investigator cannot validate the new worker by probing the old one, however thorough the requests.
The CTO has three concrete choices:
- Release without bulk export: preserve the other release work, keep the new export route disabled under a verified configuration, and finish the matched-build review later.
- Move the release: obtain the matching worker and retain time for the account-boundary checks and repair reassessment.
- Accept a narrower release decision: only if the responsible owner explicitly accepts the documented export uncertainty and its business consequences. The scanner's green status is not evidence that fills the gap.
For a feature that releases customer invoice archives, the illustrative team chooses the first option. Its final note says: “The general release can proceed with bulk export disabled. Source review identified an unresolved worker account-binding path. Dynamic results apply to the old staging worker and do not qualify the new feature. Feature enablement requires a matching deployment and the planned own/foreign-account checks.”
That is a useful result even though no method completed every ambition. The decision follows the evidence and the feature boundary.
Give the next method a usable handoff
The methods become complementary through the evidence they exchange. For ArborPay, send the runtime reviewer a small packet: the exact API and worker revisions, the account-boundary rule, the relevant source path, the expected permitted operation and the unresolved delivery step. Include the setup needed to create a synthetic export and identify which account owns it. This avoids spending the scarce staging window discovering facts the source reviewer already knows.
The runtime result should come back with equally useful context. A denied request needs the selected account, role, operation and reason for denial. A response code alone can hide an authentication failure that prevented the intended ownership check from being reached. Pair the foreign-account attempt with a legitimate own-account operation that succeeds under comparable conditions. Preserve the requested observation and any side effect separately: rejecting a download after a worker has already sent the archive elsewhere would answer only part of ArborPay's question.
When an observation contradicts the source expectation, first compare the build, route, configuration and fixtures. The source reviewer may have followed the wrong adapter; staging may have an older deployment; or an effective control may exist outside the code supplied. None of these explanations should be selected just because it favors a preferred tool. Record the disagreement as a specific boundary to investigate, then ask the owner of that boundary for the missing evidence.
This handoff is also useful when there is no discrepancy. A matched source explanation and controlled observation support a more precise account of the tested export path. They still do not extend the result to a different role, a direct storage route or next week's worker revision. The packet should make those limits easy to see without forcing leadership to read every request and code excerpt.
Know what you are deferring
This plan does not include a broad external penetration test of every application function. If an independent engagement is required, commission it with its own scope and calendar; an internal AppSec review cannot be relabeled to satisfy that requirement. Conversely, buying a broad engagement does not remove the need to supply the correct build, roles and business policy.
OWASP's DAST guidance explains the running-interface perspective; NIST SP800-115 provides assessment-planning context. The allocation above is an original example of applying those distinctions. What matters is which unanswered question each day resolves, and which release decision remains unsupported if the necessary environment never arrives.
When a method cannot run or cannot reach the target
If source is unavailable, do not invent source coverage; use approved dynamic or design review evidence and mark the root cause uncertain. If the runtime environment is unavailable or unsafe to probe, do not call a static run a DAST substitute. If DAST authentication fails or a crawler never reaches an asynchronous workflow, report that limit and provide the route/account material needed for a focused retest. If a manual tester lacks permission to inspect the object store, leave that branch unresolved even if the web route looked sound.
An inconclusive branch still supports a decision. The CTO can assign the environment owner to produce a matching staging artifact, the AppSec engineer to trace the worker's ownership check, and the tester to revisit the download path within explicit authorization. Until then, keep the uncertain production claim open. A source defect that is already established can be repaired without waiting for staging; the missing environment limits the validation and release statement, not necessarily the code task.
For the next release, write one harmful action and one intended security rule before choosing a method. Use the SAST primer to interpret static output, then the business-logic guide to examine the rule a generic scanner may not know.