I've been integrating Semgrep into our CI/CD pipeline for several months, and while the centralized findings are valuable, I've found a significant cost and efficiency benefit in running scans locally before pushing code. This pre-commit check acts as a first-pass filter.
The primary advantage isn't just catching issues earlier; it's about reducing the computational load (and therefore cost) on our CI runners. A scan that fails locally never triggers a resource-intensive CI job. For a team of 50+ developers making multiple commits daily, the aggregate savings on CI compute minutes are substantial. I've configured a pre-commit hook that runs a targeted subset of our most critical rules.
```yaml
# .pre-commit-config.yaml
repos:
- repo: local
hooks:
- id: semgrep-pre-push
name: Semgrep Critical Rules
entry: semgrep
language: system
args: ["--config", "p/critical-security", "--error"] # --error ensures exit code on findings
types: [python, javascript, go]
stages: [pre-push]
```
This approach surfaces high-severity security and cost-related patterns (like hardcoded secrets or inefficient database queries in loops) before they even reach a branch. The feedback loop is immediate for the developer, and it prevents the "noise" of repeat findings from the same issue across multiple CI runs. It also allows developers to run broader, more exploratory scans locally on demand without incurring cloud scanning costs or consuming shared CI resources.
I'm curious if others have adopted a similar local-first strategy. Specifically:
* Have you measured a reduction in CI pipeline costs or duration?
* How do you manage rule synchronization between local and CI configurations to avoid drift?
* Are there downsides, like developer environment performance hits, that I'm not weighing heavily enough?
Less spend, more headroom.