Software Development Security
Software Development Security tests whether security is built into the lifecycle rather than bolted on after release.
Core rules
- Integrate security activities into requirements, design, coding, testing, deployment, and maintenance. Threat modeling early is cheaper than fixing design flaws later.
- Validate input on the server; encode output for the correct context. Parameterized queries prevent SQL injection; output encoding prevents cross-site scripting. Neither replaces authorization.
- SAST finds code-level flaws, DAST finds runtime behavior, SCA finds dependency risk, and secret scanning finds credentials in repositories. Combine them.
- CI/CD pipelines need protected branches, artifact signing, least-privilege build identities, and reproducible dependencies. Separate development, test, and production environments.
- Secure defaults, error handling without sensitive data, and security requirements in acceptance criteria reduce recurring defects.
Worked example
A login form builds SQL by string concatenation. Input validation alone is insufficient because a valid-looking username can contain SQL syntax. The fix is a parameterized query, server-side authentication checks, rate limiting, and generic error messages. A code review plus DAST retest verifies the change. The reasoning targets the root cause-interpreted data-rather than blocking a list of characters.
Traps
Validation is not encoding. SAST does not prove runtime safety. DAST cannot see all code paths. Secrets in Git history remain exposed after deletion; rotate and purge. Passing tests do not justify skipping dependency review.