Start with SCA, since dependency checks are quick and teach version reading. Then try SAST on your code, then DAST on the running app. The point is to compare what each finds on the same small project and to learn why they disagree.
What each one does
| Type | Looks at | Needs a running app | Typical finding |
|---|---|---|---|
| SCA, software composition analysis | Your dependencies and versions | No | A package with a known advisory |
| SAST, static analysis | Source code | No | A risky code pattern, such as unsafe input handling |
| DAST, dynamic analysis | The running app from outside | Yes | A misconfigured header or an injectable parameter |
The lab
Use one small app you control, ideally with a login page, one API route and a few dependencies. A deliberately insecure training app on localhost also works, and the OWASP Juice Shop project describes itself as a target for exactly this, including for security tools and scanners.
- Run dependency checks. Record each package, version and advisory ID.
- Run a static scan on the source. Record each finding and its file and line.
- Start the app on localhost and run a dynamic scan. Record each finding and the request that triggered it.
- Make a table with one row per issue and a column per method.
What you will notice
Some issues appear in one column only. A dependency flaw shows in SCA but not in DAST unless the vulnerable code is exposed. A hardcoded secret shows in SAST but not in DAST. A missing security header shows in DAST but not in SAST. That overlap pattern is the lesson, and it is why teams use more than one method.
You will also see false positives. Pick two findings and decide, from reading the code, whether each is real. Write down your reasoning.
Add the question scanners cannot answer
For each real finding, ask whether an attacker can reach it. A vulnerable function that your code never calls is a lower priority than one in a request handler. Reachability analysis automates that question. See our post on SAST vs DAST vs SCA choosing the right tool for the team level view.
Fix and rerun
Fix three issues, one from each method. Rerun each scan and confirm the finding is gone. If a fix creates a new finding, note that too. This is real daily AppSec work.
Where Safeguard fits
Safeguard covers dependency scanning with reachability analysis, and you can start with a free scan.
Try it yourself
Open the demo for a dependency inventory and see how SCA lists packages and advisories.
Click through it at your own pace, or open it full screen.
Quick check
Can one method replace the others?
No. They look at different things and find different issues.
Where do false positives come from?
Static tools flag patterns without full context, and dynamic tools can misread responses. Verify by reading code and reproducing.
Sources
Last reviewed: 19 October 2026.
