SAST, DAST, and SCA
You cannot manually review every line for every flaw, so automated application-security testing fills the gap — each tool type catching different bugs at a different stage. SAST reads the source for dangerous patterns, DAST attacks the running app from outside, and SCA checks your dependencies (the previous topic); none is complete alone, and their strengths and blind spots are exactly complementary.
This topic gives you a working map of AppSec tooling and how to wire it into Meridian's pipeline without drowning developers in false positives — because a tool developers route around protects nothing.
SAST — Reading the Code
Static analysis scans source for vulnerable patterns — injection, hardcoded secrets, unsafe APIs — early, even before the code runs. It sees all code paths, but it produces false positives and cannot catch runtime or configuration issues, so tuning is essential. Turned on at full sensitivity without tuning, SAST floods developers with noise until they ignore or disable it.
DAST — Attacking the Running App
Dynamic analysis probes the deployed app like an attacker (Chapter 6), catching real exploitable issues and configuration flaws SAST cannot see — but only on the paths it exercises, and later in the cycle, since it needs a running target. Where SAST reads the code and guesses at exploitability, DAST proves it against a live instance, which is why the two are complementary rather than redundant.
SCA and Secret Scanning
Software composition analysis flags known-vulnerable and malicious dependencies (the previous topic), and secret scanners catch committed credentials. These are the highest-value, lowest-false-positive tools and the first ones to adopt — a dependency CVE or a committed key is a high-signal finding, so these make good blocking gates while noisier SAST is still being tuned.
Wiring Meridian's Pipeline
The integration is deliberate: SCA and secret scanning as blocking gates (high signal), SAST tuned and mostly advisory, DAST against staging, and results triaged so developers see real issues, not raw scanner output. Interactive testing (IAST) and fuzzing add further coverage, but the point is layered testing with triaged output — security tooling that helps rather than gets disabled.
SAST — white-box, reads source, early, sees all paths; higher false positives, misses runtime and configuration.
DAST — black-box, attacks the running app, finds real exploitable and configuration issues; later, only exercised paths.
SCA — checks dependencies for known CVEs and malice; high-signal, an easy win. Complementary — mature programs run all three.
- Relying on one tool type and assuming coverage — SAST misses runtime and config, DAST misses unexercised paths, neither covers dependencies.
- Turning on SAST at full sensitivity, flooding developers with false positives until they ignore or disable it.
- Running scans that block releases without triage, so security tooling becomes the enemy and gets routed around.
- Skipping the high-signal wins (SCA, secret scanning) while investing effort in noisy SAST.
- Running DAST only against production instead of a staging instance.
- Layer SAST, DAST, and SCA for complementary coverage, understanding each tool's blind spots.
- Start with the high-signal, low-noise tools (SCA, secret scanning) as blocking gates; tune SAST before making it blocking.
- Triage results so developers see real, prioritized issues, not raw scanner output — adoption depends on signal.
- Run DAST against staging and integrate testing into the pipeline as feedback, not just a release wall.
- Add IAST or fuzzing for deeper coverage once the core three are in place.
Knowledge Check
Why isn't one type of application-security tool enough on its own?
- Each misses what the others catch — SAST runtime, DAST unexercised paths, neither dependencies
- Modern SAST tools reliably catch every possible vulnerability class
- DAST reads through the application source code directly
- SCA can detect injection flaws in your own code
Which tools make the best first blocking gates, and why?
- SCA and secret scanning — high-signal, low-noise
- SAST at full sensitivity, to catch the most issues immediately
- DAST in production, to test against the real running system
- Fuzzing first, because it finds the deepest hidden bugs
Why does triaging scanner output matter for tool adoption?
- Noisy output makes developers route around the tool
- Triage makes the scans run faster
- Untriaged raw output is far more secure to act on directly
- Triage removes the need to run the scanners
You got correct