Vulnerability Discovery and Analysis · Topic 2 of 5
SAST, DAST and Code Scanning
Compare static (SAST), dynamic (DAST) and interactive (IAST) application testing with software composition analysis, secrets and container scanning.
- 5 min
- Includes a diagram
- SAST analyses code without running it, and it is white box.
- DAST tests a running application from outside, and it is black box.
- SAST gives file and line numbers and works early, while DAST finds runtime and configuration issues.
What it is
Application testing tools look for flaws in software itself, not just in the systems it runs on. The two main approaches are static application security testing (SAST) and dynamic application security testing (DAST).
They differ in what they examine and when. Knowing which one fits a scenario is a common exam question.
How it works
SAST
Static application security testing analyses source code, byte code or binaries without running the program. It is often called white box testing, because the tool sees the inside of the application.
It can run early, even before the program is complete, for example inside a developer's editor or a build pipeline. It points to the exact file and line of a problem.
| Strength | Weakness |
|---|---|
| Finds issues early and cheaply | Cannot see runtime or deployment problems |
| Shows exact code location | Often reports false positives |
| Covers all code paths, including rarely used ones | Tied to specific languages |
SAST is good at finding issues such as dangerous function use, hard-coded passwords, and unsafe handling of input.
DAST
Dynamic application security testing tests a running application from the outside, sending requests and studying responses. It is often called black box testing, because the tool does not need the source.
It finds problems that only appear at runtime, such as server misconfiguration, missing security headers, weak session handling and some injection flaws. It cannot point to a line of code, and it only tests the parts of the application that it reaches.
| Strength | Weakness |
|---|---|
| Finds runtime and configuration issues | Needs a running application |
| Language independent | Cannot show the code line |
| Issues it demonstrates are more likely to be real | Misses pages it cannot reach |
DAST should run against a test or staging copy where possible, because it can create records, send emails and slow down a live system.
Interactive testing
Interactive application security testing (IAST) places sensors inside the running application. It watches code and data flow while tests or users exercise the app, so it can link a runtime issue to the code responsible. It combines some of the strengths of SAST and DAST.
Related scanning
| Technique | What it checks |
|---|---|
| Software composition analysis (SCA) | Third-party libraries and their known vulnerabilities and licences |
| Secrets scanning | Keys, tokens and passwords committed to repositories |
| Container image scanning | Operating system packages and libraries in a container image |
| Infrastructure as code (IaC) scanning | Insecure settings in templates before they are deployed |
| Dependency checks | Outdated or vulnerable packages used by the project |
These tools matter because a large share of modern applications is made of other people's code. A flaw in a library affects every application that uses it.
Sidecar and mobile scans
Two more application scan types appear in the outline.
| Scan type | What it does |
|---|---|
| Sidecar scan | A scanner or agent runs in a container deployed beside the workload, inspecting it at runtime without changing the application |
| Mobile scan | Static and dynamic analysis of a mobile application package to find insecure storage, weak code and risky permissions |
A sidecar fits container platforms, where the scanner lives next to the service it watches. Mobile scanning applies the static and dynamic ideas from earlier on this page to app packages.
Fitting them into development
Teams run these checks in a continuous integration and continuous delivery (CI/CD) pipeline.
The earlier a flaw is found, the cheaper it is to fix. This idea is often called shifting left.
Choosing between them
- The tester has the source code and wants line-level findings: use SAST.
- The tester has only a running URL or application programming interface (API): use DAST.
- The concern is third-party libraries: use SCA.
- The concern is leaked keys in a repository: use secrets scanning.
For a penetration test, the tester usually does DAST-style work against the live or staging application. A known environment test with source access can add SAST findings.
If the question says the tool needs the application to be running, the answer is DAST, and if it says the tool reads source code, the answer is SAST.
What to remember for the exam
- SAST analyses code without running it, and it is white box.
- DAST tests a running application from outside, and it is black box.
- SAST gives file and line numbers and works early, while DAST finds runtime and configuration issues.
- IAST uses sensors inside the running application.
- SCA checks third-party components, and secrets scanning looks for exposed credentials.
- Container and IaC scanning check images and templates before deployment.
- Both SAST and DAST can produce false positives that need validation.
- Run DAST against staging where possible to avoid harming production.
Common mistakes
Swapping the two names. Static means the code is not running, and dynamic means it is.
Assuming SAST finds everything. It cannot see problems caused by deployment settings, server configuration or third-party services.
Assuming DAST covers the whole application. It tests only what it can reach, such as pages behind a login if it has a valid session.
Ignoring dependencies. An application can be safe in its own code and still be vulnerable through a library.
Treating tool output as final. Results need manual validation before they reach the report.
Check yourself
Which approach analyses source code without executing it?
Static application security testing (SAST).
Which approach tests a running application from the outside?
Dynamic application security testing (DAST).
What does software composition analysis check?
The third-party libraries and dependencies used by an application, and their known vulnerabilities.
Topic 2 of 5 in Vulnerability Discovery and Analysis
Test yourself on Vulnerability Discovery and Analysis
The full CompTIA PenTest+ PT0-003 question bank has 653 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.