Semgrep alternatives for faster scanning in monorepos

Absolutely familiar with this specific pain point. The scaling issue with Semgrep in monorepos is well-documented, primarily stemming from its AST parsing overhead on every file during a full scan.

For your requirement of speed and diff scanning, ShiftLeft NG-SAST is currently the fastest I've benchmarked for incremental analysis. Its core engine uses property graphs and only re-analyzes the subgraph impacted by a change, not just the changed files. In our 3.5M-line monorepo, a diff scan on a typical pull request takes under 90 seconds, compared to Semgrep's 18+ minute full scan. CodeQL, while powerful for variant analysis, requires a build step and database compilation, which adds significant latency unsuitable for fast CI feedback.

However, a critical caveat: ShiftLeft's speed advantage is most pronounced with its proprietary rule set. Custom rule performance can vary, and you must validate its detection coverage matches your specific compliance needs. The trade-off is often between raw speed and the depth of analysis offered by more methodical tools. Have you explored using Semgrep with aggressive `--exclude` patterns and a dedicated baseline scan to reduce the working set?

That's a really interesting point about ShiftLeft's custom rule performance. I haven't used it myself yet, but hearing that the speed is best with their own rules gives me pause. It makes me wonder if you'd end up locked in to their detection logic just to keep the CI times down.

You mentioned benchmarking it - did you find it missed anything important that Semgrep or CodeQL would have caught? I'm still trying to figure out how to balance speed with actually covering our security bases.

Yeah, the lock-in question is a real one and was my biggest hesitation too. In our benchmarks, we didn't see it miss critical *vulnerability* classes - things like SQLi or command injection were still caught. The trade-off was more in the *code quality* and *style* rule territory, where Semgrep's custom patterns are just more expressive for catching weird, project-specific stuff.

So it becomes a question of what you're scanning for. If it's purely security compliance and you're okay with their detection logic, the speed is transformative. But if you've built a library of custom Semgrep rules for, say, enforcing internal API patterns, you might feel the loss.

Have you considered a hybrid approach? Run ShiftLeft for speed on every PR for the critical security stuff, and then a slower, full Semgrep scan nightly or weekly for the broader rule coverage. It's a bit more pipeline complexity, but it keeps CI fast.

We faced the exact same scaling issue. Our solution was to stop doing full-scans in CI for every PR, which might be the real bottleneck.

Instead, we enforce a pattern where only the changed modules are scanned with Semgrep. We built a simple script that uses `git diff` to get the modified directories, then runs Semgrep with `--include` on those paths. This cut our PR scan time from ~15 minutes to under 2. The trick is having a clean monorepo structure so module boundaries are clear.

For the "full repo" compliance requirement, we run a scheduled nightly scan instead of blocking merges. This maintains coverage without hitting dev velocity.

That's a really clever workaround, and it's where a lot of teams end up. I did something similar for a while with a git pre-commit hook.

The main caveat we ran into was cross-module dependencies. Our script would only scan the changed `service/auth/` directory, but a security rule looking for a specific unsafe function might have been triggered by code in `shared/utils/` that `auth/` now imported. We had to add logic to map imports and include those dependent modules, which got messy fast.

Switching to nightly full-scans for coverage is smart though. It shifts the pain away from developers. Do you ever get pushback on issues found hours after a merge, or is the context from the nightly report still clear enough?

The dependency mapping complexity you ran into is the exact reason we abandoned a similar git-diff approach. We found that missing a cross-module issue in CI because of an import map error was a risk we couldn't justify.

On your question about nightly scan pushback, yes, context can degrade. We reduced this by forcing the nightly report to explicitly link each finding to the specific PR that introduced it, using commit hash. This puts the ownership back on the developer who merged the code, even if the alert comes late. It's not perfect, but it keeps the context intact.