自建代码扫描选SonarQube服务器还是Semgrep：按语言支持与规则管理判断

自建代码扫描平台时，真正的分歧通常不是“哪一个能发现更多问题”，而是团队需要一套集中治理的代码质量平台，还是一套方便快速编写安全规则的扫描引擎。如果重点是多项目统一质量门禁、问题生命周期和长期趋势管理，通常优先考虑部署 SonarQube服务器；如果重点是针对业务框架快速编写规则、通过Git维护策略并嵌入CI，Semgrep更灵活。

需要先对齐比较口径：SonarQube Server本身包含持久化的服务端管理能力，而开源Semgrep CLI主要是扫描引擎。若企业还需要统一策略、权限、审计和报表，不能用“SonarQube Server对比裸Semgrep CLI”，而应将Semgrep CLI、规则仓库、CI执行器以及结果管理组件作为一个完整方案评估。

不要只按“支持多少种语言”做决定

代码扫描工具所说的“支持某种语言”，至少包含四个层次：

1. 能否正确解析语法。
2. 是否具备足够的内置规则。
3. 是否支持跨函数、跨文件或数据流分析。
4. 是否理解项目的构建产物、依赖关系和框架特征。

工具能够解析代码，不代表它对该语言拥有成熟的缺陷检测能力；能够匹配单个文件中的危险写法，也不代表可以还原跨模块调用链。实际选型时，应按代码库中的主语言和关键框架逐项验证，而不是直接比较官网列出的语言数量。

因此，Java、C#、JavaScript、TypeScript、Python等常见语言是否“可用”，还应进一步拆成：目标版本能否分析、关键规则是否存在、框架是否能识别、是否需要构建产物，以及所需能力是否包含在计划采用的版本中。

对于模板语言、内部DSL、代码生成文件、嵌入式脚本和较新的语言特性，两种方案都不应只看支持列表。最可靠的方法是拿真实仓库进行概念验证，并检查解析错误、跳过文件和无法识别的语法。

SonarQube更适合集中式质量治理

SonarQube服务器的优势并不只是扫描器，而是它将项目、规则配置、质量门禁、问题状态和历史变化集中到服务端管理。扫描通常由开发机或CI中的Scanner发起，分析结果进入服务器，由服务器保存并展示。

它更适合以下需求：

• 多个团队需要使用统一的质量标准。
• 不同项目需要按语言分配规则配置。
• 合并或发布前必须通过统一质量门禁。
• 需要跟踪新增问题，而不是每次都重新查看全部告警。
• 需要对误报处理、问题确认和责任分配保留集中记录。
• 除安全问题外，还关心可维护性、可靠性和代码重复等指标。

SonarQube中的规则管理通常围绕语言规则和质量配置展开。管理员可以启用或停用规则、调整部分规则参数，再把质量配置分配给项目。对于“现有规则够用，只需要统一控制启用范围”的团队，这种管理方式成本较低。

它的边界也比较明确：如果企业经常需要根据内部SDK、私有框架或特定调用链新增规则，开发和维护自定义分析插件通常比修改一份YAML文件复杂。插件还可能涉及分析器接口、打包、测试和升级兼容性，不能只计算第一次开发规则的时间。

部署层面，SonarQube Server还意味着持续维护应用服务、数据库、持久化数据、备份和升级。代码库数量、分析历史、并发任务和启用的分析器都会影响资源需求。不能仅根据代码行数直接估算服务器配置，应该通过实际扫描任务观察分析耗时、后台任务积压、数据库增长和服务资源占用。

Semgrep更适合规则即代码

Semgrep的核心优势是规则表达和迭代速度。规则可以与业务代码一样进入Git仓库，经过代码审查、自动测试和版本发布，再由CI执行。这种模式适合安全团队主动维护规则，而不是主要依赖工具内置规则的场景。

例如，团队可以为Python项目建立一条禁止直接启用Shell解释的候选规则：

rules:
  - id: python-subprocess-shell-true
    languages:
      - python
    message: 检测到 subprocess 调用启用了 shell=True，请确认命令参数是否可被外部输入影响
    severity: ERROR
    patterns:
      - pattern: subprocess.$FUNC(..., shell=True, ...)

这条规则只是筛选风险点，不能直接证明存在命令注入。上线前还要补充正反例测试，并结合项目中的封装函数、导入别名和可信常量调整范围。Semgrep规则容易编写，也意味着团队更容易产生重复规则、宽泛规则和高误报规则，因此必须建立规则评审机制。

Semgrep更适合以下情况：

• 安全团队需要频繁增加业务专用规则。
• 代码中存在大量内部框架、封装API和组织约定。
• 团队习惯用Git管理规则变更和回滚。
• 扫描控制点主要位于CI，不强依赖独立的质量门户。
• 希望把规则测试与应用测试一起执行。
• 需要针对少量高风险模式快速建立阻断策略。

需要注意，Semgrep CLI本身不等于完整的集中治理平台。团队如果只在不同CI任务中运行CLI，还要自行解决规则版本统一、结果归档、误报状态、权限控制、策略例外和审计记录等问题。若考虑商业平台或本地化部署能力，应按目标版本核对部署方式、授权边界及管理功能，不能把平台能力默认算作开源CLI能力。

规则管理方式比规则数量更重要

两种方案的规则管理思路差异较大，采购或技术负责人可以从规则的生产流程判断。

如果企业的规则大多来自成熟内置规则集，新增规则频率低，但要求项目统一执行，那么SonarQube Server更符合管理习惯。

如果企业规则经常随着攻击手法、内部框架和编码规范变化，且有人员负责规则测试与维护，那么Semgrep的规则即代码模式更高效。不过，必须明确规则负责人、测试要求、版本发布和误报处理方式，否则灵活性会迅速转化为维护负担。

用真实代码库完成一轮对比验证

选型验证应使用同一个提交、相同的源码范围和相同的排除目录。不要比较两边的告警总数，因为规则口径不同，告警更多并不能直接代表检测能力更强。

第一步：盘点实际语言组成

可在Git仓库中先按文件扩展名进行粗略统计。以下命令只读取已跟踪文件，不会修改仓库：

git ls-files | awk '
{
    n = split($0, path, "/")
    file = path[n]

    if (file !~ /\./) {
        ext = "[no-extension]"
    } else {
        sub(/^.*\./, "", file)
        ext = tolower(file)
    }

    count[ext]++
}
END {
    for (ext in count) {
        print count[ext], ext
    }
}
' | sort -nr

扩展名统计无法识别模板中的嵌入式语言，也无法判断生成代码，应再人工确认以下内容：

• 主业务语言及其版本。
• 前后端框架和内部SDK。
• 自动生成目录与第三方代码目录。
• 构建工具、依赖文件和测试报告格式。
• 模板、脚本、基础设施配置等非标准源码。

第二步：建立关键规则样本

不要只使用工具默认规则。建议从历史缺陷和安全问题中选择一组代表性场景，例如：

• 外部输入进入命令执行或数据库查询。
• 业务封装函数绕过了常见安全API。
• 禁止使用的加密算法或内部废弃接口。
• 资源未关闭、异常被吞掉等质量问题。
• 企业要求必须阻断的编码模式。

随后检查SonarQube目标语言分析器是否已有对应规则，以及Semgrep能否在可接受的复杂度内表达。对于跨文件调用链，还要确认采用的具体版本和引擎是否具备所需分析能力。

第三步：以相同范围运行扫描

SonarQube项目可以通过类似配置指定源码、测试和排除范围：

sonar.projectKey=example-service
sonar.sources=src
sonar.tests=tests
sonar.sourceEncoding=UTF-8
sonar.exclusions=**/generated/**,**/vendor/**

Token不应写入仓库，可以通过CI密钥变量传入。实际参数应与所用Scanner和SonarQube Server版本核对：

sonar-scanner \
  -Dsonar.host.url="$SONAR_HOST_URL" \
  -Dsonar.token="$SONAR_TOKEN"

Semgrep可以先以非阻断方式执行规则仓库：

semgrep scan --config rules/ src/

确认规则稳定后，再决定哪些严重级别可以让CI失败。不要在首次接入时把所有发现都设为阻断，否则历史问题和误报可能直接影响正常交付。

第四步：按业务结果验收

建议为每项记录“通过、部分通过、不通过”以及原因：

性能也应记录，但应在相同CI资源和相同代码提交下重复运行，区分首次下载、缓存命中、构建耗时与纯扫描耗时。不要把一次运行时间直接当作长期服务器容量依据。

哪些情况下不适合选单一方案

只部署SonarQube Server，不一定能快速覆盖所有内部安全规则；只运行Semgrep CLI，也不一定能满足跨团队的质量治理和审计需求。以下场景可以考虑组合使用：

• SonarQube负责通用代码质量、项目趋势和统一质量门禁。
• Semgrep负责内部框架、危险API和高优先级安全规则。
• 两者在CI中分开执行，分别设置阻断条件。
• 为重复规则指定唯一责任工具，避免同一问题生成两条工单。
• 统一排除生成代码、第三方目录和测试样例。
• 明确误报由哪个平台记录，避免开发人员重复处理。

组合方案会增加维护面，不应因为“两套看起来更全面”就同时上线。只有在SonarQube内置治理能力和Semgrep自定义规则能力都被真实需求使用时，组合才有意义。

按条件确定选择路径

下单或投入部署前，可以按以下顺序判断：

1. 先列出不可缺失的语言、框架和分析深度；任一方案无法覆盖关键语言时，直接排除，不用继续比较界面和报表。
2. 如果大部分规则来自成熟内置规则，并且需要多项目统一配置、问题状态和质量门禁，优先评估SonarQube服务器。
3. 如果规则主要来自内部安全经验，需要频繁编写、测试和回滚，优先评估Semgrep。
4. 如果计划使用Semgrep CLI自建，确认是否已经有规则仓库、CI执行器、结果归档和审计方案；缺少这些组件时，它不能替代完整的集中平台。
5. 如果同时需要质量治理和快速安全规则，先划分两套工具的责任边界，再决定是否组合部署。
6. 最终依据目标版本的语言支持矩阵、规则能力、部署文档和授权范围复核，不沿用旧版本经验。

上线前还应保留原有CI流程，先以非阻断模式运行一个完整开发周期，观察解析失败、误报处理、规则变更和任务积压。确认关键规则可复现、例外可审计、升级可回滚后，再逐步启用合并阻断或发布门禁。