9.1.2. DevSecOps and Shift-Left Security
💡 First Principle: Most software vulnerabilities fall into a small number of recurring patterns. Understanding these patterns — and why they occur — enables both prevention (don't write vulnerable code in the first place) and detection (know what to test for). The OWASP Top 10 is the industry-standard taxonomy of the most impactful web application vulnerability classes; the CWE (Common Weakness Enumeration) provides a broader catalog of software weakness types.
OWASP Top 10 (2021) — the most tested vulnerability classes:
| Rank | Category | Root Cause | Prevention |
|---|---|---|---|
| A01 | Broken Access Control | Missing authorization checks; insecure direct object references | Enforce access control on every request; deny by default |
| A02 | Cryptographic Failures | Weak algorithms; unencrypted sensitive data; poor key management | TLS for transit; AES-256 for rest; proper key management |
| A03 | Injection (SQL, OS, LDAP) | Untrusted data interpreted as commands | Parameterized queries; input validation; least privilege DB accounts |
| A04 | Insecure Design | Threat modeling not performed; security not in requirements | Threat modeling; security design reviews; secure design patterns |
| A05 | Security Misconfiguration | Default credentials; unnecessary features enabled; verbose errors | Hardening checklists; config as code; disable defaults |
| A06 | Vulnerable/Outdated Components | Third-party libraries with known CVEs | SCA scanning; dependency update automation; SBOM |
| A07 | Identification/Auth Failures | Weak passwords; no MFA; session management flaws | Strong auth; MFA; secure session management |
| A08 | Software and Data Integrity Failures | Unsigned updates; insecure deserialization; CI/CD pipeline attacks | Sign artifacts; verify signatures; secure pipeline |
| A09 | Security Logging/Monitoring Failures | Insufficient logging; no alerting; logs not reviewed | Comprehensive logging; SIEM integration; tested alerting |
| A10 | SSRF (Server-Side Request Forgery) | Application fetches remote resources without validating URLs | Allowlist of permitted URLs; network segmentation; block internal requests |
Buffer overflow: Writing data beyond the allocated memory buffer — the data overwrites adjacent memory, potentially including the return address on the call stack. An attacker who controls what is written can overwrite the return address to point to attacker-controlled code (shellcode).
Prevention: memory-safe languages (Go, Rust, Python, Java don't allow direct memory access); address space layout randomization (ASLR); data execution prevention (DEP/NX bit); stack canaries (random values placed between buffer and return address; checked before return).
Cross-Site Scripting (XSS): Attacker injects malicious JavaScript into a web page that executes in other users' browsers. Reflected XSS: payload in URL returned in response. Stored XSS: payload saved to database, executed when other users view the page. DOM-based XSS: payload manipulates the DOM without involving the server.
Prevention: output encoding (convert <script> to <script> before rendering); Content Security Policy (CSP) headers; input validation.
Cross-Site Request Forgery (CSRF): Attacker tricks an authenticated user's browser into submitting a malicious request to a trusted site. The browser automatically includes session cookies, so the request is authenticated. Prevention: CSRF tokens; SameSite cookie attribute; verify Origin/Referer headers.
Race conditions (TOCTOU — Time of Check to Time of Use): A vulnerability where the state of a resource changes between when it is checked and when it is used. Prevention: atomic operations; file locking; database transactions with appropriate isolation levels.
⚠️ Exam Trap: SQL injection is prevented by parameterized queries — NOT by input validation alone. Input validation (rejecting single quotes) is an incomplete defense: attackers can encode their payloads to bypass validation. Parameterized queries separate the SQL structure from the data, making injection structurally impossible regardless of what the user inputs.
Reflection Question: A web application uses the following code to query user records: query = "SELECT * FROM accounts WHERE id = " + request.params["id"]. Describe the attack this enables, provide an example malicious input, explain why input filtering is an incomplete fix, and provide the correct implementation that eliminates the vulnerability structurally.
