Application Security - SSDLC, Testing Types, and Guardrails in the Pipeline
What this domain covers
Application security questions test how controls are placed across the software development lifecycle, which testing technique answers which question, and how to enforce standards without stopping delivery. Expect questions on threat modeling, secure coding standards, SAST versus DAST versus SCA, dependency and supply chain controls, and build-breaking policy.
Core rules
- Requirements come from a standard such as OWASP ASVS, which gives verifiable security requirements per assurance level; abuse cases complement user stories.
- Threat modeling at design, using data-flow diagrams and trust boundaries, is the only control that catches design flaws; scanners cannot.
- Secure coding basics: server-side authorization checks on every request, parameterized queries, output encoding, input validation, safe deserialization, no secrets in source, and awareness of OWASP Top 10 and OWASP API Top 10.
- Testing tools by question: SAST reads source, is fast and early but noisy; DAST probes a running application and finds runtime and configuration issues later; IAST instruments the running app for better accuracy; SCA inventories dependencies and licenses; secret scanning catches credentials before commit; fuzzing finds crashes and parser bugs; RASP protects at runtime.
- Pipeline placement: pre-commit for secrets and formatting, pull request for SAST, SCA and IaC scanning with feedback in minutes, build for signing and SBOM generation, deploy for DAST and configuration checks, production for runtime protection and monitoring.
- Guardrails, not blanket gates: fail builds only on new, high-confidence, high-severity findings; baseline existing debt so legacy does not block every change; track burn-down separately.
- Supply chain: lockfiles, pinned versions, a proxy registry, signature verification (Sigstore/cosign), provenance attestations, and an SBOM per release.
Worked example
A team enables SAST with fail-on-any-finding. The first run returns 3,000 legacy issues and the team disables the scanner. Reasoning: an unachievable gate produces bypass, not security. The correction takes a baseline snapshot, fails only on new critical and high findings in changed code, comments results on the pull request, and runs a separate tracked burn-down for inherited debt. SCA and secret scanning are added at the same point because they are fast and low-noise, while DAST runs against staging where it has a deployed target.
Traps that cost marks
- Presenting SAST or DAST as a replacement for threat modeling.
- Making builds fail on low-severity or pre-existing findings.
- Ignoring transitive dependencies and container base images.
- Confusing SCA (dependency inventory) with SAST (source analysis).
- Assuming shift left means developers work without security expertise available.