摘要
- 谷歌威胁情报组报告称，从 2025 年 8 月 8 日起至少至 8 月 18 日，UNC6395 使用与 Salesloft Drift 第三方应用关联的受感染 OAuth 令牌攻击了 Salesforce 客户实例。
- Salesforce 的信任公告称，Salesloft 与 Salesforce 合作，使活动访问令牌和刷新令牌失效，并将 Drift 从 AppExchange 下架；该问题并非源自 Salesforce 核心平台的漏洞。
- Salesloft 信任中心后来说，Mandiant 调查了影响 Drift 产品的疑似入侵事件，调查评估了根本原因、范围、遏制、修复以及 Drift 与 Salesloft 应用之间的隔离。
- 该事件表明，OAuth 同意并非仅仅是管理后台设置。一个权限过大的集成可以成为进入客户 CRM 数据、支持案例、记录中嵌入的凭据以及下游云系统的访问路径。
- 问责随控制而来。Salesloft 控制着 Drift 产品和令牌保管。Salesforce 控制着平台连接应用治理、AppExchange 响应、客户通知渠道、审计可见性和紧急令牌撤销。客户控制着连接应用的批准和数据卫生，但通常仅在平台和供应商提供集成之后。
公开时间线始于代理授权
谷歌威胁情报组的公告《通过 Salesloft Drift 广泛盗取 Salesforce 实例数据》是核心技术来源。GTIG 表示，从 2025 年 8 月 8 日最早开始至至少 8 月 18 日，被追踪为 UNC6395 的行为者利用与 Salesloft Drift 第三方应用关联的受感染 OAuth 令牌攻击了 Salesforce 客户实例。GTIG 称，该行为者从大量企业 Salesforce 实例中导出了大量数据，并搜索了诸如 AWS 访问密钥、密码和 Snowflake 令牌等机密信息。
Salesforce 自己的安全公告界定了平台边界。Salesforce 表示，该事件涉及 Salesloft 发布的 Drift 应用，Salesloft 与 Salesforce 合作使活动访问令牌和刷新令牌失效，并且 Drift 已从 AppExchange 移除。公告还称，该问题并非源自 Salesforce 核心平台的漏洞。这一声明很重要，应予以保留。该事件并不能证明攻击者利用了 Salesforce 核心软件漏洞。
Salesloft 的信任中心后来描述了 Mandiant 对影响 Drift 产品的疑似入侵的调查。它表示，Mandiant 于 2025 年 8 月 26 日受聘，以确定根本原因和范围，协助遏制和修复，并验证 Drift 与 Salesloft 应用之间的隔离。这一来源很重要，因为它将调查定位在供应商层面，而不仅仅是 Salesforce 平台层面。
公开响应顺序很重要。谷歌和 Salesforce 描述了 8 月初至中旬的活动。Salesforce 的公告称令牌已失效，Drift 已从 AppExchange 移除。AppOmni 的Drift-Salesforce 泄露事件分析同样记录道，Salesloft 和 Salesforce 吊销了 Drift OAuth 令牌，受影响的组织由 Salesforce 直接通知。Unit 42 的威胁简报将该攻击活动追踪为利用受感染的 OAuth 凭据从受影响的 Salesforce 环境中窃取数据。
关键的问责事实是代理授权。OAuth 允许用户或管理员在不共享用户密码的情况下授予应用访问数据和执行操作的权限。这种设计对现代 SaaS 至关重要。但当第三方应用拥有广泛的作用域、长寿命的刷新令牌、薄弱的令牌保管以及对高价值 CRM 数据的访问权限时，它也是危险的。令牌成了授权的载体。
这不是普通的密码盗窃
许多泄露应对手册仍然假定存在人类登录。重置密码、添加多因素认证、检查登录历史，然后继续。Drift 攻击活动表明这为何不够。OAuth 令牌不同于用户输入密码。它可以代表一个已经获得数据访问同意的可信应用。它可以绕过某些人类登录控制，因为应用应该在没有人参与的情况下调用 API。
这并不意味着多因素认证无关紧要。多因素认证可以防止初始用户泄露，并保护管理性同意工作流。但一旦存在有效的应用令牌，重要的控制就变成了应用作用域、令牌存储、刷新令牌生命周期、应用审查、撤销速度、API 监控以及数据访问异常检测。客户可能有良好的人为多因素认证，但如果第三方应用的令牌被盗，仍可能暴露风险。
美国联邦调查局和互联网犯罪投诉中心的 TLP:CLEAR 公告《网络犯罪团伙 UNC6040 和 UNC6395 攻陷 Salesforce 平台》警告称，UNC6395 使用了 Salesloft Drift 应用的受感染 OAuth 令牌，并且这种访问机制不同于其他针对 Salesforce 的攻击活动。FINRA 的关于 Salesloft Drift AI 供应链攻击的网络安全警报为受监管的金融公司界定了该事件，称被盗的 OAuth 认证令牌使威胁行为者得以冒充可信的 Drift 应用，获得对客户环境的未授权访问。
这两则公告表明了这为何是一个治理问题，而不仅仅是供应商泄露事件。受监管公司必须检查第三方应用是否能够访问 Salesforce 数据，机密信息是否存储在 CRM 记录中，以及客户或潜在客户是否已暴露。平台和供应商的问题变成了客户的合规问题。
Salesforce 关于连接应用的文档描述了外部应用与 Salesforce 集成的基本模型。它的连接应用 OAuth 文档，包括OAuth 设置，说明了为什么作用域和策略很重要。这些文档不是事件证据。它们解释了控制面。
作用域将信任转变为影响范围
OAuth 作用域定义了应用可以做什么。在最低限度的设计中，应用只获得特定任务所需的访问权限。在宽泛的设计中，它可以读取或写入大量记录类型、调用 API、刷新访问权限，并在广泛的数据面上操作。Drift 攻击活动提出了一个问题：集成的便利性是否超越了作用域的原则。
GTIG 报告称，UNC6395 系统性地查询并导出了 Salesforce 环境中的数据，并在记录中搜索凭据。这意味着暴露范围不限于 Salesloft 拥有的字段列表。它涉及可通过该集成访问的客户 Salesforce 数据。如果客户的 Salesforce 案例、笔记、支持线程、聊天记录、自定义字段或附件中包含机密信息，这些机密信息就可能成为下一阶段的风险。
这与供应商自身客户表的泄露事件有一个关键区别。受感染的令牌使攻击者能够触达每个连接客户的 Salesforce 环境。损害程度取决于每个客户存储了什么、其 Salesforce 组织的配置方式、应用可以访问哪些对象，以及记录中是否嵌入了机密信息。同一个被盗令牌类别可能在不同客户中产生不同的损害。
AppOmni 的分析强调了 SaaS 到 SaaS 的预防，以及跨连接应用实现可见性的困难。Arctic Wolf 的安全公告同样将事件聚焦于受感染的 Salesloft Drift OAuth 令牌和 Salesforce 数据盗窃。这些来源是供应商的分析报告，但它们都强调了同一个控制点：SaaS 集成创造的非人类身份应该接受生命周期治理。
“非人类身份”这个术语听起来可能很抽象。在本事件中，它意味着一种可以在没有人类操作键盘的情况下执行操作的应用凭据。它可能仅被批准一次，然后持续存在。它可能因为宽泛的访问权限使集成有用而拥有广泛访问权。它可能不出现在普通的用户登录仪表板中。它可能比让它存在的业务流程更长久。一旦被盗，它可以迅速行动，因为对于该身份而言，API 调用是正常的。
连接应用市场是控制链的一部分
Salesforce 的公告称，Drift 已从 AppExchange 移除，等待进一步调查。这一响应很重要，因为 AppExchange 不仅仅是一个目录。它是一个信任信号。客户常常推断市场列出的应用已经通过了审查流程，适合安装。市场并不能消除客户的尽职调查，但它会影响客户的选择。
当市场应用成为攻击活动的访问路径时，平台的责任不在于它导致供应商泄露。其责任在于，它必须比逐个客户的发现更快地进行检测、沟通、禁用并帮助客户恢复。平台可以看到跨租户的应用安装情况。它可以识别哪些客户安装了该应用。它可以协调令牌撤销。它可以通知受影响的客户。它可以移除或暂停列表。这种跨客户可见性正是平台治理至关重要的原因。
Salesforce 似乎在公开记录中已经使用了这种平台角色：其公告称它与 Salesloft 合作，使令牌失效，移除了该应用，并通知了受影响的组织。问责问题在于，相对于首次可疑活动，这些行动发生得有多快，以及客户是否有足够的日志访问权限来确定自身的暴露情况。GTIG 报告称攻击活动最早始于 8 月 8 日；令牌撤销据报道在 8 月 20 日。公众可以看到大致的时间间隔，但看不到内部的检测决策过程。
客户也有责任。他们选择应用，批准作用域，在记录中存储机密信息，监控 API 行为，并审查连接应用。但客户的责任受到平台功能的限制。如果连接应用的审查难以理解，如果作用域过于粗糙，如果日志难以访问，如果令牌清单分散，或者如果市场信任模糊不清，客户就会在可见性不足的情况下做出决策。
因此，该事件不应该被框定为简单的三方指责游戏。它是一条链：Salesloft 必须保护 Drift 及其令牌；Salesforce 必须治理连接应用信任和紧急撤销；客户必须限制应用访问并从 CRM 数据中移除机密信息；攻击者利用了这条链。
CRM 数据成为机密搜寻面
GTIG 最令人不安的发现不仅仅是 CRM 记录被导出。而是行为者搜索了机密信息。一个 Salesforce 环境可能包含支持案例、销售笔记、客户入职详细信息、技术故障排查对话、粘贴到工单中的 API 密钥、VPN 端点、云账户标识符、集成凭据、意外存储在案例评论中的密码，或者带有敏感运营数据的附件。这些材料不应该出现在 CRM 记录中，但在现实组织中常常如此。
这将损害性质从隐私转移到横向风险。如果攻击者使用 CRM 导出来查找 AWS 密钥、Snowflake 令牌、VPN 凭据或其他机密信息，泄露事件就可能从客户数据暴露升级为基础设施沦陷。CRM 系统变成了其他系统的地图。它是支持团队记录问题的地方，而这些文档可能包含攻击受支持系统所需的线索。
GTIG 的公开公告称，组织应搜索机密信息并轮换凭据。这一建议操作成本高昂，因为客户必须在自己数据中搜索他们本不应该存储在那里的材料。因此，该事件暴露了客户层的数据卫生缺陷。但触发它的是一次受信任集成的沦陷。客户可能没有意识到，一个聊天机器人或收入工作流集成能够读取包含凭据的记录。
Salesforce 和客户可以通过将机密扫描作为 CRM 控制措施来降低这种风险。应扫描记录以查找密钥模式。支持工作流应阻止粘贴密码或令牌。敏感字段应被屏蔽。应用的作用域不应包含不需要的对象。导出操作应被监控。这些并非奇异的控制措施；它们是对 CRM 系统存储杂乱运营数据这一现实的务实回应。
这种风险也解释了客户通知为何重要。如果客户组织受到影响，其安全团队需要足够快地知晓，以搜索记录、轮换暴露的机密、检查下游云日志，并在必要时警告自己的客户。延迟或含糊的通知可能使被盗的机密保持有效。
撤销是必要的，但它本身并不等同于恢复
令牌撤销关闭了即时的代理访问路径。Salesforce 的公告和 GTIG 都描述了 Drift 访问令牌和刷新令牌的撤销或作废。这是必要的。但它本身并不能移除已经导出的数据或已经被获取的机密信息。恢复工作必须在客户环境内部继续进行。
恢复的第一步是范围界定：哪些 Salesforce 对象被访问，哪些记录被查询，哪些 API 作业被运行，以及使用了哪些集成？Salesforce 的事件监控和事务安全文档以及 API 日志在这里可能起作用，但日志的可用性因版本、配置、留存期和客户成熟度而异。公开公告不能代替租户级别的证据。
第二步是机密轮换。如果记录中包含了 AWS 密钥、Snowflake 令牌、VPN 凭据、API 密钥、密码或 webhook 机密信息，就需要找到并轮换这些机密信息。这很困难，因为机密可能位于自由文本字段、附件、案例评论、聊天日志或自定义对象中。自动搜索有所帮助，但可能会漏掉不常见的格式。手动审查则很缓慢。
第三步是客户和下游通知。CRM 数据被导出的 Salesforce 客户可能对自己的客户、员工、潜在客户、合作伙伴和监管机构负有义务。这会引起连锁反应。Salesloft 的事件变成了 Salesforce 的平台事件，变成了每个受影响客户的事件，可能进一步变成每个受影响客户的客户通知。一次 OAuth 沦陷的代价向外蔓延。
第四步是应用治理审查。客户需要问，其他连接应用是否具有类似的作用域，它们是否仍然需要，刷新令牌是否长期有效，应用所有者是否已知，供应商风险审查是否当前有效，以及紧急撤销剧本是否存在。Drift 事件应被视为对所有其他高权限 SaaS 集成的演练。
AI 品牌没有改变问责问题
一些公开讨论将 Drift 框定为 AI 聊天机器人集成。这对于产品背景很重要，但安全失败并非因为 AI 而神秘莫测。关键问题是代理的 SaaS 访问。聊天机器人、销售互动工具、支持插件、分析连接器、数据增强工具或营销自动化平台，只要它们持有进入客户系统的广泛令牌，都可能变得危险。
AI 可能会增加对集成的需求，因为公司希望对话式工具能够看到更多上下文。一个销售或支持聊天机器人如果能读取 CRM 记录、回答客户问题、更新案例、分配线索并进行个性化回复，就会更实用。每增加一个作用域都会增加实用性和风险。如果该作用域背后的令牌被盗，攻击者就会获得使该产品有吸引力的同样广泛的上下文。
这就是 SaaS 自动化的安全经济学。供应商销售更顺畅的工作流。客户因为工作流节约劳动力而批准访问。平台主办权限模型，因为集成扩展了生态系统价值。风险在于，在攻击活动之后，各方都无法完全定价令牌沦陷的代价。Drift 事件就是这种被低估风险的一个案例研究。
FINRA 的警报很重要，因为受监管的金融公司不能将此视为普通科技新闻。如果一家金融公司在 Salesforce 中使用了 Drift，它就必须评估客户、潜在客户或内部数据是否暴露，以及 CRM 记录中的凭据是否造成了下游风险。同样的逻辑适用于医疗保健、教育、软件、公共部门合同，以及任何 Salesforce 包含敏感运营背景的行业。
事件暴露了可见性不对称
平台可以看到单个客户无法看到的模式。单个客户可能注意到自己 Salesforce 组织中的怪异 API 行为。Salesforce 可以看到 AppExchange 应用安装情况、令牌作废情况以及跨客户模式。Salesloft 可以看到 Drift 产品遥测和令牌保管情况。谷歌威胁情报可以看到跨客户的威胁活动及其自身的调查。没有任何一个客户能看到整个攻击活动。
这种不对称产生责任。拥有跨客户可见性的一方必须迅速发出警告。拥有产品遥测的一方必须迅速调查和遏制。平台必须帮助识别哪些客户受到影响。客户必须在收到通知后迅速采取行动。如果任何一方等待完美的证据，攻击者就可以继续使用有效的授权。
公开记录表明采取了协调行动，但未能显示内部升级的确切速度。GTIG 称攻击活动最早始于 8 月 8 日。Salesforce 的公告报告了作废和移除行动。Salesloft 的信任中心称 Mandiant 于 8 月 26 日受聘。这些日期显示了行动，但没有显示各方何时首次掌握了足够采取行动的信息，或者更早有哪些信号可用。
缺失的时间表很重要，因为 OAuth 攻击活动速度很快。一旦令牌被盗，攻击者就可以自动化查询和导出。数天的差异就可能决定客户是在使用前还是使用后轮换机密。高质量的事后剖析会显示检测时间、决策时间、令牌作废时间、客户通知时间以及日志可用性时间。
客户应了解的教训，而非受到指责
客户有责任，但教训不应变成“客户本该更了解。”许多客户安装市场应用是因为他们依赖平台的信任信号。他们批准作用域是因为供应商说这些作用域是必需的。他们将运营数据存储在 CRM 中，是因为员工将 CRM 用作客户工作的共享记忆。这些都是正常的商业行为，并非默认就是鲁莽之举。
更好的教训是严格治理连接应用。客户应清点连接应用、所有者、作用域、令牌生命周期、最后使用日期以及供应商风险状态。他们应该移除不再需要的应用。他们应该限制可用于应用的配置文件与权限集。他们应该扫描 CRM 数据以查找机密信息。他们应该通过应用（而非仅通过用户）监控 API 行为。他们应该有紧急令牌撤销的剧本。
Salesforce 可以使这些客户责任变得更容易或更困难。清晰的应用权限说明、应用风险评分、对宽泛作用域的管理员警告、简单的令牌清单、更好的默认过期设置、异常警报以及严格的 AppExchange 审查，可以减轻客户负担。平台的设计塑造了客户行为。
Salesloft 和其他 SaaS 供应商也可以通过安全存储令牌、最小化所需作用域、轮换凭据、快速发布事件更新并证明隔离来减轻负担。Salesloft 信任中心提到要验证 Drift 与 Salesloft 应用之间的隔离，这很重要，因为客户需要确信一次产品沦陷不会变成更广泛的供应商沦陷。
OAuth 标准解释了为什么持有者令牌需要额外的戒律
OAuth 的设计目的是代理授权。核心 OAuth 2.0 规范RFC 6749允许客户端在资源所有者授权下获取资源的访问令牌。这种设计强大的地方在于用户无需将密码交给客户端。风险在于，访问令牌通常是一种持有者凭据：任何持有它的人都可以在其作用域内使用它，直到它过期或被撤销。
RFC 6819中的 OAuth 威胁模型和安全注意事项警告了令牌泄露、令牌存储、重放、钓鱼、重定向滥用以及限制作用域和生命周期的需求。更新的 OAuth 2.0 安全最佳实践RFC 9700通过强调现代防护模式延续了这一方向。这些标准并非 Salesforce 的事件报告。它们解释了为什么 Drift 攻击活动在结构上是危险的。
如果 Drift 令牌拥有广泛的 Salesforce 访问权限，令牌本身就体现了信任。安全团队可以移除用户的密码、强制多因素认证，但如果应用令牌仍然有效，风险依然存在。这就是为什么令牌撤销成为紧急行动。也是为什么下一层是作用域最小化。一个作用域狭窄的被盗令牌可能有害但有限。一个拥有广泛读取权限的被盗令牌可以变成数据导出工具。
MITRE ATT&CK 的技术窃取应用访问令牌描述了对手窃取应用访问令牌以访问远程系统和 API。其关于使用替代认证材料的技术覆盖了使用有效认证工件而非密码的更广泛模式。这些框架帮助命名了攻击类别，而不夸大 Salesforce 特有的事实：问题在于有效的代理材料落入了错误之手。
标准的教训很简单，但操作上很困难。令牌应被视为机密信息。刷新令牌应被视为特别敏感的机密信息，因为它们可以铸造未来的访问权限。作用域应尽可能窄到产品容忍的程度。令牌应当被轮换和可撤销。日志应显示按应用和对象划分的令牌使用情况。客户应知道哪些非人类身份可以读取他们的数据。平台应使危险的作用域难以静默批准。
连接应用卫生需要有负责人，而非事后电子表格
许多组织在事件期间才发现自己的连接应用。这为时太晚。连接应用清单应在攻击活动之前就存在：应用名称、供应商、业务所有者、技术所有者、作用域、安装的配置文件、最后使用情况、刷新令牌策略、触及的数据对象、合同状态以及移除程序。如果无人拥有该应用，就无人拥有该风险。
Salesforce 关于管理连接应用和连接应用 OAuth 策略的文档显示，平台提供了管理控制。问题在于客户是否有足够的人员、知识和动力去善用它们。一个小公司可能安装一个销售聊天工具就再不回头审查其作用域。一个大企业可能有数百个连接应用，却没有统一的审查周期。
这正是平台设计应减少错误的地方。危险的作用域应用通俗语言显示可见。未使用的连接应用应易于发现。具有刷新令牌的应用应被突出显示。高风险应用应具备过期或定期重新授权的选项。管理员应能在不破坏无关工作流的情况下撤销应用访问。安全团队应收到按应用划分的 API 异常警报。
客户还需要策略。任何应用在缺少指定所有者和审查日期的情况下都不应获得广泛访问权限。任何应用在业务所有者离职后都不应保持安装状态。任何应用都不应仅仅因为方便而在 CRM 记录中存储机密信息。任何应用都不应因“只是个销售工具”而被排除在事件剧本之外。Drift 攻击活动表明，一个销售工具可以变成安全事件的入口路径。
这个问题部分源自经济因素。连接应用节省劳动力。审查消耗劳动力。如果利益是即时的而风险是稀有的，组织就会对审查投资不足。平台和供应商可以通过降低良好治理的成本来减少这种不平衡：清晰的仪表板、风险评分、自动化建议和更安全的默认设置。
日志必须回答客户可以采取行动的问题
事件指南常常告诉客户审查日志。这个建议只有在日志回答正确问题时才有用。对于 Drift 攻击活动，客户需要知道哪些应用令牌被使用，哪些 Salesforce 对象被查询，哪些记录被导出，来自哪些 IP，带有哪些用户上下文，在什么时间窗口内，以及查询是否搜索了类似机密信息的字符串。
Salesforce 事件监控、API 日志和连接应用报告可以有所帮助，但对完整证据的访问可能取决于许可证类型、留存期和配置。一个缺少合适版本或日志导出管道的客户可能在收到通知后仍然难以确定暴露情况。这是一个平台治理问题。当一个市场集成被跨客户滥用时，平台处于提供标准化证据包的最佳位置。
客户还需要一条可重复的分类路径。首先，确定是否安装了 Drift 并已连接。其次，确定在攻击窗口期间令牌是否处于活跃状态。第三，检查归因于该应用的 API 活动。第四，确定对象和字段访问情况。第五，搜索已导出或可访问的记录中的机密信息。第六，轮换可能已暴露的任何机密信息。第七，如果涉及受监管或客户数据，通知下游各方。
美国联邦调查局/互联网犯罪投诉中心的公告和 GTIG 的指导意见引导客户采取此类行动，但执行情况差异很大。一家大型金融公司可能拥有安全运营团队和日志湖。一家小型 SaaS 公司可能只有一名 Salesforce 管理员、一个托管安全供应商和大量积压工作。因此，同一个攻击活动造成不同等的恢复负担。
这种不平等对于问责制很重要。为不同成熟度公司提供服务的平台不应假设所有客户都能解读原始日志或威胁情报指标。可操作、租户特定的证据能降低响应成本，并减少被盗机密保持有效的机会。
CRM 记录中的机密信息是一种可预防但常见的失败
一个令人不安的教训是，客户必须停止将 CRM 视为运营机密的安全存储之地。支持和销售团队常常将 API 密钥、凭据、持有者令牌、webhook 机密、VPN 详细信息或截图粘贴到案例和笔记中，因为他们试图解决问题。CRM 变成了一个便利存档。当一个集成能够读取它时，这个便利存档就变成了机密信息仓库。
OWASP 的机密管理备忘单解释了为什么机密需要受控存储、轮换和访问纪律。Drift 攻击活动将这一原则应用到了 CRM 数据。如果机密信息出现在记录中，CRM 导出就可能变成钥匙串。
修复部分技术层面：扫描记录查找机密模式，屏蔽敏感字段，限制附件，并在已知密钥格式出现时发出警报。同时也涉及文化层面：培训支持团队不要请求或存储机密信息，为必要的诊断材料提供安全的接收渠道，并使其易于在发现时清除机密信息。如果组织惩罚缓慢的支持过程，却不惩罚不安全的支持笔记，员工就会继续走捷径。
Salesforce 和集成供应商可以通过构建机密检测功能并在广泛的应用作用域包括可能包含敏感运营数据的对象时警告客户来提供帮助。但客户仍然对自己组织内部的数据卫生负责。Drift 事件并没有创造在 CRM 中存储机密信息的不良实践；它揭示了这种实践如何放大第三方令牌沦陷。
公开记录应该保留未发生的事情
声明公开记录未显示的内容同样重要。来源没有表明攻击者利用了 Salesforce 的核心漏洞。它们没有表明每个 Salesforce 客户都受到影响。它们没有表明每个连接 Drift 的客户都有相同的数据被导出。它们没有表明每条导出的记录都包含机密信息。它们没有表明 Salesloft 更广泛的产品套件在调查描述的范围之外受到了入侵。
这些限制保护了公允性。它们也使真正的教训更加鲜明。即使不夸大，该事件也足够严重，因为一个受信任的集成变成了一条进入客户环境的代理访问路径。严重性源自信任模型，而非需要发明一个平台零日漏洞。
该事件也不应被简化为模糊意义上的“第三方风险”。特定的第三方风险是令牌保管和连接应用的授权。一个供应商可能拥有 SOC 报告、合同和安全问卷，但仍然持有需要特别保护的令牌。客户供应商风险审查需要询问 SaaS 集成如何存储令牌、需要哪些作用域、令牌可以多快被撤销，以及供应商在事件后能提供什么证据。
平台的 AppExchange 审查也需要具体化。它不应只在列示时检查应用是否功能正常且满足基本安全要求。它应支持持续监控、快速暂停、客户通知和事后重新验证。对市场的信任是一项持续的义务，而非一次性的徽章。
哪些证据会改变评估
有了更多证据，评估可能朝任一方向改变。如果后续的取证细节显示受感染的令牌作用域极其狭窄，导出数据有限，并且受影响的客户迅速获得了完整的对象级日志，那么运营严重性就应降低。如果后续证据显示作用域更宽、令牌长期有效、令牌存储薄弱、撤销延迟或机密信息广泛暴露，那么严重性就应上升。
如果 Salesforce 发布关于 AppExchange 监控改进、令牌清单功能、客户日志包或更安全的连接应用默认设置的更多细节，那将加强修复记录。如果 Salesloft 发布关于根本原因、令牌保管、隔离和客户补救的更多细节，那将加强供应商问责。如果监管机构发布调查结果，则应将其与当前的公开公告记录分开评估。
在得到上述信息之前，证据支持一个高置信度的控制结论：SaaS 生态需要连接应用治理，将代理令牌视为生产凭据，而非集成管道。
这个结论之所以有用，正是因为它避免了过度断言。它使客户能够在不等待最终法庭记录的情况下加固连接应用。它使平台能够在不承认证据未显示的核心平台缺陷的情况下改进市场和令牌控制。它使供应商将令牌保管视为产品安全义务。该攻击活动的教训并非推测性的：代理访问可能被盗，当它被盗时，生态系统必须知道谁能撤销它，谁能解释它，谁能证明它触及了什么。
撤销演练应成为常规
了解 OAuth 治理是否真实存在的最快方法，就是在事件发生前进行一次撤销演练。选择一个非关键的连接应用。确定业务所有者、作用域、用户、令牌、日志、依赖工作流以及回滚路径。在受控的时间窗口内撤销访问，并测量什么会中断。然后记录谁批准了恢复，以及什么证据表明该应用可以安全重新连接。
这种演练能将抽象的应用清单变成运营知识。它显示安全部门能否找到该应用，管理员能否撤销它，业务部门是否理解工作流，用户是否收到明确的指示，以及日志能否证明该应用访问了什么。它还揭示出团队不敢触碰旧集成的地方，因为没人知道它们为何存在。
Drift 攻击活动表明这种实践为何重要。在真实的沦陷中，当攻击者使用被盗的令牌时，组织不能耗费数天时间去发现谁拥有一个集成。有准备的客户可以先撤销，快速调查，并仅在获得证据后重新连接。没有准备的客户可能犹豫不决，因为每个令牌看起来都像是业务持续性。
问责测试
Drift-Salesforce 攻击活动应通过七项控制措施来评判。
第一，令牌保管：Salesloft 是否将访问令牌和刷新令牌作为高度敏感的凭据加以保护，并且其架构是否最大限度地减少了令牌在 Drift 和其他产品之间的暴露？
第二，作用域设计：Drift 集成是否仅请求其所需的 Salesforce 权限，并且客户是否理解批准这些权限的影响范围？
第三，市场治理：Salesforce 的 AppExchange 审查、监控和紧急移除流程是否以足够快的速度降低了客户风险，一旦供应商应用变得不安全？
第四，跨客户检测：Salesforce、Salesloft 以及威胁情报伙伴是否足够迅速地识别了攻击活动模式，以便在进一步导出之前撤销令牌？
第五，租户证据：受影响的客户是否收到了足够的日志、对象访问证据和指导，以确定被查询了什么，以及机密信息是否暴露？
第六，机密卫生：客户是否在 Salesforce 记录中存储了密码、API 密钥、云令牌或 VPN 凭据，并且他们在暴露后是否轮换了它们？
第七，公开沟通：公告是否保留了关键的区分，即 Salesforce 核心未被利用，同时明确表明 Salesforce 客户数据是通过可信的应用令牌被访问的？
最终的发现并非 Salesforce 是有漏洞的产品。公开记录恰恰相反：该问题并非源于 Salesforce 核心平台的漏洞。发现是，Salesforce 的信任边界包括了连接应用，因为客户通过生态系统体验平台。OAuth 令牌是代理授权。当一个受信任的集成失去这一授权时，平台、供应商和客户都有各自不同的责任。Drift 攻击活动以最令人不安的方式使这些责任显现出来：将一个经批准的生产力集成变成了攻击者手中的钥匙。