JetBrains TeamCity 让构建服务器成为软件供应链问责层面

摘要

• JetBrains 于 2023 年 9 月披露了 CVE-2023-42793；CISA 和微软随后报告了利用活动，包括威胁行为者使用 TeamCity 服务器作为下游入侵的入口点。
• 核心问责问题是：谁实际控制了 TeamCity 的暴露面、补丁速度、构建服务器身份、密钥存储、构建产物签名、下游客户风险以及入侵后的重建？
• 该案例的实际根源并非单一的标签，如数据泄露、服务中断、漏洞或供应商失败。记录聚焦于身份验证绕过漏洞、暴露于互联网的 CI/CD 服务器、补丁采用情况、构建凭据存储、源代码和构建产物的信任、威胁行为者的利用，以及入侵后证明构建完整性所需的证据。
• 软件团队、供应商、企业客户、开源用户、云账户和安全团队都面临着这样的可能性：受入侵的构建服务器可能成为后续攻击的可信交付路径。
• 该记录支持关于控制责任和证据差距的高可信度问责结论。它不支持假设仍为私密的事实，例如每一条日志条目、每一次客户影响、每一个内部决策或每一次下游损失。

证据记录及其使用方式

本文将公开记录视为分层证据，而非单一的权威叙述。公司通知用于说明 JetBrains, s. r. o. 所称的发现、更改或建议。政府、监管机构、漏洞和安全研究资料用于界定围绕该事件的控制责任。二次报道仅在保留公开声明、时间线或受影响方背景信息且稳定的原始文件中无法获得时才被使用。

该事件实质上关乎控制

JetBrains TeamCity 使构建服务器成为软件供应链问责层面的原因在于，该事件将实际控制置于比标题更明亮的光线下。公开记录始于JetBrains TeamCity CVE-2023-42793 博客，并得到JetBrains 已修复安全问题页面和NVD CVE-2023-42793 条目的加强。这些记录之所以重要，是因为它们区分了一个模糊的安全故事和一系列操作职责：找到受影响的系统，确定哪些数据或信任材料可被访问，通知必须采取行动的人员，并证明旧的风险路径已被关闭。

重要的分析举措是将触发因素与问责分开。触发因素是 2023 年 JetBrains TeamCity CVE-2023-42793 身份验证绕过利用和供应链风险。问责则更为广泛。它包括事件发生前的设计选择、本应检测到异常活动的监控、遏制事件的紧急权限、区分已确认入侵与可能暴露的证据，以及让依赖方能够自行决策的沟通。一个供应商可以准确描述狭隘的技术触发因素，却仍然让客户没有足够的证据来管理自己一方的风险。

因此，对于 JetBrains, s. r. o. 而言，公开问题存在于控制层面：CI/CD 暴露、身份验证绕过、构建密钥、构建产物信任、补丁采用、威胁行为者利用以及重建证据。这些并非公共关系细节。它们是危害扩大或缩小的机制。短暂的入侵可能产生长期的身份风险。一个旧漏洞可能变成当前的连续性故障。供应商账户可能变成客户账户问题。平台支持工单可能携带比生产服务本身更敏感的材料。本文全文使用这一视角。

时间线是证据的一部分

时间线之所以重要，是因为客户只有在了解足够信息后才能采取行动。在本案例中，公开时间线始于上述触发因素，随后经历了遏制、客户指导、后续报告和后期分析。早期阶段考验检测和升级能力。中期阶段考验临时控制是否转化为持久的修复。后期阶段考验组织是否学到了足够的知识来防止类似路径，而不是在关注消退后简单地关闭事件。

一个好的事件时间线应该回答几个问题。异常活动何时开始？防御者何时首次发现？防御者何时理解其重要性？组织何时遏制了该路径？它何时知道哪些客户、记录、服务、凭据或系统可能受到影响？组织外部的人员何时收到足够的信息来保护自己？公开通知很少能回答所有这些，但这些问题仍是正确的问责框架。

内部事件与公开通知之间的时间差并不自动意味着不当行为。事件响应者需要时间来验证事实。过早的通知可能传播不正确的建议。但时间差必须是可解释的。如果客户控制密码、令牌、端点、支持文件、银行账户、管理员或下游用户，延迟也将风险转移给他们。问责标准不是即刻的完美，而是及时的、分阶段的沟通，区分已确认的事实、可能的风险、建议的行动和未解决的未知因素。

数据或信任对象并非偶然

本案例中暴露或受威胁的对象对业务而言并非偶然。记录聚焦于身份验证绕过漏洞、暴露于互联网的 CI/CD 服务器、补丁采用、构建凭据存储、源代码和构建产物的信任、威胁行为者利用以及在入侵后证明构建完整性所需的证据。这意味着事件触及了一个信任对象，该对象是组织存在的管理目的，或者组织曾邀请客户依赖的对象。当该对象是凭据、签名证书、支持附件、客户元数据集、构建服务器、防火墙、虚拟化管理程序或公共服务身份记录时，组织不能将其视为普通的办公系统细节。

信任对象具有特殊的问责特性。它们让其他系统做出决策。代码签名证书告诉端点软件是否合法。支持凭据告诉平台某人是否可以查看客户记录。构建服务器告诉下游用户构建产物来自预期的过程。防火墙或远程访问网关告诉网络哪些会话可以进入。客户元数据记录告诉欺诈者将目标对准谁。危害往往在后来当他人在不同的环境中重用信任对象时才发生。

这就是为什么范围分析需要涵盖功能，而不仅仅是表名或服务器名。如果复制的字段识别了管理员，询问数据库表是否被复制是过于狭隘的。如果公司记录揭示了如何在以后攻击数据面，询问生产数据面是否遭到破坏是过于狭隘的。如果服务保持在线，但凭据、证书或附件在事件后仍可用，询问服务是否保持在线是过于狭隘的。

供应商责任遵循最高杠杆控制

在这个故事中，供应商控制了公开事件开始的环境，但这一陈述还不够。更精确的问题是哪些高杠杆控制位于供应商一侧。在许多事件中，这些控制包括架构、特权访问、服务隔离、证书或密钥处理、日志覆盖、客户数据最小化、安全默认设置、紧急吊销、发布工程以及发布可靠指南的权限。

供应商应根据其使风险路径变得容易还是困难来评判。特权工具是否需要强身份验证和严格角色？敏感支持附件或元数据是否保留了超过必要的时间？生产系统是否与公司系统分离？暴露的服务是否设计为故障关闭？日志是否足够完整以重建访问？组织能否快速吊销信任材料？客户能否验证他们已安装安全版本或已采取正确的遏制措施？

公开记录可能只显示该控制态势的一部分。它可以显示已发布通知、已发布补丁、已要求重置密码、已禁用供应商账户、已更换证书，或者公共机构保持服务运行。它通常不能显示内部访问审查、董事会讨论、取证置信度或每一条客户信息。不应以猜测来填补可见度的不足，而应将其称为证据限制，并转化为对更清晰未来保证的要求。

客户和操作者责任并未消失

客户和操作者也有职责。这不是推卸责任。而是认识到许多技术事件跨越组织边界。客户可能控制端点更新、密码重用、特权账户、防火墙暴露、支持上传、管理员行为、备份隔离、警报审查和用户教育。公共机构可能控制身份证明和公民通知。托管服务提供商可能控制客户从未见过的控制台。

适当的分配取决于能力。如果只有供应商能够识别哪些支持记录被访问，则供应商拥有该证据。如果只有客户可以轮换下游密钥或审查自己的日志，则客户在收到可靠通知后拥有该行动。如果托管提供商运行受影响的工具，则托管提供商应向客户提供行动和证据。问责遵循实际控制，而非品牌知名度。

这很重要，因为反应不足往往隐藏在他方的错误之后。客户可能说供应商导致了问题，因此未能审查自己的暴露。供应商可能说客户错误配置了系统，因此未能改进安全默认设置。托管提供商可能说它已打补丁，并避免解释是否审查了入侵。只有当各方陈述其控制了什么以及如何运用了该控制时，公共利益才能得到满足。

隔离是事件与连锁反应之间的边界

隔离决定了事件是否保持有界。在本案例中，相关的隔离可能在公司 IT 和产品基础设施之间、支持工具和生产数据之间、元数据和客户内容之间、管理面和流量面之间、构建服务和签名密钥之间，或者虚拟化管理程序主机和备份资产之间。确切的边界因主题而异，但问责原则是稳定的。

隔离声明应可测试。仅仅说一个环境与另一个环境分离是不够的。记录应显示哪些身份可以穿越边界、存在哪些网络路径、哪些日志确认不存在或缺失的移动、审查了哪些服务账户、应用了哪些紧急控制。客户不需要每个敏感细节，但他们需要足够的保证来了解供应商端事件是否改变了他们自己的风险。

最有力的公开声明避免两个极端。它们不会通过暗示每个依赖系统都遭到入侵来夸大危害。它们也不会在狭窄技术边界后隐藏而忽视连接的风险。说生产数据面未受影响是有用的。同样必要的是说出哪些元数据、凭据、证书、附件或管理记录受到了影响，因为这些材料后来可用于攻击数据面。

通知必须告知接收者他们能做什么

通知不是一种仪式，而是可操作证据的转移。有用的通知告诉接收者发生了什么、可能涉及哪些数据或信任材料、组织已经做了什么、接收者现在应该做什么、什么仍未知，以及后续更新将在哪里出现。如果通知仅说事件发生了，它可能满足正式的沟通需求，而未满足操作需求。

不同的接收者需要不同的内容。安全管理员需要指标、受影响的账户、重置要求、日志审查窗口和配置指导。消费者需要通俗语言的的身份风险建议、支付和密码指导以及支持联系。公共服务用户需要关于基本服务继续或替代方案的保证。开发者需要构建完整性指导和密钥轮换步骤。高管需要一个暴露、入侵、修复和残余风险的矩阵。

因此，本文将沟通视为一种控制，而非一种礼貌。即使初始入侵被迅速遏制，延迟或模糊的通知也可能增加危害。在每项事实确定之前，分阶段的通知可以减少危害。当范围扩大时，更正的通知可以负责。关键是诚实地标明不确定性，而不是假装第一份公开版本是最终的。

滥用面超出已确认的入侵

已确认的入侵只是第一个风险面。攻击者、犯罪分子和机会主义者可以重用事件信息进行网络钓鱼、欺诈、凭据盗窃、敲诈、假支持电话、软件更新诱饵、发票诈骗、就业瞄准和社交压力。软件团队、供应商、企业客户、开源用户、云账户和安全团队面临这样的可能性：受入侵的构建服务器可能成为后续攻击的可信交付路径。因此，组织不仅必须衡量入侵者做了什么，还必须衡量暴露的信息使其他人随后能够做什么。

当暴露的材料标识了管理员、支持联系、支付关系、特定品牌的客户、提交了身份文件的用户或运行特定技术的组织时，这一点尤其真实。这些记录降低了攻击者的搜索成本。它们使社会工程变得更便宜、更可信。它们还允许犯罪分子个性化时机：在真实事件后发出的假重置通知看起来比普通的网络钓鱼信息更可信。

事件后的滥用预防应包括监控冒充行为、警告客户可能的诱饵、收紧支持验证、撤销过时令牌、轮换暴露的密钥、监控新账户活动，并为一线支持人员提供不会泄露更多信息的脚本。组织还应审查其是否收集或保留的数据超过了支持或服务功能实际所需。

取证必须支持信任决策

取证审查具有特定目的：它支持信任决策。客户能继续使用该软件吗？组织能信任防火墙吗？它能信任构建产物吗？它能信任支持记录吗？它能信任身份提供商、元数据存储、虚拟化管理程序、证书、备份或远程访问会话吗？打补丁、重置或禁用只是答案的一部分。

信任决策需要关于什么被访问了、什么可能被访问了、什么被更改了、存在哪些凭据或密钥、哪些日志是完整的、日志是否可能被更改以及哪些独立信号确认了结论的证据。当证据不完整时，组织应说明并针对高价值资产做出保守决策。即使在最初错误已修复后，受入侵的边界系统或构建服务器可能也需要重建和密钥轮换。

薄弱的取证记录造成了次级问责问题。如果组织无法证明信任对象保持安全，它可能需要承担更广泛补救的成本。这是昂贵的。替代方案是将不确定性转移给缺乏提供者证据的客户、公民或下游用户。成熟的事件管理将私人日志转化为足够的公共保证，以便外部人员理性行动。

经济激励解释了投资不足

跨事件重复的模式并不神秘。预防性控制通常在任何事件发生前就施加了可见成本。隔离降低了便利性。最小特权挫败了支持。证书轮换造成了兼容性风险。构建服务器加固延迟了交付。虚拟化管理程序打补丁需要维护窗口。客户数据最小化可能减少营销或支持细节。备份测试消耗时间。这些成本是即时的；所避免的损害直到它到来之前都是不确定的。

这种激励差距就是问责不能等到法院记录或确认的损失数字的原因。如果每个组织都等到损害得到证明，最便宜的路径总是推迟控制并希望另一方吸收损失。客户可能遭受身份风险、停机、欺诈监控、紧急人员配置、合同中断或公共服务不便，而拥有最佳预防控制的一方将成本外部化。

一个更好的激励模型在事件发生前将控制职责与能够以最低成本降低风险的一方联系起来。供应商应使安全默认设置和完整日志成为常态。客户应维护资产清单、补丁窗口、恢复测试和凭据卫生。托管提供商应提供证据包。监管机构和保险公司应在事件发生前要求这些控制的证明，而不仅仅是事后的叙述。

治理记录应在新闻周期后存续

治理记录在新闻周期消退后应保持有用。该记录应描述触发因素、受影响的资产、受影响的人员、遏制措施、客户建议、证据质量、残余风险、业务影响、补救负责人和后续测试。它还应显示事件后发生了什么变化：访问规则、保留期、供应商监督、日志覆盖、补丁服务级别、密钥轮换、备份隔离或客户通知手册。

如果没有该记录，组织只能暂时学习。员工轮换。紧急例外留存。临时缓解成为永久。同一类事件在不同的产品或供应商关系中重现。长期问责记录让董事会、监管机构、客户或未来的操作者能够在六个月后询问承诺的修复是否依然存在。

对于 JetBrains, s. r. o. 而言，持久的教训不是每一种潜在损害都发生了。而是公开事件暴露了一个将会重现的控制类别。下一个案例可能涉及不同的产品、地理位置、攻击者或数据集。测试将相同：组织能否显示谁控制了风险路径，他们做了什么，以及为什么外部人员应该信任结果？

什么会改变评估

评估会随着更强或更弱的证据而改变。更强的证据将包括独立的取证摘要、完整的客户影响类别、从首次检测到遏制的明确时间线、相关信任材料已被轮换或从未暴露的证明，以及后续测试显示相同路径不再有效。较弱的证据将包括范围扩大而无解释、不清楚的数据类别、缺失的日志、重复的类似事件，或者将客户行动视为可选项的模式，而客户行动是必需的。

它也会随着受影响方的证据而改变。能够证明没有暴露、迅速更新、完整日志和没有可达的信任材料的客户，其评估应不同于有旧版本、暴露的管理面、不完整日志、重用凭据或敏感支持文件的客户。具有安全默认设置和较窄保留期的供应商，其评估应不同于给予广泛内部工具对敏感记录持续访问权的供应商。

这就是为什么一个好的问责文章抵制恐慌和免责。公开记录可以支持控制发现，而无需证明每一次损失。它可以识别证据差距，而无需捏造事实。它可以认识到供应商负责任地处理了事件的一部分，同时仍然询问事件前的设计是否产生了可避免的风险。精确不是软弱；它是使问责可信的原因。

客户应在记忆消退前保留证据

最有用的客户证据通常在通知后的最初几小时内收集。管理员应保留身份验证日志、支持通信、暴露账户列表、防火墙或端点事件、配置导出、密码重置记录、证书或密钥清单以及当时存在的供应商通知截图。这些材料后来解释为什么组织选择了窄范围重置、广范围重置、重建、披露或监控响应。没有它，后来的审查就变成对回忆的争论，而不是控制记录。

保留也很重要，因为供应商通知可能演变。第一份通知可能说调查正在进行。后来的通知可能缩小或扩大受影响的人群。安全公告可能增加野外利用的状态。保存每个版本的客户可以将自己的决策映射到当时可用的资料。这防止了不公平的事后诸葛亮，同时仍暴露了在可靠通知后行动迟缓的问题。

证据不应仅停留在安全团队内部。法律、采购、隐私、支持、业务连续性、工程和高管团队各需适合其角色的版本。隐私团队需要受影响的字段。工程需要技术指标和系统所有者。采购需要合同职责。支持需要面向客户的语言。高管需要残余风险和所有者姓名。一个事件如果证据正确但困在错误的函数中，就可能失败。

客户行动窗口是可衡量的责任

供应商端事件通常启动客户端的时钟。如果通知告诉客户更新软件、轮换凭据、审查日志、禁用暴露的接口或警告用户，则客户的响应时间就成为问责记录的一部分。供应商控制了通知和受影响的服务。客户控制了本地行动。任何一方都无法单独完成工作。

该行动窗口应以与风险匹配的术语来衡量。一个严重的暴露边缘缺陷可能需要数小时。广泛的元数据暴露可能需要当日网络钓鱼警告和管理员审查。证书更换可能需要更新部署、清理允许列表以及证明旧签名包不再受信任。支持工单暴露可能需要附件审查和用户通知。虚拟化管理程序勒索软件波次可能需要紧急隔离和在常规维护窗口适用之前进行备份验证。

重点不是惩罚每次延误。一些环境是复杂的，公共服务不能随意停止，紧急变更可能破坏基本操作。重点是使延误明确。如果组织延误，它应记录补偿控制、业务理由、所有者、到期时间以及风险没有无限期开放的证据。未记录的延误是临时例外如何成为下一个事件的原因。

修复声明需要持久证据

当修复声明命名了已改变的控制以及证明该改变依然成立的证据时，它更有力。对于身份事件，证据可能包括禁用的服务账户、更短的会话、更强的管理员身份验证、访问审查和抗钓鱼的重置工作流。对于支持事件，证据可能包括更窄的供应商角色、附件保留限制、特权操作日志记录和客户文件净化。对于边缘设备事件，证据可能包括外部验证的管理隔离、固定版本、日志审查、密钥轮换和重建决策。

公众受众不需要每个敏感细节，但需要修复的形态。说安全性得到增强比说删除了哪类访问、最小化了哪类记录、轮换了哪类凭据、重建了哪类设备以及哪项测试验证了结果更弱。具体的修复语言让客户将补救与故障路径进行比较。

持久性是困难的部分。许多修复在事件刚发生后看起来很强，然后衰退。临时防火墙规则回来了。旧的支持权限重新增长。新的日志记录未被审查。备份未经测试。培训只举行一次然后消失。因此，问责记录应包括一个后续验证点。一个无法在常规操作中存续的修复只是风险的暂停，而非关闭。

托管服务提供商位于责任链之内

许多受影响的组织并不直接管理公开通知中讨论的系统。托管提供商可能操作远程支持工具、构建服务器、邮件平台、防火墙、数据库账户、虚拟化管理程序、帮助台工作流或客户通知。该提供商可以迅速降低风险，也可以让客户蒙在鼓里。因此，其证据职责不仅仅是服务礼貌。

托管提供商应准备告诉客户受影响的产品或服务是否存在、是否暴露、何时更新或隔离、日志是否显示可疑活动、密钥是否轮换、备份是否测试、仍存在哪些残余风险。仅陈述问题已被处理，对于必须回应自己的用户、监管机构、保险公司或董事会的客户来说是不够的。

合同应在紧急情况之前明确这一期望。它们应指定紧急通知触发器、证据交付、紧急维护权限、凭据所有权、备份责任以及谁为特殊恢复买单。如果合同将安全证据视为可选项，客户可能在事件期间发现它购买了正常运行时间而非问责。

数据最小化改变冲击半径

最容易保护的暴露记录是根本未保留的记录。这就是为什么在看似技术入侵的事件中数据最小化很重要。存储旧附件的支持工具、保留不必要元数据的账户门户、可以查看广泛身份证据的客户服务提供商，或者汇总管理员联系人的公司系统，都在攻击者到来前增加了入侵的价值。

最小化并不意味着假装业务可以在没有记录的情况下运行。支持团队需要足够的信息来解决客户问题。安全团队需要日志。金融服务需要受监管的记录。公共交通系统需要账户、优惠、退款和支付操作。控制问题是组织能否在事件后证明每个敏感字段、每个保留期、每个供应商权限和每个导出路径的合理性。

更小的记录也改变了通知。如果供应商能够说仅保留并触达了一个狭窄的字段集，客户可以精确行动。如果供应商保留了广泛的附件或丰富的元数据，通知变得更加困难，下游滥用面扩大。因此，最小化不是隐私口号，而是一种弹性控制，因为它减少了被拖入事件的人员和决策数量。

董事会监督应要求控制证据，而非仅要求状态

高管们通常以状态词接收事件更新：已遏制、已补救、无实质影响、调查继续。这些词对于治理风险来说过于宽泛。董事会层面的监督应询问哪项控制失败或受压、哪一方拥有它、什么证据证明遏制、哪些客户或用户仍可能受到伤害、哪些修复是持久的、什么仍然未知。

董事会还应询问事件是否揭示了一种模式。这是先前支持工具暴露、旧的补丁差距、隔离假设、一个供应商监督弱点，还是轮换信任材料的反复失败的重演？一个事件可能是坏运气。重复的控制模式是治理证据。它显示组织是正在学习还是仅仅在响应。

这并不要求董事成为事件响应者。它要求他们要求决策级证据。他们需要暴露计数、行动窗口、客户义务、法律触发因素、业务连续性影响和后续所有者。当董事会只询问故事是否结束时，管理层因安静关闭而得到奖励。当董事会询问什么证据改变了控制环境时，修复变得可见。

该事件应改变未来的采购问题

客户应将此类事件转变为更好的采购问题。他们应询问供应商如何限制支持访问、如何净化客户附件、公司 IT 如何与生产服务分离、签名证书如何受保护、构建系统如何存储密钥、边缘产品如何记录管理活动、旧版本如何退役，以及在安全事件期间客户如何接收紧急证据。

这些问题应在续约前询问，而不仅仅是在危机后。商业团队可能更倾向于简单的功能比较，但事件表明运营保证可能与产品能力同样重要。一个具有广泛支持权限、薄弱日志、缓慢通知和不明恢复职责的廉价平台在出问题时可能变得昂贵。一个更有纪律的供应商即使在没有故障时也能减少隐藏风险。

采购还必须避免仅纸面保证。问卷回答应连接到可测试的证据：审计摘要、保留设置、角色模型、补丁服务级别、客户通知示例、恢复演练以及可获得的独立评估。目标不是要求不可能的透明度，而是购买足够的证据权利，以便在供应商成为其风险面一部分时客户不会无助。

问责教训可复用

可复用的教训是现代基础设施事件很少停留在其开始的系统。一个受入侵的支持提供商可以变成身份问题。一个公司系统事件可以变成客户元数据问题。一个易受攻击的构建服务器可以变成软件供应链问题。一个远程访问产品可以变成证书信任问题。一个防火墙或虚拟化管理程序可以变成业务连续性问题。这些类别重叠，因为客户依赖组合服务，而非孤立的盒子。

这种重叠就是为什么响应计划应围绕控制面编写。谁拥有身份信任？谁拥有签名软件信任？谁拥有支持数据？谁拥有边缘管理？谁拥有备份？谁拥有客户沟通？谁拥有供应商证据？如果在事件前知道这些所有者，组织可以更少混乱地响应。如果在事件期间才找到他们，事件在人们协商权限时扩大。

一个成熟的组织应能够阅读此类未来的任何通知，并立即将其映射到所有者、行动和证据。这就是事件意识和事件准备之间的区别。意识说某件事发生了。准备说谁必须做什么、何时做、用什么证据，以及依赖人员将如何知晓。

公共利益结论

公共利益结论是，JetBrains TeamCity CVE-2023-42793 身份验证绕过利用和供应链风险（2023 年）应被记住为一次控制测试。该事件测试了组织及其客户能否将技术遏制与信任恢复区分开来。它测试了通知是否可操作。它测试了敏感记录或信任对象是否被最小化。它测试了依赖方是否收到了足够的证据来保护自己。

对此类事件的最强回应不是更大的保证，而是更窄的风险路径、更快的遏制路径、更完整的证据路径和更清晰的客户行动路径。这意味着更少的不必要数据、更少的广泛支持权限、更严格的管理边界、业务和服务环境之间更强的隔离、更好的日志记录、经过测试的恢复，以及在信任不确定时更快地吊销凭据或证书。

JetBrains TeamCity 使构建服务器成为软件供应链问责层面，原因在于该组织处于一个许多其他方必须依赖其证据的位置。当这一点成立时，问责遵循实际控制面。拥有最清晰可见性和最佳减少危害能力的一方必须做得比说事件已经结束更多。它必须展示为什么信任关系可以安全地继续。