Shift-Left: Security in Every Phase

The biggest mistake in software security is treating it as a final checkpoint — a scan you run right before launch. Security added at the end is weak and expensive. Security by design (often called shift-left security) means thinking about safety in every phase, from requirements all the way to operations.

There's a familiar idea underneath this: the cost-of-change curve from Chapter 2 applies to vulnerabilities too. A security flaw caught in design is cheap to fix; the same flaw caught after a breach is catastrophic.

Think of designing a house with locks, wiring, and fire exits drawn into the blueprint — not nailing on deadbolts and stringing extension cords after the family has moved in. Safety built in from the plan is far stronger than safety bolted on later.

Design

→

Code

→

Build

→

Test

→

Production

Why Bolt-On Fails

Security tacked on at the end is the most expensive and least effective kind. By then, insecure assumptions are baked into the design and the code, and ripping them out is costly — sometimes impossible without a rewrite. A "we'll secure it before launch" mindset almost always ships something either insecure or hugely over budget. Real security comes from decisions made early, not a final scan.

Shift-Left

Shift-left means moving security thinking earlier — toward the left (the start) of the lifecycle. That means asking about threats during design, adding security checks into the continuous-integration pipeline, scanning dependencies before release, and so on. It's the same "catch it early, where it's cheap" principle as testing's shift-left, applied to safety. The earlier a security issue is found, the cheaper and easier it is to fix.

Threat Modeling, Lightly

A core early-phase practice is threat modeling: during design, simply asking "what could go wrong here, and who would want it to?" You imagine how an attacker might misuse the feature — steal data, impersonate a user, break something — and design defenses in from the start. You don't need to be a security expert; just asking the question early catches a surprising number of problems before they're built.

Everyone's Responsibility

Finally, security is not just a security team's job — it's built in by everyone. Developers writing safe code, testers probing for weaknesses, designers avoiding risky patterns: each contributes. A dedicated security team helps, but it can't bolt safety onto a product that wasn't built with it in mind. Like quality (Chapter 9), security is a shared, continuous responsibility, not a phase someone else owns.

When the Cadence team designs reminders, they don't wait for a security review. Right in the design discussion, Priya asks a simple threat-modeling question: "could one user somehow read or change another user's reminders?" That single early question leads them to build in an authorization check from the start — instead of discovering the hole after launch, when fixing it would mean a breach, an apology, and a scramble.