利用 Git Author/Committer 分离验证构建零延迟 Bot Spam 拦截流水线

开源生态正面临新型自动化威胁的侵蚀。AI 驱动的垃圾代码提交（bot spam）以惊人的速度污染仓库 —— 从低质量的 PR 到自动生成的无意义 Issue，这些行为不仅消耗维护者的审查精力，更可能引入安全隐患。传统的检测方案往往依赖事后分析或外部 API 查询，存在明显延迟。本文探讨一种更原生的防御思路：利用 Git 本身的设计特性，在 CI/CD 流水线层实现零延迟的异常提交识别。

Git 元数据的双重身份设计

Git 的提交对象包含两个看似冗余但语义不同的字段：author（作者）与 committer（提交者）。Author 记录最初编写代码变更的人，而 committer 则表示实际将变更应用到仓库的人或系统。这种分离设计源于分布式版本控制的协作需求 —— 当开发者通过邮件补丁或 rebase 操作贡献代码时，原始作者信息应当被保留，而实际执行提交动作的主体则需要被记录。

在 CI/CD 场景下，这种分离呈现出特定的模式。当自动化工具（如 semantic-release、dependabot）执行提交时，author 字段通常保留触发流程的开发者身份或预设的机器人标识，而 committer 则指向 CI 服务账号（如 github-actions[bot]）。正常的人工提交则往往保持 author 与 committer 的一致性。

这种元数据差异为检测提供了第一层信号：当 author 与 committer 不匹配时，表明提交经过了某种自动化处理。然而，这本身并不足以判定为 spam—— 合法的发布自动化、代码格式化工具都会产生此类模式。关键在于识别 "异常的自动化"。

CI/CD 层的分层验证策略

将验证逻辑嵌入 CI/CD 流水线可以实现提交阶段的实时拦截，避免恶意代码进入主分支。一个健壮的检测策略应当采用多层信号叠加，而非依赖单一指标。

第一层：签名验证。GPG 签名提供了比元数据更强的身份保证。通过要求受保护分支上的提交必须包含有效签名，可以过滤掉大量未配置签名的自动化 spam。CI 流水线可以在构建阶段执行 git verify-commit，验证签名是否来自预定义的信任密钥环。

第二层：Author/Committer 模式分析。当签名验证通过后，进一步检查 author 与 committer 的对应关系。正常的人工提交通常两者一致；合法的自动化工具往往具有稳定的标识模式（如特定的邮箱后缀、一致的命名规范）；而 spam bot 则可能呈现随机化的 author 信息配合 CI 服务 committer，或 author 指向不存在的用户。

第三层：行为频率检测。在短时间内产生大量相似提交是 spam 的典型特征。流水线可以维护滑动窗口计数，当同一 author 或 committer 在设定时间阈值内（如 5 分钟）产生超过设定数量（如 10 个）的提交时触发告警。

第四层：内容启发式检查。结合提交消息模式与代码变更特征，识别模板化的 spam 内容。例如，包含特定关键词组合、变更文件数与代码行数比例异常等。

可落地的流水线配置

以下是一个基于 GitHub Actions 的验证流水线示例，展示如何在实践中集成上述策略：

name: Bot Spam Detection
on: [push, pull_request]

jobs:
  verify-commit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      
      - name: Import trusted keys
        run: |
          for key in .github/trusted-keys/*.asc; do
            gpg --import "$key"
          done
      
      - name: Validate commit metadata
        run: |
          #!/bin/bash
          set -e
          
          COMMITS=$(git rev-list ${{ github.event.before }}..${{ github.event.after }})
          FAILED=0
          
          for commit in $COMMITS; do
            AUTHOR=$(git log --format="%an <%ae>" -n 1 $commit)
            COMMITTER=$(git log --format="%cn <%ce>" -n 1 $commit)
            SIGNATURE=$(git log --format="%G?" -n 1 $commit)
            
            # 检查签名
            if [ "$SIGNATURE" != "G" ]; then
              echo "⚠️ Commit $commit: 缺少有效签名"
              FAILED=1
              continue
            fi
            
            # 检查 author/committer 分离异常
            if [ "$AUTHOR" != "$COMMITTER" ]; then
              # 允许已知的合法自动化账号
              if ! echo "$COMMITTER" | grep -qE "(github-actions|semantic-release|dependabot)"; then
                echo "⚠️ Commit $commit: 未知的自动化提交者 $COMMITTER"
                FAILED=1
              fi
            fi
          done
          
          if [ $FAILED -eq 1 ]; then
            exit 1
          fi

对于 GitLab CI，类似的逻辑可以通过 only:merge_requests 触发器在合并请求阶段执行验证。关键配置参数包括：

• 签名信任级别：仅接受 %G? 返回值为 G（Good）的提交
• 合法自动化白名单：维护一个正则表达式列表，匹配已知的 CI 服务账号
• 时间窗口阈值：建议设置为 300 秒内不超过 5 个提交
• 分支保护范围：仅在 main、release/* 等受保护分支启用严格验证

局限性与增强建议

Author/Committer 分离检测并非银弹。研究数据表明，基于单一元数据字段的 bot 检测容易产生误报，特别是在面对精心设计的对抗性 spam 时。合法的发布自动化工具（如 semantic-release）天然会产生 author/committer 分离，需要仔细配置白名单以避免误伤。

更可靠的方案是将此机制与其他供应链安全措施结合：

1. 分支保护规则：在 GitHub/GitLab 中启用 "Require signed commits" 选项，强制所有进入主分支的提交必须签名
2. 贡献者许可协议（CLA）：要求外部贡献者签署 CLA，建立可审计的贡献者身份库
3. 行为基线学习：对仓库的历史提交进行聚类分析，建立正常贡献者的行为画像，用于识别偏离基线的异常提交
4. 人工审查兜底：对于触发检测规则的提交，自动添加标签并通知维护者进行人工审查，而非直接阻断

结语

Git 的 author/committer 分离设计为 CI/CD 层提供了轻量级的自动化识别信号。通过将其与签名验证、频率监控、内容分析相结合，可以在不引入外部依赖的情况下构建有效的 spam 拦截机制。这种方案的优势在于零延迟 —— 检测发生在代码合并之前，而非事后清理。对于维护公共仓库的团队而言，在现有 CI 流水线中集成这些验证规则的成本远低于处理 spam 污染后的清理成本。

参考来源

• What is the difference between the author and committer in Git? - Stack Overflow
• How to Use Git Commit Signing Verification in Kubernetes Deployment Pipelines - OneUptime Blog
• Evaluating a bot detection model on git commit messages - arXiv

systems