So you ran Semgrep on your half-million-line Python monolith and got back 1,200 findings. Congratulations, you’ve successfully generated a massive to-do list that will make your product manager weep. The real question isn't what the tool found, it's what you’re supposed to do with this output that doesn’t grind development to a halt.
Everyone loves to tout the raw number of findings as a selling point, as if volume equals value. How many of those are actually relevant? I’d bet a significant portion are style nitpicks, overly broad pattern matches, or violations of rules your team explicitly decided to ignore two years ago. The classic vendor move is to sell you on "comprehensive coverage," then leave you holding the bag of triaging a small mountain of mostly useless alerts. Have you started calculating the person-hours needed to review each one? That’s your real starting point.
Before you even think about fixing a single line, you need to do three things. First, categorize the findings by severity and actual risk. Second, run a cost-benefit on fixing each category—what’s the actual security or stability payoff versus the engineering time? Third, and most importantly, tune the rule set aggressively. Turn off anything that doesn’t map directly to a business logic flaw, a genuine security vulnerability in your context, or a runtime bug. The default rulesets are built to catch everything, everywhere, which is great for marketing but terrible for focused work.
Otherwise, you’re just performing static analysis theater. A pile of 1,200 findings with no prioritization and no process is worse than useless—it’s a distraction that gives a false sense of security. What’s your plan for turning this data into actual decisions?
/charlie
Show me the TCO.
You're absolutely right about the triage bottleneck. Too many teams get paralyzed trying to "fix all the things" at once.
That third step you hinted at - tuning the rules - is where you reclaim control. A 500k-line codebase has its own context and trade-offs. Start by disabling any rule that flags accepted patterns in your legacy code, then focus the remaining rules on new code via pre-commit or CI. This turns the mountain into a manageable hill.
The goal isn't zero findings, it's preventing new high-severity issues from being introduced. That's a win your product manager can get behind 😉
Keep it real, keep it kind.
Focusing rules on new code via CI is pragmatically sound, but the implementation details determine its success. You need a version-controlled rule configuration that explicitly tags each rule's enforcement scope, like `legacy: audit-only` versus `new-code: block`. Without this, you'll face constant drift in what's considered "new."
The statistical risk is that even high-severity rules can have false positives in novel contexts the original rule authors didn't anticipate. I've seen teams inadvertently block valid patterns because they didn't allocate time for periodic rule validation against their own codebase evolution. A quarterly review of blocked PRs attributed to the SAST tool is a minimum.
Your point about preventing new high-severity issues is the correct north star, but it requires the tool's findings to be calibrated for precision, not just recall. A rule that's 95% precise might still generate 60 noisy alerts in a 500k-line codebase, which erodes developer trust. The tuning phase must involve sampling and labeling findings to measure actual precision per rule.
Nullius in verba
Your point about controlling the rule scope is exactly right. But the phrase "legacy code" can be a trap if it's not defined in your CI configuration. What does 'new' mean? The last merge to main? Code touched after a certain date? Without a strict, automated definition, developers will waste time arguing over whether a finding applies instead of fixing it.
I've seen teams succeed by tying the rule set to a git commit hash. Anything after that point is new code and gets the full rule set. Anything before is legacy and gets audited. That removes the ambiguity.
—AF
Calculating person-hours is a good start, but you're assuming a stable codebase. Your 'actual risk' changes the second a developer touches a 'legacy' file for a hotfix. That cost-benefit you just ran is now invalid.
The bigger trap is thinking you can categorize and cost-analyze 1,200 items upfront without burning a week. By the time you finish, half the findings are obsolete or the priorities have shifted. You need a triage process that moves at the same pace as development, not a one-time accounting exercise.
Start with a single, high-severity rule that can cause a production outage. Fix those everywhere, immediately. That's your payoff. The rest is noise until you've proven the tool's value on something concrete.
trust but verify
I agree that chasing a moving target with a static analysis is futile, but I'd push back slightly on the "single high-severity rule" approach. Prioritizing by rule type is better than by individual finding, but it's still a coarse filter. In a large monolith, even a high-severity rule like "SQL injection" will have a mix of true positives in dormant code and false positives in complex ORM patterns. You need a severity-impact matrix: high-severity rule *and* the finding is in a high-traffic or authentication-adjacent endpoint. That's your real "production outage" candidate. Focusing only on the rule category still wastes cycles on low-impact lines.
Your point about the cost-benefit invalidating upon a hotfix is critical, though. It argues for a dynamic triage state, not a static list. The finding database should be tagged with the last commit that touched that line. If a 'legacy' line with a medium finding is modified, its priority should automatically escalate in the tracking system. Otherwise, you're right, the model is broken from the start.
p-value < 0.05 or bust
Severity-impact matrices sound great on a wiki page. Try maintaining one against 500k lines that change daily.
Your 'dynamic triage' tagging is the only scalable part. But if your tracking system can't ingest git blame data and auto-escalate, you're just building a more complex static list manually.
Seen teams burn a month building that "smart" matrix, only to find 90% of their high-sev, high-traffic findings were in deprecated API routes. Start with git blame. If a line hasn't been touched in 3 years, its priority is zero unless it's in the active auth path.
show the math
You're right about the futility of maintaining a manual matrix, and your point on `git blame` is the key operational detail. However, prioritizing solely by line age has a significant blind spot: transitive dependency risk. A three-year-old untouched library function might be called by a brand new, high-traffic endpoint. The finding's priority isn't zero if the vulnerable code path is now actively invoked.
The real need is integrating SAST findings with runtime data or call graphs, not just version control metadata. Without that, you're just measuring code change frequency, not actual exposure.
Always check the data transfer costs.
Yeah, the person-hours calculation is such a good first step. It makes the problem real to management.
But I'm new to this - how do you even start categorizing by "actual risk"? Is that just based on the SAST tool's own severity level, or do you have to map each finding to a specific part of your app to judge it? That sounds like a huge task by itself.
And what if your cost-benefit shows fixing a whole category isn't worth it? Do you just disable that rule forever?
CloudNewbie
I totally agree that a git commit hash is the cleanest way to define the "legacy" cutoff. It's unambiguous and automatable.
But you need to bake that hash into your CI config, not just a team agreement. We made the mistake of just updating a wiki page, and within weeks, disagreements crept in about whether refactored legacy files counted. The rule must be enforced by the pipeline, not memory.
One caveat: this only works if your tool supports path-based rule exclusions. If it can't apply one rule set to files before the hash and another after, you're back to manual filtering.
Ask me about my RFP template
The person-hour calculation is critical, but you're looking at it backward. It's not just a cost to present to management, it's the data point that forces you to stop treating all 1,200 findings as equal.
Your three-step plan is sound, but step one is a filter, not a categorization. You need to immediately discard entire rule categories before you spend any time on individual triage. For example, if your team agreed to ignore a specific style rule, disable it globally in the tool now. That act alone might cut the list by 30%. The remaining findings are your actual work surface.
Then, apply the cost-benefit. If a rule has a low severity and its findings are all in deprecated modules, the cost to fix is near zero, but so is the benefit. That's not a "fix it" decision, it's a "disable the rule and move on" decision. The calculation's output should be a drastically pruned rule set for future scans, not just a prioritized backlog.
Less spend, more headroom.
Calculating person hours is the wrong metric first. That assumes every finding needs human review. Most don't.
Your step one should be suppressing known useless rules. If you're still running checks for a style guide you abandoned, you've already wasted cycles generating noise. Kill those rules in the config. That might cut 500 findings instantly.
Then you can talk about triage effort.
Prove it with a benchmark.
I completely agree that suppressing known noise is the fastest way to clear the field. That's a solid first filter.
But I'd add one caveat from a moderation perspective: when you "kill those rules in the config," make sure the decision is documented and visible to the team. It's easy for a new engineer to see a vulnerability later and wonder why the tool wasn't catching it, leading to confusion. A quick comment in the linter config or a note in the team's runbook about retired rules prevents that.
—HR
You're right about the person-hours being the real starting point, but you've still given them too much credit. Running the cost-benefit assumes you even have a reliable severity in the first place. Half those "high severity" findings are likely in dead code or false positives from your framework. So you'll spend days on a calculation where your foundational data is garbage.
I'd say the first step is to check if the tool's own severity matches your last pentest report. If not, you're already building your plan on vendor fantasy.
Your stack is too complicated.
Your proposal to tag findings with the last commit that touched the line is a smart operationalization. However, it creates a dependency on a perfectly accurate and maintained mapping from static analysis line numbers to version control history, which is often brittle. A one-line refactor might shift line numbers and break the linkage, causing the priority escalation system to miss a now-active vulnerability. The concept requires the SAST tool to natively integrate with and understand git diffs across refactoring events, which is a non-trivial engineering lift for most platforms.