使用 cache-mode 控制 GitHub Actions 缓存访问
GitHub Actions 的 cache-mode 已正式可用，允许在工作流或作业级别控制缓存 read、write、write-only 权限，以最小权限降低缓存投毒风险，并支持可重用工作流的权限传递。
原贴
查看原文原文
中文翻译
你现在可以使用 cache-mode 在工作流或作业级别对 GitHub Actions 缓存应用最小权限访问。
通过仅授予每个工作流或作业所需的缓存访问权限，你可以防止不必要的恢复或保存，并帮助保护可信工作流免受缓存投毒。
此功能现已在所有计划中正式可用。
选择每个工作流或作业所需的访问权限：read 允许缓存恢复，但阻止缓存保存。
这是 pull_request_target 等低信任事件的默认值。
write 允许缓存恢复和保存。
这是 push 等可信事件的默认值。
write-only 允许缓存保存，但阻止缓存恢复。
作业级设置覆盖工作流级设置。
所选模式由缓存服务强制执行，并会贯穿可重用工作流，其中被调用工作流不能获得比其调用方授予的更多缓存访问权限。
显式声明的 cache-mode 也会覆盖 pull_request_target 等低信任事件的只读缓存默认值。
为这些事件声明 write 或 write-only 会增加缓存投毒风险，因此 GitHub Actions 在声明的模式授予写访问权限时会添加警告注释。
未设置 cache-mode 的工作流继续使用现有的安全默认值。
cache 模式已在 github.com 上面向所有 GitHub 计划正式可用。
有关配置详情，请参阅 cache-mode 工作流语法文档。
加入 GitHub Community 中的讨论
核心信息
GitHub Actions 的 cache-mode 已正式可用，允许在工作流或作业级别控制缓存 read、write、write-only 权限，以最小权限降低缓存投毒风险，并支持可重用工作流的权限传递。
- GitHub Actions 的 cache-mode 已正式可用，允许在工作流或作业级别控制缓存 read、write、write-only 权限，以最小权限降低缓存投毒风险，并支持可重用工作流的权限传递。
- 原贴提到：You can now use cache-mode to apply least-privilege access to the GitHub
- 来源：github.blog
详细解读
GitHub 在官方 Changelog 中宣布，GitHub Actions 的 cache-mode 已正式可用。它把缓存的读取与保存权限拆成 read、write、write-only 三档，并允许在工作流或作业级别声明。这意味着 CI 缓存不再只有粗粒度的读写控制，而是可以按事件信任级别和任务需求分配。
为什么重要
缓存投毒是 CI/CD 供应链中的现实风险：低信任事件（如 pull_request_target）如果拥有缓存写权限，可能污染后续可信工作流使用的缓存。cache-mode 让低信任事件默认只有 read，不能保存；可信事件如 push 默认 write；write-only 适用于只需要写入、不需要恢复的场景。作业级设置覆盖工作流级设置，并且权限会沿可重用工作流传递，被调用工作流不能获得比调用方更多的缓存访问。
对谁有价值
对使用 GitHub Actions 的开发者、DevOps/平台工程、安全团队和开源维护者都有直接价值。尤其是有大量 PR 工作流、可重用工作流或第三方工作流的仓库，可以用它把最小权限原则落到缓存层，减少不必要的缓存恢复或保存，并降低缓存投毒面。
可以怎么行动
先盘点现有工作流中 actions/cache 等缓存步骤，确认哪些事件属于低信任、哪些属于可信。对 pull_request_target 等低信任事件保持 read 默认，避免显式声明 write 或 write-only；如确需写入，应评估风险并处理 GitHub 的警告注释。对可信事件按需使用 write，对只写不读的任务使用 write-only。对可重用工作流，检查调用方是否授予了过多缓存权限。可以在仓库或组织层面沉淀 cache-mode 配置规范。
风险或限制
显式给低信任事件授予 write 或 write-only 会增加缓存投毒风险，GitHub Actions 会添加警告注释，但这不等于自动阻止。未设置 cache-mode 的工作流继续沿用现有安全默认值，因此迁移需要主动配置。作业级覆盖工作流级、可重用工作流权限不能放大，这些规则需要团队理解，否则可能误判实际权限。该功能已在 github.com 面向所有 GitHub 计划正式可用，配置语法需参考官方文档。
信息差价值
这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。
如果把《使用 cache-mode 控制 GitHub Actions 缓存访问》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。
参考来源
TOPIC HUBS
延伸专题
AI SUMMARY
这篇文章回答了什么
使用 cache-mode 控制 GitHub Actions 缓存访问主要讲什么？
GitHub Actions 的 cache-mode 已正式可用，允许在工作流或作业级别控制缓存 read、write、write-only 权限，以最小权限降低缓存投毒风险，并支持可重用工作流的权限传递。
这篇文章最值得关注的要点是什么？
GitHub Actions 的 cache-mode 已正式可用，允许在工作流或作业级别控制缓存 read、write、write-only 权限，以最小权限降低缓存投毒风险，并支持可重用工作流的权限传递。；原贴提到：You can now use cache-mode to apply least-privilege access to the GitHub；来源：github.blog
这篇文章和哪些AI专题相关？
它适合放在Agent工作流、AI超级个体、AI工具专题里阅读。 关联原因：这篇内容命中「Agent、工作流」等主题信号。；这篇内容命中「技能」等主题信号。；这篇内容来自该专题长期覆盖的栏目。
阅读这篇文章建议先理解哪些关键词？
建议先理解AI工具、工具、自动化、模型、Cursor这些关键词，再结合正文判断工具、机会或风险是否值得进入自己的工作流。