Secure Development Lifecycle

Introduction

Fixing a security flaw in production costs far more than preventing it during design. A secure development lifecycle (SDLC) builds security into every stage, so it is part of how software is made, not a last-minute inspection.

Security at each stage

Requirements: state security needs, such as who may see what, and data protection duties.
Design: use threat modelling and secure patterns. Apply least privilege, defence in depth and secure by default.
Implementation: follow secure coding guidance, such as the OWASP cheat sheets. Use trusted frameworks and libraries.
Review: peer code review with security in mind.
Testing: automated and manual security tests.
Release and operate: secure configuration, monitoring, patching and incident response.

NIST's Secure Software Development Framework (SSDF) organises these practices.

Automated testing

Type	What it does	When
SAST (static analysis)	Scans source code for risky patterns	During build, on every commit
Dependency scanning (SCA)	Finds known vulnerabilities in libraries you use	During build and continuously
Secret scanning	Finds passwords and keys committed to code	Before and after commits
DAST (dynamic analysis)	Tests the running app from outside	On test environments
Container and infrastructure scanning	Checks images and configuration	In the pipeline

None is perfect. They produce false positives and miss things, so combine them with human review and penetration tests where the risk justifies it.

Quick quiz

Which kind of scanning finds known vulnerabilities in the third-party libraries your project uses?

Dependencies and the supply chain

Most modern software is mostly other people's code. Attackers know this and target software supply chains.

Keep dependencies updated, with automated update pull requests.
Prefer well-maintained libraries, and remove unused ones.
Lock versions with lock files, and verify what you install.
Keep a software bill of materials (SBOM), a list of everything inside your software, so you can answer "are we affected?" quickly.
Protect your build pipeline and its credentials, because an attacker who controls it controls your releases.

Secrets management

Never commit secrets to Git. Use environment variables or a secrets manager.
Rotate secrets regularly and after any exposure.
Give each system the least access it needs, with separate keys for each environment.

Culture

Make the secure way the easy way: good defaults, templates and shared libraries.
Train developers on common flaws.
Treat security bugs like other bugs, with owners and deadlines.
Run a vulnerability disclosure policy so researchers can report problems safely.

Try it yourself

For a project of yours, write which of the five automated checks in the table you run today and which you do not. Pick one missing check, and add it to your build pipeline.

Summary

Build security into every stage, from requirements and design to operation.
Combine static, dependency, secret and dynamic scanning with human review.
Manage the supply chain and secrets carefully, and make the secure way the easy way.