Secure SDLC, Risk Management, and Compliance
Core concepts
Know the secure SDLC phases and the controls in each: security requirements and abuse cases at design, threat modeling, secure coding standards, code review and SAST in build, DAST and dependency/SCA scanning in test, hardening and configuration review in deploy, and monitoring in operations. Understand shift-left as early detection, not elimination of later testing. Know SAST (white-box, source), DAST (black-box, running app), IAST, and SCA (third-party components) and their strengths and blind spots.
Risk and compliance
Understand risk management: identify, assess (likelihood × impact), treat (mitigate, transfer, accept, avoid), and monitor, with a documented risk register and owner. Know the concept of risk appetite and how security debt is tracked. For compliance, know the shape of common frameworks: PCI DSS for card data, GDPR/CCPA for privacy and data subject rights, SOC 2 for controls assurance, ISO 27001 for an ISMS, and HIPAA for health data. Know that compliance is a floor, not proof of security.
Traps
Questions claim SAST finds runtime configuration issues, or that passing an audit means the app is secure. Another trap: treating risk acceptance as "do nothing" without an owner and expiry, or assuming a vendor's certification transfers all responsibility.
Rule of thumb
Every finding has an owner, a treatment decision, and a due date; automation gates the build, humans judge the risk.
Worked example
A critical SCA finding in a transitive dependency enters the risk register with an owner, a 14-day remediation target, and a compensating control (virtual patch at the WAF) until the upgrade ships.