9.2.1. SAST, DAST, IAST, and SCA

💡 First Principle: Every line of code that runs represents trust being extended — to the programmer who wrote it, to the libraries it calls, to the data it processes. Secure coding principles are systematic ways of limiting that trust: validate all inputs before trusting them, handle all errors explicitly rather than hoping they don't occur, and design so that a single component compromise doesn't compromise everything.

Core secure coding principles:

• Allowlist input validation: Define what is acceptable input; reject everything else. Stronger than denylist (blocking known-bad is less complete than allowing only known-good).
• Output encoding: Before rendering user-controlled data in output contexts (HTML, SQL, OS commands), encode for the specific context. HTML encoding prevents XSS; parameterized queries prevent SQL injection.
• Fail secure: On failure, deny access by default ("fail closed") — not allow access ("fail open").
• Least privilege in code: Database connections use accounts with minimum required permissions. Web processes don't run as root/administrator.
• Secure defaults: Applications secure by default — encryption on, most-restrictive access permissions by default. Features that increase attack surface disabled unless explicitly enabled.
• Defense in depth: Layer multiple controls — input validation + parameterized queries; authentication + authorization + audit logging.

Code reuse and supply chain security: Third-party libraries introduce inherited vulnerabilities. Log4Shell (CVE-2021-44228) demonstrated how a single widely-used library can affect millions of applications simultaneously. Controls: Software Composition Analysis (SCA) scanning for known CVEs; Software Bill of Materials (SBOM) for component inventory; pin dependency versions.

⚠️ Exam Trap: "Validate input on the client side (JavaScript) to prevent injection." Client-side validation is a usability feature — it provides immediate feedback to legitimate users. It is not a security control. An attacker intercepts the HTTP request with a proxy tool and submits whatever input they want, bypassing all client-side validation. All security input validation must happen on the server side.

Reflection Question: An application accepts a file path from the user and reads that file. Without input validation, what attack does this enable? What is the correct fix? If the application must allow user-specified filenames, what allowlist-based approach would constrain the risk?