GitHub Actions 构建来源生成器

解决什么问题

GitHub Actions 能自动化构建、测试与发布，但默认可见的往往只是产物文件和运行日志。安全评审时经常要追问：这次构建是否发生在受控 CI 中？源码 revision、构建依赖、builder identity、artifact digest 之间能否绑定？人工翻日志拼背景既慢又容易漏。缺少签名的 SLSA provenance 时，下游也无法用统一策略验证 release artifact 是否来自可信构建链。

技能如何工作

该技能围绕 GitHub Actions 与 SLSA GitHub Generator 组织流程，目标是让 release artifact 与 signed SLSA provenance 一起交付。关键步骤包括：

• 先确认前置条件：GitHub Actions 可用，SLSA GitHub Generator 已就位。
• 识别需要出证的 build job、artifact 或 release 目标。
• 在构建产物 digest 确定后接入 provenance 生成，产出签名 attestation。
• 将 attestation 附加到 workflow run 或 release 侧，供验证器和供应链审计消费。
• 对 Node.js 项目，上游资料提到 Node.js Builder 可构建并为 npm packages 生成 provenance；它在 v1.6.0 后处于 Beta，接入时要更谨慎。

适用边界与注意点

• Provenance 不等于 SBOM、dependency scanning 或 VEX；它证明构建背景，不能替代漏洞分析。
• 效果依赖 builder / generator 对技术栈的支持，非原生支持时需要兼容构建器。
• 签名可信度取决于 runner、密钥和构建环境控制；脱离 CI 手工重建不可作为同一证据。
• 发布流程需要保留 attestation；删除产物、覆盖 digest 或在流水线外重打包会断链。
• 上游文档和 requirements 是最终依据，推广前先在最小 workflow 验证。