Hi everyone, I'm trying out Semgrep to learn about SAST tools. I installed the VS Code extension and ran it on a simple test file, but it's not flagging an obvious SQL injection I made.
My file is a basic Python Flask endpoint:
```python
@app.route('/user')
def get_user():
user_id = request.args.get('id')
query = "SELECT * FROM users WHERE id = " + user_id
result = db.engine.execute(query)
return result.first()
```
The extension shows no findings at all. I have the default rules enabled. I expected at least a warning about concatenating user input into a SQL string.
Am I missing a step? Do I need to install extra rule packs or configure something specific for Python/Flask? Or is this just a limitation of the free version? I'm a bit confused because the docs make it sound like it should catch this out of the box.
Any guidance would be great!
I'm a senior security engineer at a fintech with about 200 devs, where we've embedded Semgrep into our CI/CD pipeline and evaluated a half-dozen SAST tools over the years. We run Semgrep Cloud Platform for central rule management on our main Python/Go/JS repos.
* **Target Fit - Early/Mid-Stage Dev Teams:** It's designed for developers, not security specialists, which is why the default rules are conservative. You're hitting its core limitation: out-of-the-box, it's a linter, not a deep security analyzer. To catch your Flask injection, you need the `security-audit` or `python-flask` rule packs, which aren't auto-enabled in the VS Code extension. It's a 10/10 for catching bad patterns you agree are bad (like `assert` in prod), but a 6/10 for finding novel vulnerabilities without custom rules.
* **Real Pricing & The Hidden Cost:** The CLI and basic rules are free; the Cloud Platform starts around $15k/year for a midsize team. The hidden cost is security engineering time. Writing reliable custom rules for things like your Flask endpoint requires understanding Semgrep's pattern syntax and taint tracking, which can take 2-4 hours per complex rule to get right. You're not paying in cash for the free tier, you're paying in configuration and research.
* **Deployment/Integration Effort:** The VS Code extension is a 2-minute install for a "feel." For actual coverage, you need to integrate the CLI into pre-commit hooks or your CI pipeline, which takes a day. The real effort is curating rules: enabling the right community packs, suppressing false positives, and writing 5-10 org-specific rules will consume a solid week of a senior person's time initially.
* **Where It Clearly Wins (and Where It Breaks):** It wins on speed and developer experience; scanning a large monorepo takes under 90 seconds in our CI. It breaks on context. Your example is a textbook case - Semgrep sees string concatenation but, without the specific rule pack, doesn't know that `request.args.get` is a user-controlled source flowing into a SQL sink. It's not a smart analyzer; it's a very fast pattern matcher. It also struggles with custom wrapper functions and frameworks it doesn't have baked-in models for.
My pick is Semgrep, but only if you pair the CLI with the Cloud Platform and have a security engineer to manage rules for the first quarter. It's the right tool for shifting left on agreed-upon bugs and simple vulnerabilities. If you're a solo dev or a tiny team without that security resource, you'll miss exactly the issue you found. Tell us your team size and whether you have dedicated appsec bandwidth, and I can say if you should stick with it or look at a more opinionated, "heavier" alternative.
Attribution is a lie, but we need the lie.
That's a common point of confusion with the extension. You're right, the docs often emphasize what it *can* catch, which makes it seem like it should flag that. The key is that the default rule set in the editor is indeed very basic, mostly focused on code style and a few simple bugs.
You'll need to enable the right rule packs. Open the Semgrep sidebar view, go to the settings, and add `python-security-audit` and `python-flask`. That should pick up the raw string concatenation pattern. It's not a free vs paid limitation, just a configuration step they could make clearer.
Without those packs, you're mostly just getting a fancy linter. Once they're loaded, it should work as you expected.
Keep it constructive.