Choosing Threat Model Fidelity Without the Exponential Complexity Flaw

You've sat through threat modeling sessions that balloon into a two-day death march. Every data flow gets a swimlane. Every microservice gets a threat. By hour six, the diagram looks like a plate of spaghetti and the team has stopped caring. The enemy here isn't malice or incompetence—it's exponential complexity. Each new element adds edges, and each edge multiplies threats. But here's the thing: you can choose fidelity without that explosion. You just need to know where to cut.

This field guide isn't another taxonomy. It's a set of trade-offs I've seen work (and fail) across cloud migrations, API integrations, and legacy rewrites. We'll walk through the decisions that keep complexity linear while still catching the threats that matter.

Where Fidelity Decisions Show Up in Real Work

Cloud migration threat modeling at a fintech startup

I sat in a windowless room with a fintech CTO who had seventy-two hours to decide whether their PCI-scoped card processing pipeline could survive a move to EKS. The threat model was due Friday. The team had mapped forty data flows—every queue, every Lambda trigger, every secrets manager call. That fidelity cost them two weeks. Two weeks of diagramming while the business asked why they weren't shipping. The catch is they didn't need forty flows. They needed eight: the seams where tenant isolation could collapse and where token vault access left audit trails. The rest was noise. What usually breaks first in a cloud migration isn't the crypto—it's the IAM role assumption chain. They had modeled the JWT expiry but not the cross-account trust boundary between staging and prod. That blind spot, buried under all that high-fidelity clutter, would have let a compromised dev node pivot into production. The trade-off is brutal: model too coarsely and you miss the seam; model too finely and nobody reads the output.

API boundary scoping for a third-party integration

Your team is wiring a payment orchestration layer to Stripe, Adyen, and a regional processor nobody's heard of. The third-party docs say "use our SDK." You've got two endpoints—/charge and /refund. Straightforward, right? Wrong order. The fidelity decision isn't about the happy path; it's about the error-handling boundary. Where does the API stop speaking your protocol and start speaking theirs? Most teams model the request schema at 100% detail—field types, validation rules, the works—then leave the response error codes as a single generic bubble. That's where the pitfall lives. One regional processor returns HTTP 200 with a body field "status": "failed". Another returns 422 with no body. Your threat model, at high fidelity on request shape but low fidelity on response semantics, misses a fraud-detection bypass. I have seen that exact pattern let an attacker replay refund requests because the model assumed all 200s meant money moved.

Quick reality check—threat modeling a third-party integration is a boundary problem, not a flow problem. The h3 choice between "system context" and "process-level" fidelity determines whether you catch the mismatch or ship the blind spot. Most teams default to whichever fidelity level the template suggests. That hurts.

'We modeled every HTTP header. We missed that the partner's sandbox and prod share a client secret rotation window.'

— Security engineer, post-incident retrospective, 2023

Legacy system decomposition during a modernization sprint

The monolith has been running since 2015. Your sprint goal: extract the authentication module into a sidecar. The temptation is to model the whole monolith—every call stack, every shared database handle, every cron job. Don't. The fidelity you need is the decomposition boundary: where does the old code pass session state to the new code, and what happens when that handoff fails? One team I advised spent three sprints modeling the legacy authentication flow at 100% fidelity—all seventeen conditional branches. What they needed was a single diagram showing the session cookie being written by the monolith and read by the new sidecar. That seam blew out when a deploy order mismatch left the sidecar alive but the monolith's session table migrated a day early. The high-fidelity model of the old code was a waste; the low-fidelity model of the dependency between old and new would have caught the drift. The honest cost here isn't the modeling time—it's the rework sprint after the incident. That's the exponential complexity everyone talks around.

The Foundations Most People Get Wrong

Depth vs. breadth: why they're not opposites

Most teams treat threat-model fidelity like a slider between 'high level' and 'detailed' — but that's a false binary. Breadth is about which trust boundaries you draw; depth is about how many layers you peel inside one boundary. They aren't trading against each other. The confusion shows up fast: a team decides they need "higher fidelity," so they double the number of threat scenarios per component. They don't add new components or interfaces — they just drill deeper into the existing ones. That sounds fine until the model becomes a checklist of low-probability edge cases nobody can prioritize. We fixed this once by forcing the team to map every new threat to a real data flow edge — suddenly half their "deep" threats vanished because they'd assumed a trust boundary where none existed. The catch is that depth without breadth breeds tunnel vision; you'll catch the tenth variant of SQL injection but miss the OAuth misconfiguration three hops away.

When decomposition becomes an infinite loop

Here's the pitfall: decomposition feels productive. You break a component into sub-components, then sub-sub-components, each with its own data flows. The diagrams grow. The threat count mushrooms. But ask yourself — when does this stop? I have seen teams produce twelve-layer data-flow diagrams for a single microservice. The security value flatlines after layer three. What usually breaks first is the review itself: nobody can hold twelve interdependent trust relationships in working memory, so the later layers get copy-pasted threats. That's exponential complexity in disguise — each new layer forces reanalysis of all parent layers because threats at one depth can cascade upward. Wrong order: teams add depth before they've validated breadth, then drown in cascading updates. Quick reality check—if your diagram takes more than a minute to trace the primary flow, you've already lost linearity.

The myth that more detail equals better security

More detail can mean more noise. A deep threat model often produces a long list of findings — but length isn't coverage. The real signal lives in the seams between components, not inside them. I've watched a team spend two weeks modeling a logging library's internal state machine while the API gateway had no authentication layer drawn at all. That hurts. The assumption seems to be that exhaustive internal scrutiny will surface hidden vulnerabilities — but threat modeling isn't code review. It's about mapping where trust changes hands. Detail on internal mechanisms usually just documents assumptions that aren't threats yet. The trade-off is brutal: every hour spent on deep internal scenarios is an hour not spent tracing external attack paths. Most teams skip this: they don't ask "What's the minimum depth to catch the real attack flow?" They default to "as deep as we can go."

“Depth in the wrong place is just expensive curiosity. You find things, but rarely the thing that breaks you.”

— paraphrased from a security lead after a postmortem

One concrete fix: cap depth at the point where your next decomposition step would require a separate engineering team's domain knowledge. If you can't trace the threat without calling in the logging team, you've passed useful fidelity. Keep the model shallow until the surface area is fully covered — then deepen selectively, one boundary at a time, with a clear reason why that depth matters. That keeps complexity linear, not exponential. Not yet a habit for most teams — but it's the foundation that prevents the blowup.

Patterns That Keep Complexity Linear

Attack surface slicing: model only what touches untrusted input

Most teams model everything. Every component, every data flow, every microservice talking to itself. The result? A hundred-element diagram where nobody can find the actual risk. The fix is brutal and simple: slice your attack surface at the boundary where untrusted input enters. If a component never receives data from an external caller, never deserializes a payload, never touches a user-supplied file—it’s infrastructure, not a threat modeling target. I’ve watched teams cut diagram complexity by 70% in one meeting by applying this single rule. The catch is discipline—you’ll feel tempted to add “just one more” internal service for completeness. Don’t. That seam between trusted and untrusted? That’s where the real explosions happen.

What about services that transform already-validated data? Skip them. Your threat model doesn’t need to track every hop after the sanitization gate. The trade-off bites only when you forget that a downstream component sometimes accepts raw input—a cached config file, a webhook override. That edge case needs its own slice. Otherwise, you preserve linear complexity by modeling surfaces, not architectures.

Flag this for conservation: shortcuts cost a day.

Flag this for conservation: shortcuts cost a day.

Trust boundary scoping: isolate your zones before diagramming

Draw your trust boundaries first. Not the data flows, not the assets, not the pretty boxes. Start with a blank page and ask: “What zones have different authentication authorities?” Network perimeter, DMZ, internal LAN, database tier—each boundary is a cost center for complexity. Once you’ve isolated the zones, you’ve already split the problem into independent sub-models. Most teams do this backward: they diagram everything, then add a dashed line and call it a boundary. Wrong order. Boundaries define where threats live; flows just connect them. We fixed a year’s worth of bloated threat models at one client by blocking anyone from drawing a flow line until the trust zones were signed off. The resistance was loud—developers hate process—but the complexity curve flattened immediately.

That said, trust boundaries drift as systems evolve. A microservice that was internal last month now exposes a health endpoint to a monitoring tool outside the zone. Your scoping needs a re-validation step, not a full redraw. Keep the zone definitions in a separate document that changes slower than the flows. When someone asks “should I model this?”, the answer is always “which zone does it touch?”—not “how many threats does it have?”

Risk-based pruning: discard threats below a severity floor

Not every threat matters equally. Prune aggressively. Set a severity floor—say, medium or above—and discard anything below it. You’ll get pushback: “But a low-severity XSS could combine with another bug!” That’s a vulnerability chaining argument, not a threat model concern. If the combination is plausible, the combined severity is the floor. I once sat in a review where the team spent 45 minutes debating a low-severity information disclosure that would require physical access, a zero-day, and a full moon. That 45 minutes could have been spent on the authentication bypass sitting five rows down. The pattern is brutal: if a threat wouldn’t trigger a CVE on its own, don’t model it. This keeps the review linear because you’re only reasoning about high-severity paths—and those are finite in any rational design.

“The danger isn’t missing a low-severity threat. It’s that the noise hides the one that will wake you at 3 AM.”

— A patient safety officer, acute care hospital

— paraphrased from a incident response lead who audits threat models for a bank

The pitfall? Teams prune too late. They write the full threat list, then filter. Instead, apply the floor during the brainstorming pass—if a threat idea lands below your severity threshold, write it on a sticky note and throw it away. No ticket, no spreadsheet row, no “parking lot.” Complexity grows from every recorded item, even the ones you later mark as low. Kill them before they create a maintenance liability.

What if you misjudge severity? You recalibrate during the next review, not by resurrecting old items. The model stays lean; the team stays fast. That’s the whole point—linear complexity means you can keep modeling without the exponential hangover that kills the practice.

Anti-Patterns and Why Teams Revert to Brute Force

The completeness trap: trying to model every possible threat

I have watched teams burn four weeks on a single system diagram because someone declared, 'We need to find every threat—no misses.' That sounds noble, but it breaks faster than you'd think. The completeness trap works like this: you start with STRIDE or a similar framework, tick boxes for every element, and soon you're modeling threats against a CSS file or a deprecated API endpoint that nobody touches. The diagram grows, the threat list inflates, and the real risks—the ones that actually move the needle—drown in noise.

The catch is that completeness feels responsible. It's the safe answer in a review meeting. But exhaustive modeling doesn't produce better security—it produces list fatigue. What usually breaks first is the team's willingness to care. After the third session of debating whether a read-only log bucket is vulnerable to injection, people check out. One architect I worked with described it plainly: "We spent two weeks modeling threats that would cost more to exploit than the entire sprint budget." The output? A 90-row spreadsheet nobody ever consulted again.

"Most threat models fail not because they missed a threat, but because they modeled so many that the real ones got buried."

— security lead at a mid-size SaaS firm, after killing a 200-row threat register

The antidote isn't more rigor—it's scoped rigor. If you can't articulate why a threat matters within thirty seconds, skip it. That hurts. But it's cheaper than the alternative.

Over-fitting to last year's breach: anchoring on irrelevant detail

Another common revert: teams model the threat that just hit them. Hard. A company gets nailed by an SSRF attack, and suddenly every review for the next six months obsesses over SSRF—even for internal services that don't fetch external URLs. This is anchoring, not analysis. You're building a threat model that's a perfect defense against yesterday's problem while the new service's main risk is probably something boring and structural: weak auth, misconfigured RBAC, or a dependency with a known exploit.

Here's the pattern I see repeat: the breach post-mortem creates a checklist. That checklist becomes the model template. The template gets copy-pasted into every review. Before long, teams are diagramming network paths for non-routable internal tools and calling it "high fidelity." It's not fidelity—it's cargo-cult diligence. The real cost isn't the diagramming time. It's the missed threats you never considered because your mental aperture got narrowed by a headline.

Not every conservation checklist earns its ink.

Not every conservation checklist earns its ink.

Quick reality check—ask yourself: if last year's breach had never happened, would this threat even make your top ten? If the answer is no, you're over-fitting. Drop it. Leave room for the ones you don't already know about.

Tool-induced paralysis: when diagramming becomes the goal

Worst of the bunch. A team picks a shiny threat-modeling tool—rich UI, auto-generated data-flow diagrams, drag-and-drop trust boundaries. Great for demos. But what happens next? The tool demands every component be drawn precisely, every data flow labeled with a protocol and a port, every external entity tagged. And teams comply. They spend three hours aligning boxes and routing arrows. The output looks beautiful. The threat model? Often shallow.

The tool becomes the task. Diagramming satisfaction replaces threat-finding. I've seen reviews where the team spent 80% of the session debating whether a box should be labeled 'Auth Service' or 'Authentication Module.' Meanwhile, nobody questioned the real seam: that the service accepts session tokens over HTTP with no integrity check. That's the threat. But it wasn't drawn in the tool's prescribed notation, so it got missed.

Tools are useful—they can surface repeatable patterns, enforce consistency, and compress review time. But when the tool's friction exceeds its insight, teams either abandon it entirely or, worse, double down on diagram hygiene while the risk inventory stalls. If your next threat model review opens with 'let me show you my diagram' rather than 'here are the three things that could actually break us,' you're already in the anti-pattern.

Fix it: declare the top three risks before you open the tool. Then use the tool only to test those seams. Everything else is decoration.

Maintenance, Drift, and Long-Term Cost

How Threat Models Rot

You built a beautiful model six months ago. Every data flow mapped. Every trust boundary drawn with care. Then a dependency got bumped from v2.4 to v3.1. An API changed its auth scheme. A team member left—took the tacit knowledge about why that one connector was marked high-risk. The model still sits in the wiki, looking pristine. That's the trap. Threat models don't decay gracefully; they rot from the inside while the document stays intact. What usually breaks first is the implicit connection between a control and a specific library version. I have seen teams waste two full sprints chasing a vulnerability that their model should have flagged—except the model referenced a package that hadn't existed in production for eleven months.

The second rot vector is team turnover. New engineers inherit a diagram with thirty boxes and no oral history. They don't know why a trust boundary exists, so they route a new feature right through it. Wrong order—but the model never complains. The catch is that high-fidelity models—ones with detailed component lists and per-flow mitigations—rot faster. They encode more assumptions, and every assumption is a future drift point. Low-fidelity models? They're vaguer, sure, but vagueness ages well. Something to weigh when you choose between five layers of abstraction and a single swimlane.

Detecting Drift Without Full Remodeling

Most teams skip this: a lightweight health check that takes thirty minutes every two months. Not a full review—just a pulse. Compare the model's listed dependencies against your actual dependency manifest. Check if the API endpoint names in the model still match production routes. Flag any control that references "the old auth gateway" or "legacy session handling." Quick reality check—you don't need to redraw every line. What you need is a single page of "live vs. recorded" mismatches. I have found that three questions catch eighty percent of drift: Did we deploy a new service? Did we deprecate an encryption scheme? Did we rotate a team that touches the model? Answer those, and you'll know whether fidelity has become fiction.

The anti-pattern is the all-or-nothing trap. Either the team re-does the entire threat model every quarter—brute force, exhausting—or they never touch it again. Neither works. You want a pulse check: a script that compares package-lock.json against model entries, a calendar reminder to walk the trust boundaries aloud. That scales. That keeps complexity linear.

'A threat model that isn't checked against reality is a bedtime story, not a security artifact.'

— paraphrased from a conversation with a risk engineer who learned this the hard way

Calculating Total Cost of Ownership for Different Fidelity Levels

The initial model cost is obvious: three people in a room for an afternoon, some whiteboard markers, a PDF export. The long-term cost hides. High-fidelity models demand quarterly updates because every microservice change invalidates a node. That's two person-days per quarter just to keep the diagram honest—eight days per year. Low-fidelity models cost less to maintain but more to interpret. When a real incident hits, the vague model forces a late-stage sprint to reconstruct details you could have documented earlier. You pay either way. I have observed teams that spent more on model upkeep than on the controls the model was supposed to guide. That hurts.

Here is the blunt math: if your model requires more than two full reviews per year to stay accurate, you chose a fidelity level your team can't sustain. Drop a layer. Merge components. Accept that a few trust boundaries will be rough approximations. The alternative is drift, then neglect, then a model that lies to everyone who reads it. Specific next action: this week, take the model you're most proud of and run the thirty-minute pulse check against production. Count the mismatches. If the count exceeds five, downgrade the fidelity before the next review cycle begins. Your future self—and your security posture—will thank you.

When to Keep Fidelity Low (or Skip Modeling Altogether)

Early-stage products that change every sprint

If your team re-writes the authentication module every two weeks, high-fidelity threat models are a waste. I have seen startups burn two sprints diagramming data flows that vanish in the next release. The catch is obvious but teams ignore it: fidelity costs time, and time spent modeling a moving target is time not spent shipping. Keep it loose—whiteboard sessions, bullet risks, no formal notation. You'll lose some nuance. You'll gain the ability to pivot without rewriting documentation nobody reads anyway. That's a fair trade.

Honestly — most conservation posts skip this.

Honestly — most conservation posts skip this.

Rapid prototyping with no sensitive data

No PII, no payment flows, no proprietary algorithms—then why are you building a data-flow diagram with swim lanes and trust boundaries? Some teams default to full STRIDE because it feels thorough. Quick reality check—thoroughness has a cost. When the prototype serves static mock data behind a shared API key, the highest risk is someone scanning your staging endpoint. A single-page risk register handles that. Save the heavy modeling for when real secrets enter the picture. Most teams skip this distinction. They shouldn't.

Environments where compliance mandates low-detail methods

This one surprises people. Some compliance regimes prefer shallow modeling—say, a controls-mapped spreadsheet over a formal attack tree. The logic is sound: auditors need traceability, not creative threat discovery. I've watched a team produce a gorgeous threat model for a PCI-scoped service, only to have the auditor ask for a simple checkbox list instead. Wrong order. High fidelity added friction without adding safety. If your compliance framework rewards breadth over depth, match its pace. Model wide, not deep.

'Low fidelity is not low effort. It's deliberate restraint in service of speed, signal, and survival.'

— engineer who stopped building PowerPoint palaces, circa last Tuesday

What usually breaks first is the belief that more detail always means more security. It doesn't. High fidelity creates false confidence—you mapped every edge case, so you assume you caught every risk. Meanwhile, the real threat is a developer who bypassed the model entirely because it took too long to update. That hurts. The heuristic is brutal but clean: if the model outlives three architecture changes without revision, your fidelity is already wrong. Drop it. Start with sticky notes. Iterate when the product stops rewriting itself every month. One rhetorical question worth asking: would you rather have an outdated masterpiece or a live sketch that adapts?
Your next threat model review doesn't need to be exhaustive. It needs to be honest about what stays static long enough to deserve scrutiny. When in doubt, model the smallest surface that carries actual risk. Ignore the rest until it earns your attention.

Open Questions and Frequent Misunderstandings

How many assets are enough to start? Sample size rules of thumb

Most teams ask this backward. They want a universal number—five assets, ten, twenty—before they draw a single data-flow line. That's cargo-cult precision. The real question is: can you trace an attacker's path from entry to crown jewel without a gap larger than your team's memory? I've run sessions where three assets were plenty—a web app, a database, and an admin API—because the interaction surface was that narrow. Other times, thirty assets still felt thin. The catch is sample-size anxiety usually masks a different fear: "If I list too many, I'll never finish." That's valid. But start with what hurts most. One concrete heuristic: list every external interface first, then trace inward until you hit a store of sensitive data. If that chain fits on one whiteboard, you're done. If it sprawls, you've already found your complexity problem—the model didn't create it, the architecture did.

Wrong order. Teams often start with "all the servers" or "every microservice in the Kubernetes cluster." That produces a spreadsheet, not a threat model. A better rule: reduce until removing one asset would break the attack narrative. That's your floor. Most real-world reviews settle between four and twelve assets per trust boundary. You'll know you undershot when a reviewer says, "But what about the third-party auth callback?"—that's a seam, not a failure.

Does tool choice drive fidelity? Avoiding lock-in

Tooling is a magnet for false certainty. I've seen shops buy a "threat-modeling platform" that auto-generates data-flow diagrams from infrastructure code, then declare their fidelity perfect. Meanwhile, the diagram skips how a logged-in user escalates privileges because the IaC never models session state. That sounds fine until the first pentest reveals the seam—then you're debugging a tool assumption, not a threat. The pitfall: tools encode one notion of "good enough fidelity." Yours won't match theirs. Draw.io, Lucid, a whiteboard, even a plain-text adjacency list—all of them work if your team can annotate trust boundaries and attack paths by hand. The lock-in risk isn't the file format; it's that you stop questioning whether the tool's auto-layout decisions blur a critical detail. Quick reality check—if your tool can't produce a diagram with a red "here be dragons" annotation, you're outsourcing judgment you shouldn't.

Compliance hand-waving is the cousin of this problem. Auditors ask for "evidence of threat modeling" and teams export a diagram with twenty-seven nodes and no annotations. That satisfies a checkbox, but it's a liability masquerading as work. The right move: include one paragraph per trust boundary explaining why fidelity was set at that level. That costs thirty minutes and kills auditor follow-ups dead.

“We need to model every API endpoint or the risk register will flag us.” — someone who just added a month of overhead

— Engineering lead, post-audit scars, 2024

Not every API endpoint needs its own threat model. Group endpoints that share authentication, authorization logic, and data flow. One diagram covers twenty routes if the attack surface is identical. Auditors rarely care about the count—they care that you can articulate where an attacker pivots. That articulation is fidelity, and it's free.

Compliance hand-waving: when auditors ask for detail you don't need

Here's the scene: auditor reviews your threat model, says "I don't see storage accounts broken out," and your team frantically adds every blob container, queue, and table to the diagram. That's brute force disguised as diligence. The misunderstanding is conflating granularity with rigor. A threat model isn't a bill of materials—it's a narrative about trust boundaries and compromise paths. If your storage accounts all share the same access key, same network rule set, and same monitoring, modeling them as a single block is more honest than pretending each one is a unique risk. I push back politely: "Show me two distinct attack paths that differ between container A and container B. If you can't, I'm grouping them." That conversation usually ends the granularity demand.

What usually breaks first is the "auditor wants data-flow diagrams for every internal dependency" request. Internal dependencies that never touch untrusted input? Skip them. Document why you skipped them—"no external ingress, no secrets at rest, all traffic mutual-TLS." That one-page memo saves your team three weeks of drawing boxes nobody will read. One last thing: if an auditor insists on a specific tool format, challenge the requirement. Most compliance frameworks (SOC 2, ISO 27001, PCI) mandate evidence, not tooling. A well-scoped PDF or even a photographed whiteboard passes. The next time someone says "but the template requires thirty rows," ask: "Which trust boundary are we protecting with row 29?" They won't have an answer—and that's your opening to cut fidelity back to where it matters.

Next Experiments for Your Next Threat Model Review

Try a one-page threat model on your next sprint

Stop overcomplicating it. This week, grab a single sheet of paper—digital or physical—and split it into four quadrants: asset, data flow, trust boundary, and the one threat that keeps you up at night. That's it. I have seen teams spend three days grooming a spreadsheet with 200 rows that nobody reads. The one-pager forces a brutal priority cut. If your sprint involves a payment feature, the asset is the credit card number, the flow hits an external gateway, the boundary is your API endpoint, and the threat is a man-in-the-middle. Write that down. Discuss it for twenty minutes. Then move on. The catch is that this feels ridiculously shallow at first—most engineers want to enumerate every SQL injection vector. That's the exponential trap. One page curates, it doesn't catalog. Wrong order.

Run a fidelity audit: map current model complexity vs. asset value

Take your last threat model and count the number of threats listed. Then assign a rough dollar or impact tier to each protected asset. What usually breaks first is the mismatch: fifteen threats on a low-value internal logging endpoint, and only two on the user authentication path. You'll see the pattern immediately. High-fidelity detail on low-value assets is where complexity leaks without security payoff. Quick reality check—if your team spent more time modeling the admin report generator than the payment flow, you already have a fidelity drift. Re-label each threat as high/medium/low fidelity and compare it to the asset's criticality. Where the two diverge, kill the excess detail. Not "refine it later." Drop it. Teams that skip this audit keep reverting to brute force because they can't see the imbalance.

“We modeled the entire session layer in detail. The breach came from a forgotten test API key.”

— Post-mortem notes from a fintech squad, adjusted for anonymity

Experiment with risk-based pruning: drop the bottom 20% of threats

Here is the uncomfortable experiment: rank your threats by likelihood times impact, then delete the lowest 20%. No archive, no parking lot. Just remove them. That sounds reckless until you realize those bottom-tier entries almost never drive a decision. They exist because someone felt obligated to fill a checklist. The pitfall is that threat modeling tools tempt you into storing everything—they make deletion feel like data loss. It isn't. It's signal recovery. I have seen a team prune 40 threats down to eight and still catch the critical supply-chain injection during review. The remaining 20%? Those were noise dressed as diligence. Does every low-impact CSRF variant deserve a paragraph in your model? Probably not. If the bottom quintile includes items you haven't touched in two review cycles, they're dead weight. Kill them. You'll free up cognitive space for the next sprint, and the fidelity of your remaining model actually rises. That hurts to admit—most people prefer the illusion of completeness. But a lean threat model that gets read beats a fat one that collects dust.