Storybooks › Cybersecurity for Juniors, Book 3 › Chapter 2

Mahika and Meher ma'am at a whiteboard, sketching a threat model before a single line of code ships.AI art

Cybersecurity for Juniors · Book 3 · Chapter 2

Shift Left, or Get Left Behind

Big idea: the cheapest bug is the one that's still a diagramSecure SDLC & security by design

Part 1 · A feature with no code yet

Mahika's first real assignment arrived as a calendar invite, not a ticket: "Threat model review, Course Bundles v2, 45 min." No code existed yet. There was a product doc, a rough wireframe, and a single sentence that would turn out to matter more than anything else in the meeting: students would soon be able to gift a course bundle to another student's account directly.

"We're doing this before anyone writes a line of code," Meher ma'am said, pulling up a blank whiteboard instead of a laptop. "Because the cheapest bug in this entire company is the one that's still a diagram. Once it's code, it costs more to fix. Once it's shipped, it costs a lot more. Once someone outside this building finds it first, it costs the most of all, and some of that cost isn't money."

Part 2 · STRIDE, the short version

Meher ma'am drew four boxes: a student's browser, CyberAI Hub's API, the course database, and the gifting feature sitting between them. "We walk through this using something called STRIDE," she said. "Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Six questions, one per letter, asked of every arrow on this diagram."

They went through it together, out loud. Could someone spoof being a different student while gifting? Could the gift amount or recipient be tampered with in transit? Could a student deny ever sending a gift, with no record to check? Could the flow leak another student's email or account details? Could someone spam gifts to exhaust the system? And the one that stopped the room: could gifting a course accidentally elevate the receiver's access to something they hadn't paid for or weren't supposed to have?

"That last one," Mahika said slowly, "depends entirely on how the backend checks who's allowed to receive what. Which doesn't exist yet."

"Which is exactly why we're here before it exists," said Meher ma'am.

Part 3 · Sanjeev's sprint board problem

Sanjeev gestures at his sprint board, worried the new security review step will blow his deadline.AI art

Sanjeev joined the call ten minutes in, visibly already thinking about his sprint board. "This is great," he said, in the tone of someone about to say the opposite. "But Course Bundles v2 ships in two weeks. If every feature from now on needs a 45-minute whiteboard session before a single ticket gets picked up, my team's velocity falls off a cliff."

"It won't be every feature, forever," Meher ma'am said. "It's every feature, for now, while we build the habit. And it's 45 minutes against a bug that, found after launch, costs your team a hotfix, a postmortem, and possibly a very bad week for whoever's on call. I'm not asking you to slow down permanently. I'm asking you to spend 45 minutes now so you don't spend four days later."

Part 4 · The security-champions idea

Meher ma'am's actual pitch, the one she'd clearly been building toward, came next: a security-champions program, one volunteer from each engineering team, trained up just enough to run a lightweight version of this same threat-modeling conversation themselves, for the small stuff, without needing Meher ma'am or Mahika in the room every single time.

"Security by design doesn't mean the security team reviews everything forever," she said. "It means the champion isn't us. It's whoever's already closest to the code, trained to ask these same six questions before we ever have to. We only get pulled in for the genuinely hard cases."

Sanjeev considered this for a moment longer than he'd considered anything else that meeting. "...That I could actually sell to my team," he admitted. "Who's volunteering from mine?"

"Utkarsh, probably," said Mahika, before she could stop herself. Across the room, Utkarsh, who'd wandered in for the coffee machine and stayed to listen, raised his mug in resigned agreement.

Part 5 · The fix that cost nothing

By the end of the 45 minutes, the gifting feature had exactly one new requirement added to its design doc, written in Mahika's handwriting: a server-side check, at the moment a gift is accepted, confirming the receiving account doesn't already hold higher access than the gift is meant to grant. No new screens. No new user-facing flow. One backend check, decided before a single line of code existed.

"That's the whole trick," Meher ma'am said, capping her marker. "The fix we just added costs almost nothing right now. The same fix, found in a bug bounty report three months after launch, would've cost a scramble, an apology email, and possibly a very awkward conversation with Legal about what a 'free premium course for everyone who found the bug first' policy should even look like."

Moral of the story

The cheapest bug is the one that's still a diagram. Ask the hard question before the code exists to hide it.

Before you code, before you build,
ask what could break, and how, and whom.
A line drawn early on a board
is cheaper than the fix ignored.

Field notes · the visual anchor

The Course Bundles v2 threat model

FlowStudent A → Gifting feature → Student B's accountTrust boundary crossed here
SSpoofing: could A pretend to be someone else while gifting?Mitigated: gift tied to A's authenticated session
TTampering: could the gift's recipient or item be altered in transit?Mitigated: server re-validates, doesn't trust client input
EElevation: could gifting grant access beyond what was paid for?New fix: server-side access check added before launch

(Full STRIDE walkthrough covers all six letters; this excerpt shows the three that changed the design.)

Try it yourself

Run STRIDE on a feature of your own

Tap each STRIDE question below against a simple feature: a college portal letting students "transfer" a club membership to a friend. See how CyberAI Hub's team would answer each one.

Tap a STRIDE question above to see how it applies.

Security tip

Security by design, in one sentence

Decide what "allowed" means before you decide what "possible" looks like. A wireframe or a product doc is the cheapest place in the entire lifecycle to ask "who shouldn't be able to do this," because at that stage, the answer is still just a sentence, not a rewrite.

Did you know?

Fun facts

"Shift left" is a timeline metaphorIf a project timeline runs left to right, "shifting security left" means moving security work earlier on that line, toward design, away from "right before launch" or "after an incident."
STRIDE is almost 30 years oldMicrosoft security engineers introduced STRIDE in the late 1990s. It's outlived several generations of software methodology precisely because the six questions don't depend on any specific technology.
Security champions are a real, named roleMany companies formally call this exact program "security champions," often with its own budget, training track, and even a small stipend or recognition for the volunteers.
A cost curve, not a guessMultiple industry studies place a bug found at design time as dozens of times cheaper to fix than the same bug found after release. The exact multiplier varies by study, but the direction never does.

Myth or fact?

"Threat modeling needs a security expert in the room every time."

Myth

A full threat model on a complex, high-risk feature benefits from a security specialist. But a lightweight version, the six STRIDE questions, asked honestly, can be run by any trained engineer on their own feature, which is the entire premise behind a security-champions program.

Try this · workshop exercise

Threat-model a feature in ten minutes

You need: a whiteboard, paper, or a shared doc, and a teammate or study partner.

  1. Pick any feature you've used recently, a "forgot password" flow, a food delivery app's "split the bill" option, anything with more than one user involved.
  2. Draw the boxes: who's involved, and what passes between them.
  3. Ask all six STRIDE questions out loud, even the ones that feel silly at first.
  4. For each "yes, that could happen," write one sentence describing the smallest possible fix.
  5. Compare: which STRIDE letter turned up the most surprising answer?

Careers corner

Security champion

Not a full-time security job, but a real, resume-worthy role: an engineer, embedded on a product team, who's had enough training to run lightweight threat models and spot the obvious issues before the security team ever needs to get involved. Often a stepping stone for developers who later move into security full-time, Utkarsh's likely future, whether he admits it yet or not.

Useful to learn: the STRIDE framework, enough comfort with your own team's architecture to draw it from memory, and the confidence to flag a concern to a security team without it feeling like an accusation.

Quiz time

How well did you learn?

Score: 0 / 5

Think and discuss

No wrong answers here

  • Sanjeev worried about velocity. Meher ma'am argued the real cost comparison was 45 minutes now versus days later. Do you find that argument convincing? What would make it less convincing?
  • Why might a security-champions program work better long-term than the security team reviewing every single feature forever?
  • The actual fix in this chapter was "one backend check," decided before any code existed. Why is that kind of fix so much cheaper than the same fix added after launch?
  • Think of the STRIDE letter that felt hardest to answer for the "transfer a club membership" example. Why that one?

Be curious

Ask a mentor or hiring manager

Does your team do any kind of design review before building a feature? Has a security concern ever changed a feature's design before it shipped, where you work or study? Would you want to be a security champion on your team? Why or why not? How does your organisation balance shipping speed against review steps like this one?

Word bank

New words from this chapter

Secure SDLC: building security checks into every stage of the software development lifecycle, not bolting them on at the end.
Threat modeling: systematically asking what could go wrong with a system, and for whom, before or while it's built.
STRIDE: a six-question framework (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) for threat modeling.
Security champion: a team member, not on the security team, trained to run lightweight security checks on their own team's work.

For teachers and parents: this chapter fits two sessions. Session 1: read Parts 1–5 aloud, walk through the threat-model diagram together. Session 2: the STRIDE interactive, the workshop activity, and the quiz. The key ideas: security is cheapest early (shift left), STRIDE gives six concrete questions to ask of any design, and a security-champions model scales a small team's expertise without reviewing everything centrally forever. All chapter illustrations are AI-generated scene art (pending for this draft); the threat-model diagram is built by hand.