Security

Secure Development Lifecycle

Intermediate

Security is not a stage at the end. It runs through the whole way we build, from idea to production to retirement. The Secure Development Lifecycle (SDLC) shows where security appears at each step, so it is never forgotten: threat-model in design, build securely, scan and review, deploy through gates, monitor in production, and respond to what you find.

Many of our guidelines are individual security practices. This topic ties them into one lifecycle, so you can see how they fit together and when each one applies. The principle is "shift left": catch security issues as early as possible (design and code), where they are cheap, rather than at the end, or after a breach, where they are expensive. But security also continues through operation and response.

Think of it as a checklist across the life of a feature, pointing to the detailed topic for each step.

Security at every stage

DoDesign: threat-model new features and significant changes before building (see Threat Modelling, Security by Design).
DoBuild: apply secure defaults, validate at trust boundaries, least privilege, and our security guidelines as you code (see Secure Defaults, Trust Boundaries).
DoVerify: automated scanning (SAST, dependency, secret, IaC), plus security-focused code review and tests for security-critical behaviour (see Vulnerability Management, Code Review, Testing Strategy).
DoDeploy: through the pipeline, with security gates enforced, reproducible builds, and the ability to roll back (see CI/CD & Deployment).
DoOperate: monitor and detect, patch promptly, and respond to incidents and disclosures (see Security Monitoring & Detection, Incident Readiness).
AlwaysTreat security as part of the work at every stage, not a final gate. A feature is not done until it is secure (see Definition of Done, Security by Design).

Make it the default way of working

DoBuild security checks into the tools and pipeline, so the secure path is automatic and does not depend on memory (see Secure Defaults).
DoKeep learning the current threats and practices for our stack, and share them (security champions, brown-bags) (see Continuous Learning).
ConsiderA security champion per team to keep security visible and be the first point of contact.
AvoidLeaving security to a single review at the end. Issues found there are expensive, and some will not be found at all.
NeverSkip the security steps to meet a deadline. Raise the trade-off instead. Weakening a control silently is never acceptable (see Technical Debt, Professional Ethics).

Self-review checklist

AskDid this feature get security attention in design (threat model), not just at the end?
AskAre the automated security checks passing, and was security part of the review?
AskWill this be monitored in production, so we would detect an attack or abuse?
AskIs security really part of 'done' here, or added on at the end?

Why it matters: Security failures are cheapest to prevent in design and most expensive after a breach. Running security through the whole lifecycle, and automating it, is what keeps it from being forgotten under deadline pressure. The SDLC view turns dozens of individual practices into one reliable habit, which is exactly what a fast-moving, junior team needs.