Lab 03 — Security Roadmap Prioritizer

Difficulty: 3/5 | Runs locally: yes

Pairs with the Phase 12 WARMUP Chapters 4–5 (risk framing & prioritization, the security roadmap) and the HITCHHIKERS-GUIDE ("Roadmap Construction"). The capstone lab of the curriculum.

Why This Lab Exists (Purpose & Goal)

A senior security engineer is judged not by how many problems they can find, but by whether they fix the right ones in the right order — and can defend the sequence to leadership. A roadmap is an investment thesis, not a backlog. The goal of this lab is to build the prioritizer that ranks security initiatives by the factors that actually matter, and that rejects the proposals that aren't real plans.

The Concept, In the Weeds

The prioritizer ranks initiatives across several axes, and the combination is the staff-level insight:

risk reduction · breadth · dependency enablement · effort · adoption cost · evidence quality

The decisive, non-obvious moves:

  • Leverage beats severity. The prioritizer compares shared foundations (authorization, logging, isolation) with isolated tool purchases — and a paved-road foundation that removes a bug class across every team usually beats a point fix for a single high-severity issue. This is the difference between fixing the same bug repeatedly and eliminating it everywhere (Phase 03 paved roads, Phase 08 variant analysis, at program scale).
  • Adoption is a first-class factor. A control nobody adopts reduces zero risk. Adoption cost and breadth determine whether an initiative actually changes outcomes.
  • Reject non-plans. Initiatives without owners or measurable outcomes are rejected — because an unowned initiative doesn't happen, and one without a measure can't be shown to have worked. A roadmap item needs an owner, a measurable outcome (leading and lagging), and an adoption strategy.

The deeper idea: you are translating a pile of technical findings into a sequenced investment plan a non-security leader can fund, justified by consequence × exposure × leverage — not by raw severity or count.

Why This Matters for Protecting the Company

A security team has finite capacity and an infinite list of things that could be improved. What protects the company is spending that capacity where it reduces the most risk per unit effort — and being able to defend that allocation to executives who control the budget. A roadmap that prioritizes high-leverage foundations, assigns ownership, and defines how success will be measured is how a security function turns effort into outcomes the business can see and fund. The opposite — a backlog of unranked, unowned, unmeasured items, or a pile of tools nobody adopts — is how security programs burn budget without reducing risk. This lab is the capstone because prioritization under constraint is the essence of the staff/principal role.

Build It

Implement the prioritizer: rank initiatives by risk reduction, breadth, dependency enablement, effort, adoption cost, and evidence quality; reject initiatives without owners or measurable outcomes; compare shared foundations with isolated tool purchases.

LAB_MODULE=solution pytest -q

Validation — What You Should Be Able to Do Now

  • Prioritize cross-domain initiatives by consequence × exposure × leverage and justify the sequence.
  • Explain why a high-leverage paved-road foundation often beats a higher-severity point fix.
  • Reject a "roadmap" that lacks owners and measurable (leading + lagging) outcomes, and explain why adoption is a first-class factor.

The Broader Perspective

This lab is where the entire curriculum converges into judgment. Every prior phase gave you a capability; this one is about deploying capabilities wisely under real constraints — choosing what to do, what to decline, and in what order, then defending it. That is the defining skill of senior security engineering: not knowing more, but exercising better judgment and creating more leverage with what you know. The mindset — measure leverage, sequence by dependency, assign ownership, define how you'll know it worked, and make the secure path the easy path — is what lets one engineer reduce risk across an entire organization rather than fixing one bug at a time. You have spent twelve phases becoming capable; this lab is about becoming effective, which is what actually protects the company and its assets.

Interview Angle

  • "Which three risks would you address first, and why?" — Rank by consequence × exposure × leverage, not CVSS; justify the sequence and what you defer; favor foundations that remove a bug class across teams over point fixes.
  • "How would you measure whether your roadmap changed engineering outcomes?" — Leading + lagging measures tied to engineering behavior (paved-road adoption %, MTTR; recurrence of fixed bug classes, incident frequency, audit findings) — not vanity vulnerability counts.

Extension (Stretch)

Produce a 12-month roadmap with owners, dependencies, cost ranges, adoption strategy, and leading/lagging measures, plus a one-page executive memo presenting three investment options and a recommendation (Phase 12 HITCHHIKERS worked examples).

References

  • Phase 12 WARMUP Chapters 4–5; FAIR (quantitative risk); NIST CSF; Will Larson, Staff Engineer.