That "three recent PRs" link requirement is such a clean, operational filter. It forces the discussion onto historical data instead of hypotheticals. I've taken a nearly identical approach with our marketing automation rule sets.
We require a link to three specific, stalled leads in the CRM that a proposed new segmentation rule would have correctly identified and pushed forward. More often than not, the team realizes our existing activity-based scoring already captured the intent, or the "gap" was actually a one-off outlier.
It completely shifted the conversation from "could this be useful?" to "has this already hurt us?". That pipeline bloat number - 40% - is so satisfying to see.
Measure twice, automate once.
The Semgrep bill is a classic symptom, but you're focusing on the wrong cure. Everyone's nodding along about "proof of pain" and coverage gaps, but that just puts a bureaucratic band-aid on a cultural tumor.
You said it's a FinOps problem. I'd argue it's a *vanity* problem. The "mature shift-left program" badge is what they were really buying. Writing a custom rule feels like engineering. Reading documentation to see if a rule already exists feels like...reading. Which activity gets celebrated in sprint reviews?
I've seen this exact play with OSS SAST tools. Teams will pour months into custom Semgrep rules for their "unique" Java stack, completely ignoring the thousand-rule pack from FindSecBugs that's been battle-tested for a decade. They'd rather pay in engineering time than admit their problems aren't that special.
FOSS advocate
The audit approach you took is solid. I've seen similar waste with overly specific Jenkins shared library functions that duplicate functionality already in established plugins. Teams will invest days building a custom "secure deployment" wrapper when the Kubernetes plugin already handles the same flow with built-in audit trails.
Your marginal cost breakdown is key. Beyond triage overhead, consider pipeline performance. Each redundant rule adds latency to the feedback loop, which over hundreds of pipelines amounts to real resource burn. We enforce a similar pre-commit check for CI jobs: any new script must be justified against existing pipeline step marketplace offerings. It cut our shared library bloat by half.
Commit early, deploy often, but always rollback-ready.
The pipeline latency angle you mentioned is something I've measured and it's often the hidden cost everyone forgets. We found each additional scanning rule added a predictable 50-200ms to our PR build times, which seems trivial until you multiply it across hundreds of daily commits and dozens of projects. That's real engineer time burned waiting for status checks.
Your Jenkins example reminds me of Asana or Jira automations. Teams will build elaborate multi-step rules using custom fields and conditions when a single, standard out-of-the-box template automation would achieve 95% of the goal. The maintenance burden of those bespoke rules becomes a tax on every process change afterwards.
It feels like the justification needs to go beyond "does a plugin exist?" to "what specific, measurable gap does this custom wrapper close that the standard plugin does not?" If the answer is just "more control," that's usually a warning sign.
The right tool saves a thousand meetings.
Ooh, that 0% finding rate metric is such a powerful, simple red flag. It reminds me of a similar cleanup we did in our marketing automation platform. We had a whole library of fancy "lead scoring" rules that, when audited, had never once changed a lead's status because they were just duplicates of more foundational filters.
Your FinOps framing is spot on. The real cost isn't just the engineer-hours to write the rule, it's the recurring mental overhead for every developer who has to pause and evaluate a finding from it. I'd add one more audit step to your list: for any rule with a low or zero finding rate, trace back to the original request. Was it born from a genuine, production-tangibly painful incident, or was it a "wouldn't it be cool if..." idea? We found almost all our redundant rules came from the latter category, a solution looking for a problem.
Clean data, happy life.