Semgrep在VSCode中只需安装官方插件并配置本地CLI和规则文件即可运行：先用pipx install semgrep安装CLI，再在VSCode设置中指定其路径；插件通过读取项目根目录下的.semgrep.yml（如含硬编码密钥、SQL拼接等Python规则）执行本地AST扫描，保存文件即触发单文件检测，右键可全量扫描，无需联网或商业平台。
直接装插件 + 本地规则文件就能跑起来，不需要连商业平台或配复杂服务端。 Semgrep 在 VSCode 里本质是调用 CLI 工具做本地静态分析，核心就两件事：让编辑器知道 semgrep 命令在哪，以及告诉它用哪套规则扫描哪些文件。
怎么在 VSCode 里装上 Semgrep 插件并让它真正工作
VSCode 官方市场里搜 “Semgrep” 找到由 r2c（现 Semgrep Inc）发布的官方扩展，安装后它不会自动生效——它只是个“调度器”，真正干活的是你本地的 semgrep CLI。
- 必须先在系统里装好
semgrep：推荐用pipx install semgrep（避免污染全局 Python 环境），验证是否可用：semgrep --version - 插件默认会尝试找
semgrep在 PATH 里，如果报错 “command not found”，就得在 VSCode 设置里手动填路径，比如 macOS 上可能是/Users/xxx/.local/bin/semgrep - 插件本身不带规则库，它只读你项目根目录下的
.semgrep.yml或通过--config指定的配置；没这个文件，它就安静地不扫任何东西
写一个能落地的 .semgrep.yml 规则文件
别抄网上一堆空泛示例。真实项目要防的是硬编码密钥、日志泄露、SQL 拼接——不是“禁止 print”。以下是一个开箱即用的最小可行配置：
rules: - id: detect-hardcoded-api-key pattern: "api_key = '...'" message: "检测到明文 API 密钥赋值，请改用环境变量" severity: ERROR languages: [python]
id: detect-sql-string-concat pattern: "query = 'SELECT * FROM ...' + ..." message: "SQL 查询字符串拼接，存在注入风险" severity: ERROR languages: [python]
-
id: avoid-print-in-prod pattern: "print(...)" message: "生产代码中应使用 logging 而非 print" severity: WARNING languages: [python] paths: include: ["src/", "app/"] exclude: ["tests/", "migrations/"]
-
paths.include/exclude很关键：不加的话，semgrep默认扫整个工作区，包括node_modules或venv，既慢又全是误报 - 所有
pattern都是基于语法树（AST）匹配，不是正则；所以"api_key = '...'"能匹配换行、空格、变量名变化，比正则鲁棒得多 - 如果想复用社区规则，可把
rules改成rules: https://semgrep.dev/r/python-security-audit，但注意：这会触发网络请求，离线环境失效
-
为什么改了规则文件，VSCode 里没立刻反应
Semgrep 插件默认只在保存文件时触发单文件扫描，不会监听 .semgrep.yml 变更。也就是说，你改完规则，得手动操作一次才能生效。
- 最简单办法：随便打开一个被规则覆盖的 Python 文件，按
Ctrl+S（保存），插件就会用新规则重扫当前文件 - 想全量扫一遍？右键任意文件 → “Semgrep: Run Scan on Folder”，它会执行
semgrep scan --config=.semgrep.yml . - 常见卡点：插件设置里勾选了 “Only run on save”，但你改的是配置文件本身——它不监听自己，所以必须手动触发
- 另一个坑：VSCode 工作区用了多根文件夹（multi-root workspace），而
.semgrep.yml不在最外层根目录，插件可能根本找不到它，得确认配置文件位置
和 Bandit / SonarLint 混用时要注意什么
它们不是互斥关系，但职责不同，混用容易重复告警或漏检。
-
bandit是纯 Python 安全扫描器，专注 crypto、deserialization、shell injection，但不支持跨语言、也不支持自定义 AST 模式；适合补 Semgrep 没覆盖的 Python 特定漏洞 -
sonarlint依赖远程 SonarQube 规则集，很多规则需要连接服务器才能启用；本地离线模式下，它实际只跑一小部分内置规则，和 Semgrep 的本地自治思路完全不同 - 三者共存时，建议用 Semgrep 主守“模式类风险”（如密钥、注入、金额精度），用 Bandit 补“Python 运行时语义风险”，SonarLint 仅用于团队已接入 SonarQube 的场景做规则对齐
- 性能上：Semgrep 单次扫描通常比 Bandit 快 3–5 倍，尤其在混合语言项目里；但 Bandit 对
eval()、subprocess的识别更细粒度
真正难的不是配通，而是判断哪条规则该设为 ERROR、哪条该 WARNING、哪些路径该 exclude——这些决定直接影响开发者会不会无视所有提示。规则越少、越准、越贴近当前项目真实风险，工具才越有用。
