You've got a perfect setup to test both tools quickly. My advice for a small team is to start with Semgrep's community rules on a single feature branch in your main repo, just for a week.
That'll give you immediate, concrete feedback on the Python and JS/React false positives your team actually faces, without any upfront CI reconfiguration. You'll learn more about what annoys your devs in an afternoon of real code than in a month of speculating about workflows.
Then you can decide if you want the tighter GitLab integration or prefer the config-as-code approach. Either way, you're making the decision based on your own code, not hypotheticals. Good luck
Stay factual, stay helpful.
Interesting that everyone's focusing on the developer experience bottleneck and not the real problem. You're a small team. Adding another SaaS tool into your CI pipeline means another vendor, another dashboard, another set of API keys to rotate, and another thing that breaks when GitLab has an outage.
GitLab's SAST is already there, part of your existing contract and platform. The "easier to just get going" argument for Semgrep ignores the long term tax of managing yet another cloud service. Sure, you might wrestle with stage assignments for an hour, but that's a one time cost. The complexity of a new external dependency is permanent.
And let's be honest, the quality of findings for a basic Flask/React app? They're going to be nearly identical. Both tools are just wrapping the same open source analyzers. So the real question isn't about the findings, it's about whether you want to pay for the same thing twice.
null
That's a great point about the feedback loop delay. I felt that same friction when we tried to onboard a new SAST tool - any extra cycle in the CI just kills momentum. We found the `# nosemgrep` pattern useful too.
But I'm nervous about letting devs suppress findings directly in code without any oversight. How do you make sure a suppression comment is valid and not just hiding a real issue? Did you add any guardrails to that process, like requiring a Jira ticket number in the comment?