2023年DevOps的安全预测和趋势

首先，感谢大家参加我们今天的网络研讨会，从2022年最多产的漏洞中吸取教训。我想介绍我们的两位主讲人，nathan Davidi和Shachar Menashe。

沙查尔将首先告诉我们更多关于我们从2022年的漏洞中学到的东西。然后纳提将在此基础上，告诉我们更多关于2023年的想法，以及如何看待安全问题。说到这里，我要把它交给你们了。

谢谢，阿维杰，谢谢大家今天来参加我们的节目。在进入这次聚会的主要话题，2022年备受瞩目的cve以及我们从中学到的东西之前，我想先介绍一下我们为什么要这样做，我们在去年，特别是在2022年，为了帮助社区做了些什么。

正如你在这里看到的，我们在JFrog高度关注供应链管理和安全，当你看到这里从管理到创建、包装、推广、分发、部署和生产的软件流程时，很明显，我不会说攻击面是无止境的，但相对来说是很大的。当你从攻击者的角度来看，从威胁行为者的角度来看，在每一个步骤中可以做什么，即使是以一种天真的方式，你可以看到有很多入口点。有这么多攻击媒介来利用CICD，并以一种稍后将在生产中利用的方式利用软件的旅程。

因此，它从恶意包开始，通过利用0天、已知的cve、秘密、错误配置和其他方式篡改二进制文件。当所有这些过程允许攻击者收集信息时，这些信息最终被用于生产。顺便说一下，就在昨天，我们又发表了一篇关于攻击者通过NuGet包注入恶意代码的新方法的文章，我相信这是研究部门第一次正式发现这种方法，而且这种情况每天都在发生。所以每一种攻击媒介都是一个独立的世界，但关键是，处理所有这些发现变得如此势不可挡。我们有这么多的工具，这么多的方法，这么多不同的阶段，当你扫描这些，当你需要优先考虑它们，并处理它们。

这当然会产生挫败感。有这么多的安全工具，需要时间来整合它们。在好的情况下，它只是缺少盲点，即典型的源代码分析无法覆盖的东西。在其他情况下，由于开发人员和DevOps被如此多的安全问题所淹没，将会有许多事情根本不会被关注。所以最终发生的是安全性不够好，开发速度受到严重影响。有很多挫折，但在一天结束的时候，我们错过了很多重要的东西，因为错误的方法。

但我们也投资了许多错误的事情，这些事情不一定应该得到修复。这正是我们今天要讨论的。Shachar将介绍我们建议如何在现实世界影响的背景下分析cve，并在可能的情况下以自动化的方式进行分析。这当然不是一件显而易见的事情。这是我们最近在Jfrog尝试做的事情的一部分。说到这里，我将交给沙查尔开始概述2022年的调查结果。

是的，非常感谢你，纳提，谢谢大家参加我们的节目。所以就像纳提说的，我们基本上看到的是有很多噪音，很多关注实际上不应该关注的事情。我们想从最近的漏洞中了解，从2022年的漏洞中，我们想了解这些漏洞的共同趋势是什么，最常见的漏洞是否真的很严重，在多少情况下它们真的可以被利用，以及明年的漏洞的趋势是什么?所以基本上首要的研究目标是发现2022年最常见的漏洞是什么。所以在尽可能多的工件中出现的漏洞。

然后，绘制这些漏洞的趋势，并从中得出关键发现。我们将在这里分享这些关键发现，以及一些切实可行的步骤，如何在2023年更好地应对漏洞。还有对2023年的预测，比如哪些组件将最脆弱，哪些组件实际上不那么脆弱?这就是我们写这份报告时的研究目标，2022年最多产的漏洞。

基本上，我们将深入了解这份报告并分享关键发现，稍后还会展示在哪里可以找到更详细的整个报告。总的来说，这份报告和我们的方法的好处是，我们有一个非常好的、独特的数据来源，那就是JFrog Artifactory和JFrog Xray。所以我们不只是随机下载，比如说，开源图像然后检查它们的漏洞。我们所做的是使用Artifactory的匿名使用数据，因为我们的客户，很多是财富100强公司，很多是非常多产的企业公司。所以这种用法，它实际上就像一个小宇宙，展示了企业公司中普遍存在的漏洞。

所以我们可以使用这些独特的数据，我们实际上得到了我们自己独特的漏洞计数。基本上，我们的方法是，再次以匿名的方式分析所有的工件，了解每个工件的cve数量以及我们发现了哪些cve，然后将它们加起来，计算它们，并对前10个进行深入分析。所以我们将其限制在2022年发现的前10个漏洞，因为我们想看到最近的趋势。所以不仅仅是所有的漏洞，基本上是所有行业的漏洞，我们没有把它隔离到一个特定的行业。

好吧。首先，在完整的报告中，我们可以看到十大漏洞是什么，并深入分析每个漏洞。但那是几十页的报告，所以我们今天想做的是回顾一下主要的发现，以及每个发现中最有趣的例子。所以，再一次，这些是分析前10名的主要发现。第一个关键发现让我们非常惊讶。因此，在企业中出现最多的cve实际上并不是非常严重的问题，甚至不是非常常见的组件中的问题。它们实际上是低严重程度的问题，但由于它们的严重程度较低，它们从未得到解决。因为它们永远不会被修复，每一个新版本都会增加漏洞数量，而且它会不断上升，这些漏洞的漏洞数量永远不会减少。

那么这到底是怎么发生的呢?我们会看到一个例子。如你所知，有大型项目的维护者，比如Red Hat, Debian和Ubuntu，他们执行自己的CVE分析，他们不依赖于NVD的分析。很多时候，这些维护者都明白一个特定的CVE与他们的项目无关，所以可能有一个通用的CVE是相关的，例如在Apache上，但它与红帽上的Apache版本无关。在某些情况下，即使它可能是相关的，但他们认为这是一个小问题，他们永远不会解决它。因为它永远不会固定，这些cve和cve的计数永远不会降低。上传的每个新工件，或者扫描的每个新图像仍然会有这个CVE，因为它从未被修复过。

我们发现这些cve的威胁可能是误导的因为很多时候它得到了很高的CVSS评级，但实际上，它的评级影响很低因为这就是它从未被修复的原因。例如，我们可以看看CVE-2022-29458。这是护士的CVE，这是一个很受欢迎的库，所以拒绝服务。你可以从NVD中看到，这似乎是实质性的。它的严重程度很高。这是我们在2022年看到的第二常见的CVE，这意味着我们看到了受CVE影响的最多的软件图像和人工制品。这是第二名。

因此，尽管它的严重性很高，但实际上，CVE是如此之小，即使Debian很容易受到它的攻击，他们也选择不修复它。他们说:“啊，好吧，这是个小问题，我们永远不会解决它。”这造成了很多噪音，因为基本上这是Debian自带的默认组件，默认情况下它是脆弱的，就像一个非常幼稚的安全扫描会告诉你默认情况下它是脆弱的，但实际上它是如此之小，他们决定不修复它，这就是为什么它仍然脆弱，你不能升级到任何固定的版本，因为没有固定的版本，只是停留在那里，制造噪音。我们稍后会看到如何处理这些。例如，如果你只看NVD和CVSS分数，这将是非常误导。

第二个关键发现(与此相关，但值得单独说明一点)是，公众的严重程度评级被极度夸大了，因为它们忽略了漏洞在现实世界中的影响。我们可以从很多方面看到这一点，现在就来看一些。我们知道这一点，因为正如我所说，我们的安全研究团队正在对漏洞进行自己的研究，并了解它们的真正影响。我们来看一些例子。因此，例如，您可能熟悉CVSS影响指标，因此在CVSS评分中，它表示漏洞是否导致机密性丢失。例如，如果是数据泄露漏洞，或者是完整性损失，这意味着如果是拒绝服务，就会导致可用性。如果是拒绝服务，它会导致可用性损失，完整性通常只与是否有远程代码执行有关。

因此，例如，我们的代码执行漏洞将被评为高完整性损失、高机密性损失和高可用性损失。但我们发现，这些指标只是NVD的表面价值，大多数情况下都没有深入研究。例如，如果我们有一个DoS攻击的漏洞，它会使一个重要的守护进程崩溃，所以我们会说，“哦，好吧，这可能需要高可用性，因为这实际上很严重，”这很好，这发生了。但问题是，当存在DoS攻击的漏洞时，它实际上会导致一个分叉进程崩溃，假设我正在打开一个文本编辑器，它是一个完全独立的进程，它是一个客户端进程，有一个漏洞会导致它崩溃。这实际上并没有那么糟糕，因为它会使我自己PC上的客户端崩溃，它甚至不是网络客户端，它是一个分叉进程，所以它不会使任何其他进程崩溃。但这也会得到很高的评价，毫无疑问。

我们在2022年甚至更早的时候都没有看到CVE会因此获得低可用性损失评级。所以这与现实世界的影响有点不协调。第二个例子是，如果存在缓冲区溢出漏洞，它将立即获得每个参数、机密性、完整性和可用性的最高评级。这是非常罕见的，但它可能是一个缓冲区溢出，不写，不允许攻击者覆盖任何有意义的变量。有时是有限的缓冲区溢出，比如一两个字节，攻击者就不能在缓冲区的末尾写入任何变量。因此，它甚至可能不会导致可用性损失，但只要它是缓冲区溢出，它就会在每个这些指标上获得高评级。

因为我们做自己的研究，我们关注这些事情，我们开始绘制出我们自己感知的严重程度和NVD的严重程度。我们看到的是，在前50名cve和2022年的64%中，同样是前50名，我的意思是，最常见的50名，在我们看到的2022年漏洞的所有人工制品中。因此，64%的人得到了较低的严重等级。所以这是超过一半的漏洞被重新降级从严重程度到高或从高到中。很多时候它实际上是更高的中频。这些都在这里，所有这些数据都可以在报告中找到。但重要的是，这只是表明这不是一个非常具体的问题，在所有的cve中，CVSS基本上被高估了。

最近的一个缺乏研究和盲目评分的例子可能是你们大多数安全专业人员都熟悉的。它是一个CVE-2022-23529。它是一个节点，JS包，npm包中的CVE，叫做node-jsonwebtoken。这是一个解析jsonwebtoken的包，它是jsonwebtoken最流行的解析器。所以你可以想象它是非常受欢迎的一个节点包，它在一周内被下载了1200万次，所以它非常受欢迎。该漏洞的CVSS等级为9.8，并被标记为远程代码执行漏洞。这看起来非常非常糟糕，对吧?所以有一个CVE，它几乎有一个完美的CVSS和一个非常流行的组件。所以你可能会想，这是你需要立即解决的问题。所以实际上，我们正在研究这个漏洞，我们认为在现实中，这个问题可能不会影响到任何一个生产系统。

这是我们在推特上发布的内容。我们意识到这个漏洞实际上是利用它的，这是CVSS中没有考虑到的。它要求攻击者控制函数参数，而他们永远无法控制。具体来说，它是函数参数，即攻击者是否可以控制用于验证的密钥。但很明显他们无法控制这个因为如果他们控制了这个，那么验证就没用了所以这不是一个现实的代码。所以这在生产中是永远不会发生的。这得到了如此多的反馈和反对，实际上，CVE在一周后就被撤下了。因此，这实际上是一个罕见的案例，它被删除，但在大多数情况下，它只是保持关键，它永远不会被删除或讨论。情况就是这样，因为这个方案太受欢迎了，所以阻力很大。

因此，到目前为止，我讨论了一些问题，但我确实想讨论一些可操作的项目，这些项目将让您，作为安全专业人员或DevOps工程师，实际上能够抵御这两种现象。这也是我们在报告中更详细地概述的内容，基本上是为了帮助社区。这也是我们使用的方法，所以我们可以保证。

那么如何处理过度膨胀的CVSS。所以其中一种方法，这是我们现在要关注的，但报告有更多，就是寻找其他的严重程度评级。不要只看表面价值的NVD评级，你还可以看其他地方。首先，如果你检查NVD，特别是NVD网站，而不是[听不清00:18:55]或其他一些只写CVSS的网站。所有的外部网站，写[听不清00:19:04]NVD，抱歉，是NVD CVSS，这是NVD给出的分数。

我们通常看到的是原始CNA或CVE编号机构给出的分数，基本上是漏洞的一部分供应商，他们的分数通常更现实，因为他们通常做了研究。所以他们对漏洞有非常透彻的了解。如果你去了NVD, CVE是由外部CNA报告的，你可以看到两个分数，我们说的是基本上你应该更多地依赖CNA的分数，而不是NVD的分数。

另一件事，在这种情况下，可能会有很大的不同。因此，如果你在一个特定的发行版上工作，例如，在Linux中，所以Ubuntu, Red Hat, SUSE等等，最好看看发行版的安全跟踪器所做的分析，然后依靠NVD的严重性的表面价值。例如，这里我们可以看到一个漏洞，它是相同的漏洞，但是NVD给了它很高的评级而Red Hat给了它很低的评级。在这种情况下，这甚至不是因为CVE与红帽无关，它是相关的，只是他们的安全团队明白它的影响力远不如NVD所说的。这也是因为他们有专门的安全团队来分析这些东西。所以他们的cve比NVD少，他们有一个专门的团队，所以我们更信任他们。在我们多年的研究中，我们发现它们比NVD的严重程度更切中要害。

你可以考虑的最后一点，也许这一点不太为人所知，最大的软件项目，开源软件项目通常会维护自己的漏洞数据库，这些漏洞会影响到他们自己的项目。举个例子，我们可以看到cURL，一个非常流行的网络客户端有一个漏洞被评为低，但NVD被评为高，所以这是一个很大的区别。再一次，我们鼓吹要更加信任项目的严重性评分，因为再一次，项目开发人员是修复漏洞的人，他们做了所有的尽职调查，他们做了抨击，他们真的知道那里发生了什么，他们也不害怕给出批评评级。最近有一个开放的SSL，但是项目维护者对它进行了更彻底的研究。

再一次，因为我们想要聚合东西并对社区有所帮助，我们确实建立了一个列表，列出了所有最大的软件项目，这些项目都有自己的严重性评级，你可以在哪里找到严重性评级。我在这里展示，但最容易找到的地方实际上是在安全报告中。所以完整的报告很容易获得，你只需要在Google JFrog安全研究报告2023中写，这将是第一个结果。在那里你可以看到更多可行的方法如何找到哪个CVSS，抱歉，哪个cve你可以关注哪些cve你不应该关注，甚至比我们在这里分享的更多。是的，现在内提会讲一下我们如何用其他方法解决这个问题，这样可以省去很多麻烦。

谢谢沙查尔对调查结果的回顾。正如Shachar提到的，欢迎大家访问我们的research.www.si-fil.com网站或者搜索相关研究。快速重申一下，我们在这里看到两个例子在很多情况下，有非常严重的，据说非常严重的cve当现实世界无法真正被利用时，反之亦然当你有低排名的cve当这些cve可能被利用并且永远不会被修复。这又回到了令人沮丧的地方，产生了大量的工作量，大量的开销。这只在CVE主题下的CVE中。再一次，回到软件供应链流程，我们有很多其他的风险。我们的安全部门和研究部门正在努力做的是持续快速地研究任何新引入的CVE，我们自己也在追踪恶意软件包，了解软件包的配置，并以适当的方式汇总所有这些数据，并通过产品向社区和客户提供这些数据。hth华体会最新官方网站

所以当你再次看到屏幕上的入口点时，每一个安全桶都得到了我们安全研究部门的注意，这样我们就可以正确地提供信息。现在，除此之外，在Jfrog，我们试图做的是通过为屏幕上介绍的每一个步骤引入扫描仪和分析仪，以尽可能广泛的方式覆盖软件供应链安全。这个方法实际上分为三个层次。一是在任何阶段进行分析，二是在任何阶段进行验证，在任何次要阶段确保你已经分析的东西仍然是一样的。还要记录、标记和签名，以确保不被操纵。这整个方法可以通过使用JFrog平台来实现。我们现在不讨论全部细节，但我想介绍它的安全部分。

第一个是基本的安全包，实际上可以很容易地使用或测试或演示通过访问我们的网站，我们称之为x射线。今天的Xray是一个增强的软件组合分析解决方案，可以相对容易地识别cve、恶意包、操作风险问题，当然还有与许可证相关的遵从性问题，无论是源代码还是二进制文件。我们两者都在做，我们鼓励大家两者都做，因为源代码不是二进制的。二进制文件包含的东西远不止源代码，比如配置，甚至没有以常规方式安装在工件中的包。你错过它们是因为你不看元数据，抱歉，因为你只看它们的元数据。我们所做的就是同时提供查看源代码和二进制文件的方法。特别是对于基本包中的cve，我们以一种非常简单的方式提供了Shachar刚刚分享的所有内容，一种简单的消费方式。

所以当你看CVE时，我们总是提供相同的结构，当然是标题和CVE编号，说明它是什么，给出常规CVSS分数，然后是JFrog安全评分，然后是它背后的所有原因，为什么我们认为它是可利用的或不可利用的，为了成功利用CVE需要满足的先决条件是什么?更重要的是，如何减轻它，如何处理它?不是以常规的方式升级你的包或打补丁，但在某些情况下使用这个功能而不是其他功能或改变这个特定的配置并呈现CVE[听不清00:27:31]实际上。这个结构是通过x射线为所有高规格cve提供的，这是我们基本包的一部分。

在高级包中，我们实际上采用了Shachar刚刚介绍的理解现实世界影响的方法，并运行我们称之为适用性扫描器的方法。适用性扫描器获取CVE并检查环境条件是否满足允许利用的条件。因此，如果包中存在允许或不允许利用的特定配置，那么适用性扫描器将自动识别它。例如，如果您有一个包含第一方代码和第三方包配置的容器，那么分析器将一起扫描所有内容，包括第一方、第三方和配置，以便理解上下文。所以它会告诉你配置是否允许利用，它们会告诉你第一方代码是否以允许利用CVE的方式调用易受攻击库中的实际易受攻击函数。

当然，这是一种独特的方法，可以以一种完整的方式实现，如果你同时做二进制和源代码分析，尤其是二进制分析，因为再一次，工件必然包含源代码中遗漏的东西，配置不会在源代码中引入。第一方代码和第三方代码之间的互连不一定以软件的开放源代码形式引入，因此必须扫描二进制文件。因此，适用性扫描器，我们称之为上下文分析器，现在可以通过高级软件包获得，并且可以在特定的现实环境中测试您的cve。这当然会尽可能接近生产形式。除此之外，我们还会在其他幻灯片中介绍的源代码和供应安全性的许多其他方面做同样的工作，将允许检测二进制文件中的秘密，这些秘密通常是在二进制文件中介绍的，而不是在源代码中因为这是一种错误的方法，将其嵌入到源代码中。

将识别库和服务的错误配置和误用，还将允许分析您的Terraform和其他基础设施代码工件，以了解它们是否实际上允许恶意行为者轻松利用或利用。再一次，x射线增强软件组成分析和高级包是关于更多的扫描仪和适用性扫描仪，特别是允许最后，采取研究方法，沙查介绍了如何知道CVE是如何适用于你的，并在一个完全自动化的方式。

在这种情况下，您可以看到最近的sudo漏洞允许访问不应该访问的数据，您可以看到，利用CVE的先决条件是，当sudoedit文件引入非常特定的配置时，这种情况相对较少。事实上，这是非常罕见的，罕见到我们甚至没有发现在生产中这样使用的情况。只有这样，它才会被利用。因此，正如您所看到的，希望在这里的监视器中，扫描器检查sudoers文件是否具有易受攻击的指令sudoedit，并且它是自动完成的。如果它被发现了，它就会出现在这里，再一次，在上下文分析的结果中告诉你这个特定的CVE是否适用。说到这里，我们就讲到这里，给观众几分钟的提问时间。沙查，你来接第一批吧?

是的。让我看看。是的。好，第一个问题是，“你认为cve高估CVSS分数的比例是多少?”好问题，这是我们研究过的。我们研究了docker Hub中排名前10的docker容器，扫描了它们，看看得分降低的cve的百分比是多少。在这个例子中，正如我所展示的，大约是70%。所以在这项研究中，我们表明，当看到来自Artifactory的真实世界的使用统计数据时，就像我说的，64，而来自Docker Hub的基本是70%左右，非常高。

第二个问题是，“你的情境分析方法和其他人的可达性概念有什么不同?”好的，是的，其他一些产品有类似于我们所说的上下文分析hth华体会最新官方网站的功能。例如，将其称为可达性或有效漏洞。我们的主要区别，我认为有两个。第一个也是最大的一个就是纳提所说的对二元的关注。所以基本上我们不只是检查是否调用了易受攻击的函数因为有一些不相关的漏洞。我们还检查扫描映像的配置、映像中的配置文件以及漏洞运行的环境。例如，是Windows还是Linux与源代码无关?然后我们可以为更多的漏洞编写扫描器因为有些漏洞你永远不会得到答案，不管它是否可以从源代码分析中被利用。当然，我们也做源代码，因为你必须这样做。

我认为第二部分是我们有很好的覆盖面。我们有一个专门的团队来编写这些扫描程序，有些甚至是自动完成的。所以我们确实在覆盖范围上投入了很多努力，例如，在几个基准测试上，如操作系统基准测试，如[听不清00:34:21]，我们对该图像中所有关键cve的覆盖率超过90%。基本上，我们努力使每张图像的关键cve的覆盖率始终超过75%。

“你认为2023年新的cve会增加吗?”实际上我们在报告中提到了这个，但在一些组件中。有一些组件，例如SnakeYAML，它是Java中非常流行的YAML库，它刚刚为它编写了父组件，父组件并没有运行那么久。所以我相信会有很多新的cve出现。总的来说，软件更多了。所以我认为全球范围内会有轻微的增长，但我会关注具体的组成部分。所以我会参考这份报告，看看我们在2022年看到的最受欢迎的组件，以及哪些组件的脆弱性会上升，哪些会下降。

好吧。下一个问题是，“您是否在Jfrog Xray或Jfrog Artifactory中进行恶意包检测?”所以实际上恶意包检测是作为Xray的一部分提供的。他们，再次重申，它的工作方式是我们的研究部门正在不断开发，扫描器可以针对任何新引入的软件包运行。当然，我们是通过抓取公共存储库来实现的。我们首先对成千上万的软件包进行回顾性分析，我们发现了许多潜在的恶意软件包，我们当然会将其公开给社区，我们会继续追踪每一个新的软件包。因此，我们一直在做的是建立我们声称是当今最大的恶意软件包数据库。我们有超过16.5万个不应该使用的包装。这一信息还在不断增强。除此之外，我们还提供补救措施，这是处理已识别的恶意软件包的最简单的补救措施。

“你的解决方案适用于云、多云、本地部署和混合部署吗?”答案是我们讨论过的所有扫描器，同样，它们模仿了Shachar介绍的方法，在所有的云上都可用，包括本地、混合、SaaS。再次，我欢迎你们访问我们的网站看看你们如何启动演示，抱歉，是演示过程或测试过程。

“你认为软件供应链中最脆弱的部分是什么，是否……”嗯，这是一个大问题，沙查尔是一名安全专家。我把它交给你。

好吧。我也想知道你的答案，但对我来说很简单，我想。我认为，目前最脆弱的部分实际上是恶意软件包，而不是CVE。这取决于，如果你正在使用npm和PyPI，那么我认为这是获得新包时最脆弱的部分。原因是，即使你有一个很好的安全管道，很明显，一个完美的管道，你可以逃避它，但即使有一个很好的安全管道，你仍然可能被击中，没有任何开发者错误。

恶意软件包的问题在于，它不像漏洞那样等待被利用。一旦你安装了这个包，它就会被立即利用，并且没有任何缓解措施。它不像堆栈溢出那样有缓解措施。问题是，有一些攻击，比如typposquating，开发者需要自己犯错误，这没那么严重。但是像依赖混淆和包劫持这样的攻击仍然在发生，比如我们最近看到的PyTorch包劫持。只是，即使你做得很好，你仍然会被它击中，甚至没有人为错误。

单个攻击者可以利用这种攻击在几天内利用成千上万的用户。所以它非常普遍。它可以立即被利用，有时甚至不依赖于人为错误。这就是为什么我认为这是现在最可怕的部分。但如果你不使用PyPI, npm和NuGet，情况就没那么严重了。

是啊，我也想说同样的话，我发誓。是的，到目前为止，恶意软件包还没有得到足够的关注。我们确实看到许多玩家正在努力解决这个问题。我认为最痛苦的事情是从操作的角度来看，很难以可扩展的方式做到这一点，很难真正地承受你允许进入一个大型组织的每一个包，很难以一种自动化的方式管理这些包。这正是我们最近试图解决的问题，我们将很快围绕它引入更多的新功能。

就这样，我想结束这次会议。再次感谢你们今天的到来。我想再次强调，我们的大部分工作都是为社区服务的，而不是为了商业化，也不是为了销售我们的产品。hth华体会最新官方网站我欢迎你们联系我们，向我们咨询，要求我们涵盖你们认为的新事物或新方法或新方法和技术，你们希望我们涵盖，以帮助社区。很明显，我们会让所有这些功能始终通过这个平台可用。非常感谢大家的出席。祝你过得愉快。

谢谢你！