配了三年GitHub Actions，今天才发现日志默认只保留90天——这件事把安全审计的底裤全扒开了

你配了三年 GitHub Actions，有一件事可能从来没注意到：你的日志，90天后就没了。不是有人删的，是 GitHub 默认就这么设定的。等你想回头查安全事件，日志早没了。

GitHub Actions 的构件和日志，默认保留 90 天。公开仓库可以调成 1-90 天，私有仓库可以调成 1-400 天。但这个设置只对新的日志生效，老的不会自动补上。这是第一个坑。

第二个坑：日志没了不一定是删的，可能是根本没开。GitHub Actions 失败时，默认只保留完整日志 90 天，但如果你的工作流是定时任务，跑完了没人看，等你想起要去查，日志已经过期了。很多团队配置了 CI/CD 流程，但从没想过定期导出日志。

查日志这件事，有两个级别你需要知道。

第一个是调试日志。在仓库的 Settings → Secrets and variables → Actions 里加两个变量：ACTIONS_RUNNER_DEBUG = true 开启 Runner 级别诊断日志，ACTIONS_STEP_DEBUG = true 开启步骤级别的详细日志。也可以在 GitHub UI 里对失败的 workflow 重新运行，勾选 Enable debug logging。开了之后，日志里会多出 runner 启动细节、作业队列原因等平时看不到的信息。

第二个是交互式调试。对于复杂问题，可以用一个 Action 在失败的步骤里打开 SSH 通道，亲自连上去查文件系统和环境变量。这个只在失败时触发，连上去之后可以手动跑命令、看日志、排查根因。用完自动关闭，不会卡住 workflow。

但日志再长，也只是”跑的时候发生了什么”。要查”谁在什么时候改了什么配置”，得靠审计日志。

GitHub 的审计日志（Audit Log）记录了组织级别的 Actions 相关事件。包括谁改了 Secrets、谁调整了保留期、谁启禁用了 workflow、谁改了 Runner 配置。审计日志默认保留 180 天，比普通日志长一倍。组织 Owner 可以访问：Settings → Logs → Audit log。

几个最常用的 Actions 审计事件：

• org.update_actions_secret：有人改了组织级 Secrets
• set_actions_retention_limit：有人调了日志保留期
• actions_cache.delete：有人主动删了构建缓存
• register_self_hosted_runner / remove_self_hosted_runner：有人加了或删了自托管 runner

结合异常告警，这些事件可以帮你第一时间发现异常行为。

落到日常实践，三件事你可以现在就做：

第一，检查你现在配置的保留期是不是默认的 90 天。如果团队安全要求更高，去 Actions Settings 里调大私有仓库的保留期，或者在 workflow 里用 retention-days 参数给关键 artifacts 设置独立保留期。

第二，给关键 workflow 配置自动导出日志到外部存储。GitHub 的审计日志支持导出 JSON/CSV，可以用 GraphQL API 定期拉取并存到 S3 或别的存储里，这样即使 GitHub 上的日志过期了，你自己的存储里还有。

第三，配置 Secrets 变更的告警。在审计日志里搜 org.update_actions_secret，结合 GitHub 的 webhook 或第三方 SIEM 工具做实时告警——有人在非工作时间改了生产环境的 Secrets，这件事你必须第一时间知道。

日志是安全事件的目击者。你平时不注意它，等出事了才发现它早就不在了。