每一人单厢时不时发生外泄该事件，即便是像 GitHub 这样的大玩者。这是两个较好的告诫，她们都须要提防。
国家机密外泄是两个日益突出的问题，影响着各式各样规模的子公司，包括 GitHub。她们前段时间在她们的网志上发布了关于 SSH 公钥曝露的报告书：
[上周五，GitHub]辨认出 GitHub.com 的 RSA SSH 公钥在公用 GitHub 存储库中被断断续续曝露。
该子公司向社会公众确保，该公钥仅用作为保护“采用 RSA 透过 SSH 进行的 Git 操作方式”，这意味著没有外部系统、顾客数据或安全可靠 TLS 相连处于信用风险当中。她们透过检验该事件并更动公钥立刻作出化学反应：
“在世界国际标准天数3 月24日 05:00左右，所致慎重考虑，她们更改了用作为保护 GitHub.com 的 Git 操作方式的 RSA SSH PS3公钥。”
因此，负面影响在天数和范围上都受限：“此更动仅负面影响采用 RSA 透过 SSH 的 Git 操作方式。假如您采用 ECDSA 或 Ed25519身份验证，所以您不会受到负面影响。”，据她们说。
这进一步断定，绝密扩散更为重要是由经验不足的开发者或新项目组推动的。在她们的State of Secrets Sprawl 2023调查报告中，她们辨认出了超过10,000,000个被发送到公用 GitHub 存储库的新绝密。与今年的调查报告较之，她们检验到的绝密数量减少了67%，而 GitHub 这类的新账号只减少了27%。
检验到的硬代码凭证的减少是由许多因素驱动力的，但很明显，参与该事件的开发者的年资从初学者到研究者，和源自各式各样适用性等级的组织。从她们的调查报告中，她们辨认出十分之一的提交者在2022年外泄了两个绝密。假如您申明揭露出了绝密，所以您的确不是孤立无援。GitHub 较好地告诫她们，不论她们的项目组有多大，她们都必须在安全可靠实践中提防。
让她们来看一看这种情况下的信用风险是什么，GitHub 如何处置解决问题过程，和一些防止申明公钥的单纯关键步骤。
SSH 公钥外泄的信用风险
GitHub 在她们的帖子后面说：“她们[替换了她们的 RSA SSH PS3公钥]以为保护她们的用户免受任何攻击者冒充 GitHub 或透过 SSH 窃听她们的 Git 操作方式的机会。该公钥不授予对 GitHub 基础设施或顾客的访问权限数据。”虽然她们可以对最后一部分感到放心，但不会曝露任何顾客数据。还好没有接管她们的基础设施的已知信用风险，特别是考虑到有多少开发者和如此多的互联网每天都依赖它。
但“对手冒充 GitHub 或窃听她们的 Git 操作方式”存在严重信用风险。这就是所谓的“中间人攻击”，最终用户无法区分合法的另一方和攻击者。
由于有如此多的开发者和服务依赖 GitHub SSH 通信来实现真正的安全可靠，因此子公司吊销和替换她们的 SSH 公钥非常有意义。在同一篇文章中，她们还发布了假如您受到负面影响须要做什么和如何判断您是否受到负面影响。假如在透过 SSH 相连到 GitHub 时收到警告，WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!则须要删除旧公钥或手动更新~/.ssh/knownhosts文件。您的 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 这样的大型平台上。虽然可能有许多工作流程受到负面影响，并且许多开发者须要更新她们的knownhosts文件，但由于 GitHub 对该事件进行了明确的沟通，因此有明确的解决问题路径，而且她们知道该事件的总体范围。
现在也是反思您自己的绝密管理和检验策略的好时机。
