Been running Semgrep in CI for a few months. The out-of-the-box rule sets (like `p/ci`) generate too many findings for a mature codebase. Most are low-severity or style-related, causing alert fatigue and slowing down PR merges.
Key issues:
* Flagging `TODO` comments as "secrets" - clutters reports.
* Generic "insecure randomness" warnings for non-crypto contexts.
* Language-specific style rules that conflict with internal linters.
You need to curate heavily for production. Start with a minimal set and add rules deliberately. My baseline config now looks like this:
```yaml
rules:
- r2c-ci-audit.git-secrets:
severity: WARNING
- r2c-ci-audit.shell-command-injection:
severity: ERROR
- r2c-ci-audit.path-traversal:
severity: ERROR
```
Everything else is opted into, not out of. Anyone else strip it back to the bare essentials? What's on your mandatory list?
Agree 100%. The default rules are for breadth, not precision. It's a scanner demo config.
We did the same, but we kept one more: `r2c-ci-audit.audit.sqli`. Catching even one legit SQLi pattern is worth the noise. Everything else we add only after a real vuln slips through.
Your minimal list is solid. The "insecure randomness" one was the first we dropped.
Benchmarks don't lie.
That baseline config is spot on. We landed on almost the same three, but we also kept `r2c-ci-audit.deserialization` on error. We had a real instance where a dev used `yaml.load` instead of `yaml.safe_load` in a new service, and it would have shipped.
The "TODO as a secret" one drove me nuts too. It's a perfect example of noise that trains people to ignore the scanner. Once we stripped everything back to the critical security risks, devs actually started paying attention to the alerts.
api first
Oh man, the `TODO` comments flagging as secrets was the worst for us too. We had this one PR where 90% of the findings were just TODOs in our data mapping modules. Totally trained the team to ignore the check.
Your minimal config makes so much sense. I'm curious, do you run it in blocking mode for those ERROR severity rules? We're thinking of doing that, but worried about false positives for the shell-command-injection one stopping a hotfix.
null
Totally agree. We started with the default set and it was chaos for our legacy services. Your baseline looks great. For us, the "deserialization" rule (like user403 mentioned) was a must-add after a similar yaml.load scare.
I'm curious about your opt-in approach. Do you have a process for vetting new rules before adding them, or is it just reactively adding after something slips through?
~Isla