一句话看懂：GitHub 宣布自 2026 年 8 月 25 日起，对 Dependabot 安全警报实施数据保留策略，关闭超过 2 年的警报将自动归档、不再通过 UI 或 API 直接查询，但可下载 CSV 存档。这是 GitHub 安全数据生命周期管理的正式化，开发者与企业应提前规划历史警报的查询与合规策略。
事件核心：发生了什么
GitHub 在官方 Changelog 中明确，从 2026 年 8 月 25 日开始，Dependabot 安全警报将采用新的数据保留策略。这一策略适用于 github.com 与 GitHub Enterprise Cloud（GHEC），不包括 GitHub Enterprise Server（GHES）。具体变化包括：1）所有开放的警报保持完全可访问，无时间限制；2）关闭的警报在关闭后 2 年内仍可在 UI 与 API 中查询；3）关闭超过 2 年的警报将被转移到归档存储，不再显示在 UI 或 API 中，但企业、组织、仓库管理员及安全管理员可在对应层级页面以 CSV 格式下载；4）归档数据保留完整精度，直到账户生命周期结束，且数据区域不变（对于启用了数据驻留的 GHEC 客户）。Dependabot 是首个实施此策略的警报类型，后续其他安全警报类型将在至少提前 60 天通知后逐步推行。
为什么重要
这一策略意义在于：首先，它为 GitHub 安全数据确立了可预期的生命周期规则，解决了长尾历史警报的存储与管理成本问题，也让企业在合规审计时明确数据在哪里、能查多久。其次，策略设计兼顾了合规需求（归档保留、CSV 导出）与日常运维效率（2 年内正常访问），表明 GitHub 在“数据可访问性”与“存储效率”之间寻求平衡。对于企业级用户，该策略直接影响安全运营流程——依赖 API 或 UI 批量查询历史警报的自动化脚本、报告系统或 SIEM 集成，都需要在 2026 年 8 月前改造，否则超期数据将不可通过标准接口获取。
对用户/开发者/创作者的影响
对于开发者与安全运维人员，直接影响是：如果当前依赖 Dependabot REST API 获取关闭超过 2 年的警报数据，需要在 8 月 25 日前完成数据导出或重建基于归档 CSV 的查询流程。对于中小企业或开源项目维护者，影响相对有限——大多数活跃项目很少需要追溯 2 年前的已修复警报，但若涉及长期合规审计（如某些监管要求保留安全修复记录 3-5 年），则应提前导出相关 CSV 存档。对于 GitHub Enterprise Cloud 客户，特别是安全经理与组织管理员，需要评估现有工作流是否依赖“所有历史警报始终在线”的假设，并与团队沟通新的数据生命周期时间线。值得注意的是，GitHub 明确归档数据保留“完整精度”，且不改变数据驻留区域，这对金融、医疗等受严格监管的行业来说是关键安抚。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
1）GitHub 将在至少 60 天前通知其他安全警报类型（如 Secret Scanning、Code Scanning）的具体实施时间，开发者应关注 Changelog，提前准备类似适配；2）归档 CSV 的下载接口是否提供自动化能力（如 GitHub Actions 定时同步）目前未披露，但社区可能贡献工具填补空白；3）这一策略是否会被其他云平台效仿（如 GitLab、Bitbucket），成为代码托管平台安全数据治理的行业惯例，值得观察。
