Module 2 · Secure SDLC
Module 2
Secure SDLC
How security work fits into a development process that wasn't built for it.
TODO DOING DONE 🔒 SEC
Cover
Your journey · Program map
Your journey so far
RoleM2ProcessRisksFindSupplySecretsConfigRespondMobile
9 modules. One toolkit. You are at Module 2.
Context
Your toolkit · So far
What you already have
Modules 1–1
M1
You understand WHY the Champion role exists
Broken perimeter model, onboarding economics, people-process-technology gap
M1
The role is a bridge, not a replacement
Champions complement the security team — they don't replace it
M1
Golden rule: don't disrupt the dev process
Security that blocks releases gets overridden. Every time.
M1
You've committed to first-week actions
Identify the Champion, start a security channel, normalize the conversation
Context
Module 2 · From WHY to HOW
From WHY to HOW
SEC
How do you fit security work into a sprint that's already full?
Module 1 told you why the Champion exists. This module answers the operational question: how do you actually do it without disrupting the team?
You'll leave with three tools that make it work:
1
Taxonomy for requirements
Security stories as concrete and plannable as feature stories
2
Method for visibility
Security work on the board where product can see it — labels, columns, status
3
Translate CVE → dollars
Frame risk in the only language that gets budget, not blank stares
Context
Act 1 · Foundations
What "Secure SDLC" actually changes
A team running an SDLC already has the structure: idea, design, build, test, release, operate. A Secure SDLC keeps that same structure and adds a thin layer of security practice inside each phase — security reviews during design, automated scanning during build, configuration checks at deployment.
where security work shows up
🛡
01
Plan
🛡
02
Design
🛡
03
Build
🛡
04
Test
🛡
05
Release
Security work lives inside every phase, not in a separate track alongside.
The change is mostly in timing. Without these practices, problems show up after release, when fixing them is expensive. With them, problems are caught earlier in the lifecycle, when a fix is still a small change to the design or the code.
05 / 38 · Foundations
Act 1 · Foundations
Pick a framework that gets out of your way
Several mature standards exist. NIST SSDF is excellent — focused on people, supply chain, proactive controls, and reactive response. Worth a deep read if you face regulated-industry audits.
For starting out, Microsoft SDL is the lightest option that still covers the ground. Ten practices grouped into three categories.
Governance
1
Provide training
2
Define metrics & compliance
Development
3
Define security requirements
4
Threat modeling
5
Use approved tools
6
Deprecate unsafe functions
7
Static & dynamic analysis
Operations
8
Penetration testing
9
Incident response plan
10
Validated hosting / runtime
highlighted = where a Champion contributes most
The first one — define security requirements — is where this module spends most of its time.
06 / 38 · Foundations
Act 1 · Foundations
The first practice: define security requirements
"Establish and define security requirements" sounds like work for analysts and product owners. In practice, it's the most leveraged work a Champion does in any sprint.
Everything downstream — what you test, what you review, where you spend your security budget — depends on getting the requirements right.
A vague requirement produces vague work and zero accountability. A precise one produces a backlog item, a test, and a measurable outcome.
Vague: "The application must be secure."

Precise: "Transactions must be encrypted in transit using TLS 1.3 or higher, with key rotation every 90 days, validated by an automated check in CI."

The hour you spend making a requirement precise saves a week of arguing in code review.
07 / 38 · Foundations
Pause · The principle
“
“
The principle, in one line
Security work that happens inside every sprint looks like washing your hands before each meal.
Security work belongs inside ordinary work, woven into how the team builds — not in a separate process running alongside it.
Your role as a Champion: ensure security requirements are at the right layer, visible in the tracker, and framed in language product can act on. You don't own all the security work — you own making it plannable.
08 / 38 · Punch line
Knowledge check · classifying a requirement
Knowledge check
Test your instinct
A team writes "all dependencies must be up to date and have no known vulnerabilities." What kind of security requirement is this?
D. This is a secure development requirement. It doesn't add a security feature to the product (functional security), and it doesn't define the secure behavior of a business function (secure functional). It defines how the team must build — what hygiene the development process itself maintains.
09 / 38 · Quiz
Tool · Taxonomy of requirements
Tool
Four kinds of security requirement
The taxonomy that turns "we need to be secure" into a backlog you can actually work.
Business
▼
Secure functional
▼
Functional security
▼
Dev & Ops
10 / 38 · Tool
Act 2 · The Taxonomy · 1 of 3
What the product does, and how it does it securely
The taxonomy has four layers. We'll walk through them in pairs.
Layer 1 — Business / functional. What does the product do? Process payments. Match riders to drivers. Run a multiplayer game. Nobody starts a project with authentication; they start with a business goal.
Layer 2 — Secure functional. How does the product do that thing securely? "Transactions must be encrypted." "A player profile is only accessible to its owner." Security stops being a separate concern and starts being part of the product's behavior.
These first two layers are the product itself. The next two are the support structure that makes them possible.
11 / 38 · Taxonomy
Act 2 · The Taxonomy · 2 of 3
The supporting features, and the way you build
Layer 3 — Functional security. What security features must exist to make Layer 2 possible? You can't encrypt transactions without keys. Keys need derivation, rotation, escrow, secure storage. Authentication, authorization, audit logging — all live at this layer.
Layer 4 — Secure development & operations. How do we build, ship, and run all of the above without breaking it? Trusted supply chain. Configuration management. Separation of duties for DevOps access. Disaster recovery procedures.
Layer 3 is "what security features the product contains." Layer 4 is "what hygiene the team and the pipeline maintain." Both are easy to confuse, and both matter.
12 / 38 · Taxonomy
Act 2 · The Taxonomy · 3 of 3
Why the order is not optional
Each layer depends on the one above it. Skip a layer and the layers below have nothing to attach to.
Always start at the top. Work top-down to design. Reason bottom-up to verify.
If you start at Layer 3 — building authentication, key management, an audit log — before the business has decided what "secured account access" actually means, you'll deliver perfectly correct security infrastructure for a product nobody asked for.
A team builds a polished OAuth flow with refresh tokens, scopes, and audit logging — beautiful work at Layer 3. Then the business says "actually we needed SSO with the parent company, not standalone OAuth." Or: "we needed magic-link login because half our users can't remember passwords." The security work was real. The product was wrong. This is the most common failure mode in security-heavy teams, and it's avoided entirely by writing Layer 1 and Layer 2 down first, with the business in the room.
13 / 38 · Taxonomy
Time to think · Cascade
designing
top → down
01
Business — Process payments
What the product does
02
Secure functional — Encrypt transactions
How it behaves securely
03
Functional security — Manage keys
Security features required
04
Operations — Secure deployment
How we ship and run it
your team's reality

Design decisions cascade down. Each layer constrains the one below it.

Notice — the architect stays outside. They don't live on any floor. They reason about all four together.
Time to think and reflect
Knowledge check · pick the layer
Knowledge check
A team needs to add audit logging for every payment transaction. Which layer does this requirement belong to?
C — Functional security. Audit logging is a security feature the product must contain. It's not the business goal (Layer 1), nor the secure behavior of payments (Layer 2 — "transactions must be tamper-evident"), nor a build-time hygiene practice (Layer 4). It's a feature you build into the product, alongside authentication and authorization.
15 / 38 · Quiz
Act 3 · Sprint integration
Two ways to fit security into your sprints
There are two common ways teams fit security work into Agile. Both work; they trade off against each other on metrics and on how product owners react to them.
i
Approach 1
Security as part of every sprint
Reserve 10–15% of capacity in each sprint for security tasks. They sit alongside features and bug fixes in the same backlog.
Builds a steady habit; security stays close to the product.
Metrics are harder to extract since security work is mixed in.
i
Approach 2
Separate security sprints
Whole iterations dedicated to coverage, fixes, and testing. Reporting is straightforward.
Clean metrics; easy to show what was delivered.
Hard sell to product — sprints that ship no visible features.
16 / 38 · Sprint
Act 3 · Sprint integration
Make security work visible in the tools you already use
When security work happens in side-channels — a Slack thread that says "approved", a quick word in standup — it disappears the moment the conversation scrolls. The next person who touches the ticket has no idea security ever weighed in.
The fix is mechanical. Use labels in your issue tracker. Most teams already have Jira, GitHub, GitLab, or Linear, and all of them support tags. Add a small fixed vocabulary: requires-security-review, security-tested, retest. Apply consistently.
The principle
If it's not visible, it doesn't exist.
A security review that happened in a DM didn't happen for anyone except the two people in that DM. Labels put the signal where everyone who later touches the work can see it.
17 / 38 · Sprint
Act 3 · Sprint integration
Which labels actually stick
Most label systems die because they're built by committee. A document defines twenty perfect tags. Three months later, two are in use and eighteen sit ignored.
Labels that survive share three traits — short, visually distinct, and (counter-intuitively) slightly playful. Teams reach for tags that feel human; they avoid tags that feel like compliance.
18 / 38 · Sprint
Knowledge check · visibility
Knowledge check
A team's security reviewer messages "approved" on every ticket they review, in a private DM. What's the underlying problem?
B. The fix isn't more detail or more secrecy — it's putting the signal where the team will see it. A label and a one-line comment on the ticket itself give every future reader the same context the original team had. DM-based reviews are invisible to anyone who joins the project after the conversation.
20 / 38 · Quiz
Act 3 · Sprint integration · examples
Examples — same purpose, different feel
Each row pairs a formal label a security policy might prescribe with a playful alternative teams have actually adopted. Hover any tag for what it's used for.
Formal · prescribed
requires-security-review
security-tested
elevated-risk
retest-required
compliance-impact
Playful · adopted in practice
🔍 peek-please
✅ green-lit
🌶 spicy
👀 eyes-on
🐉 here-be-dragons
!
Before introducing playful labels, agree on them with the team. Tags only work if everyone applies them the same way — pick three to five together, write a one-line definition for each, and pin it where new joiners can find it.
19 / 38 · Examples
Act 3 · Sprint integration
When one sprint isn't enough
Adding a security label is a five-minute change. Replacing your authentication system with SSO is a multi-month engineering project. They can't be planned the same way.
For larger work, treat it as a multi-sprint security story with the same structure as any feature epic. Break it into phases. Define what "done" looks like at each phase. Ask product to allocate capacity rather than promise it.
The big trap is writing a giant security epic and then leaving it on the backlog forever, because it never beats a feature on priority.
21 / 38 · Sprint
Act 3 · Sprint integration
Two ways out of the backlog graveyard
The trick to keeping a multi-sprint security story alive is to make it look more like product work and less like an indefinite cleanup task.
1 · Slice for value. The first slice should deliver something the business can show — a single high-risk service migrated to SSO, not "the whole system, eventually." Visible progress beats theoretical completeness.
2 · Tie it to a deadline. A regulatory milestone, an audit window, a vendor cutoff. Nothing moves a security epic faster than a date the company can't move.
A common failure: the team writes the epic, lists every sub-task, estimates 8–10 sprints, and then never picks it up because every individual sprint always has something more urgent. Three months later, leadership asks why nothing has shipped, and the team can point at every sprint's commitment and say "we kept the product moving." Both things are true. The security work just never landed in a sprint.
22 / 38 · Sprint
Time to think · Security inside the rhythm
🔒
P
Plan
🔒
D
Design
🔒
B
Build
🔒
T
Test
🔒
R
Release

Five phases. Five places security can live without a separate ceremony.

Notice — the shield appears at every stage, not before, not after. Inside.
Time to think and reflect
Act 4 · Talking to the business
Talk to business in money, not in CVEs
You'll never have unlimited budget. So security work becomes prioritization, and prioritization is a conversation with the business rather than a unilateral decision by security.
The reason most security pitches fail with executives isn't that the executives don't care. It's that security people show up speaking the wrong language. CVE counts and risk scores don't move budget. Two things do.
Risk = Probability × Impact — expressed in dollars.
Threat modeling tells you the probability side. Knowing the threat landscape — what actually gets attacked, what your peers got breached for last quarter — tells you the impact side. Multiply them. Now you have a number an executive can act on.
24 / 38 · Business
Act 4 · Talking to the business
The Champion's most underrated skill
Translating a technical concern into a sentence that ends in a dollar figure isn't a presentation skill. It's a habit you build by doing it weekly. The framing changes the conversation completely.
"This dependency is unpatched, CVE-2024-XXXX, CVSS 9.8."
Meaningless to a CFO.
"This dependency handles our payment routing. If exploited, attackers can redirect transactions. Probability: medium — there's a public exploit and our service is internet-facing. Impact: a single day of redirected payments at our volume is roughly $400K, plus regulatory penalties. Recommended action: upgrade this sprint, $0 marginal cost."
The vulnerability is identical. The framing is everything.
"We're storing session tokens in localStorage. That's an XSS risk, severity high."
Technically correct. Practically useless in a planning meeting.
"Our session tokens are in localStorage — any XSS vulnerability gives an attacker full account access. We have 45K active users; a single reflected XSS in our search page (found in last quarter's pentest) would expose all active sessions. Estimated incident cost: $150K in response, notification, and credential reset — plus reputational damage we can't price. Fix: move to httpOnly cookies, 2-day migration, no user-facing changes."
Same pattern: name the asset, quantify the exposure, price the impact, propose the fix with cost. Works for any domain.
When security stops being a cost center and starts being a line item that competes — and wins — on its own merits, that's the shift. You make it by doing this translation, every time, until the team picks it up too.
25 / 38 · Business
Knowledge check · framing risk
Knowledge check
Why does framing security risk in dollar terms matter more than framing it in CVE severity?
B. Executives aren't dismissing CVSS scores; they don't have a way to act on them. A budget allocation request is a decision they make every week. Dollar framing puts your security work into the same conversation as headcount, infrastructure, and feature investment.
26 / 38 · Quiz
Tool · Threat modeling
Tool
Threat modeling, made small
A short, repeatable practice for asking "what could go wrong?" before a system goes wrong in production.
?
27 / 38 · Tool
Act 5 · Threat modeling
What threat modeling actually is
Threat modeling has a reputation for being a heavy practice — whiteboards, formal frameworks, multi-day workshops. Those exist, and at large scale they're useful, but the practice itself is much smaller.
At its core, threat modeling is a habit of asking three questions during design:
1. What are we building?  A diagram of the components and how data flows between them.
2. What can go wrong?  A walk through the diagram, looking for points an attacker could exploit.
3. What are we going to do about it?  A short list of the highest-priority risks, added to the backlog.
Done this way, threat modeling fits inside a normal design conversation. The next slides cover the trickiest part — recognizing where to look — and a checklist for the second question.
28 / 38 · Threat modeling
Act 5 · Threat modeling · trust boundary
Where data changes hands — that's where to look
A trust boundary is any place where data moves from one level of trust to another. A form submission from a user crosses one. An API call to a third-party service crosses one. A queue passing messages between services with different roles crosses one.
When you walk a system looking for places to add security checks, the boundaries are where you spend most of the attention. Code inside a single trust zone usually trusts itself by convention — the work happens at the edges.
a simple web app · 3 zones, 2 boundaries
👤
User
untrusted
🌐
Web app
semi-trusted
🗄
Database
trusted
boundary 1
boundary 2
✓
✓
At boundary 1: validate & authenticate the user's input.
At boundary 2: authorize the action, check ownership, and sanitize input before the DB query — the database doesn't blindly trust the app either.
29 / 38 · Threat modeling
Act 5 · Threat modeling · trust boundary
When a check is missing at a boundary
A skipped boundary becomes a class of vulnerability
Same app as before. Boundary 1 is missing. Watch what an attacker gets.
👤
Attacker
untrusted
🌐
Web app
semi-trusted
🗄
Database
trusted
⚠ compromised
no check
boundary 2
⚠ bypassed
✓
too late
⚐ stolen by attacker
user@ex.com password_hash admin_token
⚠ incident
SQL injection executed at boundary 1 all users.email exfiltrated password hashes & admin tokens leaked attacker now holds valid credentials
30 / 38 · Threat modeling
Act 5 · STRIDE · overview
Six categories that catch most software security risks
STRIDE is the standard checklist for the "what can go wrong" question in threat modeling. Each letter is a category of threat to look for at every component of your system.
i
S
SPOOFING
i
T
TAMPERING
i
R
REPUDIATION
i
I
INFO LEAK
i
D
DoS
i
E
ELEVATION
Hover any ⓘ for the definition. The next two slides walk through them in detail.
31 / 38 · STRIDE overview
Act 5 · STRIDE · 1 of 2
The first three: spoofing, tampering, repudiation
The first three categories cover identity and integrity — who's acting, whether the data they touch is honest, and whether their actions can be traced.
S
Spoofing
Can someone pretend to be a different user, service, or system?
T
Tampering
Can data be modified — in transit, at rest, or in flight between services?
R
Repudiation
Can a user deny doing something they actually did, because no record exists?
The remaining three — Information disclosure, Denial of service, Elevation of privilege — are on the next slide.
32 / 38 · STRIDE
Act 5 · STRIDE · 2 of 2
The remaining three: leak, downtime, escalation
The last three categories cover access and availability — what data leaks out, whether the system stays up, and whether anyone can climb where they shouldn't.
I
Information disclosure
Can data leak to people or systems that shouldn't see it?
D
Denial of service
Can the system be made unavailable, slowed down, or starved of resources?
E
Elevation of privilege
Can a low-privilege user reach higher-privilege actions or data?
Run STRIDE on each component in your diagram. You won't catch every threat, but you'll catch the obvious ones — and that's most of them.
STRIDE catches most software threats, but it wasn't designed for everything. Supply chain attacks (a compromised dependency), business logic flaws (a valid user abusing a legitimate feature), and privacy-specific threats (data minimization, consent) need complementary approaches. You'll cover supply chain in Module 5 and privacy considerations alongside access control in Module 7.
33 / 38 · STRIDE
Act 5 · Threat modeling · timing
When to threat-model in agile
"Run a full threat model before each release" works in waterfall. It doesn't fit in two-week sprints.
In agile, run threat modeling at three trigger points:
1. New feature with a trust boundary. Anything new that crosses between components, networks, or user roles. Spend 20 minutes.
2. Architecture change. A new service, a new database, a new external integration. Spend 30–45 minutes.
3. After an incident. The post-mortem already has half the threat model. Finish it.
A Champion's job is to flag the trigger — to recognize when a design change deserves the time. The 20-minute version, done at the right moment, is worth more than a two-day workshop done at the wrong one.
34 / 38 · Threat modeling
Knowledge check · pick a STRIDE category
Knowledge check
A user clicks "delete account" but the system can't prove later which account button was clicked or by whom. Which STRIDE category does this represent?
C — Repudiation. The user can deny they took the action because the system has no audit trail to prove otherwise. The fix is the audit logging that Layer 3 (functional security) is supposed to provide. Spoofing would be pretending to be a different user; tampering would be modifying the request mid-flight; information disclosure would be leaking data.
A login API returns 401 Invalid password for existing users but 404 User not found for non-existent accounts. Which STRIDE category?
C — Information disclosure. The different error messages leak whether an account exists. An attacker can enumerate valid usernames before even attempting to break in. The fix: return the same generic error regardless — "Invalid credentials." This is one of the most common real-world information disclosure patterns.
35 / 38 · Quiz
Time to think · Recap
🧱
Layer the requirements
Top to bottom: Business, Secure functional, Functional security, Dev & Ops. Don't skip.
🏷️
Make it visible
Labels in the tracker. A reviewed ticket should look different from an unreviewed one.
💰
Translate to money
CVE × probability × impact = dollars. The only number an executive can act on.

Three habits that make you a Champion operating in the sprint rather than a security person shouting at it.

All three are small enough to start this week. None of them require a budget approval.
Time to think and reflect
Bridge · Into Module 3
What you carry into Module 3
You now have a way to organize security work. The next module is about what to look for.
Module 3 walks the OWASP Top 10 — the ten most common application security risks, ranked by industry data. For each one, you'll see the underlying pattern, why it persists, and what a Champion checks for during code review and design.
The structure you learned here — requirements at the right layer, visibility through labels, dollar framing for risk — is what makes the OWASP list actionable instead of just educational. Without that structure, the Top 10 is a checklist. With it, it's a backlog.
Before you continue, take one slide to commit to what you'll actually do.
37 / 38 · Bridge
Module 2 · Your action pact
⏵ Your next sprint
Don't take all of this — pick what you'll actually do.
Choose 2 or 3 actions to run during your next two-week sprint. Small enough to fit. Concrete enough to verify.
0  /  aim for 2–3 actions
🛡️
Sprint-Ready Champion · committed
+15 XP · Module 2 complete
Sign as
⤓ download your pact as an image  ·  ✎ change which actions you committed to  ·  ↻ reset all module progress
38 / 38 · Action pact