Application security testing is the practice of proving, with evidence, that a specific codebase or running application resists a defined set of attacks, and the discipline is judged on what gets closed rather than on what gets found. A report listing two hundred findings becomes a result only once the serious ones are fixed and a retest confirms that each fix holds under the original attack.
The industry has the first half working and the second half failing. The Veracode software security report finds 82 percent of organisations now carrying security debt, an 11 point rise in a single year, alongside a 36 percent surge in high-risk vulnerabilities. Detection is not the constraint. Remediation and verification are.
What do SAST, DAST, IAST and SCA each find?
SAST reads source code and finds flaws in logic you wrote, DAST attacks a running application and finds flaws in how it behaves, IAST instruments the application during testing and connects the two, and SCA inspects your dependencies and finds flaws somebody else wrote. Each is blind to most of what the others catch, which is why single-tool programmes fail quietly.
The blindness is the part worth understanding, because it determines what a clean report actually means. A codebase with no SAST findings can still be trivially exploitable through a misconfigured deployment, and an application that passes DAST can be carrying a known critical vulnerability in a transitive dependency that DAST never reaches.
| Technique | What it inspects | Finds well | Misses |
|---|---|---|---|
| SAST | Source code, no execution | Injection patterns, unsafe calls, hardcoded logic flaws | Runtime config, environment issues, auth behaviour |
| DAST | Running application from outside | Auth and session flaws, exposed surfaces, misconfiguration | Anything unreachable from the exposed surface |
| IAST | Instrumented app during testing | Confirmed exploitable paths with lower noise | Code paths your test suite never exercises |
| SCA | Declared and transitive dependencies | Known CVEs, licence risk, outdated components | Flaws in your own code, custom vulnerabilities |
SCA deserves one caution. It tells you a vulnerable version is present, not that the vulnerable function is reachable from your code, and treating every SCA finding as equally urgent is the fastest way to exhaust a team on work that changes nothing.
How is penetration testing different from a DAST scan?
A DAST scan tests known attack patterns against an exposed surface automatically, while a penetration test uses a human who chains several small weaknesses into one meaningful compromise. The difference is not thoroughness, it is reasoning. A scanner cannot notice that a harmless information leak on one endpoint makes a separate weak authorisation check exploitable.
That chaining is where real breaches live, and it is also why business logic flaws almost never appear in scanner output. A tester who understands that a discount code should not be applicable twice will find that defect. No scanner will, because nothing in the request looks malformed.
What only a human tester reliably finds:
- Business logic that is technically valid but commercially wrong
- Authorisation gaps between roles that each behave correctly alone
- Multi-step flows where state carries further than intended
- Chained low-severity findings that combine into a high-severity path
Where does each scan belong in the delivery cycle?
Place scans by what they need to run: SAST and secret scanning on every change, SCA whenever dependencies move, DAST nightly against a deployed environment, and penetration testing per release train or major change. Matching each technique to its trigger keeps results relevant, because a scan run at the wrong moment produces findings nobody can act on.
Volume is the practical constraint. A first SAST run on a mature codebase commonly produces hundreds of findings, and presenting that to a delivery team as a to-do list guarantees it gets ignored. Baseline the existing findings, treat new findings as the actionable set, and work the backlog separately on its own schedule.
| Trigger | Technique | What to do with the output |
|---|---|---|
| Every change | SAST, secret scanning | Act on new findings only, baseline the rest |
| Dependency change | SCA | Check reachability before prioritising |
| Nightly, deployed environment | DAST | Triage against the known baseline |
| Per release train | Penetration test | Ranked findings with a fix and retest plan |
How the surrounding stages are structured sits outside this discipline, and our guide to pipeline stage structure covers the mechanics.
How do you scope an application security testing engagement?
Scope by naming the assets, the roles to be tested, the environment, and what is explicitly excluded, then define the deliverable before anyone starts. Unscoped engagements produce reports that are simultaneously too long and missing the thing you cared about, because the tester optimised for coverage while you expected depth on one flow.
The decision that changes results most is authenticated versus unauthenticated testing. An unauthenticated test tells you what a stranger can reach, which is usually the smaller risk. Most serious findings sit behind a login, which means supplying working credentials for every role, including the administrative one people instinctively withhold.
Settle these before the engagement starts:
- Which applications, domains and APIs are in scope, and which are not
- Credentials for every role, including administrative accounts
- Environment to be tested, and whether production is permitted
- Data handling rules and any destructive testing limits
- The deliverable format and the agreed retest window
How do you triage findings without drowning?
Triage on exploitability and business impact rather than on the severity label the tool assigned. A critical rated flaw in an unreachable code path matters less than a medium rated authorisation gap on your payment flow. Scanner severity reflects the class of the vulnerability, not what it would cost you specifically.
False positives deserve a documented decision rather than silent dismissal. Record why a finding was rejected, because the same finding will reappear on the next scan and an undocumented dismissal means the team re-litigates it every cycle. Organisation-level risk ranking and patch policy are a wider topic, covered in our guide to ranking exploitable risk first.
The triage question that cuts the list fastest. For each finding, ask what an attacker gains if they exploit it and what they need to get there. Findings that require an authenticated administrator and yield nothing new can wait. Findings that need nothing and yield data cannot.
Why does the retest window decide whether testing worked?
The retest window is the agreed period in which fixes are verified by the original tester, and without it an engagement produces a report rather than an outcome. A fix that was never retested is an assumption, and a meaningful share of them are wrong, because the patch addressed the symptom described in the finding rather than the underlying weakness.
This is where the security debt figure comes from. Findings accumulate faster than they close, and the gap widens each year because closure is treated as an internal follow-up rather than a contracted deliverable. Build the retest into the engagement with a defined window, usually thirty to ninety days, so verification is scheduled rather than negotiated afterwards.
A retest is complete when:
- The original tester reproduced the attack and it now fails
- The fix is confirmed at the root cause, not the reported symptom
- Related endpoints sharing the same pattern were also checked
- The evidence pack records both the original and the verified state
What should the deliverable actually contain?
The deliverable should contain ranked findings with reproduction steps, evidence for each, a remediation recommendation, a verified retest record, and a summary that a non-specialist can act on. A report that cannot be reproduced from its own instructions is not evidence, and engineering teams are right to treat it as an opinion.
Reproduction detail is what separates a usable report from an expensive PDF. Each finding needs the request, the conditions, the account used and the observed result, at a level where a developer who has never spoken to the tester can confirm it in minutes. Security findings are tests, and the same reproducibility standards apply as in any suite, a point our guide to stabilising a test suite develops further.
Bringing in a security testing partner
Judging an AppSec provider is harder than judging most engineering work, because the output looks authoritative whether or not it is good. The signal worth watching is whether they ask about your business logic during scoping. Teams that only ask about your stack will return scanner output with a cover page.
Our matching process runs against the application type, the compliance context and the depth of testing you actually need, and returns one partner rather than a list to work through.
