摘要
- 2025 年的公开公告描述了通过受损的 Salesloft Drift OAuth 令牌从 Salesforce 客户实例中窃取数据的情况，同时保留了问题并非源于核心 Salesforce 平台漏洞的边界。
- 谁对 OAuth 范围、刷新令牌保管、AppExchange 操作、客户通知、秘密搜寻指导、令牌撤销、连接的应用监控以及授权后委托的 SaaS 权限是否得到治理拥有实际控制权？
- 问责问题在于委托的 OAuth 权限可能超出授予它的业务原因，因此客户和平台提供商需要范围纪律、撤销速度和集成监控的证据。
- Salesforce 客户、受监管公司、销售运营团队、SaaS 供应商、安全团队、审计师和平台市场经理需要证据表明连接的应用信任具有生命周期，而非一次性同意界面。
- 本文在独立的证据路径中保留公司声明、政府或监管机构记录、安全研究、法律材料和标准指南，以免公开档案夸大已知信息。
为什么此案例属于风险与问责档案
Salesforce 将 Drift OAuth 令牌治理作为 SaaS 集成问责测试，因为可见的事件只是更深层次制度问题的表面。2025 年的公开公告描述了通过受损的 Salesloft Drift OAuth 令牌从 Salesforce 客户实例中窃取数据的情况，同时保留了问题并非源于核心 Salesforce 平台漏洞的边界。这一触发因素形成了一个熟悉的公共模式：公司或公共机构必须迅速发布声明，技术团队必须根据不完整的证据开展工作，受影响的人必须决定该怎么做，局外人必须区分信心和证据。风险不仅在于最初的泄露或中断，还在于每个受众可能收到关于实际控制的不同描述。
对于 Salesforce, Inc.，问题涉及 OAuth 令牌、连接的应用、Drift、AppExchange 操作、令牌失效、客户通知、秘密搜寻、SaaS 到 SaaS 治理以及平台-供应商-客户责任边界。这些是操作名词，但也是治理名词。它们指出了谁本可以防止事件发生，谁本可以限制其影响范围，谁本可以使事件更容易被发现，以及谁本可以使修复结果对依赖它的人可见。一个成熟的问责记录不会满足于声明调查已经完成或系统已经恢复。它会问哪些证据使该声明成立，哪些证据仍然不完整，以及谁必须在证据可用之前采取行动。
中心问题因此变得直接：谁对 OAuth 范围、刷新令牌保管、AppExchange 操作、客户通知、秘密搜寻指导、令牌撤销、连接的应用监控以及授权后委托的 SaaS 权限是否得到治理拥有实际控制权？公开答案不应要求读者从精心措辞的事件语言中推断内部控制。它应指出控制点、证据来源、受影响受众以及剩余的不确定性。这种结构既保护了组织，也保护了公众。它可以防止猜测填补本可以诚实描述的空缺，并防止宽泛保证被视为特定修复的证据。
首要证明责任是控制，而非指责
首要证明责任是控制，而非指责，这对 Salesforce, Inc. 很重要，因为问责问题在于委托的 OAuth 权限可能超出授予它的业务原因，因此客户和平台提供商需要范围纪律、撤销速度和集成监控的证据。一个薄弱的审查会从事件中最戏剧性的名词开始，然后问谁该受到指责。一个有用的审查更早开始。它问在事件可见之前谁拥有实际控制面，谁在信号仍可操作时看到了微弱信号，谁有权改变使信号重要的条件。在这种情况下，该控制面包括 OAuth 令牌、连接的应用、Drift、AppExchange 操作、令牌失效、客户通知、秘密搜寻、SaaS 到 SaaS 治理以及平台-供应商-客户责任边界。这些项目不是装饰性列表。它们是问责要么变得可观察，要么消散到机构记忆中的地方。
围绕通过各种受损的 Salesloft Drift OAuth 令牌从 Salesforce 客户实例中窃取数据、连接的应用治理、供应商遏制以及 SaaS 集成问责记录的公开记录也显示了同一事件如何被不同受众误读。客户想知道他们是否需要轮换凭据、警告用户、重建设备、联系监管机构、停止工作流或接受剩余不确定性。董事会想知道管理层在事件发生时是否有足够证据做出这些选择。监管机构想要日期、类别、受影响人口和职责。供应商希望将其自身平台、产品或服务控制与客户的配置区分开来。这些问题没有一个是非法的。问责问题出现在每个受众收到记录的不同片段，而没有人能看到这些片段如何组合在一起。
本部分的一个来源边界是Google Cloud source。它对公开证据档案有用，但无法回答每个内部所有权问题。重点不是夸大来源，而是说明它能证明什么、只能置于背景中的什么以及公开档案之外还有什么。这种纪律在公开文章使用诸如事件、泄露、访问、受影响、恢复、安全或修复等短语时尤为重要。这些词可能准确，但除非它们与日期、系统、人员、受影响受众和剩余例外挂钩，否则仍过于模糊，无法支持决策。
因此，一个更强的记录会将指定的责任人、有日期的证据、面向客户的声明和技术日志联系起来。它会显示组织何时从怀疑转为确认，何时警告受影响方，何时更改相关控制，以及何时能证明更改已到达受影响环境。它还会保留反证。如果供应商说产品环境未受影响，审查应解释该边界的证据。如果公司说只涉及某些字段，审查应解释该范围是如何确定的。如果公共机构说服务继续，审查仍应问清楚创建了哪些手动变通方案以及事后如何对账。
本文将公司声明视为关于公司所说和所报告的证据，而非每个私人取证事实的独立证明。第二个来源边界是source: status.salesforce.com。结合在一起，这些来源支持一种负责任的审查风格：不是裁决，不是营销保证，也不是公开记录不允许的法证重建，而是读者可负责任地了解的地图。这就是为什么本文不断回到实际控制。问责与全知不同。它是说明哪些证据改变了哪些决策、谁有权更改相关控制以及组织在收集证据时谁承担了成本的责任。
证据档案必须匹配操作面
证据档案必须匹配操作面对 Salesforce, Inc. 很重要，因为问责问题在于委托的 OAuth 权限可能超出授予它的业务原因，因此客户和平台提供商需要范围纪律、撤销速度和集成监控的证据。一个薄弱的审查会从事件中最戏剧性的名词开始，然后问谁该受到指责。一个有用的审查更早开始。它问在事件可见之前谁拥有实际控制面，谁在信号仍可操作时看到了微弱信号，谁有权改变使信号重要的条件。在这种情况下，该控制面包括 OAuth 令牌、连接的应用、Drift、AppExchange 操作、令牌失效、客户通知、秘密搜寻、SaaS 到 SaaS 治理以及平台-供应商-客户责任边界。这些项目不是装饰性列表。它们是问责要么变得可观察，要么消散到机构记忆中的地方。
围绕通过各种受损的 Salesloft Drift OAuth 令牌从 Salesforce 客户实例中窃取数据、连接的应用治理、供应商遏制以及 SaaS 集成问责记录的公开记录也显示了同一事件如何被不同受众误读。客户想知道他们是否需要轮换凭据、警告用户、重建设备、联系监管机构、停止工作流或接受剩余不确定性。董事会想知道管理层在事件发生时是否有足够证据做出这些选择。监管机构想要日期、类别、受影响人口和职责。供应商希望将其自身平台、产品或服务控制与客户的配置区分开来。这些问题没有一个是非法的。问责问题出现在每个受众收到记录的不同片段，而没有人能看到这些片段如何组合在一起。
本部分的一个来源边界是source: trust.salesloft.com。它对公开证据档案有用，但无法回答每个内部所有权问题。重点不是夸大来源，而是说明它能证明什么、只能置于背景中的什么以及公开档案之外还有什么。这种纪律在公开文章使用诸如事件、泄露、访问、受影响、恢复、安全或修复等短语时尤为重要。这些词可能准确，但除非它们与日期、系统、人员、受影响受众和剩余例外挂钩，否则仍过于模糊，无法支持决策。
因此，一个更强的记录会将有日期的证据、面向客户的声明、技术日志和董事会可见性联系起来。它会显示组织何时从怀疑转为确认，何时警告受影响方，何时更改相关控制，以及何时能证明更改已到达受影响环境。它还会保留反证。如果供应商说产品环境未受影响，审查应解释该边界的证据。如果公司说只涉及某些字段，审查应解释该范围是如何确定的。如果公共机构说服务继续，审查仍应问清楚创建了哪些手动变通方案以及事后如何对账。
政府和监管机构记录用于公共职责、通知和控制类，而非视为逐受害者技术重建。第二个来源边界是source: ic3.gov。结合在一起，这些来源支持一种负责任的审查风格：不是裁决，不是营销保证，也不是公开记录不允许的法证重建，而是读者可负责任地了解的地图。这就是为什么本文不断回到实际控制。问责与全知不同。它是说明哪些证据改变了哪些决策、谁有权更改相关控制以及组织在收集证据时谁承担了成本的责任。
客户行动只有在提供商证据可用时才公平
客户行动只有在提供商证据可用时才公平，这对 Salesforce, Inc. 很重要，因为问责问题在于委托的 OAuth 权限可能超出授予它的业务原因，因此客户和平台提供商需要范围纪律、撤销速度和集成监控的证据。一个薄弱的审查会从事件中最戏剧性的名词开始，然后问谁该受到指责。一个有用的审查更早开始。它问在事件可见之前谁拥有实际控制面，谁在信号仍可操作时看到了微弱信号，谁有权改变使信号重要的条件。在这种情况下，该控制面包括 OAuth 令牌、连接的应用、Drift、AppExchange 操作、令牌失效、客户通知、秘密搜寻、SaaS 到 SaaS 治理以及平台-供应商-客户责任边界。这些项目不是装饰性列表。它们是问责要么变得可观察，要么消散到机构记忆中的地方。
围绕通过各种受损的 Salesloft Drift OAuth 令牌从 Salesforce 客户实例中窃取数据、连接的应用治理、供应商遏制以及 SaaS 集成问责记录的公开记录也显示了同一事件如何被不同受众误读。客户想知道他们是否需要轮换凭据、警告用户、重建设备、联系监管机构、停止工作流或接受剩余不确定性。董事会想知道管理层在事件发生时是否有足够证据做出这些选择。监管机构想要日期、类别、受影响人口和职责。供应商希望将其自身平台、产品或服务控制与客户的配置区分开来。这些问题没有一个是非法的。问责问题出现在每个受众收到记录的不同片段，而没有人能看到这些片段如何组合在一起。
本部分的一个来源边界是source: finra.org。它对公开证据档案有用，但无法回答每个内部所有权问题。重点不是夸大来源，而是说明它能证明什么、只能置于背景中的什么以及公开档案之外还有什么。这种纪律在公开文章使用诸如事件、泄露、访问、受影响、恢复、安全或修复等短语时尤为重要。这些词可能准确，但除非它们与日期、系统、人员、受影响受众和剩余例外挂钩，否则仍过于模糊，无法支持决策。
因此，一个更强的记录会将面向客户的声明、技术日志、董事会可见性和修复里程碑联系起来。它会显示组织何时从怀疑转为确认，何时警告受影响方，何时更改相关控制，以及何时能证明更改已到达受影响环境。它还会保留反证。如果供应商说产品环境未受影响，审查应解释该边界的证据。如果公司说只涉及某些字段，审查应解释该范围是如何确定的。如果公共机构说服务继续，审查仍应问清楚创建了哪些手动变通方案以及事后如何对账。
安全供应商分析用于观察到的技术、防御者指南和时间线，但文章不会将广泛的活动语言转化为关于每个客户或设施的声明。第二个来源边界是source: unit42.paloaltonetworks.com。结合在一起，这些来源支持一种负责任的审查风格：不是裁决，不是营销保证，也不是公开记录不允许的法证重建，而是读者可负责任地了解的地图。这就是为什么本文不断回到实际控制。问责与全知不同。它是说明哪些证据改变了哪些决策、谁有权更改相关控制以及组织在收集证据时谁承担了成本的责任。
可靠的审查区分已知与推断
可靠的审查区分已知与推断，这对 Salesforce, Inc. 很重要，因为问责问题在于委托的 OAuth 权限可能超出授予它的业务原因，因此客户和平台提供商需要范围纪律、撤销速度和集成监控的证据。一个薄弱的审查会从事件中最戏剧性的名词开始，然后问谁该受到指责。一个有用的审查更早开始。它问在事件可见之前谁拥有实际控制面，谁在信号仍可操作时看到了微弱信号，谁有权改变使信号重要的条件。在这种情况下，该控制面包括 OAuth 令牌、连接的应用、Drift、AppExchange 操作、令牌失效、客户通知、秘密搜寻、SaaS 到 SaaS 治理以及平台-供应商-客户责任边界。这些项目不是装饰性列表。它们是问责要么变得可观察，要么消散到机构记忆中的地方。
围绕通过各种受损的 Salesloft Drift OAuth 令牌从 Salesforce 客户实例中窃取数据、连接的应用治理、供应商遏制以及 SaaS 集成问责记录的公开记录也显示了同一事件如何被不同受众误读。客户想知道他们是否需要轮换凭据、警告用户、重建设备、联系监管机构、停止工作流或接受剩余不确定性。董事会想知道管理层在事件发生时是否有足够证据做出这些选择。监管机构想要日期、类别、受影响人口和职责。供应商希望将其自身平台、产品或服务控制与客户的配置区分开来。这些问题没有一个是非法的。问责问题出现在每个受众收到记录的不同片段，而没有人能看到这些片段如何组合在一起。
本部分的一个来源边界是source: appomni.com。它对公开证据档案有用，但无法回答每个内部所有权问题。重点不是夸大来源，而是说明它能证明什么、只能置于背景中的什么以及公开档案之外还有什么。这种纪律在公开文章使用诸如事件、泄露、访问、受影响、恢复、安全或修复等短语时尤为重要。这些词可能准确，但除非它们与日期、系统、人员、受影响受众和剩余例外挂钩，否则仍过于模糊，无法支持决策。
因此，一个更强的记录会将技术日志、董事会可见性、修复里程碑和异常处理联系起来。它会显示组织何时从怀疑转为确认，何时警告受影响方，何时更改相关控制，以及何时能证明更改已到达受影响环境。它还会保留反证。如果供应商说产品环境未受影响，审查应解释该边界的证据。如果公司说只涉及某些字段，审查应解释该范围是如何确定的。如果公共机构说服务继续，审查仍应问清楚创建了哪些手动变通方案以及事后如何对账。
当前产品文档用于现有控制设计和读者词汇，而非作为功能在事件窗口期间以相同方式部署的证明。第二个来源边界是source: arcticwolf.com。结合在一起，这些来源支持一种负责任的审查风格：不是裁决，不是营销保证，也不是公开记录不允许的法证重建，而是读者可负责任地了解的地图。这就是为什么本文不断回到实际控制。问责与全知不同。它是说明哪些证据改变了哪些决策、谁有权更改相关控制以及组织在收集证据时谁承担了成本的责任。
修复在公告后必须可衡量
修复在公告后必须可衡量，这对 Salesforce, Inc. 很重要，因为问责问题在于委托的 OAuth 权限可能超出授予它的业务原因，因此客户和平台提供商需要范围纪律、撤销速度和集成监控的证据。一个薄弱的审查会从事件中最戏剧性的名词开始，然后问谁该受到指责。一个有用的审查更早开始。它问在事件可见之前谁拥有实际控制面，谁在信号仍可操作时看到了微弱信号，谁有权改变使信号重要的条件。在这种情况下，该控制面包括 OAuth 令牌、连接的应用、Drift、AppExchange 操作、令牌失效、客户通知、秘密搜寻、SaaS 到 SaaS 治理以及平台-供应商-客户责任边界。这些项目不是装饰性列表。它们是问责要么变得可观察，要么消散到机构记忆中的地方。
围绕通过各种受损的 Salesloft Drift OAuth 令牌从 Salesforce 客户实例中窃取数据、连接的应用治理、供应商遏制以及 SaaS 集成问责记录的公开记录也显示了同一事件如何被不同受众误读。客户想知道他们是否需要轮换凭据、警告用户、重建设备、联系监管机构、停止工作流或接受剩余不确定性。董事会想知道管理层在事件发生时是否有足够证据做出这些选择。监管机构想要日期、类别、受影响人口和职责。供应商希望将其自身平台、产品或服务控制与客户的配置区分开来。这些问题没有一个是非法的。问责问题出现在每个受众收到记录的不同片段，而没有人能看到这些片段如何组合在一起。
本部分的一个来源边界是source: help.salesforce.com。它对公开证据档案有用，但无法回答每个内部所有权问题。重点不是夸大来源，而是说明它能证明什么、只能置于背景中的什么以及公开档案之外还有什么。这种纪律在公开文章使用诸如事件、泄露、访问、受影响、恢复、安全或修复等短语时尤为重要。这些词可能准确，但除非它们与日期、系统、人员、受影响受众和剩余例外挂钩，否则仍过于模糊，无法支持决策。
因此，一个更强的记录会将董事会可见性、修复里程碑、异常处理和事后测试联系起来。它会显示组织何时从怀疑转为确认，何时警告受影响方，何时更改相关控制，以及何时能证明更改已到达受影响环境。它还会保留反证。如果供应商说产品环境未受影响，审查应解释该边界的证据。如果公司说只涉及某些字段，审查应解释该范围是如何确定的。如果公共机构说服务继续，审查仍应问清楚创建了哪些手动变通方案以及事后如何对账。
如果出现法律文件或公开程序，除非引用来源中有明确最终裁决，否则将其视为程序或披露记录。第二个来源边界是source: help.salesforce.com。结合在一起，这些来源支持一种负责任的审查风格：不是裁决，不是营销保证，也不是公开记录不允许的法证重建，而是读者可负责任地了解的地图。这就是为什么本文不断回到实际控制。问责与全知不同。它是说明哪些证据改变了哪些决策、谁有权更改相关控制以及组织在收集证据时谁承担了成本的责任。
下一次审计应保留不确定性，而非抹平它
下一次审计应保留不确定性，而非抹平它，这对 Salesforce, Inc. 很重要，因为问责问题在于委托的 OAuth 权限可能超出授予它的业务原因，因此客户和平台提供商需要范围纪律、撤销速度和集成监控的证据。一个薄弱的审查会从事件中最戏剧性的名词开始，然后问谁该受到指责。一个有用的审查更早开始。它问在事件可见之前谁拥有实际控制面，谁在信号仍可操作时看到了微弱信号，谁有权改变使信号重要的条件。在这种情况下，该控制面包括 OAuth 令牌、连接的应用、Drift、AppExchange 操作、令牌失效、客户通知、秘密搜寻、SaaS 到 SaaS 治理以及平台-供应商-客户责任边界。这些项目不是装饰性列表。它们是问责要么变得可观察，要么消散到机构记忆中的地方。
围绕通过各种受损的 Salesloft Drift OAuth 令牌从 Salesforce 客户实例中窃取数据、连接的应用治理、供应商遏制以及 SaaS 集成问责记录的公开记录也显示了同一事件如何被不同受众误读。客户想知道他们是否需要轮换凭据、警告用户、重建设备、联系监管机构、停止工作流或接受剩余不确定性。董事会想知道管理层在事件发生时是否有足够证据做出这些选择。监管机构想要日期、类别、受影响人口和职责。供应商希望将其自身平台、产品或服务控制与客户的配置区分开来。这些问题没有一个是非法的。问责问题出现在每个受众收到记录的不同片段，而没有人能看到这些片段如何组合在一起。
本部分的一个来源边界是source: help.salesforce.com。它对公开证据档案有用，但无法回答每个内部所有权问题。重点不是夸大来源，而是说明它能证明什么、只能置于背景中的什么以及公开档案之外还有什么。这种纪律在公开文章使用诸如事件、泄露、访问、受影响、恢复、安全或修复等短语时尤为重要。这些词可能准确，但除非它们与日期、系统、人员、受影响受众和剩余例外挂钩，否则仍过于模糊，无法支持决策。
因此，一个更强的记录会将修复里程碑、异常处理、事后测试和受影响受众映射联系起来。它会显示组织何时从怀疑转为确认，何时警告受影响方，何时更改相关控制，以及何时能证明更改已到达受影响环境。它还会保留反证。如果供应商说产品环境未受影响，审查应解释该边界的证据。如果公司说只涉及某些字段，审查应解释该范围是如何确定的。如果公共机构说服务继续，审查仍应问清楚创建了哪些手动变通方案以及事后如何对账。
本文保留了未解决的问题，因为未解决问题是问责记录的一部分，而非需要隐藏的写作缺陷。第二个来源边界是Google Cloud source。结合在一起，这些来源支持一种负责任的审查风格：不是裁决，不是营销保证，也不是公开记录不允许的法证重建，而是读者可负责任地了解的地图。这就是为什么本文不断回到实际控制。问责与全知不同。它是说明哪些证据改变了哪些决策、谁有权更改相关控制以及组织在收集证据时谁承担了成本的责任。
更好的证据应是什么样子
对于 Salesforce, Inc.，一个更强的公开证据设计应保持三个文件对齐。第一个文件是决策日志：谁更改了控制，谁批准了公开声明，谁接受了例外，谁收到了警告。第二个是技术证明文件：时间戳、受影响系统、相关身份、暴露的数据类别、恢复检查以及显示修复是否到达读者实际依赖的环境的测试。第三个是读者文件：关于受影响的人应该做什么、组织已经为他们做了什么、尚无法证明什么以及下次更新何时缩小不确定性的简明说明。
这种设计很重要，因为当这些文件出现分歧时，问责就会衰减。一份技术准确的通知仍可能让客户无法行动。一份谨慎的法律通知仍可能遗漏安全团队需要的操作证据。一份自信的恢复声明仍可能隐藏从未对账的手动变通方案。因此，审查标准应问公开记录是否在同一时间线中连接了控制、证明和后果。对于本文，所需的证明是实际而非形式上的：谁对 OAuth 范围、刷新令牌保管、AppExchange 操作、客户通知、秘密搜寻指导、令牌撤销、连接的应用监控以及授权后委托的 SaaS 权限是否得到治理拥有实际控制权？
读者证据档案
本文使用以下公开来源作为通过受损的 Salesloft Drift OAuth 令牌从 Salesforce 客户实例中窃取数据、连接的应用治理、供应商遏制以及 SaaS 集成问责记录的阅读档案。每个来源都有界限：公司声明证明公司所说或报告的内容，政府和监管机构记录证明官方行动或职责，技术帖子证明在其范围内观察到的机制，法律记录证明程序状态（除非有明确最终裁决），标准文件提供控制基准而非追溯性发现。
- 用于证据档案的公开来源：https://trust.salesloft.com/
- 用于证据档案的公开来源：https://www.ic3.gov/CSA/2025/250912.pdf
本证据档案特意比单一事件通知更宽泛，因为通过受损的 Salesloft Drift OAuth 令牌从 Salesforce 客户实例中窃取数据、连接的应用治理、供应商遏制以及 SaaS 集成问责记录影响了不止一个受众。公开记录必须支持需要实际行动的人、需要修复计划的管理者、需要范围的监管机构以及需要知道哪些主张仍然不确定的读者。
董事会审查问题
审查档案应指出每个决策的实际负责人、决策日期、所使用的证据以及依赖该决策的受众。没有这种结构，同一事件日后可能被重述为技术中断、法律纠纷、客户服务问题或财务问题，而没有稳定基础来判断哪个描述是完整的。
一个有用的问责记录还保留不确定性。它应说明哪些来自公司声明、哪些来自政府或法院记录、哪些来自外部事件响应者、哪些是推断出来的。这种分离保护读者免受虚假精确性的影响，并保护组织免受早期自信作为证明的对待。
重要的控制不是事后英雄式响应，而是在事件仍在进行时展示哪些证据会改变决策的能力。如果客户通知、董事会报告、保险索赔、监管机构更新或公共服务消息在一次日志审查后会有不同，那么这种依赖性应在记录中可见。
对于这个具体案例，董事会审查应问：谁对 OAuth 范围、刷新令牌保管、AppExchange 操作、客户通知、秘密搜寻指导、令牌撤销、连接的应用监控以及授权后委托的 SaaS 权限是否得到治理拥有实际控制权？答案不应仅是叙述。它应包括有日期的证据、指定的责任人、受影响受众、面向客户的承诺以及组织在公开记录创建时仍无法证明的事实列表。