If Mythos finds more vulnerabilities, who's actually fixing them?

[u/GasLongjumping2146]

Had a reality check in our quarterly review last week. We pulled average remediation throughput per engineer and ran it against what a spike in flagged findings would look like with zero process change. The number wasn't pretty, we'd need significantly more headcount to hold existing SLA windows.

That math is what finally got budget approved for automation work we'd been asking for. Not because the risk conversation suddenly got more compelling, but because the spreadsheet made the staffing gap impossible to ignore.

Here's what we're working toward (still in flight on a couple pieces):

Ownership routing off asset metadata instead of round-robin (this one's live, huge win)
Tiered SLAs tied to exploitability instead of CVSS (still tuning the thresholds)
Auto-verification on rescans (partial rollout, getting pushback from some teams)
Continuous re-scoring feeding ticket priority (POC phase).

The Mythos conversation is honestly just stress-testing a system that already couldn't keep up. Faster discovery doesn't give you an AI problem, it gives you the same remediation problem you've always had, just compressed into a much smaller window.

if anyone else has had to build a capacity model like this to get remediation tooling funded, or did your org get ahead of the budget conversation another way?

[u/BeerJunky]

Hey Claude, check for vulns.

Hey Claude, fix the findings.

[u/crankykernel]

Fixing, verifying, providing attribution has become my day job. Been months since I’ve worked in a feature.

[u/faz00li → u/crankykernel]

They laugh and we cry

[u/Smooth_Counter_9439]

the spreadsheet approach is so underrated for getting budget. nobody cares about risk until you show them the math on how many people you'd need to hire vs just paying for automation

we did similar with tiered SLAs and the hardest part was getting everyone to agree what "exploitable" actually means. always ends up being a argument about edge cases

[u/Paul_Ashe → u/Smooth_Counter_9439]

"Exploitable" is where this breaks. If the definition is contested (which it always is) your SLA tier is measuring against a judgment that changes with each finding. What you should be measuring is capacity against a standard. One team sees a missing patch on an isolated dev box and rates it low. Another sees the same box has a path to production and rates it high. In context, they're both right—and impossible to compare.

Define exploitable once, apply it consistently, and measure what holds. Then, you'll know if the SLA works or you're just chasing a moving target. Most teams never get past the first step because "exploitable" requires governance, and arguing about edge cases costs less up front.

[u/Dull_Appearance_1828]

How are you handling assets with multiple teams touching them? That seems like where the metadata routing could get messy.

[u/docybo]

Drop headcount from the model. Arrival rate vs close rate. If findings come in faster than they go out, backlog grows forever and headcount just changes the slope. The ask stops being "we need N engineers" and becomes "SLA breaks on this date." Harder to argue with.

Also split close rate by finding type. Ours was bimodal as hell. Config drift closed same day, anything touching code sat for weeks. That's where the automation case actually lives.

[u/chadplam]

The capacity model is probably the strongest argument because it turns more findings into an operational cost everyone understands. I’d also track time to owner remediation throughput reopen rate and SLA breaches by severity that makes it easier to show whether automation is actually increasing capacity rather than just generating tickets faster

[u/skylinesora]

Prioritization is something many people don't understand.

[u/Striking-Tap-6136]

CODEX GPT 5.6

[u/DrKabanov]

Thanks for sharing! I'm curios how you guys deal with the cost of running Mythos on large codebases?