Atlassian Confluence 与补丁时间不对称：修复发布后谁承担风险？

摘要

• CVE-2022-26134 是自托管 Confluence Server 和 Confluence Data Center 中的一个严重的对象图导航语言（OGNL）注入漏洞。它允许未经认证的远程攻击者执行任意代码。Atlassian Cloud 不受影响。Volexity 在调查了美国阵亡将士纪念日周末期间的利用情况后，于 2022 年 5 月 31 日向 Atlassian 报告了该零日漏洞。Atlassian 于 6 月 2 日发布了其公告，并于 6 月 3 日列出了修复版本。
• 供应商的快速响应并未结束客户的风险暴露。CISA 于 6 月 2 日将该漏洞添加到其已知利用漏洞目录中，并要求美国联邦民事机构立即阻止互联网流量，并在 6 月 6 日前更新或移除受影响产品。互联网测量和应急响应报告随后显示了广泛的扫描、多种载荷类型、勒索软件尝试、加密货币挖矿、僵尸网络活动、内存植入和 Web Shell。
• 运营负担是不对称的。Atlassian 可以集中生产修复后的软件，但每个客户都必须识别所有实例和节点、确认版本、限制访问、备份数据、测试变更、接受紧急停机、应用修复或临时缓解措施、验证并恢复服务。Atlassian 针对特定事件的公告警告称，集群客户无法以滚动升级的方式安装修复版本。因此，小型组织和单节点部署直接面临协作中断与持续暴露之间的选择。
• 打补丁是必要的，但还不够。Volexity 观察到仅存在于内存中的植入、基于磁盘的 Web Shell、数据库访问以及试图修改日志的行为。Atlassian 的常见问题解答称，公司无法确定客户实例是否已遭入侵，并建议进行本地取证调查。成功的版本升级可以关闭漏洞，但可能留下被盗信息、凭证、持久化或销毁的证据未解决。
• 问责应遵循控制能力。Atlassian 控制着安全产品开发、漏洞调查、反向移植修复、发布质量、通知以及产品特定的检测指导。客户控制着资产清单、公开暴露、操作权限、网络边界、日志记录、备份、变更执行、事件响应和连续性。记录支持对 Atlassian 从披露到修复的快速响应给予肯定，但并未包含足够详细的公开根因审查，以评估为何这样一个广泛影响的缺陷会较早遗漏。它也没有确定有多少暴露的系统被成功入侵。
• 持久的教训是衡量达到可信服务的时间，而不仅仅是打补丁的时间。对于一个被积极利用的知识平台，收尾工作需要证明每个实例都已修复或隔离，暴露期已得到调查，凭证和连接系统已处理，连续性程序已起作用，并且恢复后的平台有一个负责任的企业所有者。

一个漏洞，四个时钟

传统的漏洞时间线有两个端点：披露和补丁。这对于衡量供应商的响应很有用，但它将客户的工作压缩成一个虚构的瞬间。CVE-2022-26134 让缺失的时间显露出来。

第一个是供应商时钟。它始于 Atlassian 收到足够信息以重现和评估该缺陷。Volexity 表示于 5 月 31 日联系了 Atlassian。Atlassian 的安全公告记录了太平洋时间 6 月 2 日下午 1 点发布，以及 6 月 3 日上午 10 点更新添加了七个修复版本。根据公开证据，Atlassian 确认了一个被积极利用的严重漏洞，分配了 CVE，传达了风险，跨受支持分支准备了反向移植，并迅速发布了修复。

第二个是遏制与变更时钟。它从每个客户开始。警告必须传达给有权采取行动的人。此人需要一份 Confluence 部署、节点、版本、外部路由、所有者、依赖关系和支持状态的清单。然后，每个受影响的实例必须断开连接、限制访问、升级、缓解或移除。时钟不会因为修复包可用而停止；只有在客户能够证明没有任何易受攻击的实例仍然可访问时，时钟才会停止。

第三个是取证时钟。主动利用发生在公开披露之前。因此，客户必须问攻击者是否在修复之前就已经到达了他们。该调查依赖于保留的 Web、操作系统、端点、身份、网络和应用程序证据。它可能扩展到内存获取、文件系统比较、凭证审查以及连接系统的检查。补丁改变了未来的可利用性。它无法重写安装前的那段时间。

第四个是连续性时钟。Confluence 通常保存操作程序、项目记录、内部知识、事件运行手册和决策历史。限制或关闭它可能会影响工作，即使没有数据被破坏。恢复需要的不仅仅是重新启动服务：用户需要确信平台可用、完整且安全。如果 Wiki 包含了恢复 Wiki 所需的说明，安全响应可能会暴露一个循环依赖。

这些时钟分配了不同的责任。供应商可以为所有人缩短到可操作修复的时间。它无法清点客户的影子实例、安排其维护、保留其日志或决定哪个业务流程可以承受中断。客户可以隔离和加固其部署。它无法检查供应商的私有开发记录，或以相同的速度独立创建受支持的补丁。当根据各方能够控制的时钟进行评估时，问责制就变得更加清晰。

利用与紧急补丁时间线

该序列记录得异常详尽，但证据有限。Volexity 的报告描述了两台客户服务器及其直接事件响应。Atlassian 的公告记录了产品范围和更新时间。CISA 的目录记录了联邦修复截止日期。互联网遥测描述了扫描或可能暴露的系统，而非经过验证的全球受害者数量。

NVD 条目给该问题评定了 CVSS 3.1 基础分数 9.8，并确定了从 1.3.0 之后到每个修复分支的受影响范围。它还复述了 CISA 目录的措施和日期。这些版本范围的广度表明许多发布线都需要修正。它本身并不能确定该缺陷何时引入、何时首次变得实际可利用、何时有人首次发现它，或者 Atlassian 是否事先知情。

这种区别对于公平的问责制很重要。一个较长的受影响版本范围可能表明修复负担重和产品谱系深。但这并不是故意隐瞒或特定安全开发失败的证据。这些判断需要公共记录未提供的证据。

CVE-2022-26134 允许了什么

Atlassian 将 CVE-2022-26134 描述为一个 OGNL 注入漏洞，允许未经认证的用户在 Confluence Server 或 Data Center 实例上执行任意代码。实际上，HTTP 请求中由攻击者控制的输入可以被计算为一个表达式，并用于在 Confluence 进程的安全上下文中执行命令。不需要有效的用户账户、窃取的会话或员工的交互。

因此，严重性部分取决于部署。互联网可访问性使实例可被广泛扫描发现。运行账户决定了命令可以在主机上做什么。网络访问和存储的凭证塑造了横向移动。Confluence 及其数据库中的信息决定了机密性影响。监控和日志留存决定了利用是否可以在后来被证明。

Volexity 的事件响应分析说明了这一链条。其响应人员发现受感染的 Confluence 进程以 root 权限运行，这赋予了命令完整的主机特权。他们发现了一个内存中的 BEHINDER 植入、一个 China Chopper Web Shell、另一个上传 Shell、侦察活动、对本地 Confluence 数据库表的访问，以及试图修改 Web 日志。Volexity 明确建议不要以 root 权限运行 Confluence。产品漏洞提供了入口；客户端的权限和架构可能会放大入口的含义。

内存中的组件对于收尾证据尤为重要。仅搜索新创建文件的响应人员可能会错过驻留在内存中的植入。重新启动服务可能会移除该组件，但不会移除写入磁盘的第二个 Web Shell、反向数据泄露，或证明凭证仍然保密。Volexity 还指出，用于与植入交互的请求在孤立状态下可能类似于合法流量。检测需要上下文和一系列证据，而不是单一的通用特征。

独立观察表明漏洞利用人群多样化的速度有多快。GreyNoise观察到了用于侦察、反向 shell、僵尸网络、加密货币挖矿、管理员用户创建尝试、破坏性命令和混淆的载荷。Cisco Talos报告了持续的利用并发布了网络检测覆盖。Sophos观察到了自动化的后续载荷和勒索软件尝试。Unit 42在其客户遥测中报告了与 Cerber 勒索软件尝试相关的成功利用。

这些观察不应被合并为一个通用的攻击。Volexity 最初的行为者、一个自动化的加密货币矿工操作者、一个僵尸网络分发者和一个勒索软件操作者有不同的目标。一个没有发现任何 Volexity 列出 IP 地址的组织可能仍然被其他人攻击了。阻止已知源地址作为临时摩擦措施是有用的，但不能替代修复或调查。

Atlassian 的响应很快，但产品记录不完整

从 Volexity 报告的 5 月 31 日通知算起，Atlassian 大约在两天内发布了公告，并在第二天发布了修复版本。该公告保留了更新历史，指明了受影响的产品，将 Cloud 与自托管部署区分开来，列出了修复版本，提供了临时文件替换步骤，警告了滚动升级限制，并引导客户使用最新的长期支持版本。这些是紧急响应中的实质性优势。

速度很重要，因为供应商分析的每一小时都是在客户缺乏受支持修复的情况下度过的。发布七个版本不仅仅是更改一行源代码。供应商必须识别缺陷、测试修复、确定受影响的分支、构建并签名工件、准备发布信息、协调支持，并避免造成第二次中断或漏洞。公共记录支持 Atlassian 将其视为紧急情况的结论。

Atlassian 还发布了一个专门的CVE-2022-26134 常见问题解答。它澄清了 Cloud 不易受攻击，SSO 不能保护自托管实例，因为利用是未经认证的，非面向互联网的系统也应该升级，并且只有修复版本才能确保保护。它建议客户将文件系统工件与备份进行比较，并让本地安全团队或取证专家参与。该指导正确地将漏洞修复与入侵评估分开了。

通知取决于渠道。常见问题解答称，Atlassian 向相关的产品警报邮件列表发送了严重公告。该公司当前的安全公告发布政策同样描述了公开发布和邮件列表通知。邮件列表可以大规模分发信息，但不能保证当前的运营商接收、确认并根据消息采取行动。客户记录可能保留了采购者或前任管理员。托管服务的责任可能不明确。公告是客户治理的输入，而非修复已发生的证据。

然而，关于预防的公开细节较少。Atlassian 的2022 财年安全事件报告将协调 CVE-2022-26134 响应归类为一级事件，并注意到面向互联网实例上的主动利用。公告和公开问题描述了漏洞和修复。它们没有提供相关代码路径的完整根因分析，解释为什么现有的开发或测试控制没有发现它，确定之后做出的控制变更，或发布这些变更的独立验证。

这种缺失并不证明没有进行内部审查。这意味着外部利益相关者无法以与补丁响应相同的精度评估预防性控制响应。一份有力的事后记录应该至少分开五个问题：什么代码行为创造了注入路径；它何时进入了维护分支；哪些审查或测试应该发现它；它们为什么没有发现；以及现在有什么可衡量的变更来测试类似的表达式语言路径。没有这样的说明，公众可以比产品学习深度更自信地评估响应速度。

因此，负责任的发现是混合的。Atlassian 值得基于证据的称赞：快速分流、透明的公告更新、广泛的受支持修复和明确的客户指导。公共记录不足以判断底层安全开发控制是否合理、不足或事后得到了实质性改进。发现后的速度是重要的问责证据；但它不能替代对预防的解释。

发布的补丁不等于已修复的客户资产

软件供应商通常报告修复已发布。客户通常在安装成功时将工单关闭。这两个事件都不能证明风险已在组织中结束。

首先，客户必须找出分母。这包括生产、灾备、预发、测试、开发、迁移、培训、收购公司、承包商管理和临时停止的实例。它包括每个 Data Center 节点和每个反向代理路由。DIVD 案例记录很有启发性，因为通知在公告和补丁之后仍在继续。外部研究人员仍然能够识别出其所有者尚未修复或甚至不知道已暴露的易受攻击系统。

其次，客户必须确定版本和支持状态。Atlassian 的受影响范围跨越受支持的和旧的版本。Unit 42 在 6 月 3 日估计有 1,251 个面向互联网的生命周期结束服务器，这代表了一个独特的治理问题。不受支持的产品可能没有直接、低风险的升级路径。其操作系统、Java 运行时、数据库、应用或自定义主题也可能很旧。看似一个补丁可能变成多组件迁移。

第三，安装必须覆盖每个相关组件。临时缓解措施要求客户停止 Confluence，替换特定的 JAR 或 class 文件，保持正确的所有权和权限，重新启动服务，并在所有集群节点上重复该过程。留在安装目录中的复制旧 JAR 可能会破坏预期的更改。因此，操作证据必须包括工件身份和节点覆盖，而不仅仅是管理员声称已尝试了变通方法。

第四，必须重新评估连通性。一个被认为是内部的服务器可能仍然可以通过 VPN、合作伙伴路由、远程访问网关、应用链接、云负载均衡器、遗忘的 DNS 记录或临时的故障排除规则可达。Atlassian 的常见问题解答谨慎地说，缺乏一般的互联网访问阻止了源自一般互联网的攻击，但仍然建议升级，因为访问路径各不相同。“内部”是一个需要检验的假设，而不是永久的资产属性。

第五，修复需要验证。NIST 的企业补丁管理规划指南将该过程定义为包括识别、优先级排序、获取、安装和验证更新。在可能的情况下，验证应独立于变更操作：通过全新的认证清单、包或文件哈希检查、应用健康检查、不会损害生产的漏洞测试，以及网络确认旧路由在验证完成前保持关闭。

关键指标不是已发现实例的打补丁百分比。而是负责任资产中处于非易受攻击、隔离或移除状态的百分比。如果资产清单不完整，一个 100% 的补丁仪表板可能在数学上正确但操作上错误。分母本身需要保障。

补丁可以在不建立信任的情况下阻止入口

Atlassian 的常见问题解答明确指出了核心的取证限制：Atlassian 无法确认个别客户实例是否已被入侵。它建议让本地安全人员或专业公司参与，并警告攻击者可能会修改系统、审计或访问日志。这种分配并非推诿；决定性证据存在于客户环境中。

因此，一个有用的响应分离了两个工作流。修复工作流通过隔离实例、安装修复版本或受支持的缓解措施并验证结果来防止新的利用。事件工作流调查历史暴露窗口并处理任何后果。并行运行它们避免了“取证完美先行于遏制”的危险假设，同时保留了足够证据以便稍后得出结论。

调查窗口不能从 6 月 2 日开始。Volexity 在之前的周末就已经看到了利用，而 Unit 42 发现来自相关基础设施的扫描最早可追溯到 5 月 26 日。谨慎的组织应该从可获得的最早可信证据开始，并在指标、缺失日志或异常行为合理的情况下向后扩展。它不会将全球研究日期视为自身遭受入侵的证据。

证据收集需要适应观察到的技术。相关来源包括反向代理和 Web 访问日志、Confluence 应用程序日志、认证和管理事件、端点遥测、进程创建、可行的内存、文件完整性、计划任务、服务变更、出站 DNS 和网络流量、云流日志、身份提供者事件、数据库访问和特权凭证使用。远程或受保护的日志记录特别有价值，因为拥有命令执行权限的攻击者可以更改本地文件。

CISA 针对中小企业的日志记录指南建议保护日志免受未授权访问或删除，根据策略保留日志，并在技术、通信、法律和连续性方面分配事件角色。CVE-2022-26134 显示了这些为何是相互关联的控制措施。日志留存不仅是安全运营的一项开支；它决定了管理层后来能否区分“未发现证据”和“未保留证据”。

如果发现入侵或无法合理排除，从可信介质重建可能比清理未知主机更安全。可供 Confluence 服务使用、存储在配置中、用于数据库、由管理员持有或在 Wiki 内容中暴露的凭证可能需要轮换。连接的系统可能需要审查。必须检查备份的完整性以及它们是否可能保存了受损状态。数据暴露分析必须考虑实例包含的内容以及服务账户可以访问的内容。

这就是为什么“24 小时内打补丁”和“24 小时内恢复”是不同的声明。前者可以通过软件状态来证明。后者需要关于攻击者活动、数据完整性、身份、连接系统和业务运营的证据。一个组织可以安全离线、易受攻击地在线、已打补丁但不受信任，或者已恢复并受信任。一个负责任的仪表板应保留这些状态，而不是将它们简化为红和绿。

紧急修复也是一次可用性事件

特定事件的 Atlassian 公告称，运行集群的客户无法在不中断服务的情况下升级到修复版本。这一警告打破了“Data Center 架构总是能将关键更新变成无缝滚动更改”的安慰。更安全的软件状态需要中断。

Atlassian 的通用滚动升级文档解释说，零停机资格取决于源版本和目标版本，需要多节点 Data Center 集群，并且在另一个节点离线时，活动节点必须有足够的容量。它建议备份、升级前检查和预生产环境。这些都是良好的实践，但零日漏洞压缩了执行它们的时间。

单节点客户没有第二个 Confluence 节点来承载流量。有些可以在用户面前放置一个静态维护页面或只读导出；其他则没有准备好的替代方案。建立了自动化、演练过升级、测试过备份并记录了依赖关系的组织可以更快、更少不确定性地移动。将维护视为偶尔技术工作的组织不得不在紧急情况下发现过程。

抽象地看，选择并非“安全还是可用性”。持续暴露也威胁到可用性，因为攻击者正在部署破坏性命令、僵尸软件、加密货币矿工和勒索软件。计划停机施加了一个有界且受管理的中断。不受控制的入侵可能造成更长且更不可预测的中断。控制目标是选择一条通往可信服务的最少损害路径，而不是不惜一切代价保持状态页面为绿色。

Atlassian 的升级中心和 Data Center 指南强调了备份、兼容性、配置更改和升级后检查。备份和恢复文档也说明了为什么“进行备份”不是完整的连续性控制。不同的备份方法有不同的目的；备份作业可能失败；恢复可能覆盖当前数据；重新启动可能中断任务。一个有用的恢复计划应测试恢复，而不是统计文件数量。

对于知识平台，连续性设计应包括一个离线的最小操作集：事件联系人、身份和基础设施恢复步骤、网络图、供应商账户详情、决策权限、关键客户程序以及恢复 Confluence 本身的说明。该副本必须受到保护、保持最新，并且在不依赖受影响的身份或应用路径的情况下可访问。不必导出每个页面；但必须保留通过隔离进行运营所需的小集合。

为什么中小企业承担不成比例的连续性负担

在技术上，该漏洞对于运行相同受影响版本的跨国公司和一家小公司是相同的。但吸收响应的能力却不同。

大型企业可能拥有 24 小时安全运营中心、配置数据库、预生产集群、基础设施自动化、签约的事件响应公司、应用所有者以及有权接受停机的高管。它仍然可能失败，但它拥有专业化的能力。较小的组织可能只有一个管理员、一个外包供应商、一个单一的生产节点、有限的日志留存、没有测试环境，以及一个主要在不工作时维护的 Confluence 实例。

这种差异创造了一个响应队列。同一个人可能需要阅读公告、验证真实性、联系管理层、找到服务器、进行备份、测试升级、通知用户、应用补丁、排查应用程序、检查日志、与供应商沟通并恢复访问。虽然每一步单独来看都很合理，但它们的顺序可能超过公开利用窗口。补丁时间不对称在一定程度上是专业知识和协调的不对称。

NCSC 小型企业应对和恢复指南是围绕准备、识别、解决、报告和学习构建的。它在此处的相关性是实践性的：准备将决策移出危机。中小企业可以预先授权针对被积极利用的严重漏洞的互联网隔离，保持供应商联系方式最新，在事件发生前确定取证供应商，维护离线运行手册，并确定谁可以接受临时中断。这些控制都不需要企业规模。

NIST 的补丁实践指南直接承认了结构性冲突：补丁是资源密集的，并且可能降低系统可用性。它将清单、紧急缓解、隔离、测试、跟踪和验证视为同一能力的一部分。对于中小企业而言，这建议一个适度但完整的设计，而非微缩的企业计划。

一套可行的中小企业控制集将包括：

1. 一个负责任的登记簿。记录实例 URL、部署位置、产品和版本、许可证和支持状态、管理员、企业所有者、公共路由、认证依赖关系、数据库、备份方法和供应商联系方式。在服务变更时进行审查。
2. 一个预先批准的紧急阈值。主动利用加上暴露实例上的未经认证的远程代码执行应授权立即限制或关闭，无需等待例行变更会议。
3. 一条经过测试的维护路径。准备好安装介质、配置记录、应用兼容性信息、备份说明和一个简单的验证清单。至少演练一次升级和恢复。
4. 一个替代的知识渠道。维护事件响应和基本服务交付所需的少数文档的受保护离线或独立托管副本。
5. 一份带有时钟的供应商合同。如果托管服务提供商运营该服务，明确定义谁监控公告，谁可以断开连接，响应和通知时间，证据留存，非工作时间覆盖，以及谁为紧急工作付费。
6. 远程证据。将重要日志发送到远离应用程序主机的地方，并保留足够的历史记录以调查披露前的窗口。知道谁可以检索它们。
7. 一个重启决策。指定可以宣布服务可信的人，并定义所需的证据：修复版本、所有节点已覆盖、健康检查通过、暴露已审查、入侵评估已按商定级别完成，并在必要时处理了凭证。

当前的NCSC 漏洞管理指南同样面向中小企业和大型组织。它强调默认更新、主动利用响应、资产识别、不更新决策的高级所有权以及验证。虽然是在 Confluence 事件之后更新的，但它抓住了持久的治理模型：技术团队可以就风险提供建议，但保持暴露的决策是一个业务决策，并且应该如此可见。

中小企业的局限性不应成为全面的借口。一个面向互联网的、不受支持的、以过高权限运行的 Wiki，无论员工人数多少，都是一种可避免的风险。但在分配补救措施时，问责制应该承认能力。供应商可以通过清晰的版本矩阵、机器可读的公告、经过验证的工件哈希、简明的隔离说明、受支持的修补程序、检测包和供应商就绪的通信来减少客户负担。市场和管理服务合作伙伴可以明确应用兼容性和升级所有权。更好的上游设计创造更平等的下游安全。

云依赖，但没有云入侵

CVE-2022-26134 没有影响 Atlassian Cloud。公告和常见问题解答都说托管的 Cloud 实例受到保护，不需要客户采取行动。这一事实必须保持为核心；将该事件描述为通用的“Confluence 入侵”将错误地包含 Atlassian 称未受攻击的服务。

该事件仍然属于云服务依赖分析，原因有二。首先，Atlassian 是一家全球协作平台提供商，其产品涵盖托管和自托管交付方式。组织依赖同一个供应商生态系统、工作流、应用市场、身份链接和知识实践，尽管运营控制不同。其次，Cloud 和自管理之间的选择本身就是一种控制分配。

在 Atlassian Cloud 中，供应商可以集中修补托管资产，客户无需安排产品版本升级。客户放弃了一些基础设施控制，以换取这种运营集中。在 Server 和 Data Center 中，客户控制托管、网络暴露、维护时机、日志记录和许多集成，但也承担执行负担。“共同责任”并非一个固定的百分比；它随服务模型而变化。

Atlassian 当前的Confluence 安全概述称 Data Center 安全是共同承担的，并引导客户查阅安全清单。这在方向上是正确的，但只有当翻译为命名操作和证据时，这句话才有用。供应商修复产品代码。客户应用修复并保护部署。供应商提供准确的入侵指导。客户保留并分析本地证据。供应商不能安全地承诺客户的服务器是干净的；客户不能独立证明供应商的开发控制防止了复发。

迁移到托管服务可以减少紧急补丁执行，但这不是一个通用的答案。监管、驻留、集成、性能、定制或控制要求可能支持自管理。云也带来了集中化和供应商可用性依赖。治理问题不是哪种模型在道德上优越。而是组织是否为其选择的模型配套了相应的责任。

责任应遵循独特的控制与证据

一个问责模型应该避免两种简单的失败。第一种将一切归咎于供应商，因为缺陷在其代码中。第二种将发布后的一切归咎于客户，因为存在补丁。两者都抹去了重要的控制。

这种分配也解释了为什么客户需要供应商提供证据。一份说“立即升级”的公告足以触发行动，但不足以评估产品治理。企业买家和公共机构可以合理要求提供保密的或公开的事后说明、安全开发变更、独立保证以及从已验证报告到受支持修复版本的时间。小型买家单独很少拥有杠杆，因此标准的供应商透明度具有分配价值。

反过来，供应商在开始支持或事件分析时也需要客户提供证据。准确的版本、节点数量、拓扑、日志、时间戳、变更、插件和观察到的指标可以将产品缺陷与部署特定的影响区分开来。一个模糊的“我们打了补丁”的断言不能让任何一方重建风险。

责任可以共享而不被稀释。产品缺陷仍然是 Atlassian 的责任，即使客户以 root 权限运行 Confluence。Root 权限仍然是客户的责任，即使攻击者是通过 Atlassian 代码进入的。缓慢的打补丁不会抹去缺陷；快速的修复不会抹去不安全的暴露。每个控制都可能促成同样的损失，但仍有不同的所有者。

可信服务恢复的证据包

对于董事会和中小企业所有者来说，最有用的输出不是一份庞大的技术报告。而是一个紧凑的证据包，允许持怀疑态度的读者追踪从警报到收尾的决策过程。

包应以范围声明开始。它列举 CVE-2022-26134、受影响的产品家族、使用的权威公告版本、组织首次收到通知的日期以及响应负责人。它列出所有已知的实例和节点，包括非生产和停用的系统，并解释如何根据 DNS、负载均衡器、云账户、许可、外部扫描、配置记录和提供商数据对该清单进行核对。

接下来是遏制记录。对于每个实例，它显示互联网流量是否以及何时被阻止、服务是否被停止、访问是否被限制、是否安装了临时缓解措施、是否部署了修复版本，或者系统是否被移除。它记录谁授权了任何持续运营的期间以及存在哪些补偿控制。例外需要过期时间和升级路径。

变更记录捕获变更前版本、目标版本、备份结果、兼容性检查、维护开始和结束时间、工件来源、每个变更的节点、重新应用的配置、错误、回滚决策以及变更后的健康检查。由于 Atlassian 警告修复版本不符合滚动升级条件，记录还应显示计划的中断以及告知用户的内容。

验证记录应来自独立于操作者记忆的方法。它可以包括当前版本输出、包身份、提供的校验和、经过认证的软件清单、安全的漏洞验证、外部可达性测试，以及确认没有旧节点或镜像返回服务。批准收尾的人应该能够看到分母和结果。

入侵评估说明调查的期间、证据来源、留存缺口、时钟同步、测试的指标和行为、发现以及置信度。它区分“未发现利用证据”与“未被入侵”。如果日志在可能的攻击窗口之后才开始，该限制是一个管理事实，而非要隐藏的脚注。如果发现入侵，包需链接到遏制、凭证轮换、连接的系统审查、通知、重建和恢复决策。

连续性记录识别哪些业务功能失去了访问权限、激活了什么替代方案、基本程序是否仍然可用、实际停机时间、恢复后需要的数据核对，以及企业所有者的验收。仅技术正常运行时间是不够的，如果员工无法访问运营所需的信息。

最后，复发计划分配了带日期的改进项。典型行动包括消除不受支持的版本、将服务置于受控访问之后、确保 Confluence 不以不必要的特权运行、集中日志、延长留存期、测试恢复、维护预生产路径、更新供应商联系方式、明确托管服务提供商职责、创建离线运行手册，并审查所选的托管模型是否仍然符合组织能力。

这个包也是对后见之明偏见的防御。它记录了每个决策点所知道的信息。在 6 月 2 日，客户知道存在主动利用，但尚未列出修复版本。可以不同于 6 月 3 日之后的等待决策来评估立即隔离的决策。良好的记录保留这种差异。

暴露而非隐藏不对称的指标

常见的“平均修补时间”指标从漏洞记录进入工具时开始，到安装报告时结束。它遗漏了本事件中承担最多问责的部分。

一套更好的指标包括：

• 供应商从报告到公告的时间：从已验证的外部报告到可操作的公开警告，要区分到受支持修复的时间。
• 从通知到所有人的时间：从权威发布到技术和企业所有者确认。
• 清单核对时间：从通知到所有实例、节点和路由的可辩护清单。
• 遏制时间：从通知到每个已知暴露实例的隔离或有效缓解。
• 验证修复时间：从通知到独立证明负责任资产已修复、隔离或移除。
• 入侵决策时间：从通知到记录有证据限制的结论。
• 可信恢复时间：从遏制到企业所有者接受一个安全且可用的服务。
• 未计入的资产：外部观察到的或已许可的、但没有映射到所有者和已验证状态的部署。
• 证据覆盖率：存在所需日志和遥测的调查窗口部分。
• 连续性表现：实际中断、回退激活时间和维持的基本功能。

这些指标防止供应商的快速发布掩盖下游负担，也防止客户的成功安装掩盖缺失的证据。它们也有助于采购。一个可以在数小时内可靠升级、提供机器可读警报和良好检测支持的平台，与一个需要临时周末工作的平台相比，强加了不同的生命周期成本。

指标不应被用来惩罚选择安全停机的团队。如果一个性能目标奖励可用性，而未经认证的 RCE 仍然暴露，那就会造成错误的行为。当替代方案是无控制的入侵时，计划隔离是一次控制成功。质量问题是中断是否被预期、授权、沟通并在测试目标内恢复。

记录证明了什么，没证明什么

公共记录支持几个高置信度的发现。CVE-2022-26134 是 Confluence Server 和 Data Center 中一个严重的、未经认证的远程代码执行漏洞。Atlassian Cloud 未受影响。利用发生在公开披露之前。Volexity 于 5 月 31 日通知了 Atlassian。Atlassian 于 6 月 2 日发布了公告，6 月 3 日发布了修复版本。CISA 将该漏洞列入 KEV，截止日期为 6 月 6 日。公开利用迅速扩大。特定事件的修复需要停机而非滚动升级。补丁不能确定客户是否已遭入侵。

其他结论需要克制。记录没有提供一个经过验证的全球易受攻击组织、成功入侵、数据丢失或中断的数量。Unit 42 的 19,707 个数字描述的是可能受影响的面向互联网的服务器，而非确认的受害者。DIVD 的通知描述的是其识别的易受攻击实例，不一定是独特的公司或已被利用的主机。GreyNoise 测量的是其传感器网络看到的请求，而非针对每个 Confluence 服务器的攻击。

记录也没有确定 Atlassian 最早何时可以合理发现该缺陷，为什么它逃脱了发布前的控制，某个特定的更早测试是否确定会发现它，或者完成了哪些内部纠正措施。受影响版本的历史不能替代根因调查。快速的客户修补也不能证明在补丁之前没有数据被访问。

关于 2022 年最常利用漏洞的联合公告确认了该漏洞的持续威胁相关性。它没有确定每个未打补丁的实例都遭到了入侵。对这些限制的精确性并非为了谨慎本身。它使问责制与证据而非标题算术挂钩。

问责发现

Atlassian 对 CVE-2022-26134 的紧急响应在公众可衡量的维度上实质上是强大的：快速确认、及时的警告、主动利用的语言、跨维护分支的修复版本、临时缓解措施、更新日志、Cloud 范围界定和支持指导。最重要的未解决供应商问题处于生命周期的更早期。公共记录没有解释预防性控制的失败，也没有提供足够的证据来评估事后安全开发变革的深度。

客户无法控制隐藏的缺陷，但他们控制着协作服务器是否面向互联网、是否以过高权限运行、是否不受支持、是否有当前所有者、是否产生持久证据，以及是否可以在不丢失基本操作知识的情况下被下线。这些控制决定了供应商的缺陷是成为短暂的管理中断、无法证明的暴露，还是更广泛的入侵。

对于中小企业，该事件既暴露了内部问题，也暴露了市场设计问题。补丁可供每个客户使用，但安全消费它的能力是不平等的。一个负责任的供应商和合作伙伴生态系统应该通过低摩擦升级、可操作的通知、受支持的缓解措施、检测指导和明确的服务提供商职责来缩小这一差距。一个负责任的客户不应购买自托管控制权，却不为其带来的维护和事件工作预留预算。

最终的测试很简单：在补丁发布后，谁能证明接下来发生了什么？Atlassian 能证明它修复了什么以及何时发布了修复。只有每个客户能证明有哪些系统、何时被隔离、攻击者是否已进入、哪些业务功能被中断，以及为什么服务可以安全恢复。风险持续存在于那个证据缺口之中。弥合它就是问责制的真正工作。