What does Security by Design mean?

Build security into the system from the first day of design, and consider it in every phase of the lifecycle — not as a bolt-on at the end.

The opposite is "build the feature, ship it, then have a security review tell us what's broken." That approach is catastrophically more expensive — the further into the lifecycle a flaw is found, the more rework it costs to fix.

What "from the start" looks like in practice:

• Requirements: security requirements alongside functional ones (data sensitivity, threat model, regulatory needs).
• Design: threat modelling (STRIDE, attack trees) before any code.
• Implementation: secure coding standards, automated SAST in CI.
• Testing: DAST, fuzzing, pen-testing.
• Deployment: hardened configs, secrets management.
• Maintenance: patch cadence, vulnerability monitoring, incident response.

Why it matters: a SQL-injection bug caught in design review costs maybe an hour of conversation. The same bug caught in production might cost a breach disclosure, regulatory fines, and rebuilding customer trust.

Tip: "Shift left" is the modern slogan for the same idea — move security activities earlier in the development pipeline.