📚 课程目录第4章静态代码扫描工具选型与集成

4. 静态代码扫描工具选型与集成

IaC静态扫描工具的核心价值，是在资源被真正创建之前，从代码文本中识别出安全配置缺陷。但不同工具的解析引擎、规则来源、覆盖范围和集成方式差异很大，选型时不能只看“规则数量”或“是否支持Terraform”，而要回到三个问题：它解析什么、它能发现什么、它如何嵌入流水线并阻断风险。

一、五类工具的能力边界

Checkov基于Python编写，采用“解析器+策略”架构，对Terraform、CloudFormation、Kubernetes、Helm、ARM等均有支持，规则以Python策略和YAML策略两种形式存在，适合多云混合环境。它的优势在于策略可编程、可自定义，且能输出SARIF、JUnit、JSON等多种格式；不足是规则数量庞大时误报率会上升，需要配合基线抑制。

tfsec专注Terraform，用Go编写，扫描速度快，规则直接对应AWS、Azure、GCP的具体资源属性，例如S3桶是否开启加密、安全组是否开放0.0.0.0/0。它的边界也很明确：只覆盖Terraform，对Kubernetes清单、CloudFormation等无能为力。若团队只使用Terraform，tfsec是轻量高效的选择。

KICS由Checkmarx维护，支持Terraform、Kubernetes、Docker、Ansible、CloudFormation等，规则以Rego（OPA）编写，查询能力灵活，适合已经采用OPA体系或需要跨IaC类型统一策略的团队。其规则更新频率和社区活跃度略逊于Checkov，但Rego带来的表达力在复杂条件判断上更强。

Terrascan同样基于OPA/Rego，强调“策略即代码”，支持Terraform、Kubernetes、Helm、Kustomize等，并能与Kubernetes准入控制集成。它的定位偏向策略治理平台，适合需要将IaC扫描与运行时策略统一管理的场景；但规则库规模相对较小，部分云资源覆盖不如Checkov细致。

Semgrep严格来说不是IaC专用工具，而是通用语义代码扫描器。它通过模式匹配和轻量数据流分析，可以扫描Terraform HCL、Kubernetes YAML中的危险写法，例如硬编码密钥、明文密码、不安全的镜像标签。它的优势是自定义规则极其灵活，能发现“配置逻辑”层面的问题；不足是缺少对云资源语义的深度理解，无法判断某个属性组合是否真正违反云安全基线。

选型判断可以归纳为：多云广度优先选Checkov，纯Terraform速度优先选tfsec，OPA/Rego体系选KICS或Terrascan，自定义语义规则和密钥检测选Semgrep。实际落地中，多数团队会采用“1个主扫描器+1个补充扫描器”的组合，而不是只依赖单一工具。

二、CI流水线中的扫描门禁设计

工具选型确定后，关键是把扫描嵌入到正确的阶段，并定义清晰的阻断规则。一个可落地的门禁设计通常分为五层。

第一层：提交前本地扫描。通过pre-commit钩子调用tfsec或Checkov，只扫描本次变更的文件。这一层不阻断提交，但能快速反馈，减少进入CI的明显错误。示例配置：

repos:
  - repo: https://github.com/aquasecurity/tfsec
    rev: v1.28.0
    hooks:
      - id: tfsec
        args: ["--minimum-severity", "HIGH"]

第二层：PR构建阶段全量扫描。在CI的pull_request事件中，对仓库全量IaC代码执行主扫描器，同时用Semgrep补充密钥和逻辑缺陷检测。输出统一转为SARIF格式，上传到代码平台，使问题直接显示在PR的变更行上。这一层必须设置超时和缓存，避免全量扫描拖慢流水线。

第三层：策略判定与基线比对。扫描结果不能直接等同于门禁结论。需要将发现的问题按严重度分级，并与已批准的基线进行比对。基线中记录的是“已知且接受”的风险，例如测试环境中的宽松安全组。基线之外的CRITICAL和HIGH必须阻断，MEDIUM产生告警但不阻断，LOW和INFO仅记录。

第四层：门禁决策。在CI配置中显式定义退出码逻辑。以Checkov为例，可以使用--hard-fail-on CRITICAL, HIGH让扫描器在命中严重问题时返回非零退出码，从而阻断流水线。对于需要临时豁免的情况，通过--skip-check或基线文件放行，但豁免必须附带审批记录和到期时间。

第五层：合并与部署放行。只有扫描门禁通过后，才允许合并到主分支并触发部署流水线。部署阶段可以再次运行扫描，但此时扫描对象应是已构建的制品或计划文件（如terraform plan的JSON输出），以捕获变量插值后才会暴露的问题。

常见误区：把扫描器接入CI但不设置阻断，结果所有问题都变成“仅供参考”。门禁必须至少对CRITICAL和HIGH产生阻断，否则扫描就失去了治理意义。另一个误区是只扫描变更文件，导致历史遗留问题永远不被发现；建议PR阶段做差异扫描，每日定时任务做全量扫描。

三、组合策略与落地建议

实际项目中，推荐“Checkov或tfsec作为主扫描器 + Semgrep作为补充”的组合。主扫描器负责云资源安全配置的广度覆盖，Semgrep负责硬编码密钥、明文密码、不安全的镜像标签等语义问题。如果团队已经使用OPA管理Kubernetes准入策略，可以把KICS或Terrascan纳入，实现IaC扫描与运行时策略的统一。

集成时还需要注意三点：一是扫描器版本要固定，避免规则更新导致流水线突然失败；二是扫描结果要集中存储，便于趋势分析和审计；三是门禁规则要定期评审，随着业务变化调整严重度阈值和基线内容。工具是手段，门禁策略才是治理的核心。