Best Practices & the Operating Model
Every mechanic on this page already has its own lesson elsewhere in this course: security culture & champions covers why the champions model exists at all, and vulnerability management & triage covers how DefectDojo aggregates, deduplicates, and SLA-tracks a finding once it lands. Neither one answers the harder, less exam-shaped question: does any of that survive a real organization, under real deadline pressure, three quarters in? This page is about running the program for real — an embedded advocate on every team instead of one small group reviewing everything, the sprint-over-sprint numbers that tell you whether the network is actually keeping up, and a routing discipline that decides which findings a product team just fixes and which ones genuinely need the platform team's attention, so that team never becomes the queue the whole org quietly blames for being slow.
A big apartment building can't have one superintendent answer every single request personally — a leaky faucet on floor 9 and a gas leak on floor 3 would both end up in the same line, waiting behind each other. A well-run building trains one resident per floor to handle the small stuff on the spot and know exactly when to call the super instead. The building manager doesn't just count "how many maintenance tickets did we close" — they track how fast small problems get fixed, how many floors actually have a trained resident right now, and whether the super's own time is spent on genuine emergencies or on faucets that never should have reached them. Get all three right and the building runs itself most days. Get any one wrong — an untrained floor, a manager tracking the wrong number, or every request routing straight to the super out of habit — and the super's line is the whole building's bottleneck again.
One operating model, three decisions that decay the same way
☺ Like you're 10: All three practices on this page break the exact same way — quietly, under pressure, the one week nobody's watching — so they need the exact same fix.
Security culture & champions already made the case for why a small central team cannot personally review every pull request across an org with dozens of product teams, and named the model that closes that gap: one embedded, trained champion per team, spending a bounded slice of their time — commonly cited at 10–20% — on triage, translation, and advocacy instead of a second full security review layer. This page assumes that argument is won and asks the operating question instead: what actually keeps a champions network, a metrics dashboard, and a triage route alive past the pilot quarter?
All three share one point of failure. A champion's protected time is a promise a manager makes during planning and quietly reclaims the first time a sprint runs long. A metric is only as honest as the discipline to look at it on a schedule instead of screenshotting it once for a slide. A triage route only holds if people actually use the escalation path for what it's for, instead of routing everything to the platform team "just to be safe" the moment something feels ambiguous. Every one of these degrades the same way: it stays true right up until the moment honoring it is inconvenient, and if nothing specifically notices at that exact moment, the practice becomes theater — a title with no calendar behind it, a dashboard nobody opens, a platform team quietly back to reviewing everything again. See DevSecOps anti-patterns & pitfalls for the mirror image of this page: the specific, observed ways each of the three practices below is seen failing in the wild.
The champions network as a living program, not a title
☺ Like you're 10: Naming someone "the security person" on a team doesn't do anything by itself — what matters is whether they actually get the time, the training, and the authority the title implies.
The definitional case for champions — the reviewer-to-developer ratio problem, the OWASP SAMM and BSIMM references for the model, the 10–20% time-allocation figure — already lives on security culture & champions; go there first if any of that is new. What that page does not cover, and what actually decides whether a champions network is still functioning eighteen months after launch, is three operating questions: how long does someone stay a champion before rotating off, what exactly are they authorized to decide on their own, and what happens the sprint their protected time gets reclaimed?
Rotation term matters more than it looks. A champion who rotates off after one sprint never builds the pattern-recognition that makes the role valuable in the first place — they're still learning where the org's actual risk lives right as they hand it off. A commonly workable term is two to four quarters: long enough to build real fluency with the team's codebase, its scan findings, and its escalation history, short enough that the role doesn't calcify into a permanent unpaid second job that quietly becomes someone's whole identity, and short enough that a healthy number of engineers rotate through it over a few years, spreading security literacy wider than a handful of permanent specialists ever could. Whatever term a program picks, write it down and staff a deliberate handoff — a departing champion briefing their successor on the team's open escalations and known trouble spots — rather than letting the role change hands the way a shared password does, silently and undocumented.
The other operating gap is authority: exactly what can a champion decide alone, and what needs a second signature? A charter that spells this out in writing, agreed by the platform/AppSec team and reviewed with each new champion during onboarding, is what keeps the answer from being re-litigated finding by finding:
# Security Champion Charter — v3, reviewed quarterly
Role: embedded on your home team, not a transfer to the platform
team. You keep your regular engineering assignments.
Protected time: 15% of a sprint, blocked on your calendar as
"Security Champion" — visible to your manager and the platform
team, not an informal understanding.
Term: 3 quarters, then rotate off with a documented handoff to
your successor (open escalations, known trouble spots, any
standing Risk Acceptances your team holds).
You ARE authorized, alone, to:
- Triage new findings in DefectDojo: acknowledge, assign
severity sanity-check, request a False Positive review.
- Mark Low-severity findings False Positive with a documented
reason (no second signature required).
- Answer routine "is this okay to do" questions using the
org's published policy and golden-path docs.
- Facilitate a lightweight threat-modeling session for a new
feature on your own team.
You are NOT authorized, alone, to:
- Approve a Risk Acceptance for a Medium finding or above
(needs the platform/AppSec team's sign-off — see routing).
- Suppress a Critical or High finding for any reason.
- Change a scanner's org-wide ruleset or SLA configuration.
Escalate immediately, same business day, when:
- A finding is Critical severity, or High with a public-facing
reachable path.
- A finding's blast radius crosses more than one team (a shared
base image, a shared library, a shared IdP config).
- You genuinely don't know who owns a finding.
Support you get: a monthly 45-minute guild sync with every other
champion, a dedicated #security-champions channel with a same-day
response SLA from the platform team, and first access to every new
tool or policy before it rolls out org-wide.That charter is doing the same job the SLA table on vulnerability management & triage does for a finding: turning a vague expectation into a specific, checkable promise. A team can audit "did Payments' champion actually get 15% this sprint" exactly the way DefectDojo audits "did this Critical finding get fixed inside 7 days" — and a program that never checks either number is a program that has already decided, without saying so out loud, that the promise doesn't really bind.
The single most common way a champions network dies isn't a bad champion — it's a good one whose protected time gets quietly reclaimed the first time a sprint runs long, and never given back. Nobody announces the cut; a manager just stops blocking the calendar slot for "one busy sprint," the champion stops showing up to the guild sync because they're behind on their actual assignments, and three months later the team's scan coverage has drifted and every finding from that team is landing straight in the platform team's queue with no first pass at all. The fix isn't asking harder — it's tracking the calendar block as a real metric (did this team's champion actually get their 15% this sprint, yes or no) and treating three consecutive misses as an escalation, exactly the way a burned error budget or a missed SLA would be treated anywhere else in this course.
A champions network's leverage isn't knowledge — a motivated developer can learn a scanner's findings in an afternoon. Its leverage is capacity: it turns a fixed, small platform team's attention into something that scales roughly with headcount instead of staying flat while the org grows around it. Every finding a champion resolves locally is capacity the platform team never has to spend — which is exactly why the routing discipline later on this page matters as much as the network itself.
Metrics that actually tell you whether the program is working
☺ Like you're 10: Don't count how many alarms went off — count how fast the ones that mattered got handled, and how many rooms even have a working alarm in the first place.
A raw open-finding count is close to useless on its own, for the same reason vulnerability management & triage warned against comparing "3,000 findings last week to 1,800 this week" without checking whether the scan scope changed in between. Three numbers, tracked the same way sprint over sprint rather than glanced at once, are what actually tell a program whether it's getting healthier: how dense the confirmed risk is relative to the code producing it, how fast a confirmed finding actually gets fixed, and how much of the estate is even being watched in the first place. This is the "Measurement" pillar of CALMS from the very first page of this course, made concrete instead of left as a principle.
| Metric | How to compute it | Healthy sprint-over-sprint signal |
|---|---|---|
| Vulnerability density | Confirmed, Active findings ÷ thousand lines of code (KLOC), or ÷ service for a polyglot portfolio where KLOC comparisons across languages get unreliable fast | Flat or falling while feature velocity holds steady — falling because fewer new bugs are introduced, not because scan scope quietly shrank |
| MTTR by severity | Mean days from Active → Mitigated in DefectDojo, bucketed Critical/High/Medium/Low, rolling 90-day window | Trending down, and sitting comfortably inside the SLA days each severity is configured with (see the 7/30/90/120-day table on vulnerability management & triage) |
| Scan coverage | Services with every required gate green (SAST + SCA + secrets, plus IaC and DAST where applicable) ÷ total services in the catalog | Trending toward 100%; watch specifically for regressions the moment a new repo gets created outside the golden-path template |
Notice what these three do together that a single number can't: scan coverage and vulnerability density are leading signals you can act on this sprint — a coverage gap or a density spike is something a champion or the platform team can respond to immediately — while MTTR is the lagging confirmation that a fix actually landed, not just that a ticket got filed. Balance both. A team can look great on density (nothing new is being found) while quietly sitting on a rising pile of unresolved Highs that MTTR would expose immediately, or look great on MTTR (everything closes fast) while resolving mostly Lows because Critical and High findings never make it past an overloaded queue — which is exactly why routing, covered next, is inseparable from the metrics that measure it.
The moment scan coverage climbs from 60% to 95%, the raw open-finding count almost always goes up, sometimes sharply — not because the code got worse overnight, but because a program that couldn't see 40% of its own estate just started measuring it. Reading that spike as regression and panicking (or worse, quietly rolling coverage back to make the chart look better) punishes exactly the behavior that was supposed to be rewarded. Compare density and MTTR only within a stable, apples-to-apples scan scope, and expect a real, visible bump in raw findings every time coverage genuinely improves — that bump is evidence the measurement got more honest, not that anything got worse.
These three numbers also aren't the only lens — they're the sprint-level instrument. DSOMM, SAMM & BSIMM covers the slower-moving maturity assessments a program layers on top: DSOMM's Culture and Organization dimension is where a champions network's actual coverage and rotation health gets scored on a longer cadence, and SAMM's Governance function is where the champion charter above becomes documented evidence for an Education & Guidance stream rating. Run the three metrics on this page every sprint; let them feed the slower-moving maturity model every quarter or year, rather than inventing a second, competing scorecard from scratch.
Routing triage so the platform team doesn't become the bottleneck
☺ Like you're 10: The building manager can't personally check every leaky faucet — their job is knowing exactly which calls actually need them, and trusting the trained floor reps with the rest.
Vulnerability management & triage already covers DefectDojo's severity-and-SLA mechanics in depth — what this page adds is the organizational question that chapter deliberately left open: who actually makes each triage call, and on what authority. A platform or AppSec team that insists on personally reviewing every finding before it's actioned isn't running a champions network at all — it's running the exact centralized-gatekeeper model security culture & champions already showed doesn't scale, just with an extra layer of process on top pretending otherwise. The routing table below is what makes "the champion decides most of it, the platform team decides the rest" an enforceable division of labor instead of a vibe:
| Finding or decision | Champion | Product team | Platform / AppSec team |
|---|---|---|---|
| Low or Medium finding, single service | Responsible & Accountable — triages and closes the loop | Fixes it, or implements the champion's False Positive call | Informed only, via the dashboard — no ticket reaches them |
| High finding | Responsible — same-day acknowledgment, tracks to SLA | Fixes it inside SLA | Consulted if the fix isn't obvious |
| Critical finding | Responsible — immediate escalation, same business day | Fixes it, expedited | Accountable — confirms severity, can reassign priority org-wide |
| Finding spanning >1 team (shared base image, shared library, shared IdP config) | Consulted — reports local impact | Consulted — implements its slice of the fix | Responsible & Accountable — coordinates the fix across every affected team |
| Risk Acceptance, any severity above Low | Consulted — drafts the business justification | Consulted | Accountable — approves, sets an expiry date, owns the re-review |
| Scanner tuning, new rule, or org-wide suppression policy | Consulted — reports false-positive noise and friction | Informed | Responsible & Accountable — owns the ruleset |
Read the "Platform / AppSec team" column top to bottom and the shape of the whole page falls out of it: that team is Accountable for exactly four things — confirming a Critical, coordinating a cross-team blast radius, approving anything above a Low Risk Acceptance, and owning the scanner ruleset itself. Everything else is explicitly a champion-and-product-team decision. A platform team whose actual weekly time doesn't roughly match that column — one that's spending most of its hours re-triaging Mediums a champion could have closed instead of tuning rules and coordinating cross-team fixes — has drifted back into being a bottleneck no matter what the org chart or the charter says.
Escalation triggers — the ONLY four reasons a finding leaves
a team's own DefectDojo queue and reaches the platform team:
1. Severity is Critical.
2. Blast radius crosses more than one team's product boundary.
3. Ownership is genuinely ambiguous (orphaned repo, no clear
ownership team on file, or the finding sits in shared
platform-provided infrastructure itself).
4. The request is a policy exception — a Risk Acceptance above
Low, or a request to change a scanner's org-wide ruleset.
Anything else that reaches the platform team anyway gets bounced
back to the owning champion with a one-line reason, logged. A
rising bounce-back rate is itself a metric worth watching — it
usually means a champion is either new, under-supported, or their
protected time has quietly been reclaimed (see the warning above).The routing table above only holds if people actually trust it under pressure. The most common way it erodes is well-intentioned: a champion or a product-team lead, unsure whether a Medium finding really is a Medium, forwards it to the platform team "just to be safe" instead of making the call the charter already authorizes them to make. One instance costs nothing. A hundred teams doing it once a sprint recreates the exact centralized-review bottleneck the whole network was built to remove — just routed through a triage queue instead of a code-review queue. Treat every over-escalation the same way vulnerability management & triage treats a dedup key nobody trusts: as a signal that confidence, not process, is the thing that actually needs fixing — usually with a short retraining pass at the next guild sync, not a new approval step.
The operating-model scorecard
☺ Like you're 10: Score yourself honestly on all nine rows, and the lowest one tells you exactly what to fix before it becomes an incident.
These nine rows are this whole page condensed into one table. Score your own program 0 (not really), 1 (partly, inconsistently), or 2 (solidly, every sprint) on each — out of 18 total.
| Practice | Why it matters | How to run it for real — score 0–2 |
|---|---|---|
| Protected champion time is real | An unprotected 15% is the first thing a busy sprint reclaims. | Blocked on a shared calendar, visibly, and tracked as a metric like any other SLA. |
| A written champion charter exists | Without one, authority gets re-litigated finding by finding. | Names exactly what a champion can decide alone versus what needs the platform team. |
| Champions rotate on a fixed term | Too short never builds fluency; too long calcifies into a second job. | 2–4 quarters, with a documented handoff to the successor. |
| A guild sync and support channel exist | An isolated champion with no peer group burns out quietly. | Recurring cross-team sync, a same-day-response channel from the platform team. |
| Vulnerability density is tracked, sprint over sprint | A point-in-time count can't show a trend. | Confirmed findings ÷ KLOC or ÷ service, compared within a stable scan scope. |
| MTTR is tracked per severity, against the SLA table | A closed ticket isn't proof; a rescan is. | Trended over a rolling 90-day window, benchmarked to the 7/30/90/120-day SLAs. |
| Scan coverage is tracked toward 100% | A gap you can't see is a gap you can't fix. | Services with every required gate green ÷ total catalog; watch new-repo regressions. |
| Routine findings resolve inside the team | This is the whole point of having champions at all. | Most findings never generate a ticket to the platform team — check the actual ratio. |
| The platform team's time matches its Accountable column | Time spent re-triaging Mediums is time not spent coordinating or tuning rules. | Majority of hours on cross-team coordination and ruleset ownership, not routine triage. |
Score your real program against the nine rows above, 0–2 each, out of 18. Then do three things. First, for whichever row scored a 2, name the actual evidence — a specific calendar block, a specific dashboard someone checked this sprint, a specific finding that got bounced back to the right owner — not just the fact that a document describing the practice exists. Second, pull last sprint's real numbers: what fraction of findings actually got resolved inside a team without reaching the platform queue? If nobody can answer that in under a minute, that's not a scoring gap, it's a visibility gap, and it belongs at the top of next quarter's list regardless of what the rest of the scorecard says. Third, ask one champion directly whether their protected time actually held up last sprint — their answer is a more honest score than anything on the dashboard.
Benny the Beaver: Sprint's packed. Can I skip champion office hours this week and just ship the feature?
Master Panda: That's the third week running you've asked me that, Benny. What happens to your team's queue the weeks you skip?
Foxy: Honestly, isn't the 15% functionally just a suggestion at that point? Nobody's actually stopping him from skipping it.
Nutty: Nobody has to stop him — the dashboard already did the telling. Payments' scan coverage dropped from 96% to 71% across the exact three sprints Benny's calendar block went missing.
Timmy: And every finding from Payments those three sprints landed straight in my queue with zero first-pass triage. That's not a coincidence, that's the bottleneck showing up exactly where you'd expect it to.
Benny: ...I genuinely didn't think three skipped office hours would move a number that much.
Master Panda: That's exactly why the charter treats your 15% as a real promise instead of a nice idea — a promise nobody checks is one that quietly stops being true. Block it again this week. I'll check next sprint's number with you.
That's the operating model in full: a champions network with protected time and real authority instead of a title with nothing behind it, three sprint-over-sprint metrics that show whether the network is actually keeping up instead of a snapshot nobody revisits, and a routing table that keeps the platform team spending its hours on the four things only it can do. None of the three mechanics here is exotic, and none of them is new content this course hasn't already covered in depth — what separates a program that runs this well from one that's DevSecOps in name only is whether all three still hold on the sprint it's inconvenient to honor them, and whether someone's actual job is to check.
1. What two operating questions does a champion charter answer that the definitional case for champions, on its own, doesn't? 2. Name the three sprint-over-sprint metrics this page tracks, and say which are leading signals versus which is the lagging one. 3. Why isn't a rising raw finding count automatically bad news, and what should you compare instead? 4. In the routing table, what four kinds of finding or decision is the platform/AppSec team actually Accountable for? 5. What's the single failure mode that breaks all three practices on this page?
Check your answers
- How long someone stays a champion before rotating off (commonly 2–4 quarters, with a documented handoff), and exactly what they're authorized to decide alone versus what needs the platform team's sign-off — neither is covered by the case for why the champions model exists in the first place.
- Vulnerability density, MTTR by severity, and scan coverage. Scan coverage and vulnerability density are leading signals you can act on immediately; MTTR is the lagging signal that confirms a fix actually landed, not just that a ticket got filed.
- Because improving scan coverage almost always makes the raw open-finding count go up — not because the code got worse, but because a previously-invisible part of the estate just started being measured. Compare density and MTTR within a stable, apples-to-apples scan scope instead of trusting the raw count alone.
- Confirming a Critical finding's severity, coordinating a fix that spans more than one team, approving a Risk Acceptance above Low severity, and owning the scanner ruleset (tuning rules, org-wide suppressions). Everything else in the table is explicitly a champion-and-product-team decision.
- A promise that stays true only until the moment honoring it is inconvenient, with nothing specifically checking at that exact moment — an unprotected champion's calendar block gets reclaimed, a metric stops getting looked at, or "just to be safe" over-escalation quietly rebuilds the centralized bottleneck the whole model was built to remove.