Simple explanation
Different tools scan for different things — this lesson is about knowing which tool produces which kind of output, so you can read a report and understand exactly what was and wasn't tested.
Technical explanation
- Web application scanners — tools like Burp Suite and OWASP ZAP (Zed Attack Proxy) actively probe a web app for flaws like injection and XSS; Nikto specifically scans web servers for known-dangerous files, outdated software, and common misconfigurations.
- Infrastructure vulnerability scanners — Nessus and OpenVAS scan hosts and network devices broadly for known CVEs and misconfigurations, the general-purpose workhorses of vulnerability management.
- Software Composition Analysis (SCA) — scans an application's dependencies (third-party libraries) for known vulnerabilities, since modern software is built on huge amounts of code the organization didn't write itself.
- SAST (Static Application Security Testing) — analyzes source code without running it, catching flaws early in development.
- DAST (Dynamic Application Security Testing) — tests a running application from the outside, catching issues that only appear at runtime.
- Cloud infrastructure assessment tools — scan cloud-specific configuration (IAM permissions, storage bucket settings, network security groups) that traditional infrastructure scanners aren't built to understand.
Synonyms / related terms
| Term | Means | |---|---| | SAST | Static Application Security Testing | | DAST | Dynamic Application Security Testing | | SCA | Software Composition Analysis |
Concept Check
"A development team wants to catch a SQL injection vulnerability in their own code before it's ever deployed, by analyzing the source directly." This calls for SAST, not DAST — SAST examines code statically, before runtime, which is exactly the "before it's ever deployed" requirement; DAST requires a running application to test against.
Interview-style Q&A
Q: Why would an organization run both SAST and DAST rather than just one? A: "They catch different things. SAST finds flaws in the code itself, early, but can miss issues that only manifest when the application is actually running with real configuration and data. DAST catches those runtime issues but can't see into the source to catch a flaw before deployment. Together they cover more of the actual attack surface than either alone."
Memory trick
"Static reads the Script, Dynamic watches it Dance" — SAST reads code without running it; DAST watches the application "dance" (run) to find issues.