GitHub 扩展日志密钥检测，Actions 输出的泄露处置有何变化

GitHub 最近把 Secret scanning 的覆盖面扩展到了 GitHub Actions 工作流日志。它目前是公开预览能力：企业管理员可以在 GitHub Enterprise Cloud 中，为启用了 GitHub Secret Protection 或 GitHub Advanced Security 的企业打开这项策略。对开发团队来说，变化不只是“多了一个扫描入口”，而是 Actions 输出中的偶然泄露也要进入凭据轮换和事件响应流程。

官方地址：https://github.com/

公告地址：https://github.blog/changelog/2026-11-09-secret-scanning-detects-secrets-in-github-actions-workflow-logs/

启用后，工作流运行完成时，GitHub 会按支持的 provider pattern 扫描日志；发现结果会出现在仓库的 Secret scanning 告警列表中，并回链到对应的 Actions 工作流日志。它不是对所有历史日志的回溯扫描，也不是对所有类型密钥的万能检测。

• 新增范围：GitHub Actions workflow logs。
• 结果位置：仓库的 Secret scanning alert list，并带有日志回链。
• 可用范围：GitHub Enterprise Cloud 企业，且需要 GitHub Secret Protection 或 GitHub Advanced Security。
• 重要边界：默认关闭，只扫描启用后完成的运行；预览期不会为这类告警发送通知。

这次新增的到底是什么检测面

过去，团队通常把 Secret scanning 的注意力放在代码提交、Issue、Wiki、讨论区和 Pull Request 等内容上。新能力把工作流日志也纳入了检测范围。这个变化很实际：调试脚本可能把环境变量拼进错误输出，第三方 Action 可能把参数写进日志，或者维护者为了排查失败任务而临时打印配置对象。即使代码仓库本身没有提交密钥，日志也可能成为新的暴露面。

官方公告说明，工作流运行完成后才会进行日志扫描，命中结果会和其他 Secret scanning 告警放在一起，并指向对应日志。这意味着排查时要把“哪个工作流、哪次运行、哪个日志片段”当成事件上下文，而不是只看告警名称。

怎样判断企业是否具备启用条件

这项预览不是所有 GitHub 账户都可以直接打开。官方给出的范围是 GitHub Enterprise Cloud 企业，并且企业拥有 GitHub Secret Protection 或 GitHub Advanced Security；支持包含数据驻留的 GHE.com 环境。企业所有者可以进入企业设置中的 Policies → Advanced Security，把 Actions workflow logs 的 Secret scanning 策略设为 Enabled，策略默认关闭。

这里要特别区分“企业策略已打开”和“仓库已经启用 Secret scanning”。前者决定企业是否允许这项能力，后者决定具体仓库是否在覆盖范围内。落地时可以先选少量 CI 日志较稳定、权限边界清晰的仓库观察告警，再扩大范围。

发现日志中的密钥后，处置方式要怎么改

最重要的变化是把工作流日志当成“可能已经暴露的凭据载体”来处理。看到告警后，不要只删除日志或关闭工作流。更稳妥的顺序是先确认凭据类型和影响范围，再让签发方撤销或轮换，最后检查后续运行和其他仓库是否仍然使用旧值。

1. 定位来源。从告警回链进入对应工作流运行，记录工作流、作业、步骤和运行时间，判断是脚本主动输出、Action 输出还是错误堆栈带出。
2. 立即处理凭据。把日志中的值视为已经暴露，按签发方流程撤销或轮换；不要把“日志已删除”当作凭据已经安全。
3. 收紧输出。移除临时调试打印，检查是否把环境变量、请求头、连接串或完整配置对象写入日志，并保留必要的脱敏输出。
4. 检查复用位置。搜索仓库、组织级 Secret、环境配置和其他工作流，替换仍引用旧凭据的地方，避免轮换后 CI 立即失败。
5. 保留响应线索。记录告警、运行链接、处置时间和轮换结果，方便后续判断是否有更多工作流或仓库受到影响。

预览期告警不会自动产生通知，因此团队不能只等邮件、Webhook 或聊天机器人提醒。需要把“定期查看仓库 Secret scanning 告警列表”加入值班或安全运营任务；如果已有自动化集成，也要确认它是否能读取这类新位置的告警。

哪些日志不会被这项预览覆盖

这项能力有几个容易被忽略的限制。第一，只有在启用功能之后完成的工作流运行会被扫描，历史运行不会回填。第二，官方公告明确提到，generic patterns、custom patterns、AI-detected secrets，以及已经被 Actions 脱敏的 secrets 不在这次预览的检测范围内。第三，扫描结果依赖支持的 provider patterns 和有效性检查，不能把“没有告警”理解成“日志绝对没有敏感信息”。

因此，工作流仍然应该遵守最小输出原则：不打印 Secret 值，不把完整环境变量转储到日志，不在失败信息中拼接带认证参数的 URL；需要诊断时优先输出字段名、状态码、资源标识和脱敏后的短摘要。Secret scanning 是额外防线，不是替代安全编码和日志治理的理由。

团队可以怎样把它接进 CI 安全流程

建议把这次能力拆成三层管理。第一层是配置层，确认企业策略、仓库 Secret scanning 和数据驻留范围；第二层是输出层，审查工作流中 run、第三方 Action 和错误处理是否可能泄露敏感值；第三层是响应层，明确谁查看告警、谁批准凭据轮换、谁负责修复工作流，以及如何记录事件。

采用时还要给预览能力留出观察窗口：先统计新增告警的来源和误报，再决定是否扩大到所有仓库；对关键生产工作流，提前准备凭据轮换和回滚方案。由于预览期不会扫描旧日志，启用前已经产生的历史暴露仍要通过现有日志保留策略、人工抽查和凭据审计另行处理。

常见问题

启用后会自动扫描过去的 Actions 日志吗？

不会。官方公告说明，只有启用功能后完成的工作流运行会被扫描，已有日志不会回填。

Actions 已经把 Secret 脱敏了，还会产生告警吗？

这次预览明确不检测已经被 Actions 掩码的 secrets。仍应避免依赖掩码，因为拼接、编码、截断或错误日志上下文可能形成新的泄露路径。

为什么打开了企业策略却没有日志告警？

先确认仓库已启用 Secret scanning，并且是在策略打开后完成的运行；再检查命中的是否属于支持的 provider patterns。预览期也不会为这类告警自动发送通知。

发现日志泄露后只删除日志可以吗？

不建议。应把凭据视为已暴露，优先撤销或轮换，再清理输出、检查复用位置并保留处置记录。删除日志不能让已经被读取或复制的凭据失效。