Practice vocabulary for SAST, DAST, IAST, SCA, and security finding terminology used in DevSecOps pipelines.
0 / 5 completed
1 / 5
What does SAST stand for and how does it work?
SAST (Static Application Security Testing) inspects source code, bytecode, or compiled binaries for security issues — SQL injection patterns, hardcoded credentials, unsafe function calls — without running the application. Tools include Semgrep, SonarQube, CodeQL, and Checkmarx.
2 / 5
What is DAST and how does it differ from SAST?
DAST (Dynamic Application Security Testing) attacks a live, running application — sending fuzzing inputs, scanning for XSS, SQLi, and authentication flaws — without access to source code. Tools include OWASP ZAP, Burp Suite, and Nuclei. SAST is white-box (has code access); DAST is black-box (no code access).
3 / 5
What is SCA (Software Composition Analysis) in a security context?
SCA (Software Composition Analysis) identifies open-source libraries and dependencies in a project and checks them against CVE databases. Tools include Dependabot, Snyk Open Source, OWASP Dependency-Check, and Renovate. SCA is distinct from SAST (which analyses your own code) and DAST (which tests the running app).
4 / 5
In security testing, what is a 'true positive' vs. a 'false positive'?
A true positive is a real security finding — the tool correctly identified a vulnerability. A false positive is a spurious alert — the code is actually safe but the tool flagged it. High false positive rates degrade trust in security tooling. Teams triage findings to confirm true positives and suppress confirmed false positives.
5 / 5
What does it mean to 'suppress' a false positive in a SAST tool?
Suppressing a false positive marks a specific finding as intentionally ignored — e.g., via a code annotation (`// nosec`, `@SuppressWarnings`), a findings-management config file, or the tool's UI. Good practice requires a justification explaining why the finding is not a real risk. Suppressions should be reviewed periodically.