配了三年 CI/CD 可观测性，今天才发现根子根本不在监控里——GitHub Actions Data Stream 把这件事彻底变了

CI/CD 出了安全事件，问的第一个问题是「哪个 workflow 跑的」——然后你发现日志只保留 90 天，runner IP 查不到，action 版本无法回溯。这是 2026 年大多数团队 CI/CD 可观测性的真实处境：出了事才知道，追溯全靠猜。

GitHub Actions Data Stream 就是来解决这个问题的。

CI/CD 黑盒子这件事，账到底有多烂

GitHub-hosted runner 默认没有出口限制，一个被污染的 action 或者恶意依赖可以随意外联。你不知道它连了谁，不知道哪个 action 解析到了哪个版本，不知道 artifact 跑在哪个 runner 上。出了 TJ-Actions 那类供应链事件，追查路径是断的。

Datadog Security Labs 2026 年 6 月的调研发现，大多数团队根本没有把 action 固定到 commit SHA——意味着你跑的那个 action 可能已经不是你看的那份代码了。

这些不是配置问题，是平台层缺失。

Data Stream 把 CI/CD 变成了可观测系统

Actions Data Stream 是 GitHub 2026 安全路线图里最先 GA 的功能之一（预计 Q4 2026/Q1 2027），它做的事情是把 workflow 执行事件以近实时流的方式推送到你的监控系统——Amazon S3 或者 Azure Event Hub / Data Explorer。

事件流里包含什么：

• 每个 job 的开始/结束时间、状态、runner 类型
• 每个 action 解析到了哪个具体版本（而不是哪个 tag）
• 哪些 secret 在这个执行上下文里可用
• 后续还会加入网络活动日志

有了这个，出了事你可以直接问：哪个 workflow？哪个 job？哪个 action 版本？哪个 runner？哪些 secret 到过这个环境？——不再靠猜日志。

这才是 CI/CD 应该有的可观测性。生产系统早就这么做了，流水线没有理由例外。

数据流怎么接

GitHub Actions Data Stream 配置在 organization 设置里绑定 S3 bucket 或 Azure Event Hub，之后所有 workflow 事件自动流入，无需修改 workflow 文件。

数据会关联到 workflow run → job → step → command 的完整链路。调查事件时不再需要手动拼凑日志。

Data Stream 只是第一步——和 egress firewall 配合才是完整解法

Data Stream 解决的是「看见」的问题。你用它先拿到 CI/CD 流量的 baseline：哪些域名在跑、哪些 action 在连外网、哪个 job 解析到了哪个 SHA。然后 egress firewall 登场，把「看见」变成「控制」。

Datadog 给的渐进路线：

1. 先接 Data Stream，看清当前流量模式（Monitor 模式）
2. 用真实数据建 allowlist（哪些 registry、哪些域名合法）
3. 切 Enforce 模式，未授权出口直接阻断

这两件事不是替代关系，是递进关系。看不见就控不住，控住了也不代表没问题——两个都要。

下一步：今天就能做的事

1. 去 GitHub organization 设置里找 Actions Data Stream 预览版入口，申请加入
2. 绑定一个 S3 bucket 或 Azure Event Hub，先跑两周看数据
3. 拿到 baseline 之后，开始给所有 action 补 SHA pinning（uses: actions/checkout@完整SHA，而不是 @v4）
4. 结合 egress firewall 的 Monitor 模式建出口 allowlist

TJ-Actions 那次攻击，23,000 个仓库的密钥外泄，根子不在代码，在 runner 可以连任意服务器、并且你事后查不出来。Data Stream 把这个账补上了第一块。