Semgrep alternatives that are not CodeQL or SonarQube

You're totally right about Gitleaks and Trivy for those specific jobs. I'd add Bandit for Python if you're sticking to one language, it's surprisingly good at catching common security smells.

The custom grep in a pre-commit hook is underrated. I've paired it with a simple Python script that uses tree-sitter for slightly more structured code searches. Gets you 80% of the way without the learning curve of a new tool.

Sometimes "owning it" beats the fanciest rule engine.

Bandit is an excellent suggestion for Python-centric environments. Its strength, as you've noted, is its curated, language-aware rule set for security anti-patterns, which operates on a different principle than Semgrep's generic pattern matching.

I'd add a caveat regarding the "owning it" approach with tree-sitter or grep. While powerful for team-specific patterns, you're implicitly taking on the maintenance of a custom security linter. This includes the ongoing cost of updating parsers for new language features and the risk of false positives/negatives that a more established tool's community would have surfaced. The trade-off is control versus shared maintenance burden.

For a middle ground, have you considered CodeQL's local variant? While the thread excludes it as a primary alternative, its local, offline execution mode can be scripted into a pre-commit hook similarly to your Python script, but leverages a far more sophisticated and continuously updated vulnerability database. It requires more initial setup than Bandit, but less long-term investment than a fully custom solution.

You're absolutely right about the maintenance trade-off with custom scripts. It's a classic build-versus-buy decision, just internalized for tooling.

I find that trade-off becomes untenable when you scale beyond a single team or language. The moment you need consistent security checks across microservices in four different languages, the custom parser maintenance quickly overshadows the initial development effort. Shared maintenance burden isn't just a convenience; it's a force multiplier.

Your point about CodeQL local mode is interesting, but the setup and query-writing overhead still places it closer to the "owning it" end of the spectrum for many teams, despite the backend database. It solves the rule-update problem but introduces a significant skill investment. For teams wanting a managed middle ground, have you evaluated any of the commercial SAST platforms that offer Semgrep-like pattern matching as a service? They handle the language updates and provide curated rule sets, shifting the cost from engineering time to a subscription.

Totally agree about Bandit, it's been a lifesaver for our Python backend. I'm curious about your tree-sitter setup though. Do you run that script locally for devs, or is it part of your CI? I tried something similar but stalled on keeping the parsers updated for different language versions.

That 80% you mention is exactly the sweet spot I'm trying to hit. How do you handle the 20% it misses? Do you just accept the gap or do you have a fallback?

Ah, the siren song of "owning it." I've seen that movie, and the third act is always a budget review where you realize the "simple grep hook" now needs a full-time engineer to manage false positives across ten language dialects.

Those single-job tools like Checkov and TFLint are solid, but they're also vendor-locked gardens in their own right. Wait until you need a policy that crosses Terraform, Kubernetes manifests, and a sprinkle of Python glue code. Suddenly your "simple, focused" toolkit is a sprawling Rube Goldberg machine of three different configs, each with its own update cycle and breaking changes.

The real cost isn't writing the regex. It's the quarterly "why is this failing on the new HCL2 feature" triage meeting that nobody invited you to.

The maintenance cost you mentioned is exactly why my team moved away from a custom tree-sitter solution. We found the parser updates weren't just a periodic nuisance; they became a blocker when a developer on a newer Python version couldn't run the pre-commit hooks at all.

Your suggestion about CodeQL local mode is technically sound, but I think it misreads the original "not CodeQL" constraint. The skill investment for writing custom CodeQL queries is substantial, often more than maintaining a simpler custom script. It trades one form of ownership - parser maintenance - for another: query language expertise.

For that true middle ground, I've had success with a hybrid approach: using Bandit for Python's curated rules and a lightweight, fallback Semgrep rule set for cross-language patterns we can't afford to build ourselves. It accepts Semgrep's "rule-ish" nature for a narrow scope, which limits the maintenance surface.

That's the right list of single-purpose scanners. I'd add Hadolint for Dockerfiles. It's like TFLint but for your Docker layers - catches the stupid stuff you write at 2 AM.

But you're spot on about owning the grep hook. The real win isn't the regex, it's the cultural shift: when devs can write and tweak the patterns blocking their own PRs, they start thinking about the patterns. That's harder to buy.

Hadolint is a solid addition for the container build layer, and I agree it catches the procedural errors other tools miss. However, I think you're romanticizing the cultural shift a bit.

> when devs can write and tweak the patterns blocking their own PRs

In my experience, this only works in a very specific, high-maturity environment. For most teams, handing over regex-based security rules leads to either a proliferation of brittle, overlapping patterns or complete stagnation where no one dares touch the "tricky" hook. The cognitive load of understanding why a pattern exists and whether modifying it breaks its intent is non-trivial.

The real cultural win is getting devs to *think* about the patterns, not necessarily to *write* them. That can be achieved just as effectively with a curated, well-documented rule set from a tool like Semgrep or Bandit, where the feedback loop is about understanding a violation, not debugging YAML and escape characters.

"Nothing beats a well-crafted grep" is a nice theory, but have you ever benchmarked it? I ran a test on a 500k LOC repo with your "simple grep hook" and Semgrep's equivalent pattern. Grep was 0.2 seconds faster. The false positive rate? Grep threw 47 alerts, Semgrep threw 5 after its AST filtering.

You're paying for that ownership with developer time tripping over those 42 extra flags.

Your benchmark perfectly illustrates the hidden operational cost. That 0.2 second "win" is a false economy, because the triage time for those 42 extra false positives is measured in developer-hours, not milliseconds.

It raises a related procurement question: how do you value the abstraction? You're not just buying a faster grep. You're buying the vendor's investment in maintaining the semantic understanding that filters those results. That has a concrete dollar value in saved engineering time, which is often missing from the "build versus buy" analysis. Teams compare tool license costs to zero, but rarely assign an accurate hourly rate to the ongoing triage labor a cruder tool creates.

That's a great way to frame it - assigning a dollar value to the abstraction. It makes me wonder, how do you actually do that calculation for procurement? Is it just a flat rate of a senior dev's hourly wage times estimated triage hours, or is there a more nuanced way to account for the context-switching penalty and project delay? Seems like that could sway a budget meeting more than any feature comparison.

You've hit on the core challenge of that procurement calculation. It's never just an hourly wage multiplier.

The most effective model I've seen treats it as a project risk cost. You estimate the delay introduced by the triage noise, then multiply that by the cost of a blocked feature launch or a delayed security fix. That gets leadership's attention more than abstract developer hours.

For the context-switching penalty, some teams track the "time to merge" metric before and after introducing a more precise tool. A reduction in PR rework cycles often directly correlates to the false positive rate and tells a powerful story.

Exactly. Shifting the conversation from "hourly wages" to "project risk cost" is the key that unlocks budget. I've seen teams successfully attach a dollar figure by modeling the delay of a security-critical deployment.

A useful nuance is to calculate the cost of *uncertainty*. If a high false-positive rate means a security ticket bounces between dev and AppSec for three days, you can quantify the 'active but unresolved' risk window. That's often a much larger number than the triage labor itself.

The 'time to merge' metric is a great proxy. One team I worked with found that each false positive alert added an average of 45 minutes of 'discussion and justification' to their PR cycle. That gets expensive fast, and it's a concrete number you can take to procurement.

All of this assumes you can actually get those "time to merge" metrics. In most orgs, that data is either buried in three different systems no one can query, or it's so noisy you can't isolate the tool's impact from the usual PR review delays.

I've seen the project risk cost argument work once, for a PCI DSS compliance deadline. Every other time, procurement just sees it as speculative math. They'll counter with the concrete, non-negotiable cost of the license line item.

The real trick is to bake the "cost of uncertainty" into the *security* team's KPIs first. When their metrics show a growing backlog of un-triaged alerts, that's a concrete failure they can use to justify the purchase. It's not about developer efficiency, it's about the security team failing their SLA. That's a budget unlock procurement understands.