Secure software development and operations
Secure software development and operations tests whether security is built into the lifecycle. Expect questions on secure coding, testing types, dependency risk, CI/CD controls, and production hardening.
Core rules and concepts
- Shift left: define security requirements, threat-model designs, and review code before release. Security is not a single penetration test at the end.
- Common web weaknesses include broken access control, injection, cryptographic failures, insecure design, security misconfiguration, vulnerable components, authentication failures, integrity failures, logging failures, and server-side request forgery.
- SAST analyzes source or bytecode without running the app. DAST tests a running application from the outside. SCA inventories dependencies and known vulnerabilities. Code review and secret scanning catch issues tools miss.
- CI/CD controls: separate environments, least-privilege build identities, signed artifacts, pinned dependencies, automated tests, and secrets stored in a managed vault rather than the repository.
- Operations: patch management, secure baselines, infrastructure as code review, backups, and monitoring. Production changes should be traceable and reversible.
Worked example
A login form concatenates user input into a SQL query. The flaw is injection, enabled by string concatenation and excessive database privileges. Fix it with parameterized queries, validate input, apply least-privilege database accounts, add SAST and dependency scanning to the pipeline, and test the fix with DAST. Do not rely on hiding the error message as the primary control.
Traps that cost marks
SAST does not exploit a running app; DAST does not read source. Input validation is not the same as output encoding. A vulnerability scan is not a full penetration test. Removing stack traces is hardening, not a fix for injection.