Storybooks › Cybersecurity for Juniors, Book 3 › Chapter 1

Mahika, nervous and excited, stands outside CyberAI Hub's glass office entrance on her first morning, fresh visitor badge in hand.AI art

Cybersecurity for Juniors · Book 3 · Chapter 1

Welcome to the Blast Radius

Big idea: know your blast radius before something breaks itFreshers, freshers-at-work & career switchers
Previously, in Cybersecurity for Juniors: Mahika survived orientation week scams, a fake internship offer, a leaking GitHub repo, and a ransomware email to the Placement Cell. In her final placement interview, she answered a question about the CIA triad, confidentiality, integrity, availability, and walked out with an offer letter. New to the story? That's all you need. Everything else, you'll meet again here.

Part 1 · Badge number 2217

The badge machine printed Mahika's photo slightly too dark and her name slightly too small, and she still found herself staring at it for a full ten seconds before clipping it to her collar. Mahika Rao, Junior Application Security Engineer, CyberAI Hub. Six months ago she'd been answering a CIA-triad question in a placement interview with her heart hammering. Today her heart was hammering for an entirely new reason: she had absolutely no idea what her first day actually involved.

CyberAI Hub's Bengaluru office didn't look like a bank or a government building, the two places Mahika had privately imagined "security job" meaning. It looked like any other fast-growing tech company, open desks, a wall of sticky notes nobody had the heart to clear, and a surprising number of people wearing company hoodies despite the Bengaluru heat.

A woman in a simple kurta, hair tied back, laptop already open before she'd even sat down, waved her over without looking up from her screen. "Mahika? I'm Meher. I'll be dropping a lot on you today, so get a coffee first. Seriously."

Part 2 · A company that teaches the thing it has to actually do

Over coffee, Meher ma'am laid out what CyberAI Hub actually was: an EdTech platform that taught cybersecurity and AI security to students and working professionals, courses, labs, certificates, the whole thing. "Which means," she said, "we are, structurally, the worst possible company to get hacked. Imagine the headline. 'Security Course Platform Breached.' We would never recover from the jokes, let alone the damage."

She pulled up a single diagram on the shared screen, one Mahika would end up redrawing in her own notes a dozen times over the coming months. Application Security sat at the centre. Around it, four other neighbourhoods, Cloud, DevSecOps, Infrastructure and Network, each connected back to the centre by a line. A fifth neighbourhood, added more recently than the rest, sat slightly apart: AI and Agentic Security, for the platform's newest feature, an AI tutor that helped students navigate their courses.

"Everything you'll learn this year touches this map somewhere," Meher ma'am said. "Today's just the tour."

Part 3 · Utkarsh and the pipeline that never sleeps

Utkarsh shows Mahika and Meher ma'am the CI/CD pipeline dashboard on a wall-mounted monitor.AI art

The platform tour's second stop was Utkarsh's desk, laptop open to a dashboard that refreshed every few seconds. "This ships code to production like, nine, ten times a day," he said, not looking especially proud or especially worried about it, just stating a fact he'd long since made peace with. "Course content, the lab sandboxes students run exercises in, the platform itself. All through here."

"And security fits into that... how?" Mahika asked, already picturing a human reviewing every single deploy, which even she knew couldn't be right at this speed.

Utkarsh grinned for the first time since she'd walked up. "It doesn't fit in. It's built in, or it's supposed to be. We'll get to exactly how much of that is actually true in a few weeks. Spoiler: less than the dashboard makes it look."

Part 4 · Shruti, six months behind her own plan

At lunch, Mahika found the one other new face in the building eating alone with a notebook open beside her tray, dense handwriting, underlined headers, the look of someone taking very serious notes on her own first day too.

"Shruti," the woman said, sliding over a chair without being asked. "Five years in QA, then I transferred into security the same week you got hired, apparently. I thought testing software would translate. It's translating less than I expected."

"How so?"

"QA asks 'does this break the way it's supposed to.' Security asks 'does this break in a way nobody planned for, and can someone make it happen on purpose.' Different question. I keep forgetting that." Shruti said it lightly, but Mahika recognised the undertone immediately, it was the exact feeling she'd had reading her first bug bounty writeup back at TEC.

Part 5 · Sanjeev's one real question

Sanjeev, arms crossed but not unfriendly, questions Meher ma'am about security review timelines near a sprint-planning whiteboard.AI art

The last stop was supposed to be a quick introduction to Sanjeev, the engineering lead for the course-platform team, but he had one question ready before Meher ma'am had finished saying Mahika's name. "Is she going to be the one blocking my releases now?"

Meher ma'am didn't flinch. "She's going to be the one telling you what you're shipping, before it ships, not after someone outside this building finds out first. Those aren't the same thing, and only one of them is a choice you still get to make."

Sanjeev considered this, then shrugged, the universal gesture of a man with four more meetings before lunch. "Fine. Just don't be the kind of blocker who shows up with no timeline."

"I'll hold you to the same thing," Mahika said, surprising herself. Sanjeev actually smiled at that.

Part 6 · The blast radius question

Back at her new desk, Meher ma'am posed the question that would end Mahika's first day: "Say our AI tutor's lab sandbox, the container a student's exercise runs inside, gets compromised somehow. What else does that attacker now reach? What's the blast radius?"

Mahika thought about the map from that morning. "The container itself. Whatever's mounted into it. If it can reach the internal network, maybe more than that. If it shares credentials with anything else..." she trailed off, realising she didn't actually know the answer, only the shape of the question.

"Good," said Meher ma'am. "That not-knowing is accurate. You'll spend this whole year finding out exactly how far each blast radius actually reaches, chapter by chapter, system by system. Today you just need to know the question exists before you ever touch a system you don't yet understand."

Moral of the story

Before you touch any system, ask how far trouble would travel if something inside it went wrong.

Before you build, before you ship,
ask how far the damage trips.
A map drawn early, understood,
stops small mistakes from spreading wide.

Field notes · the visual anchor

CyberAI Hub's security map

This is the diagram Meher ma'am drew on day one. It comes back, re-annotated, in every chapter from here to the very last one.

Application SecurityCode, authentication, access control, APIs, secrets. The centre of the map.
Cloud SecurityStorage, IAM roles, the shared responsibility model.

↕ connected to the centre, and to each other ↕

DevSecOpsCI/CD pipelines, scanning, the supply chain that ships code.
Infrastructure & NetworkServers, containers, patching, the wires and walls around everything.
AI & Agentic Security
Newest neighbourhood: the AI tutor feature, and anything that can act on its own.

Try it yourself

Which neighbourhood owns this problem?

Tap each real CyberAI Hub problem below to see which part of the map it belongs to, and why more than one neighbourhood sometimes shares the blame.

Tap a problem above to see where it lives on the map.

Try it on a computer · optional

Sketching a blast radius in plain text

# a toy model: what can this component reach?
reaches = {
    "lab_sandbox_container": ["internal_api_gateway"],
    "internal_api_gateway": ["user_db", "course_content_db"],
    "user_db": [],
    "course_content_db": [],
}

def blast_radius(start, graph):
    seen, stack = set(), [start]
    while stack:
        node = stack.pop()
        if node in seen: continue
        seen.add(node)
        stack.extend(graph.get(node, []))
    return seen

print(blast_radius("lab_sandbox_container", reaches))

{'lab_sandbox_container', 'internal_api_gateway', 'user_db', 'course_content_db'}

Run this in any free online Python editor. A compromised sandbox container that can reach the internal API gateway, which can reach two databases, has a blast radius of four things, not one. Try removing the edge from lab_sandbox_container to internal_api_gateway and watch the blast radius shrink, that single missing connection is what network segmentation (Chapter 11) is actually for.

Security tip

Four questions for any new system you meet

What can this touch directly? What can those things touch in turn? What's the smallest version of this that would still do its job, since smaller surfaces mean smaller blast radii? And who else already knows the answers, because someone usually does, and asking them beats guessing.

Did you know?

Fun facts

The term is older than computers"Blast radius" comes from explosives and military planning, how far damage spreads from a single detonation. Security borrowed it because the shape of the problem, damage spreading outward from one point, is identical.
Least privilege is the oldest fixThe core idea behind shrinking a blast radius, give each part only the access it strictly needs, dates back to 1970s mainframe security research, decades before cloud computing existed.
Big companies draw this exact mapMost mature security teams keep a living architecture diagram much like CyberAI Hub's, updated as systems change. The map isn't decoration, it's a tool people actually use during incidents.
AI agents widen the map, they don't replace itEvery new AI or agentic feature still sits on top of application, cloud, and network fundamentals. Chapter 15 returns to exactly why those fundamentals don't become optional just because the system can act on its own.

Myth or fact?

"Security engineers mainly write exploit code."

Myth

Most of a junior AppSec engineer's week looks like Mahika's first day: diagrams, questions, conversations with DevOps and engineering leads, and a lot of reading other people's code and systems closely. Exploit-writing is a real skill some roles use (Chapter 16's red team, for instance), but it's a small slice of the actual job, not the whole of it.

Try this · workshop exercise

Map your own blast radius

You need: paper, a pen, and a system you actually use, an app, a college portal, a home wifi setup, anything with more than one moving part.

  1. Draw a box for the system's "front door", the part a user touches directly.
  2. Draw a box for everything that front door can reach behind the scenes, a database, another service, a file store.
  3. Draw arrows from each box to whatever it can reach in turn.
  4. Circle the smallest change you could make to remove just one arrow, without breaking the system's actual job.
  5. With a study partner or colleague: compare maps. Did you each draw the same blast radius for a system you both use?

Careers corner

Junior Application Security Engineer

Mahika's actual title. The role sits closest to developers of any security specialty, reviewing code and designs, running or reading scan results, and translating "this is a vulnerability" into "here's the one-line fix" in a way an engineer under deadline pressure can actually act on.

Useful to learn: at least one programming language well enough to read unfamiliar code quickly, the OWASP Top 10 as a starting vocabulary, and the soft skill this chapter was really about, asking a system's owner good questions before assuming you already know the answers.

Quiz time

How well did you learn?

Score: 0 / 5

Think and discuss

No wrong answers here

  • Sanjeev worried Mahika would "block releases." Meher ma'am reframed that as "telling you before it ships, not after." What's the difference between those two framings in practice?
  • Shruti said QA and security ask different questions about the same system. Can you think of another job, besides QA, whose instincts would need to shift the same way moving into security?
  • Why might a company that teaches cybersecurity be especially motivated, or especially embarrassed, to get its own security right?
  • Look at the five-neighbourhood map. Which neighbourhood do you already know the most about? Which one is totally new to you?

Be curious

Ask a mentor or hiring manager

What does "blast radius" mean on a system you actually work on? How does your team decide how much access something new gets by default? What's a time a small, contained mistake almost became a big one? How do security and engineering teams usually resolve disagreements about timelines?

Word bank

New words from this chapter

Blast radius: how far the impact of a compromise or mistake can spread from its starting point.
Attack surface: everything about a system that could possibly be attacked or misused.
Least privilege: giving a person or system only the access it strictly needs, nothing more.
Shared responsibility model: the idea, especially in cloud computing, that security is split between a provider and its customer, not owned entirely by either.

For teachers and parents: this chapter fits two sessions. Session 1: read Parts 1–6 aloud, explore the security-domains map and the "which neighbourhood owns this" interactive together. Session 2: the code corner (optional, can be skipped for non-coding readers), the workshop activity, and the quiz. The key ideas: every system has a blast radius, shrinking it (least privilege) is a core security habit, and security roles are mostly about asking sharp questions early, not writing exploits. All chapter illustrations are AI-generated scene art (pending for this draft); the domain map and picker are built by hand.