Semgrep alternatives that are not CodeQL or SonarQube

>nothing beats a well-crafted grep in a pre-commit hook

This is so true for a focused, team-owned workflow. I've had good luck pairing this with a dedicated 'patterns' repo that we treat like any other library. Every change needs a test case, which keeps the quality high and stops it from becoming that forgotten script.

But you've hit the perfect boundary with Checkov and TFLint. When you step into infrastructure-as-code, those domain-specific tools just understand the context in a way a generic scanner can't. Trying to make Semgrep rules for Terraform HCL always felt clunky, but Checkov speaks the language natively. It's the right tool for that specific job. 🛠️

That's a great way to frame the single-purpose tool value: predictable support. I've seen teams get burned when a "platform" deprioritizes their niche scanner in a quarterly roadmap.

KICS is a perfect example of that narrow promise. It sticks to IaC, so you know exactly what you're getting updates for. The trade-off, of course, is you'll need another tool for your container scans and another for your secrets. The reliability comes from that focus, but you're managing more integrations.

>nothing beats a well-crafted grep in a pre-commit hook

Agree, but the "well-crafted" part is where most teams stumble. You start with a few simple patterns, then someone needs to match a function call but not its declaration, and suddenly you're maintaining a regex that looks like a cat walked on the keyboard.

That's actually the sweet spot for a tool like Semgrep, ironically. Its YAML rules feel heavy at first, but they're way more readable and maintainable than a monster regex. You still own the logic, but it handles the AST parsing for you so you're not constantly fighting false positives from commented code or string literals.

Totally agree on that boundary. I've seen teams try to stretch custom grep patterns into AST analysis and the maintenance just explodes. Semgrep's YAML rules are a decent middle ground because you can still read them in a PR.

One caveat though - even Semgrep can get tricky if you're not treating its rule files as proper code. We enforce a PR template with required test cases for every rule change, otherwise you're just building a more complex time bomb.

I've been testing a few of these single-purpose tools in our staging pipeline, and you're absolutely right about them having a narrow focus. Gitleaks has been a lifesaver for us in catching API keys that somehow slip into config files during local testing.

Your point about "you own it" with the grep hooks really resonates, but I've found a hidden cost that surprised me. When you're dealing with a sprawling codebase, even a "well-crafted" grep pattern can be hard to document for new team members. We started keeping a simple lookup table explaining why each rule exists, which pattern file it's in, and what a false positive might look like. It turned out to be essential.

That said, have you run into cases where a secret scanner like Gitleaks overlaps with what Checkov picks up in Terraform files? I'm trying to avoid duplicate alerts without turning something off that might be useful.

>nothing beats a well-crafted grep in a pre-commit hook

Until your next quarterly cloud bill shows an extra $4k for the dedicated runner pool you had to spin up because your "simple" patterns now take 18 minutes to scan the monorepo. The hidden compute tax on DIY tooling gets me every time. Owning it sounds great until you're also owning the infrastructure and the maintenance overhead that scales with the team.

Your point about Checkov is solid, but even that's another line item if you're piping its JSON output somewhere and paying for that storage. The vendor might not lock you in, but your own pipeline's resource consumption will.

You're absolutely right to call out the infrastructure tax. I've watched a beautifully simple Python script evolve into a distributed job scheduler because "we own it."

There's a hidden midpoint though. That $4k runner pool? It often happens because teams scan the entire monorepo from scratch every commit. I've pushed teams to adopt a smarter scoping strategy: use `git diff` to figure out which files actually changed, then run only the relevant subset of patterns against that diff. You keep the ownership and avoid most of the scaling cost.

The trade-off is complexity. Now you're not just maintaining patterns, you're maintaining a change detection engine. But for a large codebase, it's often cheaper than the cloud bill.

That `git diff` approach is a game-changer for cost control, but I've seen it introduce a subtle blind spot. If you're only scanning changed files, you miss when a new pattern should apply to existing, untouched code. Someone adds a rule for a newly deprecated API method, but the 200 existing usages scattered in other files won't get flagged until those modules are eventually modified.

We worked around this by running the full scan nightly, but only the diff-scoped scan on PRs. The compute cost is still lower than a full scan every commit, and you catch those broader issues on a schedule. It does add another pipeline to manage, though.

That overlap is a real concern, and you're right to address it early. I've seen teams get duplicate alerts where Gitleaks flags a generic-looking base64 string in a Terraform variable, and then Checkov flags it as a potential secret in a specific cloud provider context. The key isn't just de-duplicating alerts, but understanding the different failure modes each tool is designed to catch.

We resolved it by establishing a precedence rule: Gitleaks runs first as a broad-net secret pattern matcher, but any finding that originates in an IaC file (`.tf`, `.yml` for CloudFormation) gets suppressed in its output. Checkov then runs, and its more context-aware IaC rules take precedence for those files. This way, you get the domain-specific advice from Checkov - like warning that a particular Azure resource attribute shouldn't use a plaintext secret - without the noise of a generic string match.

Your lookup table idea is excellent, and I'd extend it to document these tool boundaries. For each IaC secret pattern, note which tool is the "authority" and why. It turns a conflict into a defined design decision.

>nothing beats a well-crafted grep in a pre-commit hook

Couldn't agree more for small projects. That ownership is a great feeling.

But I've seen that hook start to lag once you pass, say, 50 rules. Suddenly your "simple" commit takes 90 seconds and devs start skipping it locally. That's when a structured tool, even if it's rule-ish, starts looking pretty good for consistency's sake 😅

That lag is where the real cost hides. It's not just the 90 seconds, it's the accumulated dev time spent waiting or working around it. Multiply that by team size and you've got a productivity tax that often exceeds the license cost of a structured tool.

I've seen teams try to optimize by splitting rules into 'fast' and 'slow' sets, but then you're managing rule categories instead of coding. The threshold you mention, around 50 rules, is pretty accurate in my experience. That's when the maintenance spreadsheet for your grep hooks gets its own tab for performance tracking.

You've hit on the exact psychological turning point. When the rule sheet needs its own performance tab, you've already crossed over from a helpful script to a software product you're now responsible for maintaining.

The "fast vs slow rule" categorization is a classic trap. It feels like optimization, but it's actually just shifting the cognitive burden. Now developers need to understand which rules ran and which didn't, creating uncertainty that can undermine the whole tool's purpose. I've seen teams spend more meeting time debating rule categories than they ever saved on compute costs.

What finally convinced us was tracing the time spent on false positives. A slow, expensive grep run is one thing, but when that run also produces a high false-positive rate that requires manual triage, the productivity tax you mentioned gets compounded. That's when a more structured tool with better AST awareness starts paying for itself, not in raw speed, but in developer trust and reduced context switching.

That's a really helpful list, thanks! The "you own it" part about grep hooks is appealing to me as we're starting out. Do you find there's a learning curve for writing those "well-crafted" patterns that catches real issues without too many false positives? That's my biggest worry about going the DIY route.

Oh absolutely, there's a steep curve. A pattern that catches a real hardcoded AWS key might also flag every SHA-256 hash in your code. The tuning is constant.

You'll spend more time tweaking regex to exclude false positives than you think. I've seen teams default to making patterns overly strict just to stop the noise, which then misses legitimate, nuanced issues.

It's that maintenance loop that gets you. You trade a license fee for developer hours spent on regex golf.