摘要
- Confluence 案例揭示了一个结构性问责问题：Atlassian 可以发布公告、缓解措施和修复版本，但每个自管理客户仍需将该通知转化为资产盘点、停机、升级执行、取证审查和信任恢复。
- CVE-2022-26134 是最清晰的共模示例，因为它影响 Confluence Server 和 数据中心，允许未经身份验证的远程代码执行，在公开披露前已被利用，并于 2022 年 6 月 2 日被纳入 CISA 已知被利用漏洞目录，且在修复版本发布后产生了多种利用方式。
- 托管和自管理的责任必须分开。Atlassian 表示其 Cloud 站点未受影响，而运营 Server 或 数据中心 的客户则承担了运行实例的负担：网络暴露、升级规划、备份、日志记录、权限、调查和业务连续性。
- 补丁不等同于关闭。响应者观察到内存植入、Web Shell、修改日志的尝试、勒索软件尝试、加密货币挖矿、僵尸程序载荷和公开的利用流量。修复版本可以阻止一条路径，但可能留下未解决的证据、凭据、持久性和受损的信任。
- 问责测试在于供应商-客户生态系统能否衡量达到可信服务的时间，而不仅仅是公告发布或首次修复包的时间。
共模暴露是一种业务条件
Confluence 通常被引入作为维基或协作工具，但在许多组织中，它成为了运营记忆。它存储着规程、事件记录、架构说明、政策页面、项目决策、客户支持手册、产品计划以及指向其他系统的链接。当具有这一角色的产品包含被积极利用的漏洞时，风险不仅限于软件所有者。它会影响到每一个日常工作依赖于这些空间完整性和可用性的团队。
Atlassian 的Confluence Security Advisory 2022-06-02公开了 CVE-2022-26134 的风险。该公告描述了 Confluence Server 和 Confluence 数据中心 中的一个 OGNL 注入问题，可能允许未经身份验证的远程代码执行。它还声明 Atlassian Cloud 站点不受影响。这种云区别之所以重要，是因为它分配了运营责任。托管服务客户依赖 Atlassian 来运行易受攻击的服务。自管理客户依赖 Atlassian 获得修复，但控制着暴露的实例、变更窗口、备份、网络可达性、权限上下文和利用后调查。
该漏洞并非沉默的理论缺陷。Volexity 的零日利用报告描述了在美国阵亡将士纪念日周末、公开披露前的利用情况，包括 Web Shell、内存中的 BEHINDER 植入物、访问 Confluence 存储的内容以及修改日志的尝试。该报告还指出 Volexity 于 2022 年 5 月 31 日通知了 Atlassian。Atlassian 的公开响应在那份报告后很快展开，但供应商的速度并未消除分散的客户工作负载。
CISA 于 6 月 2 日将 CVE-2022-26134 添加到已知被利用漏洞目录，并规定覆盖的联邦民事机构在 6 月 6 日前完成修复。CISA 在 6 月 3 日单独发布的警报引导各机构和组织关注 Atlassian 的修复版本。联邦截止日期并非普遍的私营部门法律截止日期。但它仍然是关于紧迫性的强烈公开信号，因为它将'重要补丁'转化为'必须立即处理的政府系统积极利用的服务'。
共模问题在于同时经历同一紧急情况的组织数量。Unit 42 的威胁简报估计有 19,707 台可能受影响的互联网可见 Confluence 服务器和 1,251 台生命周期终止服务器。DIVD 的案例记录称，它开始通知约 15,000 个易受攻击实例的运营者。这些数字并非经核实的唯一受害者或成功入侵数量。它们表明，暴露发现本身就是一项庞大的运营任务。
共模依赖测试询问生态系统能否吸收这种同步任务。Atlassian 必须发布精确的范围和修复。客户必须识别每一个实例，尤其是被遗忘或外部暴露的实例。管理服务提供者必须为客户翻译公告。公共机构必须优先采取紧急行动。安全供应商必须发布检测和响应观察。企业所有者必须决定是否关闭员工可能需要执行响应的协作平台。产品缺陷变成了一个协调问题。
补丁时钟和服务时钟不同
补丁时机通常从报告到公告或从公告到修复发布来度量。这对供应商问责有用，但它可能隐藏客户服务时钟。客户时钟从警告到达正确所有者开始，只有当组织能够证明易受攻击的服务已修复或隔离、暴露期已得到调查、且恢复的服务足够值得信赖时才会停止。
Atlassian 的公告更新历史显示了这些时钟为何不同。最初的 6 月 2 日通知警告主动利用。6 月 3 日，Atlassian 更新了缓解信息，然后列出了各受支持发布线的修复版本。它还警告客户无法通过滚动升级达到修复版本。最后一点是一个连续性事实，而非脚注。一个不能通过滚动流程修复的集群产品可能需要更广泛的停机、紧急批准和用户中断。
Atlassian 的一般Confluence Upgrade Hub和无停机升级页面显示，正常的升级工作包括准备、兼容性检查、备份、集群考虑和验证。紧急公告压缩了这些任务。客户必须决定是遵循完整的升级路径、应用临时文件替换，还是隔离实例同时计划更安全的变更。每个选项都带有风险：持续可利用性、运营中断、兼容性故障或不完全缓解。
备份使这个选择复杂化。Atlassian 的备份和恢复文档是一般产品指南，但事件使其目的具体化。准备紧急补救的客户需要确信数据可以在升级失败时恢复。然而，利用后获取的备份可能保留 Web Shell 或受损状态，而恢复到易受攻击版本可能重现问题。备份不是关闭。它是精心选择的恢复路径的一个输入。
美国国家标准与技术研究院在事件前不久发布了SP 800-40 Rev. 4和SP 1800-31。这些指南将补丁视为一个企业流程，包括识别、优先级、测试、安装、验证和异常处理。它们不是 Confluence 特有的发现。它们有用，因为它们描述了'存在补丁'和'风险已控制'之间缺失的工作。
对于 Confluence，验证有几个部分。是否找到了每个实例，包括测试、旧版本、外部暴露或单项目实例？版本是否已修复或访问是否被阻止？缓解措施是否应用到每个节点？服务是否在非必要的主机权限下运行？日志是否在修改或删除前得到保留？关联的凭据是否已轮换？用户是否被告知在服务受限期间避免做什么？恢复的内容是否可信？补丁时钟可以在 Atlassian 发布修正包时停止。服务时钟则停止得更晚，如果客户有证据的话。
这就是为什么共模漏洞可能不成比例地暴露较弱组织的原因。大型企业可能拥有资产工具、变更委员会、保留日志、暂存环境和事件响应团队。小型团队可能只有一名管理员、一个生产实例、没有独立的暂存环境，并且难以承受停机。同一公告落到两者头上。问责应注意到这种不对称，而不假装供应商可以执行每个客户的补救。
可利用性语言承载了运营重量
漏洞公告的措辞不是公关。它决定领导者是否授权停机、管理员是否停止日常工作、公共机构是否触发紧急流程、安全团队是否在重启服务前保存证据。CVE-2022-26134 需要异常清晰的语言，因为互联网可访问的协作平台上的未经身份验证的远程代码执行很容易被低估，直到业务角色被命名。
Atlassian 的公告称所有受支持的 Confluence Server 和 数据中心 版本都受影响，并且该问题正在被积极利用。公共问题记录CONFSERVER-79016将缺陷与 OGNL 模板注入关联。NVD 的CVE-2022-26134 条目后来反映了 CVSS 3.1 基础分数 9.8。分数是粗略的工具，但这里分数匹配了运营现实：不需要账户，可以远程访问服务，主机上的任意代码执行可能随之发生。
Atlassian 的CVE-2022-26134 常见问题增加了几个对问责很重要的点。它说单点登录不会阻止利用，因为漏洞可以在认证前触发。它建议非互联网暴露的实例仍应升级。它还表示 Atlassian 无法确定客户的实例是否已受损，并建议客户本地或与专家一起调查。这一声明令人不安但诚实。供应商并不拥有每个客户的本地日志、内存状态、文件更改和身份活动。
事件响应者提供了该警告背后的实际细节。Volexity 观察到内存中的植入物、基于磁盘的 Web Shell、产品环境中的内容表访问以及修改日志的尝试。GreyNoise 的观察到在野利用的报告描述了大量尝试利用的源地址和广泛的载荷。Cisco Talos 的威胁通告指出公开的概念验证可用和积极利用。Sophos 后来报告勒索软件和其他载荷到达易受攻击的服务器。这些报告没有描述统一的攻击活动。它们展示了单个利用路径如何迅速多样化成许多运营威胁。
CISA 领导的2022 年最常被利用漏洞联合通告后来将 CVE-2022-26134 列为当年最常被利用的漏洞之一。这一追溯状态很重要，因为它显示漏洞在最初一周后并未从防御者的担忧中消失。未修补的系统、从旧镜像恢复的系统或收购后被遗忘的系统可能仍然对攻击者有价值。
因此，精确的可利用性语言应回答四个实际问题。未经身份验证的攻击者能否到达路径？云托管服务是否受影响，还是仅自管理实例？缓解是否需要完全升级、文件替换、网络隔离或关闭？应用修复是否结束调查，还是客户必须假设可能已经发生利用？Atlassian 的公开材料回答了许多这些问题，响应者生态系统填充了后果。弱点不仅仅是公告说了什么。而是每个客户能否足够快地采取行动。
托管与自管理责任必须明确
Confluence 案例是一个共同责任案例，但不是那种每个人都应该做得更好的模糊感觉。责任跟随控制。Atlassian 控制产品开发、公告发布、修复版本发布、产品特定缓解说明、客户支持材料以及云与自管理范围的清晰度。客户控制暴露、实例清单、操作权限、备份、监控、变更执行和利用后调查。
Atlassian 的FY22 安全事件报告将 CVE-2022-26134 响应归类为重大事件，并承认互联网暴露实例的积极利用。这份公司编写的报告很有用，因为它确认了 Atlassian 内部的严重性。它没有提供完整的根本原因审查，解释缺陷为何以前逃脱、安全开发测试后续如何改变、或复发控制如何独立验证。
Atlassian 当前的安全公告发布政策和Confluence 中的公告提醒材料展示了当下通知渠道和产品安全期望的框架。当前政策不应被视为 2022 年 5 月生效的确切政策的证明。但它仍有助于识别生态系统控制：客户需要可靠的公告渠道，供应商需要识别严重性和行动的面向客户语言。
自管理客户承担了更艰巨的运营负担。Confluence Server 或 数据中心 实例可能位于防火墙后、公共互联网上、代理后、托管安排内或旧基础设施上。它可能由中央 IT、业务单元、项目组或承包商拥有。它可能包含当前规程或无人认为关键直到紧急情况发生的过时内容。供应商无法可靠地从外部识别每个此类部署，尤其是在许可、经销商关系、并购和网络变化模糊所有权的情况下。
这并不意味着客户单独承担风险。供应商的公告必须早期、清晰、可操作并持续更新。修复版本必须对受支持分支可用。临时缓解必须精确。当积极利用改变风险时，公开答案必须避免隐藏在一揽子“应用补丁”语言背后。Atlassian 的响应在报告后迅速展开，但公共记录未回答如此广泛影响的未经身份验证的执行路径为何存在，以及事件后产品保证证据如何改变。
对于客户，问责标准应极其务实。一个拥有公共可达性的自管理协作平台应拥有所有者、补丁渠道、维护权限、经过测试的备份、保护在应用主机外的日志、端点或主机监控、网络限制以及不依赖受损平台的紧急通信计划。如果公司无法回答谁拥有实例以及如何在数小时内将其下线，那么它拥有的不仅是漏洞管理问题。它拥有运营记忆依赖问题。
客户关闭需要证据而不仅仅是版本号
安装修复的 Confluence 版本是必要的。但它本身并非健康证明。在补丁前被利用的客户必须回答内容是否被读取或修改、Web Shell 是否残留、凭据是否暴露、日志是否被更改、攻击者创建的用户是否存在、其他主机是否被触及以及恢复的内容是否可以信任。
Volexity 的叙述在这里很重要，因为它观察到内存驻留和基于文件的活动。简单的文件扫描可能错过一类。简单的重启可能移除一类同时丢失易失性证据。版本检查可能显示实例已修复但持久性可能留在他处。Atlassian 的常见问题合理地将对受损的评估交给客户和专家响应者，因为 Atlassian 无法看到每个客户的本地状态。
日志因此是一种控制，而非奢侈品。CISA 关于在企业系统上使用日志的指南是通用的，但它直接针对这类事件。如果日志仅存在于受损主机上、轮换太快或服务本身可篡改它们，则利用后信心变得脆弱。客户可能打了补丁但仍然无法证明发生了什么。缺乏证据因此成为运营成本。
英国国家网络安全中心当前的漏洞管理指南强调所有权、优先级、默认更新、高级接受异常和验证。NCSC 的小企业响应和恢复指南增加了连续性维度：准备、识别、解决、报告和学习。这些不是 Confluence 的发现。它们很有用，因为 Confluence 客户范围从成熟企业到需要简单响应模型的小型组织。
关闭还需要业务判断。Confluence 可能包含响应 Confluence 紧急情况的说明。它可能包含供应商联系列表、架构说明或连续性计划。将其下线可能减慢响应。保持在线可能保留攻击者路径。一个韧性组织将紧急操作手册和联系路径存储在同一可能失效的系统之外。共模依赖不仅仅在于许多组织运行 Confluence。还在于许多组织将其响应记忆存储在其中。
版本号因此只有在附加更广泛的证明时才是证据。哪些实例在范围内？哪些有互联网暴露？哪些已修补、隔离或退役？哪些在修补前得到了调查？哪些凭据已轮换？哪些日志已保留？哪些业务所有者接受了残余风险？哪些用户被告知服务再次值得信赖？没有这些答案，组织已修补了一个产品，但未必恢复了一个可依赖的工作表面。
第二视角的问责问题
先前对这一事件的报道常常集中在补丁时间不对称上，即供应商修复与客户补救之间的差距。第二视角更广泛：共模依赖。一个协作平台可以安静地坐在许多不相关的组织中，同时创建同步暴露。当单个漏洞在各地触发相同紧急情况时，问题变成生态系统能否优先修复而不让每个客户独自重学同一课。
生态系统的第一个要素是供应商证据。Atlassian 不仅应基于公告速度评估，还应基于可利用性清晰度、托管与自管理范围、分支支持、缓解准确性、支持响应能力和利用后保证。公共记录支持在 Volexity 报告后的快速紧急响应。它没有公开建立详细的产品保证修复记录。这一差距不是指控。它是证据边界。
第二个要素是客户清单。客户无法修补他们找不到的东西。Unit 42 的公开暴露估计和 DIVD 的通知工作表明外部方可以看到大量实例。如果外部非营利组织能在所有者行动前找到易受攻击的主机，那么所有者就存在资产所有权问题。平台越成为工作核心，平台所有者越不能含糊不清。
第三个要素是自动化。紧急补救不应取决于每个管理员在完美时刻阅读公告。组织需要自动化漏洞智能、资产映射、可达性评估、配置检查、维护手册以及向业务所有者上报。自动化不能决定每个权衡，但可以减少从公共警告到合格行动的时间。
第四个要素是连续性设计。Confluence 可能是知识服务而非支付系统，但知识损失可能瘫痪恢复。如果团队需要 Confluence 来发现如何隔离 Confluence，依赖就是循环的。一个成熟环境将最小紧急地图、联系人列表和恢复流程保留在主协作系统之外。
第五个要素是剩余未知数的透明化。没有来源确定有多少独特组织通过 CVE-2022-26134 受损。没有公共记录确定每个客户的利用状态。没有公共的 Atlassian 报告完整解释缺陷为何早期逃脱以及如何防止复发。这些未知数应被陈述而非用自信假设填充。
因此共模测试不是“Atlassian 发布补丁了吗？”而是“依赖 Confluence 的组织群体能否将一个供应商公告转化为验证后的修复，在共享攻击面变成共享损害之前？”2022 年的记录显示了部分成功和明显的摩擦。供应商速度重要。客户准备重要。外部响应者重要。下一个问责步骤是使他们的证据连接起来。
依赖证据应在紧急情况前存在
Confluence 最难的一课是依赖关系不能在利用期间首次得到治理。当公告说自管理协作服务易受未经身份验证的远程代码执行攻击时，组织已经失去了安静的规划窗口。正确的所有者、清单、维护窗口、备份状态和紧急权限应在警告到达前存在。否则事件响应始于本应属于常规运营的发现工作。
Confluence 所有者应能回答基本问题而无需启动新的调查。哪些业务过程依赖于该空间？实例是 Server、数据中心 还是 Cloud？是否可从互联网访问？它在哪个发布分支？分支是否受支持？谁能批准停机？哪些插件带来兼容性风险？备份存储在哪里？哪些日志保护在主机外？哪些身份和令牌从该服务存储或链接？如果这些答案不准备就绪，漏洞有两个爆炸半径：缺陷创建的技术爆炸半径和不确定性创建的组织爆炸半径。
Atlassian 的公告正确区分了 Atlassian Cloud 和自管理的 Confluence Server 和 数据中心。这一区别应在每个客户内部触发依赖映射。使用 Cloud 的团队需要理解特定 CVE 不适用于他们的托管站点。运行 Server 或 数据中心 的团队需要立即的所有权和变更行动。在混合组织中，两种情况可能同时存在。公司可能中央使用 Atlassian Cloud，而业务单元、收购公司、实验室或承包商仍运行较旧的自管理实例。当官方架构与实际状态不同时，共模依赖变得难以看到。
生命周期终止的软件尤其重要。Unit 42 对可能受影响的互联网可见系统的估计包括一组生命周期终止版本。生命周期终止状态改变问责，因为补丁路径可能不直接。客户不能再假设常规供应商支持、兼容性测试或受支持分支升级。选择变成紧急隔离、迁移、付费扩展支持（如可用）或接受不受支持的风险。这一选择应在利用前属于业务所有者，而非在午夜属于一名管理员。
外部通知也不应成为主要的资产发现方法。DIVD 的通知工作很有价值，公共利益的扫描可以帮助减少损害。但当外部方发现数千个易受攻击实例时，这一发现揭示了更深层的治理问题：许多运营者已对其暴露的协作层知之不足。一个成熟组织应对外部警告心存感激，同时质疑为什么它一开始就需要这个警告。
依赖证据还包括合同和支持知识。客户可能依赖托管提供商、经销商、管理服务提供者或内部平台团队来运营 Confluence。接收到 Atlassian 公告的人可能不是能打补丁的人。能打补丁的人可能未被授权使服务下线。业务所有者可能不理解为什么维基停机比暴露的执行漏洞更安全。依赖地图应包括这些决策路径。否则公告成了寻找所有者的消息。
NIST 的补丁管理指南在这里很有用，因为它们将补丁视为一种计划能力而非英雄任务。识别、优先级、获取、测试、安装、验证和异常管理都需要危机前的数据。Confluence 紧急情况压缩了这些步骤，但压缩不是消除。在不做鲁莽变更的情况下快速行动的唯一方法是为该服务演练过快速变更的样子。
共模视角也改变了组织对沟通的看法。如果 Confluence 保存着事件响应手册、紧急联系人列表、架构图和供应商支持记录，那么正被限制的同一平台可能移除限制它所需的指令。一个韧性团队将最小响应包保留在协作平台之外：所有者、当前版本、网络路由、备份位置、紧急凭据、关键程序和外部联系人。这个包并不引人注目。它是知识平台与知识陷阱之间的区别。
问责工件是关闭记录
在像 CVE-2022-26134 这样的漏洞之后，最有用的工件是关闭记录。它不是新闻稿，不是修复版本的截图，也不是系统已修补的模糊陈述。它是一个结构化的解释，说明组织如何从公告移动到可信服务。记录应足够具体，使业务所有者、审计师、保险公司或公共部门监督职能能够理解做了什么以及什么仍然不确定。
关闭记录始于范围。它列出每个考虑的 Confluence 实例，包括生产、暂存、开发、已退役但仍可达的系统、收购公司系统、托管安排和不受支持的版本。它说明哪些是 Atlassian Cloud 因此在本次 CVE 产品范围之外，哪些是 Server 或 数据中心。它说明哪些是互联网暴露的，哪些是内部的。它说明每个实例的所有者。范围只有在无主实例成为入侵点时才显得枯燥。
第二部分是行动。对于每个范围内的实例，记录应说明是否已关闭、阻止互联网访问、升级到修复版本、通过 Atlassian 的临时说明缓解、退役或迁移。它应识别时间：何时收到公告、何时访问变更、何时安装修复版本、何时完成验证以及何时允许用户返回。它还应记录为何接受任何例外以及谁接受了它。一旦积极利用公开，高级接受更新例外很重要，因为风险不再是纯粹的技术性。
第三部分是证据保留。如果利用在披露前活跃，组织应假设日志、内存、文件和关联凭据可能重要。关闭记录应说明在重启或升级前保留了哪些证据、哪些日志可用、是否在适当情况下进行了主机镜像或内存捕获以及哪些证据无法恢复。这并不意味着每个小组织都必须进行复杂的取证调查。它意味着组织应了解“我们看了没找到证据”和“我们没有可以查阅的证据”之间的区别。
第四部分是受损评估。Volexity 的报告显示利用可能涉及 Web Shell、内存植入物、内容库访问和日志修改。Sophos、GreyNoise、Talos 和 Unit 42 显示后来的利用可能包括多种载荷家族。因此关闭记录应记录执行的检查：对已知 Web Shell 路径的文件系统审查、进程和持久性检查、应用程序日志、反向 shell 指标、意外用户、出站连接、内容库访问、凭据暴露和端点警报。它还应声明是否使用了专家帮助或为何没有。
第五部分是连接系统审查。Confluence 很少独立存在。它可能与身份提供者、源代码系统、工单平台、CI/CD 工具、聊天、文档存储和结构化内容仓库集成。如果 Confluence 主机受损，这些集成使用的凭据可能需要轮换或审查。忽略连接凭据的狭窄补丁记录可能使攻击者拥有存活于原始漏洞的路径。因此关闭应包括服务账户、API 令牌、内容库密码和管理会话。
第六部分是业务恢复。用户不应仅仅因为服务器进程运行就返回平台。他们需要知道内容是否完整、响应窗口期间的编辑是否得到保留、附件是否可用、搜索是否正常、通知是否可信以及是否有任何页面或空间在审查中受限。如果平台包含运营规程，内容完整性同样重要。
第七部分是学习。关闭记录应识别为何实例暴露、为何在其发布分支上、警报渠道是否到达正确的人、停机批准是否缓慢、备份是否测试过、日志是否充足以及紧急操作手册是否在 Confluence 之外。这是问责从责备转向控制改进的地方。目的不是惩罚打补丁的人。而是使下一个共模公告不那么混乱。
Atlassian 在此类关闭中的角色是提供客户需要的产品特定事实：受影响范围、固定分支、缓解有效性、可利用性说明、云范围、升级约束和利用后警告。客户的角色是将这些事实转化为本地证据。公共机构和外部响应者可以通过优先化、观察和发布检测上下文来提供帮助。这些角色都不能完全取代其他角色。关闭记录是它们证据相遇的地方。
重复的 Confluence 漏洞应改变董事会问题
CVE-2022-26134 并非公共记忆中唯一的严重 Confluence 漏洞。重复紧急 Confluence 补救的更广泛模式应改变董事会问题，从“我们修补了那个 CVE 吗？”变为“为什么这个协作层反复需要紧急行动，以及当它发生时我们如何限定业务后果？”董事会不需要知道每个 OGNL 细节。它需要知道组织是否在结构上准备好应对下一个 Confluence 公告。
这种准备有成本。保持 Confluence 更新可能需要停机、插件审查、用户沟通、测试和偶尔的业务摩擦。限制互联网访问可能需要 VPN、零信任访问或合作伙伴工作流变更。维护受保护的日志和备份需要存储和人员时间。退役不受支持的实例可能需要迁移劳动。这些成本在事件前通常是可见的，而避免的入侵则是不可见的。问责意味着使避免的风险可见，使得领导者不再将维护视为可选择的家务。
锁定维度也很现实。Confluence 空间可以积累多年的制度记忆。迁移很困难，因为页面、权限、附件、链接、宏和集成已嵌入工作。这种粘性可能使紧急升级决策更难。一个脆弱的插件或旧主题可能使组织留在易受攻击的分支上，因为迁移看起来太具破坏性。留在原地的业务便利变成了安全暴露。一个成熟的治理过程命名这一权衡，而不是让它埋在工单积压中。
对于公共部门和受监管的客户，董事会问题应包括连续性。如果 Confluence 托管紧急计划、政策解释、案件记录、基础设施文档或服务规程，那么安全关闭可能影响公共工作。所有者应在安全事件期间知道哪些信息必须在 Confluence 外部可用。这不仅是网络卫生。它是制度记忆的连续性。
共模依赖测试可能重复出现，因为广泛使用的协作平台集中知识。从 Atlassian 2022 年记录中得到的教训不是客户应不信任平台。而是信任应在操作上受到限制。客户应能快速修补、更快隔离、诚实调查，并在平台受疑时保持核心知识可及。供应商应通过精确、及时和技术坦诚的公告使工作更容易。生态系统应通过验证的关闭而非修复版本出现的时刻来衡量成功。
还有一个采购教训。买家经常询问协作产品是否支持认证、备份、支持渠道和高可用性。他们还应询问紧急安全指导如何到达运营者、受支持分支多快收到修复、当修复版本无法通过滚动升级达到时会发生什么、以及客户在重启可疑实例前应保留哪些证据。这些问题不会让买家对供应商的代码负责。它们让买家负责了解当下一个紧急情况到来时，共享工具将如何被治理。
排版说明
接下来应衡量什么
一个有用的事件后记分卡将衡量客户知晓时间、清单确认时间、互联网暴露系统隔离时间、受支持修复版本应用时间、取证信心时间和业务服务恢复时间。这些是不同的时钟。将它们合并为一个补丁指标会使生态系统看起来比实际更可控。
对于 Atlassian，持久的公共证据将包括公告记录、客户支持改进、安全开发变更、变体分析以及产品团队减少未经身份验证表达式评估路径复发可能性的方式。对于客户，持久证据将包括所有者列表、受保护日志、紧急操作手册、经过测试的备份、凭据轮换程序以及在积极利用下将协作系统下线的业务批准。对于公共机构，持久证据将包括适用的约束性优先化以及面向面临相同风险但没有相同权力的非联邦组织的明确指导。
Confluence 事件最终教会我们，协作软件可以成为基础设施。一旦如此，关键漏洞就不再仅仅是产品维护事件。它是对知识、连续性和安全证据分布是否足够好的测试，使得一个缺陷不会让每个依赖的组织同时即兴发挥。