一个叫“Private-CISA”的 GitHub 仓库，偏偏是公开的。

更难看的是，里面不只是几段测试代码，而是 SSH 私钥、明文密码、令牌和其他敏感资产。报道显示，这些内容最早可追溯至 2025 年 11 月。仓库现已下线，但风险不会因为页面 404 就自动消失。

这件事原本可以被归类为“又一个把密钥传上 GitHub 的低级事故”。最新披露把问题抬高了一层：GitHub 默认的秘密扫描和保护机制据称被仓库管理员关闭；外部研究人员联系仓库所有者未获回应；安全研究人员还称，部分凭据可访问多个 AWS GovCloud 账户，权限较高。

这就不是一句“操作失误”能盖过去的事了。

发生了什么：公开仓库里挂着 CISA 相关秘密

目前已知事实可以压缩成几条：

项目已知情况为什么要紧
仓库名称“Private-CISA”，现已下线名字叫 Private，状态却是 public，讽刺但不是重点
暴露内容SSH 私钥、明文密码、令牌等这些东西可能绕过正常登录和审批链路
暴露时间最早可追溯至 2025 年 11 月窗口太长，事后审计会很重
保护机制报道称 GitHub 默认秘密保护被关闭不是没兜住，而是闸门被人卸了
云环境研究人员称凭据可访问多个 AWS GovCloud 账户涉及政府云资源，权限边界更敏感
责任链仓库疑似由承包商 Nightwing 管理问题落到外包治理和权限归属上

最早发现异常的是 GitGuardian 的 Guillaume Valadon。GitGuardian 会扫描公开代码仓库里的敏感信息。Valadon 发现该仓库后尝试联系仓库所有者，但没有得到回应，随后把线索告知安全记者 Brian Krebs。

Ars Technica 援引 Krebs 报道称，提交记录显示，GitHub 默认提供的 secret scanning 和 protection 被关闭。这个细节很关键。

秘密扫描不是银弹。它挡不住所有坏流程，也不能替代密钥管理。但它至少能拦住一批最常见、最愚蠢、最昂贵的误提交。把它关掉，性质就变了：不是安全带没系好，而是有人嫌它碍事，先剪掉了。

Seralys 创始人 Philippe Caturegli 进行测试后称，仓库中的凭据可用于访问多个 AWS GovCloud 账户，并且权限较高。这里要谨慎：公开证据不能证明攻击者已经利用这些凭据。

但安全评估不等攻击者写回执。

“高权限云凭据公开数月”本身，已经足够触发吊销、轮换、日志回溯和权限复盘。

为什么重要：失守的不是代码，是密钥生命周期

开发者把 API key、数据库密码、证书文件传进公开仓库，不稀奇。GitHub、GitLab、Bitbucket 上每天都有类似事故。

成熟团队一般靠四步止血：

  • 自动扫描，先拦一次；
  • 即时告警，让人知道；
  • 立刻吊销，别赌没人看见；
  • 回查日志，确认有没有被用过。

这次麻烦在于，几个环节像多米诺骨牌一样倒下。

仓库不是短暂误公开。暴露至少持续到被发现。默认保护机制据称被关闭。外部报告没有及时得到回应。凭据还被验证具有可用性和较高权限。

单点失误可以说是人犯错。多点失守，就要看制度有没有牙。

CISA 的身份让这件事更刺眼。它负责美国关键基础设施网络防御，平时给别人发告警、发指南、讲最佳实践。结果相关项目在最基础的密钥管理上翻车。

这不是要求安全机构永不犯错。那不现实。问题在于，安全机构最应该有一套“犯错后立刻被系统兜住”的机制。

现在看起来，兜网破了好几层。

谁受影响：普通用户不直接受伤，政府项目要付信任成本

普通公众的日常上网，大概率不会因为这个仓库直接出问题。别把它理解成“所有美国人数据都泄了”。目前没有公开证据支持这种说法。

真正受影响的是两类人。

一类是政府网络安全项目的采购方和管理方。承包商接入政府云资源，本来就靠最小权限、可审计操作和清楚责任链维持信任。一旦公开仓库能挂着高权限凭据数月，采购方接下来一定会加码审计。

这会带来三种成本：

  • 更多密钥托管和统一凭据管理要求；
  • 更严的承包商仓库纳管；
  • 更慢的项目交付和更重的合规文档。

安全成本不是凭空消失。前面省掉的流程，后面会以审计、返工、停机窗口和问责的形式回来。

另一类是政府承包商。很多组织的盲区不在主代码库，而在边角料：临时脚本、迁移仓库、测试项目、离职员工留下的 repo、承包商自己的工作区。

这些地方最容易出现一种假安全：核心系统看起来很干净，旁路仓库里全是钥匙。

AWS GovCloud 让事情更敏感。它服务美国政府机构、承包商和受监管工作负载，合规门槛和访问控制要求更高。凭据出现在公开仓库，不等于 GovCloud 被攻破；但它迫使相关团队回答更难的问题：谁拿过这些凭据？谁用过这些角色？有没有横向移动痕迹？哪些权限本不该给到仓库维护者？

这些问题都不便宜。

更难看的地方：CISA 不是第一次在“规则执行”上失分

这起事故还会叠加 CISA 近期的治理压力。

2026 年 1 月，时任 CISA 代理局长 Madhu Gottumukkala 被曝在获得例外许可后，将敏感政府文件上传至 ChatGPT；他在 2 月被移出该职位。那件事和这次 GitHub 凭据暴露，技术形态不同。

一个是生成式 AI 使用边界。一个是代码仓库和密钥管理。

但它们指向同一个硬问题：规则写得出，执行压不实。

安全治理最怕这种状态。PPT 上有制度，平台上有开关，合同里有条款，真正到一线，没人把最后一米盯住。

“纸上得来终觉浅”。放到安全行业，就是制度得来终觉浅，密钥轮换才知深。

我不太买账那种“任何组织都会犯错”的轻描淡写。会犯错当然是真的。但 CISA 这种机构被信任的原因，恰恰不是它不会犯错，而是它应该比别人更快发现、更快隔离、更快追责。

这次难看的不是仓库名。也不是 Ars Technica 标题骂得多狠。

难看的是基本动作松了：秘密不该进代码；进了代码要被拦；没拦住要告警；告警后要响应；响应后要吊销、回溯、复盘。

这条链子断一环，还能解释。断几环，就不是“倒霉”。

真正该盯的，不是道歉，是三张账单

后续最该看的不是一段漂亮声明，而是三件可验证的事。

第一，相关凭据是否全部吊销并轮换。

公开仓库下线只是擦掉痕迹，不是处理风险。密钥一旦公开，就应该默认失效。别问有没有人用过，先问为什么还能用。

第二，AWS GovCloud 访问日志是否完成回溯审计。

重点不是“有没有发现攻击”。重点是审计范围够不够、时间窗口够不够、权限链路有没有查到角色级别。高权限凭据公开数月，不能只看最近几天日志。

第三，CISA 和承包商之间的仓库权限、告警责任、秘密扫描开关，是否重新划线。

谁能创建公开仓库？谁能关闭 secret scanning？关闭后谁会收到告警？承包商自有 GitHub 组织是否纳入政府项目安全治理？这些问题比“谁手滑了”更重要。

安全行业很多事故，表面是技术事故，底层是激励事故。

开发要快，交付要赶，承包商要压成本，甲方要结果。秘密扫描、权限分层、密钥托管、审计日志，平时看起来都像阻力。直到出事，大家才想起它们本来就是刹车。

天下熙熙，皆为利来。古话讲的是人性，今天讲的是组织激励。只要项目奖励速度、惩罚流程，安全开关迟早会被某个人当成麻烦关掉。

这也是我最在意的地方。

CISA 相关项目踩穿底线，伤的不是面子，而是它对外输出安全规则时的信用。你当然还能继续发指南、开研讨会、提醒别人不要把密钥传 GitHub。但听的人会多想一秒：你们自己的承包商仓库，管住了吗？

安全守门人最怕的不是丢一把钥匙。

最怕的是别人发现，门闩原来一直没人查。