Static Application Security Testing

Final Quiz

Connecting to LMS... Progress: in progress

Assessment

1. What is Static Application Security Testing? A. A method for analyzing code or related artifacts for security issues without requiring a live running attack scenario. B. A production firewall rule. C. A password reset process. D. A replacement for all security work.

2. How does SAST differ from DAST? A. SAST and DAST are identical. B. SAST examines code or artifacts before runtime, while DAST tests a running application from the outside. C. DAST only reviews source code comments. D. SAST requires attacking production systems.

3. Why is SAST useful in the Secure SDLC? A. It guarantees no vulnerabilities will exist. B. It replaces secure design. C. It can provide earlier feedback to developers before issues reach production. D. It eliminates the need for remediation.

4. What is a source in static analysis? A. A final report template. B. A user interface color. C. A backup job. D. A point where untrusted or security-relevant data can enter the application.

5. What is a sink in static analysis? A. A location where data may have security impact, such as a query, command, file path, template, or response. B. A marketing asset. C. A deployment logo. D. A password reset email.

6. What is taint tracking at a high level? A. Encrypting backups. B. Tracking how data moves from sources through code toward sensitive sinks. C. Formatting source code. D. Compressing logs.

7. What is a SAST finding? A. A guaranteed exploit. B. A final authorization decision. C. A potential issue reported by the tool that requires review, context, and disposition. D. A replacement for code ownership.

8. What is a false positive? A. A real issue missed by the tool. B. A confirmed production incident. C. A release approval. D. A reported issue that does not apply as described after review.

9. What is a false negative? A. A real issue that the tool fails to report. B. A formatting warning. C. A duplicate ticket. D. A fixed finding.

10. Why does finding severity need context? A. Severity is never useful. B. Tool severity may not reflect reachability, exposure, data sensitivity, business impact, or compensating controls. C. Context should always be ignored. D. Severity automatically proves exploitability.

11. What should good remediation guidance include? A. Only a generic warning. B. No owner or evidence. C. Clear explanation, affected code context, safer pattern, expected fix behavior, and validation approach. D. Instructions to suppress every finding.

12. Why can suppressing findings be risky? A. Suppression always fixes vulnerabilities. B. Suppression replaces remediation. C. Suppression guarantees secure code. D. Suppression may hide real risk if it is not justified, documented, reviewed, and revisited.

13. What is a baseline scan useful for? A. Establishing known existing findings so teams can track new issues and plan remediation over time. B. Deleting all unresolved findings. C. Proving every issue is false. D. Replacing secure coding standards.

14. Why should SAST be integrated into CI/CD carefully? A. CI/CD integration makes human review impossible. B. Automation should provide timely feedback without creating unreviewed noise, blocking unnecessarily, or hiding accountability. C. CI/CD integration guarantees zero findings. D. CI/CD should always ignore security results.

15. Which metric is useful for SAST program health? A. Dashboard color only. B. Number of decorative charts. C. Finding aging, remediation trends, recurring root causes, scan coverage, and exception trends. D. Repository name length.

16. Which statement best summarizes SAST? A. SAST guarantees perfect software. B. SAST replaces threat modeling and runtime testing. C. SAST findings should always be accepted without review. D. SAST is a tool-assisted practice for finding risky code patterns early, but it requires triage, context, remediation, validation, and continuous improvement.