摘要
- GitHub 确认其 GitHub.com RSA SSH 主机私钥曾在公开仓库中短暂暴露，并于世界标准时间 2023 年 3 月 24 日约 05:00 更换了 RSA 主机密钥；GitHub 还表示该密钥并未被用于访问 GitHub 基础设施或客户数据，且无理由认为该密钥已被滥用。主要通知位于 GitHub 安全声明https://github.blog/news-insights/company-news/we-updated-our-rsa-ssh-host-key/。
- 实际事件并不仅仅是私钥暴露。它也是一个信任修复问题，强加给开发者、CI 系统、发布经理和小型企业，他们必须判断变更的 SSH 主机身份是合法的提供者轮换还是拦截尝试。
- 合同与控制的不匹配在于，平台条款可以限制保证和责任，而提供者操作仍对客户构建、发布和源代码控制连续性行使实际权威。GitHub 的条款https://docs.github.com/en/site-policy/github-terms/github-terms-of-service在法律风险分配上与轮换期间的操作控制运作方式不同。
- 问责制遵循每个参与者实际掌控的控制：GitHub 控制主机密钥保管、检测、轮换、第一方指导和支持的 Action 更新；客户控制信任存储清单、独立验证、固定工作流更新、回退传输和发布中断纪律。
合同无法轮换密钥，但 GitHub 可以
2023 年 3 月的事件很容易被低估，因为它并未导致客户仓库、客户账户或 GitHub 生产环境的公开泄露。但也容易被高估，因为拥有服务器主机密钥并不等同于拥有用户凭证或私钥的主密钥。有用的问责分析位于这两种错误之间。一个由提供者控制的信任对象失去了机密性，而提供者的修复行动在客户系统上显示为与这些系统在面对恶意变更时相同的警告。
GitHub 的通知称，旧的 RSA SSH 主机私钥曾在公开 GitHub 仓库中短暂暴露，该公司已采取措施保护用户免受可能的 SSH 冒充或窃听。它声明影响仅限于使用 RSA 的 SSH Git 操作，并说明 HTTPS Git 操作、Web 流量、ECDSA 和 Ed25519 用户未受影响。这一范围至关重要。该事件并不支持私有仓库被从 GitHub 读取、客户 SSH 私钥被泄露或 GitHub 内部服务普遍遭到破坏的结论。但它确实支持 GitHub 必须更换一个许多客户已经固定为接受 SSH 代码先决条件的服务身份。
合同与控制的问题始于服务关系。GitHub 当前的条款定义了广泛的服务，并包含免责声明，即服务按“现状”提供，对及时性、安全性、不间断访问或无错误运行等方面的保证有限。这些条款在法律分配上有用，但它们并未赋予客户更换 GitHub.com 主机密钥的权力。它们并未让一个小型软件公司在私钥公开后安全地保留旧密钥。它们并未给 CI 运行器一个独立的方式来验证新密钥是否真实。法律语言和操作权指向不同的方向。
这种不匹配在云依赖中很常见。提供者可以保留广泛的裁量权并限制风险，同时也成为唯一能操作共享控制的实体。客户理论上可以离开平台，但在紧急轮换的当下，他们需要的是几分钟内的决定，而非一个采购流程。他们的构建系统、部署工具、子模块、供应商集成和内部镜像通常假设 GitHub 的 SSH 端点是一个稳定的真相来源。当真相来源本身改变时，客户必须要么停止，要么通过其他渠道验证。
这并不是抱怨 GitHub 进行了轮换。轮换是私钥合理暴露后的正确遏制步骤。问责测试在于，拥有信任对象的组织是否有足够的预防控制来防止其进入公开仓库，是否有足够的检测来了解暴露是如何发生的，是否有足够的响应控制来撤销而不造成可避免的混淆，以及是否有足够的公开信息让客户在不削弱保护他们的控制的情况下恢复。
已确认的事实与未知信息
GitHub 的公开声明确认了五个事实。第一，涉密信息是 GitHub.com Git 操作通过 SSH 使用的 RSA SSH 主机私钥。第二，该公司发现它曾短暂出现在一个公开仓库中。第三，GitHub 于世界标准时间 2023 年 3 月 24 日约 05:00 更换了密钥，并报告新密钥在约 02:30 开始的准备过程中短暂可见。第四，该公司表示该事件并非由 GitHub 系统或客户信息泄露引起。第五，GitHub 表示无理由认为该密钥已被滥用。
这些陈述定义了证据边界。它们没有指明仓库、人员、工作流、扫描器、暴露持续时间、查看次数、克隆次数、缓存行为或根本原因。它们没有披露用于得出无已知滥用结论的遥测数据。它们没有说明私钥的生成或存储方式是否本应使仓库发布成为不可能。它们没有说明暴露是由 GitHub 自身的秘密扫描、员工报告、用户报告、研究人员还是其他控制发现的。
这种缺失很重要，因为 GitHub 销售并记录旨在防止公开秘密暴露的控制。2023 年 2 月，GitHub 宣布对公开仓库免费提供秘密扫描警报，参见source: github.blog。2023 年 5 月，在主机密钥事件之后，它宣布对公开仓库免费提供更广泛的推送保护，参见source: github.blog。当前的 GitHub 文档列出了通用私钥模式，参见source: docs.github.com。这些来源显示了控制家族。它们并未证明哪个控制在 2023 年 3 月看到、错过或阻止了特定的主机密钥。
因此，根本原因应被狭义地表述。触发因素是主机私钥在公开仓库中的暴露。根本问责问题不仅仅是暴露本身，而是允许生产服务身份成为可发布的保管系统，以及随后依赖实时验证的客户恢复路径。促成条件包括 GitHub SSH 使用的广泛性、固定到 RSA 的旧客户端信任存储、在没有人工干预时自动失败、固定到旧操作码的工作流，以及通常将主机密钥警告视为本地麻烦而非供应链信号的客户运行手册。
公开记录也将潜在危害与观察到的伤害区分开来。拥有旧 RSA 主机私钥的一方可以尝试冒充 GitHub 与一个客户端通信，前提是其流量可被转移且客户端接受旧 RSA 身份。这可能暴露 Git 命令、推送的对象、通过该连接请求的仓库内容，或根据攻击者位置实现更复杂的欺骗。但密钥本身并不提供网络位置、用户凭证、GitHub 账户访问或 GitHub 存储仓库的访问。审查过的来源未确认有成功的冒充事件。
警告正是控制在工作
SSH 主机密钥警告并非装饰性的摩擦。RFC 4253 (参见source: datatracker.ietf.org) 将传输层的服务器认证与用户认证分开。记住预期服务器身份的客户端应该在服务器出示不同密钥时停止。OpenSSH 客户端手册 (参见source: man.openbsd.org) 将严格主机检查描述为拒绝已变更主机密钥的设置。如果攻击者试图插入客户端与 GitHub 之间，客户需要的正是这种拒绝。
3 月份的轮换造成了一个操作悖论。合法的 GitHub 修复导致了与中间人攻击可能相同的症状。开发者看到了一个变更密钥警告。CI 运行器看到了一个失败的检出。部署作业看到了一个非零退出。机器无法知道变更是否合法。它只知道主机身份不再匹配本地记录。这就是为什么该事件属于风险与问责系列，即使没有确认的客户数据盗窃。
GitHub 的故障排除指南 (参见source: docs.github.com) 告诉用户寻找官方解释，并在没有解释时避免连接。其指纹页面 (参见source: docs.github.com) 发布了当前的 GitHub SSH 指纹。其 REST Meta 文档 (参见source: docs.github.com) 说明 meta 端点返回 SSH 密钥指纹和主机密钥，无需认证即可用于公共资源。这些渠道共同提供了一条恢复路径，但并非神奇路径。客户仍必须决定 HTTPS 文档和 API 在紧急情况下是否足够可信，并在不教导员工接受 SSH 路径上出现的任何密钥的情况下分发更正后的信任条目。
不安全的捷径是全局移除主机检查，或从实时网络扫描中填充受信任密钥而不进行独立验证。OpenBSD ssh-keyscan 手册 (参见source: man.openbsd.org) 警告在不验证的情况下使用扫描输出可能使用户面临拦截风险。该警告直接适用。在身份有争议的名称上运行扫描，如果路径是敌意的，可能会将攻击者的答案记录为真相。
规范的序列更慢但更安全：保留警告，将呈现的指纹与经过认证的提供者声明和内部批准源进行比较，仅更新相关主机名的受影响 RSA 主机条目，执行金丝雀提取，然后通过管理客户端和运行器滚动更新。该序列接受短暂的发布延迟，作为不将信任失败转变为信任绕过的代价。
CI 将信任修复变成了服务连续性
人类开发者可以阅读通知。CI 系统不能。GitHub 特别警告，使用带有 ssh-key 选项的 actions/checkout 的工作流可能会失败，并且 GitHub 正在更新受支持的标签，如 v2、v3 和 main。该操作的公共仓库 (参见source: github.com) 记录了 SSH 密钥支持和严格主机检查行为。一个移动标签可以集中接收的相同修复，不会自动到达固定到特定提交 SHA 的作业。
这种紧张关系并非固定缺陷。GitHub 自身的操作强化指南 (参见source: docs.github.com) 建议对操作进行固定到不可变提交以实现供应链完整性。2023 年 3 月，不可变审查造成了连续性权衡。固定旧操作代码的客户免受静默操作变更的影响，但也必须审查并采用新提交以接收嵌入的信任更新。使用移动标签的客户可以更快地接收提供者的修复，但代价是执行可能未经客户自己审查而移动的代码。
这就是事件的开发者工具经济学。GitHub 集中化仓库托管、协作、问题跟踪、包工作流和 CI 集成，因为集中化降低了成本和摩擦。同样的集中化意味着提供者的密钥轮换可能同时中断许多客户。每个客户可能经历本地构建失败，但原因是共享平台控制。每个客户可能拥有自己的 known-hosts 文件，但其中的值是提供者拥有的断言。
中小型团队面临最艰难的版本。大型企业可能拥有端点管理、CI 平台所有者、安全工程和供应商联系人。而五人软件企业可能只有一个人看到失败的部署，检查社交动态，搜索支持页面，并决定是否交付。CISA 针对中小企业的 ICT 供应链指南 (参见source: cisa.gov) 承认较小企业严重依赖外部技术提供商，同时缺乏专门的风险人员。3 月事件正是这种依赖的紧凑例子。
中小企业不需要一个完美的替代锻造来承担责任。它确实需要一个轻量级计划：一个已经测试过的第二 Git 传输、一个用于关键代码的仓库镜像或捆绑包、两个订阅提供者通知的人、一个列出批准的主机指纹和源 URL 的内部页面，以及一条主机密钥警告在验证前都是安全事件的规则。GitHub 的远程 URL 文档 (参见source: docs.github.com) 显示在 SSH 和 HTTPS 之间切换技术上很简单。操作上，它需要不会造成新秘密问题的凭证、权限和日志记录。
备份同样有界限。GitHub 的仓库备份指南 (参见source: docs.github.com) 和 Git 的 bundle 文档 (参见source: git-scm.com) 可以保留 Git 历史，但它们不会自动保留问题、拉取请求、工作流密码、包注册表、访问审查或发布批准。一个保护源代码但丢失发布状态的备份计划可能仍会使企业无法干净恢复。
合同条款解释了暴露，而非控制
当前的 GitHub 服务条款之所以相关，是因为它们展示了许多组织视为关键基础设施的服务周围的法律表面。条款广泛定义了服务，将私有仓库内容视为服从于规定访问目的的机密，规定了电子通信，说明了对普通条款通信不提供电话支持，并否认了广泛的保证。这些条款在商业上可能是合理的。它们也表明为什么合同语言不能替代操作问责。
GitHub 的私有仓库条款 (参见source: docs.github.com) 表示 GitHub 将私有仓库内容视为机密，并可能出于指定目的（如安全、支持、完整性、法律义务或同意）访问内容。这种语言承认提供者有权维护服务完整性。主机密钥轮换在连接层行使了类似的权威。客户可能拥有其内容并配置访问，但他们并不拥有通过 SSH 认证 GitHub.com 的平台身份。
问题不在于 GitHub 是否有合同权利进行轮换。它几乎肯定需要轮换。问题在于合同风险分配是否与实际控制相匹配。客户承担了更新信任存储、重新运行构建、解释失败和防止不安全变通方案的下游成本。GitHub 控制安全完成这些工作所需的事实：新指纹、受影响的密钥类型、轮换原因、暴露边界、支持的 Action 更新状态以及关于滥用的置信度。当一方控制证据而另一方承担恢复劳动时，披露质量就成了一种控制，而非公共关系。
GitHub Status (参见source: githubstatus.com) 可以传达操作事件和组件健康状态，但主机密钥事件还需要经过身份验证的安全指导。一个通用的绿色状态页面无法告诉 CI 作业新 SSH 指纹是否合法。提供者的通知、指纹页面、API 端点、支持响应和状态组件需要内部一致。如果一个说密钥已更换，而另一个保持沉默或过时，客户可能暂停更长时间或做出不安全决定。
公开通知做得很好。它指出了受影响的算法，给出了精确的轮换时间，承认了新密钥的早期出现，提供了新指纹和完整公钥，将 HTTPS 和其他主机密钥算法与 RSA SSH 分开，警告了 Actions 用户，并解释了旧密钥未授予对 GitHub 基础设施或客户数据的访问。这些是有用的操作事实。缺失的事实在于其他地方：确切的暴露持续时间、检测路径、检索证据、遥测限制、保管变更以及后来的保证——相同类别的发布已变得更加不可能。
因此，问责镜头并不要求 GitHub 承诺完美可用性或零错误。它要求平台提供与其持有的控制相称的证据。合同可以说风险有限。它不能使暴露的主机私钥不暴露。它不能使已变更的主机密钥自我认证。它不能允许客户验证 GitHub 单独未发布的事实。
按实际控制划分的检测、响应和恢复失败
触发因素是 RSA 主机私钥的暴露。根本问题是密钥保管和紧急信任修复。促成条件包括共享平台身份、客户对 RSA 而非更新主机密钥的不均衡使用、自动化中的隐藏信任存储、Actions 中的固定权衡，以及通常缺乏已验证轮换路径的客户运行手册。
检测失败无法从公开记录中详细分配，因为 GitHub 没有披露检测器。事件可能由一个正常工作的控制发现。可能由一个人发现。可能在一段延迟后才发现。正确的公开结论不是检测失败，而是检测证据从外部无法验证。对于其产品包含秘密检测的提供者来说，这一证据差距至关重要，因为客户只有通过描述路径才能从中学习。
响应部分强大。暴露的密钥在公开通知后很快被撤销。替换范围限于 RSA，未变更的 ECDSA 和 Ed25519 密钥减少了爆炸半径。GitHub 提供了权威指纹和更新方向。它还更新了受支持的 actions/checkout 标签。响应的弱点在于新密钥在约 02:30（UTC）短暂出现，早于声明的 05:00 更换，这造成了不可避免的混淆。这可能无害的准备，但对客户来说，在最终切换之前看起来像是变更的身份。GitHub 承认了这一点；公开记录没有解释机制。
恢复工作分配给了客户。工作站、运行器、容器、基础镜像、设备、构建服务和部署系统都必须更新本地信任。GitHub 可以更新其支持的 Action 标签，但固定提交或外部 CI 的客户必须行动。这本身并不不公平。这是共享责任边界的运作。只有当提供者的指导不完整、客户没有实际方式接收它，或者客户合同暗示在平台身份事件期间不存在的自治权时，它才变得不公平。
最富揭示性的指标将是验证恢复的时间，而非提供者轮换的时间。主要客户类别需要多长时间才能恢复严格的 SSH 信任而不禁用检查？有多少支持工单涉及不安全的变通方案？有多少失败的 Actions 运行涉及固定代码？有多少客户在通知后使用了旧 RSA 密钥？为本文审查的公开记录没有提供这些衡量标准。它们的缺失限制了我们判断恢复是否仅仅是完成还是可衡量改进的能力。
关于记录和可读性的排版说明
取证不仅是一堆事实；它也是一个呈现问题。客户需要以这样方式安排警告、指纹、日期和注意事项，使得安全行动在压力下清晰明确。以下排版说明属于公开证据体，因为通知的形式可以改变读者是保留还是擦除信号。
应用于主机密钥轮换，实际要点很简单：指纹、受影响的算法、时间窗口和安全命令路径必须在视觉上区别于上下文和安慰。将密钥材料埋藏在营销布局或模糊的状态散文中的通知，会增加客户粘贴错误条目或跳过验证的机会。同样的纪律适用于内部运行手册。在发布压力下的开发者应在看到背景叙述之前看到停止条件、批准来源、精确指纹和审查者规则。
按控制而非口号问责
GitHub 拥有最大的预防控制份额。它控制了主机私钥的生成、存储、使用和退役。它控制了密钥出现的仓库服务。它控制了本可检测或阻止私钥的产品安全功能，即使公开记录未显示哪一个适用。它控制了轮换计划、权威公告、指纹页面、API 数据、支持指导和第一方 Action 更新。它还控制了在遏制之后发布多少细节。
GitHub 也拥有合理的紧急裁量权。为避免客户摩擦而保留可能被复制的主机私钥，将保留冒充路径。正确的批评不是平台行动过于激进。而是紧急权力应与准备证据相结合：演练过的轮换、已验证的发布控制、一致的消息传递以及持久变更的事后说明。
客户控制了自己的信任消费。他们决定是否使用 SSH 或 HTTPS，是否固定 RSA 主机密钥，是否学习备用主机密钥算法，是否集中管理 known-hosts，是否将密钥烘焙到镜像中，是否固定 Action 提交，是否维护镜像，以及是否允许开发者绕过严格检查。这些选择并不能开脱提供者的密钥暴露。它们决定了提供者端事件转化为客户停机或不安全恢复的程度。
CI 维护者和集成供应商控制了嵌入的信任材料和更新渠道。为方便而隐藏主机密钥的工具应暴露安全更新它们的方式。依赖实时扫描的工具应警告用户关于验证。为完整性而固定依赖的工具应使紧急审查足够快，使安全固定不会变成过时固定。
采购和法务团队控制了一个更安静的边界。他们通常接受平台条款，而不映射哪些控制由供应商单独行使。一个更好的合同审查问题不简单是损害赔偿是否设限。而是提供者将在信任事件期间披露哪些操作事实，客户如何验证紧急通知，安全关键轮换是否有支持路径，以及修复后将交付哪些证据。
攻击者，如果有谁使用了密钥，将为冒充或窃听负责。公开记录未确认此类使用。网络运营商、DNS 提供者和其他信任渠道参与者在假设性利用中可能相关，但审查的事实未显示他们在此事件中的失败。
可验证的修复会是什么样子
此事件后成熟的控制记录不会是没有主机密钥会被暴露的承诺。而是证据表明该类失败变得更难重复，且更容易安全恢复。
对于保管，GitHub 应能证明生产主机私钥无法通过记录在案的紧急路径之外进入普通仓库、开发者工作站、日志、测试夹具或构建工件。该证据可能包括密钥生成控制、访问日志、导出限制、扫描覆盖范围和自动撤销触发器。外部人员不需要每个敏感细节。他们只需要足够的保证，以了解修复不仅限于更换一个密钥。
对于检测，GitHub 应能显示从发布到警报、从警报到遏制、从遏制到轮换决策、从轮换决策到客户通知的时间。它还应该能说明审查了何种检索证据以及还有哪些可见性限制。“无理由认为存在滥用”是有意义的公司声明，但它与已发布的检测依据不同。
对于响应，GitHub 应将主机密钥轮换作为正常练习进行测试。OpenSSH 支持在认证后使用已信任密钥进行 UpdateHostKeys 的机制，参见source: man.openbsd.org，但紧急暴露限制了重叠时间。提供者仍然可以演练客户通知、API 更新、状态消息、第一方集成和支持脚本。干净的演练将衡量客户是否能在不禁用检查的情况下更新。
对于客户，可验证的修复意味着保持所有 GitHub 信任材料和使用 SSH 的工作流的清单。它意味着知道哪些作业使用带有 SSH 的 actions/checkout，哪些是固定的，哪些基础镜像包含 known-hosts 文件，以及哪些发布路径可以切换到 HTTPS。它意味着将主机密钥故障记录为安全事件，而非简单的构建噪声。它意味着在编辑信任文件之前保留证据。
对于中小企业，修复应保持简单。一个简短的运行手册、一个测试过的 HTTPS 远程、一个关键仓库的镜像、一个主机密钥变更的第二审查者，以及订阅的安全通知，对许多公司来说可能就足够了。核心要点不在于消除对 GitHub 的依赖。而在于使依赖足够可见，从而提供者信任修复不会迫使即兴发挥。
小型客户的故障链
此事件的小型客户版本通常最不可见，因为它产生的公开申报少且没有合并的事件计数。一个开发者遇到失败的管道。错误提到变更的主机密钥。发布已经延迟。安全通知可能可用，但阅读它的人必须比较指纹、更新信任文件、重新运行作业，并向客户或经理解释延迟。如果组织没有运行手册，安全路径将与从旧论坛答案复制的一行变通方案竞争。
这就是开发者工具经济学成为问责证据的地方。GitHub 通过在一个位置托管仓库、协作工作流、拉取请求、问题、包和托管自动化，降低了小型团队的运营成本。小型企业可能通过依赖该平台节省了数年的基础设施工作。这种节省的代价是提供者信任变更作为本地操作事件到达。企业不协商主机密钥轮换时间表。它对此做出反应。
对此类企业，第一个控制是预先决策的清晰性。主机密钥警告不应分配给最强烈希望发布通过的人。它应分配给预先选定的安全或发布负责人，即使该负责人是仅有的两名工程师之一。组织应在一个简短记录中保留确切的提供者指纹来源、内部批准规则和回滚计划。重点不在于仪式。而在于消除在压力下发明判断的需要。
第二个控制是分离的恢复。一人通过 HTTPS 通道验证提供者通知和指纹。另一人通过配置管理或审查后的提交应用变更。如果团队太小，无法有两名待命人员，则后备选项是延迟发布，直到可用的第二审查者，除非是定义的紧急补丁。这并不是因为两个人总是更准确。而是因为分离验证和应用的行为抓住了最常见的不安全捷径：信任有争议的 SSH 路径呈现的密钥。
第三个控制是传输纪律。当 SSH 主机信任正在修复时，HTTPS 回退可以保留交付，但它必须已经配置了范围限定的凭据。使用广泛个人令牌或暴露凭据在构建日志中的匆忙切换，是用一个事件换取另一个事件。回退应在提供者事件之前进行测试，具有足够获取或推送特定仓库的权限，且不超过此权限。
第四个控制是证据保留。失败的 CI 日志、主机密钥警告和时间戳应在编辑之前保留。如果客户后来怀疑拦截或需要证明失败的部署是由提供者轮换引起的，擦除的本地证据将使答案更弱。GitHub 可能有成功 Git 活动的服务器端记录，但被拒绝的 SSH 握手可能永远作为 Git 事件到达服务。客户端日志是记录的一部分。
这些控制是适度的。它们不需要企业安全运营中心。它们需要认识到主机身份是生产配置。一旦有了这种认识，密钥轮换的成本就可以作为小变更来管理，而不是一场安全控制被禁用以使工作变绿的危机。
采购应要求轮换证据
采购通常向云和开发者工具供应商询问正常运行时间数字、数据处理条款、安全认证和事件通知条款。2023 年 3 月的事件为软件供应链平台提出了更具体的证据请求：展示客户信任对象如何轮换，以及客户如何认证替换。
该请求不应要求秘密内部设计。它应询问生产私钥是否受到导出限制、紧急轮换是否经过演练、哪些客户渠道用于认证密钥材料、哪些第一方集成嵌入了主机身份、状态和安全通知如何保持一致性，以及客户是否会收到变更控制的事后说明。这些不是奇异的问题。它们是供应商权威与客户依赖之间的操作接口。
合同语言也可以命名客户职责，而不假装客户控制平台密钥。一个平衡的条款可以说，提供者将及时发布经过认证的替换材料并说明受影响的服务范围，而客户将维护更新自身信任存储和保留严格检查的流程。这并不消除责任争议。它给双方一个实践过的路径。
同样的证据属于内部风险登记册。一家声称 GitHub 不关键因为代码可以克隆到别处的公司，应该测试这种说法。它能否在别处足够快地恢复仓库、受保护分支规则、发布工件、工作流定义、部署密钥、问题历史、包引用和团队权限？如果不能，即使合同否认广泛可用性保证，GitHub 也足够关键，需要信任轮换计划。
测试应包括通知渠道本身。如果只有那些可以通过聊天系统、单点登录流程或依赖同一平台事件的部署仪表板联系到的人才能批准主机密钥变更，那么恢复计划是循环的。紧急信任变更需要一个认证的来源、一个离线可读的运行手册，以及一个在开发者工具降级时仍然存在的审查者路径。
最终评估
确认的事件是中等影响和高置信度。RSA 主机私钥暴露为仍然信任该密钥且网络路径可被转移的 SSH 客户端创造了可信的冒充风险。GitHub 的轮换是审慎的、有范围限制的，并有公开记录。审查的记录未显示客户仓库被盗、GitHub 基础设施受损、用户私钥暴露或旧主机密钥被确认滥用。
问责认定比事件规模更尖锐。GitHub 对共享主机身份的操作控制超过了客户在普通条款下能购买的实际保护。客户可以阅读合同，但不能检查密钥保管路径。他们可以接受免责声明，但主机身份变更时他们仍必须停止构建。他们可以拥有自己的仓库，但提供者端的密钥事件可能决定他们的发布系统是否信任来源。
这就是合同与控制的不匹配：法律文件描述了服务关系；事件揭示了操作依赖。因此，问责属于实际控制点。GitHub 负有保管、快速轮换、准确通知和修复证据的责任。客户负有严格验证、信任清单和连续性计划的责任。这些职责之间的区别并非抽象。在 2023 年 3 月 24 日 05:00 UTC，这正是一个安全暂停与一个不安全粘贴之间的区别。