I’ve been auditing our security tooling spend, and the Semgrep bill caught my eye. The engineering team was patting themselves on the back for a “mature” shift-left program with hundreds of custom rules. Sounds like a win, right?
Here’s the pitfall: it turns out a significant portion of those rules were redundant. The team spent weeks authoring and maintaining custom rules for vulnerabilities and bad patterns that were already covered—and covered *better*—by the standard security rulesets they’d already purchased. They were essentially paying engineers to reinvent a wheel that was already on the car. 🛞
The proof? I pulled the last quarter’s scan logs. We had over 80 custom rules with a **0%** finding rate. Another 30 or so only ever triggered findings that were *also* caught by an existing core or Pro rule. The duplication meant longer scan times, more noise for developers, and of course, the sunk cost of engineering hours.
This isn't just a "learn the tool" issue. It's a FinOps problem. The marginal cost of a Semgrep rule isn't zero. It's the ongoing maintenance, the triage time, and the compute overhead. Before your team goes rule-crazy, do the analysis:
1. Audit your custom rules against the official registry.
2. Measure the actual unique finding rate.
3. Calculate the engineer-hours spent versus the value.
Otherwise, you're just building a very expensive, private collection of linting rules you didn't need.
- cost_observer_42
cost_observer_42
Your point on "the marginal cost of a Semgrep rule isn't zero" hits hard. I see a parallel in analytics with overly complex dbt project tests. Teams will write thirty custom data tests for a table when five core ones would catch 99% of issues. The maintenance burden becomes a silent tax.
Did you quantify the scan time impact? I'd be curious if the redundant rules added a linear or exponential slowdown to your CI pipeline. Sometimes that's the most tangible cost for engineering teams.
Exactly. This is a classic misapplication of "shift-left" where the activity itself becomes the goal, not the outcome.
I've seen the same pattern with custom Prometheus alerts. Teams proudly deploy 200 alerts while ignoring that 80% are never triggered or are redundant with upstream dashboards.
Your analysis is correct: the cost is in the maintenance tax and the alert fatigue. Every new rule adds cognitive load for the on-call engineer during an incident. Before writing a rule, the question should be: "What observable, actionable outcome does this provide that the vendor rule doesn't?" If the answer is "it catches our specific pattern," validate that pattern actually exists in your codebase first.
Trust, but verify