Salesforce 使 Heroku OAuth 令牌保管成为开发者平台问责的试金石

总结

• Heroku 2022 年的 GitHub 集成事件之所以重要，是因为 OAuth 令牌并非普通密码；它们是一种委托授权，可以连接源代码仓库、部署流水线、构建系统、客户应用程序以及下游软件用户。
• GitHub 公开警告称，攻击者使用了窃取到且颁发给 Heroku 和 Travis CI 的 OAuth 用户令牌，而 Heroku 的事件通报要求客户在调查、撤销和凭据重置过程中遵循轮换指南。
• 问责问题不仅在于 Heroku 最终是否轮换了密钥或恢复了集成，更在于谁控制了令牌保管、客户通知、GitHub 应用行为、源代码访问证据、CI/CD 信任边界以及事后证明。
• 本文将 Heroku、GitHub、Travis CI、Salesforce、IETF、NIST、CISA 和 MITRE 来源视为独立的证据渠道；没有任何公开来源被当作完整的内部取证记录。
• 持久的教训是：开发者平台的便利性必须附带一份保管台账——存在哪个集成令牌、为什么存在、拥有什么权限、存储在哪里、谁能撤销它、以及当令牌变得可疑时客户能收到什么证据。

为何此案属于风险与问责档案

Salesforce 使 Heroku OAuth 令牌保管成为开发者平台问责测试，因为 Heroku 是一个托管型开发者平台，其价值建立在代码、部署、身份和操作之间边界的信任之上。客户使用 Heroku 将应用程序连接到源代码仓库、部署代码、自动化构建流程、管理团队、添加附加组件、接入数据服务以及运行生产工作负载。因此，Heroku 与 GitHub 的集成并非锦上添花的便利。它可能成为从客户的源代码系统通往部署平台、再从部署平台回到客户运营风险的桥梁。

2022 年的公开触发点是由于 GitHub 在https://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/发布了安全警报，描述了窃取到且颁发给 Heroku 和 Travis CI 的 OAuth 用户令牌。Heroku 自己的状态事件页面https://status.heroku.com/incidents/2413以及 Heroku 于 2022 年 4 月公开发布的事故回顾https://blog.heroku.com/april-2022-incident-review从平台角度勾勒了事件框架。Travis CI 的安全公告https://www.travis-ci.com/blog/2022-04-15-security-bulletin/提供了另一个受影响的集成渠道。这些来源确立了公开的轮廓：与开发者工作流相连的 OAuth 令牌、客户通知、调查更新以及一系列保护措施。

该案例之所以重要，是因为 OAuth 改变了问责的形态。被盗的密码通常可以通过单个用户账户来解释。而被盗的 OAuth 令牌可能代表着委托授权，其寿命超出了用户最后一次考虑同意的时刻。它可能携带仓库访问权限、自动化工作流访问权限、API 权限、元数据访问权限、组织成员关系影响或部署权限。IETF OAuth 2.0 资料https://datatracker.ietf.org/doc/html/rfc6749以及 OAuth 安全最佳实践记录https://datatracker.ietf.org/doc/html/rfc9700虽非针对 Heroku 的事件报告，但有助于定义令牌颁发、权限范围、存储、轮换、撤销、重放抵抗以及客户端信任为何重要。

问责档案不应将 Heroku、Salesforce、GitHub、Travis CI 和客户混为一谈。Salesforce 拥有 Heroku 这个业务和品牌。Heroku 控制着平台集成设计、客户通信、平台内的凭据处理以及其能够发布的证据。GitHub 控制着自己的调查、令牌撤销、源托管证据、OAuth 应用控制以及面向客户的安全警报。Travis CI 控制着自己受影响的集成渠道和客户指南。客户控制着自己的仓库权限、部署选择、秘密轮换、审计审查以及对指令的回应。下游软件用户如果因源代码访问或部署信任导致后续暴露，则承担风险。

这种角色映射之所以重要，是因为开发者平台创造了共享责任，但并不总是同时提供共享证据。Heroku 客户可能被告知要轮换凭据或检查仓库，但他们无法独立重建 Heroku 端的令牌存储路径或 GitHub 端攻击者的行为。GitHub 用户可以撤销一个 OAuth 应用，但他们可能不知道哪个 Heroku 部署流水线、应用程序或团队需要替换访问权限。采购官员可以询问平台是否仍然可接受，但决定依赖于并非全部公开的技术细节。因此，问责问题在于证据分配：每个行为者知道什么，每个行为者能证明什么，以及在不确定性持续期间客户必须做什么？

公开记录还显示，为何开发者工具事件属于软件供应链问责，而不仅仅是账户安全问责。源代码访问是应用程序安全、秘密、CI/CD 作业、构建产物、部署凭据和产品发布的上游环节。MITRE ATT&CK 的应用程序访问令牌技术https://attack.mitre.org/techniques/T1528/和替代认证材料技术https://attack.mitre.org/techniques/T1550/是很有用的词汇，因为它们区分了令牌滥用和普通的凭据猜测。CISA 的安全设计资料https://www.cisa.gov/securebydesign和 NIST 的《安全软件开发框架》https://csrc.nist.gov/pubs/sp/800/218/final有助于解释为何源代码保管和构建系统信任必须被视为生产控制措施。

本文不声称拥有 Heroku 私有日志、GitHub 私有仓库审计数据、Travis CI 内部记录、逐客户通知、执法部门通信或 Salesforce 董事会材料。它利用公开档案来追问：证据是否使实际控制可见？一份强有力的问责记录不仅应显示令牌已被撤销，还应显示可疑活动何时被发现、涉及哪些权限范围、哪些客户需要采取行动、哪些仓库访问已确认或排除、哪些秘密可能已暴露、凭据何时轮换，以及平台做出了哪些改变以防相同的令牌保管路径再次无声发生。

OAuth 同意在首次点击后即变为保管

许多 OAuth 审查中的首个操作错误是将同意视为一次性的用户决定。在开发者平台中，同意变成了保管。一旦用户授权应用程序访问仓库，平台、身份提供方、源代码托管方和客户管理员都继承了持续的义务。令牌有一个生命周期。它被颁发、存储、刷新、使用、记录、定作用域、撤销、替换，并最终被遗忘或退役。Heroku 事件之所以重要，是因为公开记录迫使客户在信任决定已嵌入开发工作流之后才思考这个生命周期。

GitHub 当前的 OAuth 文档https://docs.github.com/en/apps/oauth-apps和维护 OAuth 应用指南https://docs.github.com/en/apps/oauth-apps/maintaining-oauth-apps很有用，因为它们展示了围绕 OAuth 应用、客户端密钥、回调 URL、所有权和应用管理的控制词汇。GitHub 的企业审计日志指南https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/about-the-audit-log-for-your-enterprise显示了为何组织需要在疑似集成事件后获得活动证据。Heroku 的 GitHub 集成文档https://devcenter.heroku.com/articles/github-integration显示了客户可见的功能界面。这些文档中没有任何一份能确切证明 2022 年发生了什么。它们确立了客户必须加以保护的操作界面。

保管意味着平台必须回答与正常运行时间不同的问题。OAuth 令牌存储在哪里？是刷新令牌还是访问令牌？它们是否已加密、分段或按租户隔离？哪个服务或数据库能读取它们？什么监控能显示异常使用？谁能撤销它们？撤销后需要客户采取什么操作？Heroku 能否在未经客户重新同意的情况下从 GitHub 部署？构建时秘密、配置变量、仓库内容或部署密钥是否面临风险？首次通知时已知哪些答案，哪些仍在调查中？

这些问题并非不友好。它们是信任的基础。开发者平台可以有正当理由存储令牌，但必须同时提供保护证据。平台可以快速撤销令牌，但撤销证据必须与客户指令配对。平台可以要求轮换 Heroku 用户密码或 API 密钥，但客户需要知道为何需要轮换，以及是否还需要检查仓库。平台可以说对于部分用户无需客户操作，但该声明应基于技术边界。

Heroku 的公开记录包含不断演变的客户指令。这种演变本身并非失败。事件响应通常从怀疑到确认经历多个阶段。问责问题在于这些阶段是否足够清晰，以至于客户无需猜测就能跟上。如果客户收到的第一条消息说一件事，而后来的消息要求更广泛的操作，平台应解释证据发生了什么变化。如果客户被告知要轮换凭据，指令应指定哪些凭据、截止日期、哪些应用上下文以及客户应审查哪些日志。

经济维度是真实的。开发者团队优化快速集成，因为手动部署和凭据管理成本高昂。OAuth 应用减少了摩擦。但当提供方的保管路径失败时，便利的成本以紧急劳动的形式重新出现：审查仓库、轮换秘密、重建集成、搜索日志、向客户解释暴露情况以及回答审计问题。因此，开发者工具经济学属于本文的主题范围。从便捷集成中获益的平台必须投资于保管、撤销和证据。

源代码访问不等于生产环境沦陷，但并非无害

公开记录必须抵制两种错误的简化。一是认为被盗的 OAuth 令牌自动意味着生产应用程序已沦陷。二是认为如果没有生产中断，源代码访问就无害。两种说法都站不住脚。源代码可能包含应用程序逻辑、依赖信息、内部端点、部署脚本、配置模式、测试夹具、注释、旧秘密、基础设施名称和安全假设。同时，仅有源代码访问并不能证明运行时访问、数据窃取或部署操纵。

GitHub 的警报和 Heroku 的事件通报之所以重要，是因为它们将源代码访问风险放入了公开档案。使用连接仓库的客户需要知道攻击者能否读取私有仓库、仓库中是否提交了秘密、部署凭据是否存在于 GitHub 之外、GitHub Actions、Heroku 流水线、审查应用或 CI 作业是否暴露了额外材料，以及仓库级别的审计日志是否显示了异常访问。如果客户使用 Travis CI，同样的问题可能扩展到 CI 环境变量和构建日志。

NIST SP 800-218https://csrc.nist.gov/pubs/sp/800/218/final很有用，因为它将安全软件开发视为一个生命周期，而不仅仅是代码编写。NIST SP 800-204Dhttps://csrc.nist.gov/pubs/sp/800/204/d/final有助于理解云原生应用程序安全和服务身份问题。NIST SP 800-53 Rev. 5https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final提供了访问控制、审计、配置、事件响应和系统完整性方面的控制词汇。这些材料并非针对 Heroku 的发现。它们是判断开发者平台事件是否应视为软件供应链事件的基准。

关键的边界是证据。如果平台能确定 OAuth 令牌仅用于某个特定仓库或客户集，则应解释该判断的依据。如果由于日志限制无法确定逐客户访问范围，应明确说明。如果 GitHub 能基于令牌使用或仓库访问通知受影响的用户，则公开记录应明确通知的含义及其不包含的含义。如果客户需要检查自己的日志，提供方应说明哪些日志源是重要的。

公开风险还因客户的成熟度而异。大型企业可能拥有 GitHub 企业审计日志、集中式秘密扫描、软件组合分析、CI/CD 隔离和事件响应人员。较小的 Heroku 客户可能只有一个简单的 GitHub 连接、一两名维护人员和有限的日志保留期。因此，相同的令牌事件会带来不同的负担。成熟的问责记录不会假设每位客户都能独立填补提供方的证据缺口。它应为小团队提供实际步骤，并为大团队提供足够的技术细节以进行自动化审查。

下游受众比 Heroku 账户持有人更广泛。如果源代码访问暴露了漏洞或秘密，客户软件的下游用户可能后来受到影响，即使原始平台事件并未导致立即停机。这并不意味着每个下游用户都受到了伤害。这意味着问责分析必须追溯风险路径：令牌窃取、可能的仓库访问、可能的源代码或秘密暴露、可能的 CI/CD 滥用、可能的生产访问以及可能的下游损害。每个步骤在成为主张之前都需要证据。

通知时机是控制面的一部分

事件通信通常被视为法律或公共关系职能，但对于开发者平台，它是操作控制。客户在知道该做什么之前无法撤销令牌、轮换秘密、重建集成或检查仓库。延迟、模糊或不断变化的通知可能会延长客户暴露或不明确的时间。快速但不完整的通知可能会造成不必要的工作。因此，问责标准不仅仅是速度，而是每个阶段的决策有用性。

Heroku 的事件页面https://status.heroku.com/incidents/2413很有用，因为状态更新显示的是序列而非单一的最终声明。GitHub 的安全警报提供了另一个时间线渠道。Travis CI 的公告提供了第三个。仔细的读者不应将这些时间线合并成一个完美的年表，除非来源支持。有用的问题是每个行为者的通知如何改变客户的操作。客户是否需要撤销应用授权？是否需要轮换 Heroku API 密钥？是否需要轮换 Heroku 用户密码？是否需要检查 GitHub 仓库？是否需要检查 CI 环境变量？是否需要重建部署钩子？

答案可能随着事实的浮现而改变。当变化得到解释时，这是可以接受的。通知可以说“我们正在调查可能的访问，并将提供进一步说明”。可以说“我们已撤销令牌，客户必须重新授权”。可以说“我们要求重置密码，因为我们无法排除哈希凭据被访问的可能性”。可以说“我们没有发现某类证据，但客户应检查自己的日志以查找这些指标”。削弱问责的不是不确定性，而是将不确定性呈现为结论。

客户通知还负有细分义务。并非每个 Heroku 客户都使用了 GitHub 集成。并非每个 GitHub 用户都授权了 Heroku。并非每个 Travis CI 用户都有相同的权限范围。并非每个仓库都包含敏感材料。有用的通知应区分受影响的、可能受影响的、未受影响的和未知的群体。如果无法精确细分，提供方应解释原因。客户不应从宽泛的标题推断消息是否适用于他们。

通信质量是可以衡量的。提供方是否发布了持久的事件页面？消息是否包含日期和时间戳？是否指明了受影响的服务？是否提供了具体的客户操作？是否在变更时更新了先前的指南？是否保持了直接客户通信和公开记录的一致性？是否发布了事后回顾，指出了控制改进而未披露可利用的私有细节？这些既是问责问题，也是通信问题。

在开发者工具经济学中，不清晰的通信将成本转移给客户。每个模糊的句子都会变成下游的一场会议、一张工单、一次日志搜索、一封客户邮件或一次审计例外。平台可能出于法律谨慎，但一个销售开发者信任的平台应将决策有用的通知视为产品的一部分。Heroku 事件显示了为何事件通信需要产品工程纪律：版本化的指令、细分受众、可追溯的修正以及完成证据。

强制轮换只有在客户知道什么发生了变化时才是一种补救

强制凭据轮换可能是必要的，但作为信任修复仍可能不完整。客户可以轮换 API 密钥、重置密码或重新授权 OAuth 应用，但客户还需要了解平台保管模型中发生了什么变化。如果相同的存储路径、权限范围设计、监控缺口或客户证据缺口仍然存在，轮换可能恢复访问而非恢复信心。围绕 Heroku 2022 年事件的公开记录将轮换和重新授权置于客户行动的中心。问责问题在于这些行动是否得到了持久控制证据的支持。

Heroku Dev Center 页面如https://devcenter.heroku.com/articles/oauth、https://devcenter.heroku.com/articles/platform-api-reference、https://devcenter.heroku.com/articles/heroku-cli和https://devcenter.heroku.com/articles/account-security展示了 Heroku 平台使用周围的更广泛访问管理环境。Heroku 的两因素身份验证页面https://devcenter.heroku.com/articles/heroku-2fa提供了客户端的账户加固背景。再说一次，当前的文档并非 2022 年内部状态的证据。它们有助于读者理解 Heroku 账户周围可能存在的各种凭据和用户操作。

轮换有三个不同的层面。首先，撤销受损的 OAuth 令牌，使攻击者无法继续使用委托授权。其次，客户端替换或重新授权，使合法工作流能够用新令牌恢复。第三，审查相邻凭据，包括 API 密钥、密码、部署密钥、CI 变量、仓库秘密、个人访问令牌和云凭据。平台通知应明确说明需要哪个层面及其原因。

最困难的层面是源代码秘密暴露。如果攻击者能够读取仓库，仅轮换 OAuth 令牌可能不够。客户可能需要搜索仓库中已提交的秘密，并轮换任何暴露的值。GitHub 的秘密扫描文档https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning为客户端审查提供了当前词汇。CISA 的软件供应链指南https://www.cisa.gov/resources-tools/resources/software-supply-chain-risk-management-sscrm和安全设计资料有助于解释为何代码中的秘密可以将仓库事件转化为更广泛的运营风险。

强制轮换还需要一个完成信号。客户应知道旧令牌是否已失效、是否需要重新授权、禁用的集成是否在客户操作前保持禁用、密码重置完成是否被跟踪、以及过期的凭据是否仍在任何地方被接受。没有完成信号，每个客户都必须运行自己的对账工作。这既昂贵又容易出错。

平台也需要内部的完成证据。哪些客户账户完成了要求的步骤？哪些账户仍处于例外状态？哪些客户无法联系？哪些集成已被遗弃？哪些令牌无法映射到当前的拥有者？添加了哪些控制措施以防止无声的长期令牌保留？公开的事后总结可能不会披露客户名称，但可以披露清理工作的概况。这就是“我们轮换了”与“风险状态不再存在”之间的区别。

GitHub、Heroku、Travis CI、Salesforce 和客户各自拥有不同的证据

此次事件的问责地图是多方的。GitHub 拥有源托管证据、OAuth 应用可见性以及其发布的安全警报。Heroku 拥有其平台集成、客户通信、令牌保管和强制凭据计划。Travis CI 拥有其受影响的 CI/CD 集成渠道和客户指南。Salesforce 拥有 Heroku 的治理、资源分配、风险升级以及使平台修复可信的责任。客户拥有仓库卫生、秘密轮换、组织 OAuth 审批和部署审查。这些角色没有一个能取消其他的角色。

这一点很重要，因为客户伤害可能源于角色之间的空白。如果 GitHub 知道令牌被使用，但客户不知道它映射到哪个 Heroku 应用程序，客户的响应就会更慢。如果 Heroku 知道哪些账户使用了 GitHub 集成，但无法判断仓库内容是否被访问，客户就必须进行更广泛的审查。如果 Travis CI 和 Heroku 共享一个 GitHub 警报但客户指令不同，同时使用两者的组织就必须协调冲突或重叠的操作。如果 Salesforce 将 Heroku 视为子公司品牌，而客户将 Heroku 视为生产平台，那么治理就必须弥合品牌边界。

云和 SaaS 共享责任文件通常说明提供方和客户义务不同。Heroku 事件表明，共享责任还需要共享证据。如果提供方不披露其保证涵盖供应链的哪一部分，客户就无法负责任地接受提供方的保证。如果提供方将所有行动转嫁给客户，但客户缺乏所需的日志或产品功能，则无法负责任地采取行动。源托管方不能假设下游工具会完美地翻译其警报。每个行为者必须使其证据对链条中的下一个行为者有用。

IETF、NIST、MITRE、CISA、GitHub、Heroku 和 Travis CI 来源共同构成了一个有限的公开档案。它们没有揭示每一个私有事实，但允许一个清晰的问责模型。OAuth 令牌应严格限定范围、可防御地存储、可快速撤销、持续监控，并映射到当前的业务目的。开发者平台应足够具体地通报事件，以便客户采取行动。客户应定期审查集成，而不是将授权视为永久性的。源托管方应使审计证据足够可用，以便客户区分可能的暴露和已确认的访问。

角色地图也提醒我们避免简单的指责。如果攻击者窃取了令牌，攻击者应对滥用负责。但问责会追问谁能够减少机会、爆炸半径和不确定性。令牌存储设计可以减少机会。权限范围最小化可以减少爆炸半径。快速撤销可以减少持续时间。良好的日志可以减少不确定性。清晰的客户指令可以减少浪费的劳动。事后控制证据可以减少复发。这些是设计选择，而不仅仅是事后声明。

客户可验证的证据是共享责任中缺失的一半

Heroku 事件也显示了当证据不对称时共享责任语言的局限性。平台可以告诉客户，他们负责仓库卫生、秘密轮换和 OAuth 应用审查，但客户仍然依赖提供方证据来决定在哪里查找。如果提供方无法说明令牌是否具有仓库读取权限、是否在某个日期之后被使用、是否与特定应用关联、或是否存在客户特定的日志，那么客户的责任就变成了猜测练习。一个公平的共享责任模型应同时赋予客户职责和可用的证据。

客户可验证的证据始于清单。每个客户应能看到哪些 Heroku 应用程序连接到了哪些 GitHub 组织、仓库、用户和部署流。清单应显示当前状态、最后授权时间、权限范围、拥有者、重新授权要求以及连接是否已被提供方禁用。没有这张地图，安全团队就必须从旧工单、仓库网络钩子、部署历史和个人开发者账户中重建集成。这正是一个平台在提供方侧令牌事件后应减少的紧急劳动。

第二个证据层面是活动。客户需要知道哪些日志可以显示仓库访问、OAuth 授权使用、API 密钥使用、Heroku 账户活动、部署事件、构建事件和配置更改。如果相关证据仅存在于 GitHub，提供方应引导客户查看 GitHub 审计记录。如果相关证据仅存在于 Heroku，提供方应提供客户特定的视图或支持渠道。如果某些证据由于日志未保留或未收集而不可用，提供方应明确说明。“没有滥用的证据”只有在客户知道审查了哪些证据时才对决策有用。

第三个层面是秘密暴露。仓库访问风险不仅限于作为知识产权的源代码。它还包括已提交的秘密、历史配置、测试凭据、部署令牌、云密钥、数据库连接字符串以及揭示架构的注释。客户需要将令牌事件与秘密扫描和轮换联系起来的指南。强有力的平台响应应说明哪些类别很可能、哪些类别可能以及哪些类别不在已知路径之内。还应避免暗示仅凭令牌撤销就能化解仓库内容的风险。

第四个层面是软件发布保证。如果客户使用 Heroku 从 GitHub 自动部署，客户需要知道未经授权的仓库访问是否可能影响了已部署的代码、构建产物、审查应用、流水线或发布历史。这并不意味着这种影响已经发生。它意味着客户应收到足够的信息来证明或反驳它。发布历史、构建来源、部署时间戳、仓库提交签名、分支保护和 CI 日志都应成为问责档案的一部分。

第五个层面是持久的清理。客户应能判断可疑状态何时结束。旧的 OAuth 令牌是否已被撤销？集成是否已用新令牌重新授权？密码或 API 密钥轮换是否已完成？已放弃的应用是否已禁用？孤立的个人授权是否已被移除？平台是否阻止了旧令牌类在任何后台作业或遗留路径中保持活动？当客户能够将自己的租户状态与提供方的完成证据进行对账时，提供方的保证最为有力。

这种客户证据模型并不要求提供方在开放网络上发布敏感的私有日志。它可以通过账户仪表板、直接通知、支持导出、企业事件简报或合同证据包来交付。形式可因客户层级和敏感性而异。但原则不应改变：当提供方要求客户采取行动时，还应提供客户按比例采取行动所需的证据。

采购和治理应将集成视为常设接入

采购的经验教训是，OAuth 集成是常设接入，而非一次性设置任务。只询问提供方是否支持加密、多因素认证或正常运行时间目标的供应商风险调查问卷将错过 Heroku 的教训。更尖锐的问题是集成清单、令牌存储、权限范围最小化、客户日志、紧急撤销、租户级通知、构建系统隔离和事后证据。开发者平台应预期这些问题，因为它们的产物有意靠近软件交付。

合同语言也应避免模糊的责任转移。提供方可以要求客户保护其仓库和凭据，但应说明如何处理提供方侧的集成事件。提供方是否会通知使用相关集成的每位客户？是否会提供受影响的时间窗口？是否会确认源代码访问是否已被确认、可能或未观察到？是否会要求重新授权？是否会暴露审计事件？是否会提供事后摘要？是否会支持需要自己通知的受监管客户？这些并非大型企业的奢侈品。它们是任何其软件供应链依赖该平台的客户的基本操作问题。

Salesforce 和 Heroku 内部的治理也很重要。公众不应假设一个子公司品牌因其面向开发者而承担较少的问责。Heroku 应用程序可以是生产应用程序、内部工具、公共 API、成为关键的原型或处理敏感工作流的后台系统。所有权结构之所以重要，是因为治理决定了在日志记录、令牌保管、事件响应、客户支持和安全工程方面的投资。母公司无需披露每一次董事会讨论，就能表明一个开发者平台事件得到了认真的控制关注。

同样的治理问题也适用于产品管理。产品团队可能希望无缝的 GitHub 集成，因为它能减少摩擦并帮助客户快速部署。安全团队可能希望短命令牌、狭窄权限范围、客户可见的日志和定期重新授权。支持团队可能希望消息足够简单以适应小客户。企业销售团队可能希望合同证据。问责出现在这些激励在事件发生前得到协调的地方，而不仅仅是发生后。如果平台在正常运营中无法说明谁拥有令牌保管风险，那么在危机期间它将难以说明谁拥有它。

对于客户来说，实际的治理响应是按后果分类集成。个人生产力集成不同于可以读取生产源代码的部署集成。只读仓库应用不同于可以创建部署或管理网络钩子的应用。试用 Heroku 应用不同于面向客户的生产应用。组织应对能够影响生产代码或秘密的集成分配更强的审查、日志记录和重新认证。Heroku 事件提醒我们，“已连接应用”是一个治理对象，而不仅仅是一个便利功能。

结果是一个更成熟的问责标准。开发者平台应发布足够的事件证据，以便客户完成自己的风险决策。客户应维护足够的集成清单，以便能够快速对提供方证据采取行动。源代码托管方应保持 OAuth 和审计控制的可用性。CI/CD 供应商应将构建秘密与广泛的仓库信任分开。母公司应将开发者信任视为生产信任。当以这种方式解读时，2022 年的 Heroku 事件就不仅仅是历史上的安全警报。它成为一次测试，检验软件交付链是否能在攻击者迫使所有人关注之前识别出常设接入。

OAuth 保管事件后持久修复应有的样貌

开发者平台 OAuth 事件的持久修复标准至少包含八个部分。第一，提供方应发布明确的时间线：检测、GitHub 通知、Heroku 调查、客户通知、令牌撤销、凭据轮换、重新授权可用性和事后总结。第二，应指明受影响的集成面，而不暗示每位客户或每个仓库都受到同等影响。第三，应解释被盗的 OAuth 令牌、客户密码、API 密钥、部署密钥、仓库秘密和 CI 变量之间的区别。

第四，提供方应以清单形式发布客户操作，区分必要、推荐和条件步骤。第五，应说明客户可以看到哪些证据，以及只有提供方或源托管方才能看到哪些证据。第六，应指明哪些控制措施发生了变化：令牌存储、加密、秘密管理、权限范围审查、监控、异常检测、客户审计访问或集成弃用。第七，应提供完成信号，例如强制重置完成、令牌撤销完成或重新授权执行。第八，应清楚说明剩余的未知项。

Heroku 的公开档案包含有意义的证据，但问责教训比单一事件更广泛。开发者平台应在可疑令牌日到来之前就为其设计。这意味着 OAuth 应用清单、拥有者映射、权限范围最小化、令牌年龄跟踪、自动撤销工作流、客户通知模板、客户特定操作页面、审计日志导出和定期集成重新认证。还意味着在危机之前测试强制重新授权的客户体验。如果客户在平静的一天无法理解修复路径，他们在事件期间也不会理解。

客户也需要持久的习惯。他们应对 OAuth 应用进行盘点、移除未使用的集成、限制组织范围的审批、对高权限应用要求审查、使用秘密扫描、避免提交凭据、轮换长期秘密、保留审计日志以及映射部署流。GitHub 和 Heroku 文档提供了许多基础模块，但治理工作属于每个组织。当客户已经知道哪些应用连接到哪些仓库和生产系统时，供应商事件就会变得更可控。

最终的问责测试不在于平台能否说事件已经结束，而在于能否追溯证据得出结论。可疑令牌是否已被无效化？受影响的客户是否已收到通知？要求的重置是否已完成？源代码访问问题是否已按证据水平得到回答？秘密和部署凭据是否已审查？产品控制措施是否已改变？剩余的未知项是否已保留？对这些问题的“是”比一般的信心声明更有力，因为它告诉客户什么发生了变化。

因此，Heroku 的 2022 年 OAuth 事件属于 Daniel Kade 的风险与问责系列，因为它使开发者信任变得可见。该事件将一个熟悉的集成按钮变成了一个保管问题。它表明，源代码平台、部署平台、CI/CD 供应商和客户通过一个在用户点击后仍然存续的委托授权连接在一起。当这种授权被盗时，问责就会跟随令牌：谁颁发了它、谁存储了它、谁能看到它、谁撤销了它、谁警告了用户、谁证明了修复、以及在证明仍不完整时谁承担了成本。