The Security Landscape: Roles, Teams, and Where You Fit

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: “Cybersecurity” is not one job — it is a dozen distinct careers that happen to share a field. Trying to “learn cybersecurity” in general is like trying to “learn medicine” — you eventually specialize. This page maps the territory so you can choose a direction deliberately, and shows how a developer switching in has a specific, real advantage.

Part 1: The Problem

It’s easy to spend months “learning cybersecurity” with no sense of what role it’s all building toward. The field is broad — breaking into systems, defending them, hunting threats, governance, securing AI — and these need different skills and different day-to-day work.

This page gives you the map. It won’t force a final decision today, but it lets you read the rest of the curriculum knowing how each phase serves each path — and at the Phase 5 specialization fork, you’ll choose with eyes open.

Part 2: The Big Split — Red, Blue, and Purple

The most fundamental division in security is offense versus defense.

🔴 Red team — offense. Red teamers think and act like attackers, with authorization, to find weaknesses before real attackers do. Penetration testers, bug bounty hunters, exploit developers. The mindset: “How do I get in?”

🔵 Blue team — defense. Blue teamers build, monitor, and defend systems, and respond when something goes wrong. SOC analysts, incident responders, security engineers, defenders. The mindset: “How do I keep them out, detect them fast, and recover?”

🟣 Purple team — the bridge. Not a separate team so much as a practice: red and blue working together, so offensive findings directly improve defenses in a continuous loop. Increasingly, the best practitioners are “purple” — fluent in both.

   🔴 RED  ───────── 🟣 PURPLE ───────── 🔵 BLUE
   attack            both / bridge        defend
   "how do I         "attack to           "detect, defend,
    get in?"          improve defense"      respond"

This curriculum is deliberately purple. You learn offense (Phases 2–3) and defense (Phase 4) in equal measure, because each makes you better at the other — you can’t defend well against an attack you don’t understand, and you can’t attack thoughtfully without knowing what defenders see.

Part 3: The Main Roles, in Plain Terms

A practical map of common security roles — not exhaustive, but the ones you’ll repeatedly encounter:

You don’t pick today. You absorb the shape of the field, and notice which descriptions make you lean in.

Part 4: The Developer’s Advantage — Why You’re Not Starting From Zero

If you’re coming from software development, you are not a beginner who happens to like security. You hold an edge that many people in security genuinely lack — and several roles specifically reward it.

What you already bring:

• You read and write code. Vast amounts of security work — finding vulnerabilities, reviewing code, writing exploits and tooling — is code work. People without a dev background often struggle here; you won’t.
• You understand how software is actually built. You know how applications, APIs, and databases really fit together — because you’ve built them. That intuition makes finding their flaws far more natural.
• You can automate. From Phase 0.6, scripting is a force multiplier across the whole field, and it’s already in your hands.
• You speak the developers’ language. A defender who can talk to engineers as a peer — and translate findings into fixes — is disproportionately valuable.

The roles that most reward a developer background: Application Security engineer, DevSecOps / cloud security, bug bounty / web pentesting, and the emerging AI security niche — which is largely about securing the AI-powered software that developers are, right now, shipping faster than anyone is securing.

The honest flip side: development is not the whole of security. Networking, infrastructure, the defensive disciplines, the attacker mindset — these still have to be learned, which is exactly why Phases 0, 1, 3, and 4 exist. But you’re starting partway up the mountain, not at the bottom.

Part 5: How This Curriculum Maps to the Roles

Every phase ahead serves these destinations. Seeing the mapping makes the journey purposeful:

   Phase 0–1  →  Foundations + mindset    → EVERY role needs these
   Phase 2    →  Web attacks              → pentest, bug bounty, AppSec
   Phase 3    →  Infra / network attacks  → pentest, red team
   Phase 4    →  Defense                  → SOC, security eng, AppSec, blue
   Phase 5    →  Specialization fork:
                 Track A Bug Bounty       → freelancing / 🔴
                 Track B AppSec           → employment / 🟣
                 Track C Cloud/DevSecOps  → employment / 🟣
   Phase 6    →  AI security              → the emerging niche
   Phase 7    →  Career + freelancing     → turning skill into income

Phases 0–4 are the common core — everyone does them, because offense and defense each require the other. Phase 5 is where you commit to depth. The two questions from this page — do I lean offense or defense? and do I want employment or freelancing? — are exactly what Phase 5’s three tracks answer:

• Lean offense + freelancing → Track A: Bug Bounty Hunter.
• Lean toward securing software, employment → Track B: Application Security Engineer.
• Lean toward cloud/infrastructure, employment, high demand → Track C: Cloud & DevSecOps Security.

And because all three Phase 5 tracks are being written for you, you are not locked in — you go deep on one first, then add the others over time.

Part 6: It’s a Field of Continuous Learning

One honest, defining truth about every security role: the learning never stops. New vulnerabilities, new tools, new attacker techniques, new technologies to secure (AI being the current wave) appear constantly. A technique that’s current today is dated in a few years.

This sounds exhausting; for the right person it’s the appeal. If you enjoy perpetual learning, security rewards it like few fields do. If you wanted a fixed body of knowledge to memorize once, security will frustrate you.

The practical consequence: what you’re really building through this curriculum is not just a fact-set but a learning system — the foundations, the mindset, and the habit of staying current. That’s why the final page, 7.5, is devoted entirely to “staying current and going further.” The curriculum has an end; the learning doesn’t.

📓 Key Terms

🧪 Hands-On Lab

Career-orientation exercises — do them in writing in Notion.

Task 1 — Gut-check red vs blue. Read the Part 2 descriptions again. Which pulls you more — the offensive “how do I get in?” or the defensive “how do I detect and stop them?” There’s no wrong answer, and this curriculum builds both regardless — but noticing your instinct is useful.

Task 2 — Shadow a day. Find a “day in the life” account (blog post or video) for two roles from Part 3 that interest you. Note what the work actually looks like hour to hour. Roles often differ from their imagined version.

Task 3 — Inventory your developer edge. Write down, specifically, the skills your dev background already gives you (languages, frameworks, databases, cloud, scripting). Keep it — Phase 7.3 turns this exact list into a security résumé.

Task 4 — Read three real job postings. Find one posting each for penetration tester, AppSec engineer, and a SOC/security-analyst role. List the skills and certifications each demands. You’ll see heavy overlap (the common core) plus role-specific extras — and you’ll see how directly this curriculum targets them.

Task 5 — Make a provisional pick. Based on everything so far, write down a tentative Phase 5 track (A, B, or C) and one sentence of why. It’s provisional — Phases 2–4 may shift it, and you can do all three eventually — but having a direction makes the core phases feel purposeful.

⚠️ Common Mistakes

• Trying to learn “all of cybersecurity.” The field is too broad to master whole. Build the core, then specialize. Generalist-forever is a slow path.
• Believing offense is the only “real” security. Hacking gets the spotlight, but defensive roles are more numerous, in high demand, and just as skilled. Don’t dismiss blue.
• Undervaluing your developer background. It’s a genuine, uncommon advantage. Some of the field’s best-fitting roles for you exist because of it.
• Picking a specialization too rigidly, too early. Use Phases 2–4 to actually feel what you enjoy. The Phase 5 pick should be informed by experience, not guessed on day one.
• Expecting a finish line. Security is continuous learning by nature. Build the habit, not just the knowledge.

✅ Recap & What’s Next

• “Cybersecurity” is many roles, split fundamentally into red (offense), blue (defense), and purple (both) — and this curriculum is deliberately purple.
• A developer background is a real advantage, especially for AppSec, DevSecOps, web pentesting/bug bounty, and AI security; Phases 0–4 are the common core, and Phase 5’s three tracks let you specialize.
• Security is a field of continuous learning — the lasting goal is a learning system, not a fixed set of facts.

Phase 1 complete. You now hold the entire thinking framework: the law and ethics that keep you professional, what security means (CIA, risk, trade-offs), how to think like an attacker (threat modeling), the crypto that underpins it, the identity machinery attackers target, and a map of the field with your place in it.

Next — Phase 2: Offensive Core — How Web Applications Are Attacked. This is where the hands-on hacking begins in earnest. With your lab built and the rules of engagement firmly internalized, you’ll start finding and exploiting real vulnerability classes — every one of them, later, defended in Phase 4.

📋 Phase 1 — Page Checklist

Tick each page when its reading and its hands-on lab are done.

• [ ] 1.0 — Rules of Engagement: Law, Ethics, and Authorization ← non-negotiable; read before any attack
• [ ] 1.1 — What Security Actually Means: CIA, Risk, and Trade-offs
• [ ] 1.2 — Thinking Like an Attacker: Threat Modeling
• [ ] 1.3 — Cryptography for Practitioners
• [ ] 1.4 — Authentication, Authorization, and Identity
• [ ] 1.5 — The Security Landscape: Roles, Teams, and Where You Fit

Keep growing your two living pages:

• [ ] Master Glossary — append every 📓 Key Terms box above.
• [ ] Tools & Reference Cheatsheet — add tools as they appear.