公司，包括 GitHub。他们最近在他们的博客上发布了关于 SSH 私钥暴露的公告：
[上周，GitHub] 发现 GitHub.com 的 RSA SSH 私钥在公共 GitHub 存储库中被短暂暴露。
该公司向公众保证，该密钥仅用于保护“使用 RSA 通过 SSH 进行的 Git 操作”，这意味着没有内部系统、客户数据或安全 TLS 连接处于风险之中。他们通过检测事件并更改密钥立即做出反应：
“在世界标准时间 3 月 24 日 05:00 左右，出于谨慎考虑，我们更换了用于保护 GitHub.com 的 Git 操作的 RSA SSH 主机密钥。”
因此，影响在时间和范围上都受到限制：“此更改仅影响使用 RSA 通过 SSH 的 Git 操作。如果您使用 ECDSA 或 Ed25519 加密，那么您不会受到影响。 ”，据他们说。
这进一步证明，秘密蔓延不仅仅是由缺乏经验的开发人员或新团队推动的。在我们的State of Secrets Sprawl 2023 报告中，我们发现了超过 10,000,000 个被推送到公共 GitHub 存储库的新秘密。与去年的报告相比，我们检测到的秘密数量增加了 67%，而 GitHub 本身的新帐户只增加了 27%。
检测到的硬编码凭据的增加是由许多因素驱动的，但很明显，参与事件的开发人员的资历从新手到专家，以及来自各种成熟度级别的组织。从我们的报告中，我们发现十分之一的提交者在 2022 年泄露了一个秘密。如果您公开揭露了秘密，那么您肯定不是孤军奋战。GitHub 很好地提醒我们，无论我们的团队有多大，我们都必须在安全实践中保持警惕。
让我们来看看这种情况下的风险是什么，GitHub 如何处理补救过程，以及一些避免公开私钥的简单步骤。
SSH 私钥泄露的风险
GitHub 在他们的帖子后面说：“我们 [替换了我们的 RSA SSH 主机密钥] 以保护我们的用户免受任何攻击者冒充 GitHub 或通过 SSH 窃听他们的 Git 操作的机会。该密钥不授予对 GitHub 基础设施或客户的访问权限数据。”
虽然我们可以对最后一部分感到放心，但不会暴露任何客户数据。还好没有接管他们的基础设施的已知风险，特别是考虑到有多少开发人员和如此多的互联网每天都依赖它。
但“对手冒充 GitHub 或窃听他们的 Git 操作”存在严重风险。这就是所谓的“中间人攻击”，最终用户无法区分合法的另一方和攻击者。
由于有如此多的开发人员和服务依赖 GitHub SSH 通信来实现真正的安全，因此公司吊销和替换他们的 SSH 密钥非常有意义。在同一篇文章中，他们还发布了如果您受到影响需要做什么以及如何判断您是否受到影响。如果在通过 SSH 连接到 GitHub 时收到警告，WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!则需要删除旧密钥或手动更新~/.ssh/known_hosts文件。
您的 GitHub Actions 也可能会受到影响。GitHub 轮换他们的 SSH 私钥将意味着如果他们使用actions/checkoutssh-key 选项，工作流运行将失败。这对于CircleCI 客户来说可能很熟悉，他们因泄漏事件经历过类似的意外工作流程中断。
大量更换的反应和风险
正如预期的那样，开发者社区对该事件有很多公众反应。似乎没有人对这种情况感到高兴。但有些人在没有添加太多评论的情况下帮助传播信息。其他对话推测这可能是如何发生的，以及可能发挥作用的进一步潜在安全问题。在几次谈话中出现的一个问题是新的中间人攻击的可能性。攻击者知道密钥将被许多开发人员使用命令替换，而无需手动验证新指纹是否为预期值。坏人完全有可能在某些情况下插入自己的指纹。ssh-keygen -R github.com这是一个很好的提醒，我们应该拥抱零信任，从“信任，但验证”转变为“验证，然后才信任”的立场。
事件补救的教训
虽然不幸的是，GitHub 需要轮换此证书，影响了如此多的客户，并发布了这样的通知，但我们想强调他们用来响应事件的一些最佳实践。
虽然我们不知道这个秘密暴露了多长时间，但我们可以假设它是最近才出现的。
迅速而谨慎地采取行动，不要惊慌失措，这对于秘密整治至关重要。鉴于他们发布的时间戳，我们可以假设这一事件导致相关团队失眠，他们不得不权衡多种因素。他们似乎认为安全风险值得密钥轮换，即使它可能会影响大量用户。
我们也可以为他们非常迅速和公开的沟通鼓掌。虽然大多数人可能没有订阅 GitHub 博客，但他们将新闻推送到多个渠道尽可能公开。虽然社区中的一些人觉得在使用“我们没有理由相信”或“非常谨慎”等术语时有点过多的“营销旋转”，但 GitHub 团队在他们所有的沟通中一直直截了当安全事件。我们将采取一些温和的措施，而不是没有得到包括补救步骤的概述。
如何防止凭证泄露
没有人是完美的，我们都会不时犯错误。期望人类总是完美地交付只会让你失望，尤其是在处理像 Git 这样概念上复杂的东西时。虽然我们都喜欢世界上最受欢迎的版本控制系统，但大多数开发人员会告诉您，做错事太容易了，例如推送到错误的远程存储库。
虽然我们不知道究竟是什么导致了这一特定事件，但我们想借此机会提醒您一些最佳做法。
永远不要将凭据添加到版本控制
这一点看起来很明显，但我们所有接触代码的人有时都会为此感到内疚。有时，尤其是在调试某些东西时，您只需要测试凭据是否有效。密码、API 密钥以及与之相关的证书都是如此。
您可能会直接在项目中添加一个新证书，完全有意将其移动到安全的地方或修改您的.gitignore文件，但是生活发生了，您会分心。一个git add -A和git commit以后，您的证书现在在您的 git 历史记录中。一个'git push'之后，它现在在共享仓库中。
这就是 git hooks 和ggshield等工具真正派上用场的地方。设置预提交挂钩非常快速和简单。设置完成后，每次提交代码的尝试都将触发扫描，如果在任何跟踪文件中发现秘密，扫描将停止操作。在秘密成为您的 git 历史的一部分之前捕获秘密是补救这种情况的最安全和最便宜的地方。
仔细检查遥控器是否正确
Git 的优势之一是能够轻松地将所有更改推送到您有权连接的任何远程存储库。不幸的是，这很快就会变得混乱。假设您有两个存储库，一个是公共的，一个是私有的，分别具有远程名称 proj-1-p和proj-1-pr。你只差一个字母就可能被推到错误的地方。意外发生。使这些起源名称更明确是一个很好的主意。
许多开发人员处理的另一个因素是他们自己的 shell 别名。例如，通常将别名gpo作为经常键入的快捷方式git push origin。很容易进入自动模式并使用可能将错误分支发送到错误位置的快捷方式。如有疑问，请输入。
经常轮换秘密
虽然此事件可能不需要轮换 SSH 密钥，但您知道上次轮换它是什么时候吗？是这个十年吗？如果您不知道，那么现在是补救的好时机。任何有效凭证存在的时间越长，该凭证被发现和滥用的机会就越大。
我们发现，在秘密管理成熟度方面，更频繁地轮换密钥的团队处于金字塔的顶端，即专家级别。在没有紧急情况的情况下定期轮换证书将使您做好准备，以便在出现这些额外压力时更好地应对。
保持警惕和安全
泄漏有时会发生在我们所有人身上，甚至发生在像 GitHub 这样的大型平台上。虽然可能有许多工作流程受到影响，并且许多开发人员需要更新他们的known_hosts文件，但由于 GitHub 对事件进行了明确的沟通，因此有明确的补救路径，而且我们知道事件的总体范围。
现在也是反思您自己的秘密管理和检测策略的好时机。
