从 CISA 最近的 GitHub 泄露中汲取的教训 – Krebs on Security

网络安全和基础设施安全局 (CISA) 对最近的一次数据泄露发布了事后分析，其中一名承包商在公共 GitHub 存储库中发布了数十个内部 CISA 凭证（包括 AWS Govcloud 密钥）近六个月，然后才收到 KrebsOnSecurity 的通知。专家表示，该机构初步反应中发现的漏洞提供了所有安全团队都应该吸取的重要教训。

2026 年 5 月 15 日，安全公司 GitGuardian 寻求帮助，通知 CISA 存在一个名为“私有 CISA”的公共 GitHub 存储库，其中包含 844 MB 的 CISA 相关敏感数据。其中一份名为“importantAWStokens”的暴露文件包含三台 Amazon AWS GovCloud 服务器的管理凭证。另一个文件“AWS-Workspace-Firefox-Passwords.csv”列出了数十个内部 CISA 系统的纯文本用户名和密码。

CISA 很快承认了我们最初的警报，但花了超过 48 小时才使 GitHub 存储库中泄露的 AWS 密钥和许多其他重要机密失效。 CISA 在有关数据泄露的报告中表示，该机构系统的复杂性以及与联邦和行业合作伙伴的互连导致其密钥轮换时间比预期的要长。

报告指出：“借鉴这一经验，CISA 鼓励其他人保持成熟且经过充分测试的密钥管理能力。”

CISA 还承认，在响应外部各方的安全事件通知方面，它可以做得更好。事后分析强调，清晰明确的报告渠道对于确保影响组织本身的事件与涉及其产品或客户的事件的处理方式不同至关重要。

CISA 智能体首席信息官 Preston Werntz 和智能体首席信息安全官 Brad Libbey 分别撰写的分析称：“在 CISA 的案例中，这些渠道没有明确定义，导致安全研究人员尝试多种途径，包括向承包商发送电子邮件、通过 CISA 的漏洞披露平台提交（旨在针对影响更广泛网络安全社区的漏洞），并最终涉及记者。”

CISA 表示正在完善其报告渠道，以使研究人员更轻松、更快捷地报告。 CISA 作者写道：“此外，虽然许多研究人员依赖 security.txt 文件，但组织可以通过在多个显着位置发布报告说明来确保清晰度。”

GitGuardian 研究员 Guillaume Valadon 首次就暴露的 CISA 凭据问题联系 KrebsOnSecurity，他表示，在我们于 5 月 15 日发出通知之前，CISA 忽略了九个有关暴露凭据的自动警报。Valadon 的公司不断扫描 GitHub 和其他地方的公共代码存储库以查找暴露的秘密，自动向违规帐户发出任何明显敏感数据泄露的警报。

Valadon 在 CISA 报告的分析中写道：“如果 9 封通知电子邮件无人回复，一天的事件就会变成六个月的事件。” “让报告有关您的泄密变得微不足道，而不仅仅是有关您的产品。向您报告泄密的人不是威胁。发布 security.txt ，但不要就此止步。将报告说明放在几个显眼的地方，并确保有关您自己的基础设施的报告不会出现在产品错误队列中。”

该报告的作者还强调了持续扫描 GitHub 等公共代码存储库以查找暴露秘密的重要性，并表示 CISA 此后已轮换所有秘密并制定了一项行动计划，以改进对开发人员秘密的管理并更好地监控未来的情况。

报告指出，虽然 CISA 开发了一本应对网络安全事件的手册，但该手册并未包括在涉及 GitHub 或其他云服务的情况下应采取的措施。瓦拉登表示，该报告证实了需要持续扫描（而不仅仅是每季度一次）来查找泄露的秘密。

“Private-CISA 存储库公开了六个月，”Valadon 写道。 “对公共 GitHub 的持续监控让这个问题浮出水面。全面的内部扫描本可以在明文密码离开大楼之前就捕获并提交备份。”

CISA 在多个安全准备领域给自己打了及格分数，称这些领域有助于该机构衡量泄露秘密的范围和影响，包括增强的日志记录能力，以及在其生产和开发系统中采用零信任原则。 CISA 表示，这些详细的日志使其能够显示没有客户或任务数据被泄露，并且泄露的凭据没有在 CISA 环境之外使用。该机构表示，泄露机密的承包商的系统访问权限被撤销。

Valadon 认为最大的收获是 CISA 事后分析本身，并赞扬该机构对哪些措施有效、哪些无效的做法保持透明。

瓦拉登写道：“据我所知，这也是国家网络安全机构首次公开倡导秘密扫描并简化与安全研究人员的关系。” “这正是我们期望每个组织都能进行的事件沟通。”