VS Code 扩展供应链事件之后，Go 项目如何做一次 GitHub 仓库安全体检

前不久GitHub公开了一起第三方VS Code扩展引发的内部设备入侵事件，官方后续已经全部移除恶意扩展版本、隔离受影响终端，完成全链路安全响应。对Go开发团队来说，当下最该优先处理的不是到处转发相关新闻，而是直接自查手上的项目仓库：一个看起来完全正常的编辑器扩展、Actions工作流甚至忘记删掉的临时密钥，很可能已经拿到了远超自身工作需要的过高权限。

一次实用的体检顺序是：先盘点能改代码和发版的身份，再检查工作流能拿到什么，最后核对依赖、密钥与日志。任何一项说不清，都先收紧权限再继续发布。

这起事件为什么会落到 Go 仓库上

软件供应链的风险入口不只是第三方模块。开发者电脑上的编辑器扩展能接触工作区文件、终端环境和登录态；GitHub Actions又会把代码、依赖和一部分凭据带进构建环境。两条路径一旦连通，风险就从“本地工具不可信”升级成“仓库可能被篡改、构建流程可能被投毒”。

GitHub的公开说明提到，事件涉及第三方发布的受污染VS Code扩展，后续还提醒GitHub Enterprise Server用户只从官方来源获取更新。这个信息对普通Go项目的启发很直接：梳理信任边界时，不能只盯着业务代码，也要把编辑器、工作流和发布凭据全部纳入检查范围。

先盘点四类真正有价值的资产

打开一个Go仓库，先不要急着升级依赖。把下面四类资产列成一张简单表格，对应负责人和失效时间最好能直接明确写出来：

• 代码资产：默认分支、保护规则、能合并代码的成员和机器人账号。
• 构建资产：.github/workflows 中的触发条件、运行环境、第三方action和可写权限。
• 运行资产：发布密钥、镜像仓库令牌、云平台短期凭据，以及它们对应的环境。
• 依赖资产：go.mod、go.sum、私有模块代理和构建时下载的工具。

最容易遗漏的是机器人账号。它们往往没有人类账号那样明显的登录记录，却可能拥有推送代码、创建发布版本或读取环境变量的权限。把“谁有发版权限”单独列出来，通常比逐行过一遍源代码更快发现隐患。

沿着一条攻击路径做分层检查

第一层：工作区和编辑器

检查团队是否允许任意成员安装扩展，尤其是会读取工作区、调用终端或处理凭据的扩展。建议在团队文档里列出经过审核的批准清单，项目根目录不要保存个人配置、云端登录缓存和本地调试密钥。

第二层：GitHub Actions

重点看工作流顶部有没有设置过宽的权限声明。没有写权限需求的构建任务，可以明确配置只读权限；需要发布的任务拆成单独的job，并绑定环境保护规则。拉取外部贡献时，不要让不受信任的代码直接接触生产密钥。

name: go-check
on:
  pull_request:
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version-file: go.mod
      - run: go test ./...

这里的关键不是复制对应版本号，而是确认每个job都能回答两个问题：它为什么需要这个权限？它拿到的变量会不会出现在日志、制品或错误信息里？

第三层：Go 依赖和工具链

先用 go env GOVERSION 记录当前工具链，再查看 go list -m all 与 go mod verify 的结果。Go发布历史显示，Go 1.26.5 和 Go 1.25.12 都包含安全修复，版本选择不能只看“能否编译”，还要确认版本是否仍在官方支持范围内。

对于构建工具，固定版本和校验值比每次拉取最新版更容易审计。私有模块要明确代理和校验策略；出现陌生模块、异常替换指令或突然新增的构建脚本时，先停下合并操作，核对提交来源和变更理由。

体检发现问题后，按风险而不是按文件处理

发现一个问题不代表要全仓库推倒重来。可以按影响路径分级：能改默认分支或创建发布的令牌属于高风险；能读取私有源码的工作流属于中风险；只影响格式化或测试结果的配置属于低风险。分级之后，优先处理“入口可达、权限过大、缺少日志”的组合项。

• 令牌出现在提交或日志：立即撤销并重发，随后回溯搜索历史提交和制品。
• 工作流权限过宽：先改成只读，再给确有需要的发布job单独授权。
• Go版本落后且包含未应用的安全修复：创建小分支升级，跑完单元测试、集成测试和镜像构建验证。
• 第三方action或扩展来源不明：暂停使用，换成官方维护或团队审核过的版本。

修复以后要做反向验证：用一个没有发布权限的测试身份触发普通检查，确认它不能写入默认分支；再用发布环境执行一次小范围构建，核对日志没有打印令牌，最后保存运行链接和提交号。

相关问题与复查记录

安全体检最怕“一次性检查”。建议在仓库里留存不含秘密值的检查记录，至少写下检查日期、工具链版本、工作流权限、依赖变更、令牌轮换动作和复查人。每次修改 .github/workflows、发布脚本或编辑器扩展清单时重新跑一遍检查流程。

为什么私有仓库也要限制 Actions 权限？

私有只说明代码可见范围，不代表工作流、机器人和外部贡献路径天然可信。权限配置得越小，异常代码能带走的信息越少。

只升级 Go 版本能解决供应链风险吗？

不能。工具链升级解决的是已知版本的漏洞问题，扩展、第三方action、依赖来源和令牌暴露这类风险仍需分别排查确认。

发现可疑提交时先删掉提交记录吗？

先保留证据并冻结相关令牌，记录提交号、工作流运行记录和操作者信息，再按团队响应流程清理历史。直接删除会让后续定位缺少关键线索。

发布前的最小验收清单

最后把检查压缩成四个可勾选动作：默认分支保护规则生效；普通工作流只有读取权限；Go工具链和依赖版本有明确记录；发布令牌不出现在提交、日志和构建制品中。四项都能给出对应证据，再把这次体检记录链接到变更单，下一次遇到同类事件响应时就不必从猜测开始。