Docker Hub 令牌泄露：容器供应链的一次问责考验

摘要

• Docker Hub 2019 年未经授权访问事件成为容器供应链问责测试，因为公开报道复制了 Docker 的用户通知，称一个存储了部分非财务用户数据的 Hub 数据库被访问，约 190,000 个账户可能被暴露，并且用于 Docker 自动构建的 GitHub 和 Bitbucket 令牌受到影响。
• 谁实际控制着访问令牌存储、仓库集成范围、客户通知、令牌无效化、自动构建信任以及证明注册表事件不会悄无声息地演变为更广泛的软件供应链妥协的证据？
• 通过 BleepingComputer 在https://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/确认的公开记录以及保存在https://news.ycombinator.com/item?id=19763413的用户通知支持暴露、重置、重新连接和安全日志审查的顺序，而 Docker 当前的文档解释了自动构建和令牌模型。
• 支持的推论是，该事件不仅仅是一个账户安全事件。由于 Docker Hub 自动构建将 Docker Hub 与源代码提供者连接起来，令牌暴露在 GitHub、Bitbucket、Docker Hub、CI/CD、镜像发布和下游镜像消费之间创建了一个治理问题。
• 未知因素依然存在：公开记录未提供 Docker 的完整取证报告、精确的数据库模式、每个账户的令牌范围、源代码提供者的访问日志、没有仓库修改的证据、通知人群或每个客户补救行动的证据。

为什么这个案例属于风险与问责档案

Docker Hub 属于风险与问责档案，因为开发者注册表不仅仅存储工件。它们连接身份、仓库、构建规则、令牌、镜像、标签、网络钩子和下游部署习惯。当注册表表示源代码提供者的令牌可能已被暴露时，问责面立即扩展到注册表账户之外。它延伸到为构建提供支持的代码仓库，以及团队拉取到开发、测试和生产环境中的镜像。

最好的公开事件记录目前不是 Docker 通知页面。2019 年报道中引用的旧 Docker 支持 URL 不再是一个可靠的实时来源。因此，公开记录基于复制的用户通知文本和同期报道。BleepingComputer 在https://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/报道，Docker 于 2019 年 4 月 25 日意识到对 Docker Hub 数据库的未经授权访问，受影响的数据包括用户名、一小部分用户的哈希密码以及用于 Docker 自动构建的 GitHub 和 Bitbucket 令牌。同一篇文章复制了用户通知文本。Hacker News 的存档帖子https://news.ycombinator.com/item?id=19763413显示了通知语言，包括大约 190,000 个账户可能被暴露（不到 Hub 用户的 5%），并且 Docker 已撤销受影响自动构建用户的 GitHub 令牌和访问密钥。

这些是本文依赖的确认事实：报告了 Docker Hub 数据库的未经授权访问；部分非财务用户数据受到影响；大约 190,000 个账户可能被暴露；包括一些用户名和哈希密码；包括用于 Docker 自动构建的 GitHub 和 Bitbucket 令牌；Docker 要求用户更改相关密码；Docker 表示已撤销受影响的令牌和访问密钥；Docker 要求自动构建用户重新连接仓库并检查源代码提供者的安全日志。Security Affairs 在https://securityaffairs.com/84554/data-breach/docker-data-breach.html、The Hacker News 在https://thehackernews.com/2019/04/docker-hub-data-breach.html以及 Help Net Security 在https://www.helpnetsecurity.com/2019/04/29/docker-hub-breach/都报道了相同的基本顺序。

支持的推论是，这是一个供应链治理事件，即使没有公开来源证明下游妥协。Docker 当前的自动构建文档https://docs.docker.com/docker-hub/repos/manage/builds/解释了 Docker Hub 可以从源代码仓库自动构建镜像，并将构建的镜像推送到 Docker 仓库。链接源代码的文档https://docs.docker.com/docker-hub/repos/manage/builds/link-source/解释了用户链接 GitHub 或 Bitbucket 源代码提供者，以便 Docker Hub 可以访问源代码仓库。设置页面https://docs.docker.com/docker-hub/repos/manage/builds/setup/表示当代码被推送到源代码提供者时，自动构建可以构建镜像。这种设计使源代码提供者的令牌成为构建链的一部分，而不仅仅是账户便利。

未知因素仍然重要。公开记录未识别未经授权的行为者、访问方法、数据库字段、所有令牌权限、任何令牌是否被使用、任何源代码仓库是否被修改、任何镜像是否以未经授权的更改重建，或 Docker 如何验证是否发生滥用。因此，本文避免无根据的指控。它没有说 Docker Hub 镜像被投毒、源代码被更改或 Docker 掩盖了更大的妥协。它表示，在自动构建平台中令牌暴露产生了证明撤销、范围界定、客户行动和构建链完整性的问责义务。

确认的事实、支持的推论和未知因素

确认的公开时间线始于 2019 年 4 月 25 日，当时 Docker 的通知称发现对一个 Hub 数据库的未经授权访问。保存在https://news.ycombinator.com/item?id=19763413的通知语言表示该数据库存储了部分非财务用户数据，Docker 已采取行动干预并保护网站。通知称约 190,000 个账户的敏感数据可能被暴露。它描述该群体不到 Hub 用户的 5%。它标识的数据类别包括用户名和一小部分用户的哈希密码，以及用于 Docker 自动构建的 GitHub 和 Bitbucket 令牌。

确认的公开修复顺序有三个层次。首先，Docker 要求受影响用户更改他们的 Docker Hub 密码以及任何其他共享该密码的账户密码。其次，对于可能受影响的自动构建用户，Docker 表示已撤销 GitHub 令牌和访问密钥，并要求用户重新连接仓库。第三，Docker 要求用户检查 GitHub 和 Bitbucket 安全日志以查找意外操作。通知还表示正在进行的构建可能受影响，用户可能需要取消链接并重新链接 GitHub 和 Bitbucket 源代码提供者。

支持的推论是，Docker 正确处理了令牌无效化，认为其比仅重置密码更重要。密码暴露威胁 Docker Hub 账户。源代码提供者令牌暴露威胁 Docker Hub 与代码仓库之间的桥梁。该桥梁可能具有读取或写入含义，具体取决于提供者权限和集成模型。GitHub 的 OAuth 文档https://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-apps警告用户检查授权的应用程序并查找广泛的权限，包括私有仓库访问。GitHub 的安全日志文档https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-security-log解释了用户可以检查涉及他们账户的操作。Bitbucket Cloud 审计日志指南https://support.atlassian.com/bitbucket-cloud/kb/bitbucket-cloud-audit-log-events/解释了工作区审计日志跟踪关键活动。这些来源支持实际的修复模型：撤销、重新连接、检查日志并验证。

未知因素限制了判断。公开记录不包括受影响客户列表、完整令牌范围、每个被撤销令牌未被使用的证明、完整的 GitHub 或 Bitbucket 日志关联、因撤销导致的失败构建列表，或事后技术报告。从公开证据中也不清楚所有受影响用户是否理解更改 Docker 密码和检查源代码提供者仓库之间的区别。这种沟通差距很重要，因为如果发生源代码提供者滥用，将首先在 GitHub 或 Bitbucket 活动中可见，而不一定在 Docker Hub 中。

令牌保管使注册表成为源代码控制依赖

核心问责问题是令牌保管。提供自动构建的注册表要求开发者连接源代码提供者。这种连接很有价值，因为它减少了手动工作。推送到 GitHub 或 Bitbucket 可以触发 Docker Hub 构建，生成的镜像可以推送到注册表供下游使用。但同样的连接创建了保管义务。Docker Hub 持有或控制可以影响源代码访问和构建行为的凭据。当这些凭据暴露时，注册表事件跨入源代码控制风险。

Docker 当前的文档仍然显示了这种依赖关系的形态。自动构建概述https://docs.docker.com/docker-hub/repos/manage/builds/表示 Docker Hub 可以从外部仓库的源代码自动构建镜像，并将构建的镜像推送到 Docker 仓库。链接源代码页面https://docs.docker.com/docker-hub/repos/manage/builds/link-source/表示用户将托管源代码服务链接到 Docker Hub，以便 Docker Hub 可以访问源代码仓库。设置页面https://docs.docker.com/docker-hub/repos/manage/builds/setup/将 GitHub 和 Bitbucket 列为源代码提供者。这些页面是当前产品文档，而非 2019 年事件证据，但它们解释了为什么源代码提供者令牌是高价值对象。

对于开发者来说，自动化路径感觉正常。配置源代码提供者。定义构建规则。让推送触发镜像。稍后拉取镜像。对于问责分析师，路径是保管链。谁可以授权源代码提供者？需要哪些范围？令牌是用户绑定、团队绑定还是服务账户绑定？它们是加密存储的吗？它们被轮换了吗？它们可以大规模撤销吗？构建是否签名或可证明？镜像标签是否可变？日志是否保存足够长以重建可疑重建？这些问题在令牌暴露后变得紧迫。

Docker 的通知，按公开复制的形式，通过行动回答了某些问题。令牌被撤销。用户被告知重新连接。安全日志被提及。额外的监控被声称已就位。这是一个可信的初步回应。但它没有证明完整的链。它没有显示暴露的令牌具有哪些权限、未经授权访问持续了多久、是否有任何源代码仓库来自意外地址的访问、任何构建输出是否改变，或者 Docker 是否可以将每个令牌与源代码提供者活动关联起来。

这种区别正是该事件不仅仅是违规通知故事的原因。这是一个开发者平台控制故事。存储构建集成令牌的注册表必须能够回答不仅“谁的账户数据被暴露”，而且“这种暴露能否改变代码、改变镜像或改变下游系统部署的内容？”答案可能是“否”。但可问责的记录需要证据。

自动构建将便利转化为爆炸半径

自动构建是一个经典的具有隐藏弹性成本的生产力特性。Docker 的文档https://docs.docker.com/docker-hub/repos/manage/builds/描述了当源代码更改时，分支或标签规则触发构建。然后构建生成镜像并推送到 Docker Hub。这减少了手动发布摩擦。这也意味着附加到自动化路径的凭据可以位于已发布工件的上游。如果凭据范围过大、寿命长、用户绑定到强大的维护者或监控薄弱，注册表妥协可以创建源代码控制和镜像完整性不确定性。

2019 年事件没有公开证明恶意镜像发布。关键点是可能性必须被调查。BleepingComputer 在https://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/警告说，令牌可能允许访问私有仓库代码，并可能根据权限进行修改。该表述是一个风险场景，而非确认的结果。Help Net Security 在https://www.helpnetsecurity.com/2019/04/29/docker-hub-breach/同样强调了令牌危险。一个严谨的文章应保持该界限：令牌暴露创建了供应链风险；公开证据未显示风险已实现。

修复的含义是苛刻的。密码重置不够。令牌撤销是必要的但不充分。重新连接可以恢复构建，但如果团队急于使管道变绿，也可能隐藏缺失的审计工作。负责任的客户必须检查 GitHub 安全日志https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-security-log，检查已授权的 OAuth 应用程序https://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-apps，检查 Bitbucket 审计日志https://support.atlassian.com/bitbucket-cloud/kb/bitbucket-cloud-audit-log-events/，并根据相关指南（如https://support.atlassian.com/bitbucket-cloud/docs/revoke-a-workspace-access-token/）撤销或替换受损的访问令牌。

对用户来说，这是一个沉重的运营负担。平台的违规成为客户的审计项目。维护者必须检查源代码提供者日志、调查意外访问、轮换凭据、重新链接提供者、确认没有镜像从未经授权的源代码更改构建，并告知下游团队镜像标签是否仍可信。通知可以要求用户做这些工作，但平台必须认识到这是转移的成本。

这对于开源维护者和小团队尤其困难。大型企业可能有日志、SIEM 集成、仓库治理和事件响应手册。志愿者维护者可能有一个个人 Docker Hub 账户链接到 GitHub 仓库，有限的日志可见性，以及没有直接联系的下游用户拉取镜像。开发者工具经济学鼓励便利和低摩擦。问责要求将由此产生的令牌资产视为生产基础设施。

通知将修复工作转移给维护者

Docker 的通知，按公开复制的形式，不仅仅宣布了暴露。它分配了工作。用户必须更改相关密码、重新链接源代码提供者、检查安全日志并恢复损坏的自动构建。这是对令牌事件的合理回应，但它也将成本转移给了维护者和组织。控制受损数据库的一方可以撤销令牌并发送通知。控制源代码仓库的一方必须证明暴露的桥梁是否被使用。

这很重要，因为维护者的能力截然不同。具有 GitHub 组织审计控制、Bitbucket 工作区日志、Docker 组织管理和 CI/CD 监控的企业可以构建证据文件。它可以问谁授权了应用程序、授予了哪些仓库权限、哪些令牌被撤销、哪些构建作业失败，以及是否在时间窗口内发生了任何源代码提交或镜像标签更改。个人维护者可能只看到一封令人困惑的电子邮件、一个损坏的自动构建和一个检查日志的请求。同样的事件因此在生态系统中造成不平等的修复负担。

修复负担也延伸到从未收到原始通知的下游用户。拉取公共镜像的公司可能不知道维护者的 Docker Hub 账户是否在范围内。维护者可能不知道每个下游消费者。注册表平台可能知道账户级别的暴露，但不知道每个部署的镜像副本。这就是为什么开发者平台中的令牌事件值得供应链分析的结构性原因。直接暴露以账户衡量。信任效应以工件、依赖项和假设衡量。

因此，可问责的通知应做三件事。它应明确标识受影响的账户和集成。它应区分必需的行动和推荐的审查。它应解释平台已做了什么以及客户单独能验证什么。如果用户必须检查源代码提供者日志，通知应说明时间窗口、提供者和要检查的事件类型。如果自动构建在重新链接前将失败，通知应解释恢复构建不等于完成安全审查。

公开记录显示 Docker 的通知确实提到了重新链接和源代码提供者安全日志。这是一个优势。剩下的差距是结案证据。公众无法看到 Docker 后来是否确认没有令牌滥用、每个受影响的令牌是否成功撤销、是否错过了任何客户群体，或者是否向客户发送了最终报告。私下的结案可能存在。它不在本文可用的公开记录中。这种不确定性应被记录，而不是用假设填充。

源代码提供者日志成为客户的证据层

Docker 的通知告诉用户检查 GitHub 或 Bitbucket 安全操作以查找意外访问。这个指示是对的，但它也揭示了一个问责限制。Docker 可以撤销令牌并识别受影响的 Docker Hub 账户。源代码仓库是否被访问或更改的证据可能存在于不同公司的日志中，并在客户的账户下。这使单一平台事件转化为跨提供者调查。

GitHub 的安全日志页面https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-security-log解释了账户用户可以检查涉及他们的操作。GitHub 的 OAuth 应用审查页面https://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-apps告诉用户验证没有新的具有广泛权限的应用程序被授权。GitHub 的 OAuth 访问限制指南https://docs.github.com/en/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictions解释了组织如何控制 OAuth 应用程序对组织资源的访问。当第三方构建集成在范围内时，这些控制至关重要。

Bitbucket 的 OAuth 文档https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/解释了令牌流程和提供者授权。Bitbucket Cloud 审计日志指南https://support.atlassian.com/bitbucket-cloud/kb/bitbucket-cloud-audit-log-events/描述了工作区级日志记录。Bitbucket 令牌撤销指南https://support.atlassian.com/bitbucket-cloud/docs/revoke-a-workspace-access-token/和仓库令牌撤销https://support.atlassian.com/bitbucket-cloud/docs/revoke-a-repository-access-token/解释了如何移除访问权限。这些文档显示了客户需要在 Docker 之外协调的证据和修复工作。

问责挑战是关联。客户需要连接 Docker 的受影响账户通知、Docker 的令牌撤销、GitHub 或 Bitbucket 日志、自动构建失败、仓库活动和镜像发布历史。如果客户不能关联这些记录，调查将通过假设结束。对于低风险爱好项目来说，这可能可以接受。但对于企业构建链或广泛使用的开源镜像来说，这不可接受。

提供者可以通过提供结构化证据来减轻负担：受影响的令牌标识符、提供者类型、受影响的仓库名称（如果已知）、最后使用时间（如果可用）、撤销时间、所需的客户行动，以及关于 Docker 是否在未经授权访问期间观察到任何令牌使用的明确声明。公开报道未显示每个客户是否私下收到了那种细节水平。公开记录显示用户被告知检查日志并重新连接。

现代令牌指南显示了修复路径应成为的样子

Docker 后来的令牌指南有助于定义持久的修复应是什么样子。Docker 个人访问令牌文档https://docs.docker.com/security/access-tokens/解释了令牌生成、过期、权限和管理。Docker 组织访问令牌文档https://docs.docker.com/enterprise/security/access-tokens/强调了范围限定的仓库权限、管理权限、轮换、监控令牌使用和安全存储。Docker 2019 年关于个人访问令牌的博客https://www.docker.com/blog/docker-hub-new-personal-access-tokens/将令牌定位为密码的替代品和高级访问控制的构建块。2021 年 Docker 的范围限定令牌博客https://www.docker.com/blog/level-up-security-with-scoped-access-tokens/明确了最小权限方向。

这些后来的材料不是 2019 年 4 月存在哪些控制的证据。它们之所以相关，是因为它们描述了该类风险的持久修复逻辑。令牌应该有范围。它们应该过期。它们应该被监控。它们应该是可归因的。它们应该是可撤销的。它们不应跨不相关任务共享广泛的管理员权力。构建令牌应只执行构建所需的工作，其使用应留下足够的证据以重建活动。

Docker 的迁移文档https://docs.docker.com/docker-hub/repos/manage/builds/migrate/也相关，因为它表示 Docker Hub 自动构建已被弃用，将于 2027 年 4 月 1 日退役。该页面建议迁移到 CI 工作流，在 CI/CD 平台机密管理器中创建并安全存储令牌。这一未来方向并未抹去 2019 年事件。它强化了注册表托管的自动构建凭据是一个特殊的治理问题。将自动化迁移到 CI/CD 并不会消除令牌风险。它改变了谁存储令牌、谁记录使用以及谁能证明构建。

NIST SP 800-218 在https://csrc.nist.gov/pubs/sp/800/218/final推荐了可集成到软件开发生命周期中的安全软件开发实践。CISA 的安全软件开发证明表https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form反映了公共部门对证据支持的安全开发实践的趋势。OWASP CI/CD 安全备忘单https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html将 CI/CD 管道视为高价值攻击面。OWASP 机密管理备忘单https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html强调集中化、轮换、审计和生命周期控制。这些来源都不是对 Docker 私有环境的调查结果。它们定义了现代构建链令牌系统应满足的证据标准。

最小权限只有在可观察时才有用

最小权限通常被描述为一种权限设置纪律，但此事件表明它也是一种证据纪律。具有窄权限的令牌减少了损害。具有窄权限和清晰日志的令牌减少了不确定性。具有窄权限、清晰日志、过期、轮换历史和所有者归属的令牌为事件响应者提供了结案的路径。没有这些证据，撤销的令牌可能让客户问：暴露的凭据在撤销之前是否重要？

对于 Docker Hub 自动构建，有用的问题非常具体。令牌能够读取私有仓库吗？它可以写部署密钥或网络钩子吗？它可以更改仓库内容吗？它可以触发构建吗？它可以读取构建机密吗？它可以推送镜像吗？它是绑定到一个仓库、一个组织还是一个用户的广泛访问？在暴露窗口期间，它是否从意外网络位置被使用？Docker 和源代码提供者能否在不暴露机密的情况下关联令牌标识符？公开记录没有回答这些问题。持久的控制模型应该回答它们。

可观察的最小权限也改变了客户行为。如果客户可以看到令牌是只读的、限于仓库、在相关窗口内未被使用、在特定时间被撤销，并用一个寿命更短的范围限定令牌替换，客户可以做出有限的决策。它可以从已知良好的提交重建镜像并结案。如果客户看不到任何这些，它可能不得不假设更大的爆炸半径，或者因为审查成本太高而什么都不做。两种结果都很糟糕。

后来 Docker 的访问令牌材料https://docs.docker.com/security/access-tokens/和https://docs.docker.com/enterprise/security/access-tokens/指向一个更可问责的模型，因为它们强调权限、管理、监控和安全存储。同样的想法出现在 GitHub 和 Bitbucket 组织控制中。仅仅给用户创建令牌的方法还不够。平台应使令牌范围在创建前可理解、在使用期间可见、在暴露后可重建。

对于 CI/CD 和注册表生态系统，可观察的最小权限应成为合同期望。持有构建凭据的供应商应能够识别凭据类别、范围、所有者、创建时间、最后使用、存储保护、轮换状态和撤销状态。客户应能够导出足够的日志，而不仅仅依赖支持单票进行调查。下游用户应能够在工作流支持的情况下固定镜像摘要或验证出处。结果不是完美的安全性。而是一个更小、更可检查的不确定性场。

容器镜像携带下游信任

该事件之所以重要，是因为容器是下游工件。Docker 镜像可以被开发者笔记本电脑、CI 作业、Kubernetes 集群、云服务、测试环境或生产主机拉取。它可能被标签固定、摘要固定、内部镜像、扫描、重建或直接从 Docker Hub 拉取。如果上游令牌暴露引发了对源代码或镜像完整性的不确定性，下游消费者可能不知道测试哪个假设。

学术工作强化了更广泛的风险环境。2020 年对 Docker Hub 镜像的漏洞分析https://arxiv.org/abs/2006.02932研究了数千个镜像，并将 Docker Hub 描述为主要的镜像仓库。2023 年对容器镜像中机密的研究https://arxiv.org/abs/2307.03958发现，暴露的机密在容器镜像中可能对证书、API 机密和主机产生实际影响。这些研究并未证明 2019 年 Docker Hub 数据库事件的任何情况。它们显示了为什么镜像仓库和容器工件是软件供应链的高后果表面。

关键区别在于平台妥协和用户创建的风险之间。2019 年事件涉及 Docker Hub 账户和集成数据。镜像中机密的问题通常涉及用户意外将凭据烘焙到镜像中。两种风险在注册表交汇。平台必须保护账户和令牌数据。用户必须避免发布机密并验证镜像出处。下游消费者必须决定信任哪些镜像。成熟的注册表生态系统支持所有这三个角色，并带有控制和证据。

对于 Docker Hub，令牌暴露后的问责问题不仅仅是“密码是否已重置？”而是“维护者能否证明源代码和镜像输出在暴露窗口期间未被更改？”该证明可能需要仓库日志、构建日志、镜像摘要、签名标签、源代码提交检查、依赖项审查和下游重新部署决策。如果团队不能产生该证明，他们可能需要从可信来源重建并重新发布。

该成本不应被忽视。公开通知中的直接数字是大约 190,000 个账户。间接数字从公开证据中无法得知：这些账户涉及的项目、镜像、CI 系统和下游部署。按平台百分比计算的小受影响群体如果一些账户维护广泛使用的镜像或私有企业构建，仍然可能重要。

客户应该能够验证什么

客户需要首先验证自己是否受到影响。一个好的通知应标识他们的 Docker Hub 账户是否在范围内，他们的源代码提供者集成是否在范围内，哪个提供者受影响，令牌是否已被撤销，自动构建是否会失败，以及需要哪些确切行动。一个让用户猜测的通用消息可能导致反应不足或恐慌。复制的通知确实给出了直接行动。未知的是每个用户收到了多少账户特定的细节。

其次，客户需要验证源代码提供者活动。对于 GitHub，这意味着检查安全日志、OAuth 应用程序、仓库审计事件（如果可用）、部署密钥、网络钩子和相关期间的提交。对于 Bitbucket，意味着检查审计日志、OAuth 消费者、工作区或仓库令牌，以及意外的仓库更改。在这两种情况下，目标不仅是看是否有人登录。而是看与自动构建相关的令牌是否创建或修改了访问、触发了意外活动或接触了代码。

第三，客户需要验证镜像完整性。如果令牌对源代码或构建配置具有写能力，即使 Docker Hub 账户本身看起来正常，下游镜像也可能受影响。维护者应比较源代码提交、Dockerfile 更改、构建日志、镜像摘要和发布时间。如果有任何不清楚，使用新凭据从已知良好的提交重建，并为下游用户发布清晰的通知。

第四，客户需要验证凭据卫生。如果哈希密码在范围内，密码重置很重要。但源代码提供者 OAuth 令牌、Docker Hub 访问令牌、CI/CD 机密、部署密钥、网络钩子机密和注册表凭据都有不同的生命周期。OWASP 机密管理备忘单https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html在这里很有用，因为它将机密管理视为存储、配置、审计、轮换和生命周期控制，而不是一次性重置。

第五，客户需要验证未来治理。GitHub 组织 OAuth 访问限制https://docs.github.com/en/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictions可以防止未管理的 OAuth 应用程序访问。Docker 组织访问令牌https://docs.docker.com/enterprise/security/access-tokens/可以范围限定到仓库和管理操作。Bitbucket 仓库级令牌权限https://support.atlassian.com/bitbucket-cloud/docs/repository-level-access-token-permissions/可以限制令牌权力。这些控制在下次集成暴露时减少爆炸半径。

持久的修复应证明什么

在开发者注册表令牌事件后，持久的修复应证明六件事。第一，应证明范围。提供者应知道哪些账户、令牌类、源代码提供者和仓库受影响，并应区分已确认的暴露和可能的暴露。当确切的证据不可用时，应说明这种不确定性。

第二，应证明撤销。令牌无效化必须记录时间、目标、提供者和成功状态。如果任何提供者或客户的撤销失败，例外必须可见。“我们撤销了令牌”是有用的，但客户需要知道他们的令牌是否被撤销以及他们是否必须采取额外行动。

第三，应证明滥用分析。提供者应保存并分析关于暴露令牌是否在未经授权访问期间或之后被使用的可用证据。由于某些证据位于源代码提供者处，提供者应给客户足够的标识符和时间窗口以进行自己的审查。Docker Hub 的公开记录未显示完整的滥用分析。这仍然是一个未知数。

第四，应证明构建链完整性。对于自动构建平台，恢复必须包括构建日志、源代码提交关联、镜像摘要审查、标签历史和失败构建协调。如果由于令牌范围有限而无法影响镜像输出，应予以解释。如果镜像输出可能受影响，客户需要重建和通知路径。

第五，应证明客户沟通。通知应区分确认的事实、客户行动、提供者行动、未知因素、后续更新和支持渠道。还应明确重新链接源代码提供者恢复功能，但不代替源代码日志审查。复制的 Docker 通知确实列出了行动，并指向了 GitHub 和 Bitbucket 日志。更强大的公开记录将包括最终结案声明。

第六，应证明未来的最小权限。令牌存储应走向范围限定、短生命周期、服务账户、每仓库权限、轮换、监控和集中化机密治理。Docker 关于范围限定令牌和组织令牌的后续文档反映了这一方向。可问责的标准不是 2019 年的每个控制都已匹配未来指导。而是令牌事件应产生朝向最小权限和可验证使用的持久移动。

问责随凭据走，而不仅仅是账户

最终的分配应跟随凭据路径。Docker 控制 Hub 数据库、令牌存储环境、用户通知和令牌撤销操作。GitHub 和 Bitbucket 控制源代码提供者授权、日志和提供者端撤销机制。客户控制仓库、构建定义、组织策略和下游通知。用户和部署者控制他们是否固定镜像、审查摘要、从源代码重建或继续拉取可变标签。

这种分配比说 Docker 对一切负责或客户对一切负责更精确。Docker 对数据库事件和暴露令牌群体有最好的视角。客户对仓库活动和镜像使用有最好的视角。源代码提供者对其系统中的令牌活动有最好的视角。下游用户可见性最低，对维护者证据的依赖性最大。链只有在每个方都能产生其独特控制的证据时才有效。

凭据路径问责也改变了事件的命名方式。将事件称为账户违规是准确的但不完整。将其称为令牌保管事件更有用，因为它将注意力引向系统之间的桥梁。相同的用户名和密码暴露可以包含在一个平台内。令牌暴露可以按设计到达另一个平台。集成越强，响应必须随凭据走的越多。

对于软件供应链，这一教训即使 Docker Hub 自动构建走向退役也仍然成立。CI/CD 系统、包注册表、工件仓库、云部署者、源代码主机、扫描服务和发布自动化都使用凭据连接服务。每个便利集成都创建一个保管问题。凭据存储在哪里？谁可以使用它？它能接触什么？如何撤销？什么证据证明它没有被滥用？2019 年的注册表事件之所以仍然重要，是因为这些问题变得比以往更加核心。

因此，可问责的标准简单但苛刻：暴露的凭据不应留下无声的不确定性。平台应撤销并披露。源代码提供者应公开日志和控制。客户应在必要时审查并重建。下游用户应有方式验证可信工件。当任何环节不能产生证据时，供应链将歧义吸收为风险。

反事实不是没有事件；而是没有无声的供应链路径

没有主要的开发者平台能保证永远不会遭受未经授权访问。更好的反事实是，事件不能从账户数据无声地跨越到源代码和容器工件。如果令牌有范围、被轮换、被监控并且可撤销，平台可以减少爆炸半径。如果构建输出可以追溯到源代码提交和镜像摘要，维护者可以证明完整性。如果客户通知是具体的，用户可以无需猜测行动。

2019 年 Docker Hub 事件显示了注册表问题如何迅速变成控制链问题。Docker 控制 Hub 数据库、用户通知、令牌撤销和自动构建集成。GitHub 和 Bitbucket 控制它们的日志、OAuth 控制和令牌撤销机制。客户控制源代码仓库、构建配置、镜像发布和下游通知。下游用户控制拉取、固定和部署决策。注册表事件穿越所有这些层，因为集成令牌将它们链接起来。

该分配不支持无根据的指责。公开记录未证明 Docker Hub 源代码仓库被更改或镜像被妥协。它确实证明 Docker 的集成令牌保管创建了比正常密码事件更广泛的问责义务。正确的问题不是“每个最坏情况是否被确认？”正确的问题是“什么证据关闭了每个场景，谁能看到它？”

对于开发者平台，这是永久的教训。便利特性在持有凭据时成为责任特性。自动构建在可以发布工件时成为供应链表面。注册表信任在下游系统部署注册表服务的内容时成为证据信任。因此，令牌重置不仅是账户恢复步骤。它是测试软件供应链能否证明凭据、源代码、构建、镜像和下游信任保持在可问责控制之下的测试。