使用机器学习轻量级混合方法检测DOM XSS漏洞 - CDra90n

Towards a Lightweight, Hybrid Approach for Detecting DOM XSS Vulnerabilities with Machine Learning
原文发表于WWW’21：https://users.ece.cmu.edu/~lbauer/papers/2021/www2021-dom-xss-dnn.pdf

摘要

Web 应用程序中的客户端跨站点脚本 (DOM XSS) 漏洞很常见，难以识别且难以预防。污点跟踪是检测 DOM XSS 的最有前途的方法，具有高精度和召回率，但对于许多实际用途来说计算成本太高。

本文研究了机器学习 (ML) 分类器在检测 DOM XSS 漏洞能力时是否可以替代或增强污点跟踪。通过大规模的网络爬虫，本文收集了超过 180 亿个 JavaScript 函数，并使用污点跟踪将超过 180,000 个函数标记为潜在易受攻击的函数。有了这些数据，本研究训练了一个深度神经网络 (DNN) 来分析 JavaScript 函数并预测它是否容易受到 DOM XSS 的攻击（https://kilthub.cmu.edu/articles/dataset/DOM_XSS_Web_Vulnerability_Dataset/13870256 ）。本研究试验了一系列超参数，并提出了一个低延迟、高召回率的分类器，可以作为污点跟踪的预过滤器，将独立污点跟踪的成本降低 3.43 倍，同时检测 94.5% 的独特漏洞。认为 DNN 和污点跟踪的这种组合对于污点跟踪本身并不适用的一系列样本来说足够有效，包括浏览器运行时 DOM XSS 检测和分析大型代码库。

0x01 Introduction

未能正确清理其输入的 Web 应用程序可能容易受到跨站点脚本 (XSS) 漏洞的攻击，这些漏洞正变得越来越普遍。一种特定类型的 XSS 漏洞，客户端 XSS (DOM XSS)是由网站 JavaScript 代码中的错误引起的；它们的流行度随着客户端代码复杂性的增加而上升。近年来，eBay、雅虎、IBM 和 Facebook 等知名组织都报告了 DOM XSS 漏洞 。

DOM XSS 漏洞可以通过使用签名和启发式过滤掉内容来防止，但现代攻击策略可以规避这种防御。其他防御措施使用静态或动态分析检测 DOM XSS 漏洞。原则上，静态分析可以在代码注入漏洞被利用甚至发布之前检测到它们。然而，静态分析工具难以推理 JavaScript的动态特性，具有高错误率，或者可能无法扩展到大型代码库，这使得它们作为 DOM XSS 防御不切实际。

相比之下，动态分析——特别是污点跟踪——已经显示出检测 DOM XSS 漏洞的希望。在动态污点跟踪方法中，分析代码以在执行时检测 DOM XSS 漏洞。这增加了大量开销（页面加载时间增加了 16.8%），表明这种方法不太可能在许多设置中采用，例如作为浏览器内的防御。

利用观察到许多 DOM XSS 漏洞在语法上相似且复杂性较低，本文提出了一种替代方法，该方法使用机器学习 (ML) 来大大减少动态污点跟踪带来的开销，以检测 DOM XSS 漏洞。还研究了用现有分析组合机器学习的可行性。具体来说解决了两个主要的研究问题：

RQ1：ML 是否可以作为污点跟踪的预过滤器来检测 DOM XSS 漏洞，同时保持高召回率，并且开销远低于单独污点跟踪？

RQ2：ML 是否可以单独用于检测 DOM XSS 漏洞，其召回率和精确度可与其他技术相媲美或优于其他技术？

为了训练和评估这些 ML 分类器，首先获得足够数量的真实数据。本文使用启用了开源污点跟踪的 Web 浏览器，分两步收集 DOM XSS 易受攻击的 JavaScript 函数的状态（见下图）。首先使用污点跟踪来识别使用看似未经处理的参数调用危险接收器（例如 document.write）的 JavaScript 函数。污点跟踪本身无法确认这些函数是可利用的，因此将这些函数标记为未确认的漏洞（数据集1）。为了将这组函数修剪为仅可利用的函数，使用启发式方法来执行概念验证利用，并将可利用的函数标记为已确认的漏洞（数据集2）。

本文在未经确认的漏洞上训练的分类器可用作基于污点跟踪的 DOM XSS 检测 (RQ1) 的预过滤器，将 97.5% 的独特函数分类为非脆弱性，同时保持 94.5% 的独特漏洞召回率。在此配置中，污点跟踪仅用于其余 2.5% 的函数，与单独的污点跟踪相比，漏洞检测开销降低了 3.43 倍。

或者，在已确认漏洞上训练的分类器可用作判断 JavaScript 函数是否容易受到 DOM XSS 攻击 (RQ2) 的唯一手段，并以 57.8% 的精度捕获 50% 的已确认漏洞。总的来说还没有找到一种调优，可以提供高召回率和高精度的组合，足以让这种分类器成为检测 DOM XSS 漏洞的唯一方法。

在探索分类器设计空间以回答这些研究问题时，试验了两种模型类型（线性模型和深度神经网络 (DNN)）；源代码的多种表示（基于脚本、函数或语义距离）；各种模型架构（嵌入大小和 DNN 层大小）；并调整训练机制以补偿不平衡的基本事实（即，在野非漏洞函数的数量远远超过漏洞函数）。

0x02 Background

A.DOM XSS 漏洞

跨站点脚本 (XSS) 漏洞在输入被正确清理时发生，允许攻击者将任意 JavaScript 代码注入受害者的浏览器。攻击者可以通过重定向到恶意网站来窃取私人信息或危害受害者的机器。

这项工作关注由客户端对浏览器文档对象模型 (DOM) 的操作导致的客户端漏洞。攻击者可以将漏洞注入到诸如 document.location 对象（URL）、网页引用或 postMessage API 之类的源中。当来自这些攻击者可控来源的信息用于敏感的代码执行函数（称为接收器）时，可能存在 XSS 漏洞。此类接收器的示例包括：DOM 节点的 innerHTML 属性、eval方法或 javascript: URL。

从源到接收器的可利用流并不一定意味着存在漏洞，因为程序员可能会在使用敏感接收器之前对信息进行消毒。常见的清理方法包括内置浏览器 API，例如 encodeURI 和 encodeURIComponent 或手动检查用户输入是否与安全正则表达式（例如字母数字字符）匹配。

在本文工作中，训练了一个基于源代码预测 DOM XSS 漏洞的模型。训练单独的模型来预测未确认的漏洞（由污点分析标记并需要进一步调查）和已确认的漏洞（通过执行概念验证漏洞确认）。

B.内容过滤

浏览器和 Web 服务器试图为 DOM XSS 漏洞利用过滤器。内容安全策略 (CSP) 可以限制网站上允许的脚本，但经常以一种不会实质性限制 DOM XSS 漏洞利用的方式错误配置。已经引入了基于可信类型概念的实验性浏览器 API，但该 API 与遗留应用程序不兼容。 Web 应用程序防火墙过滤器是另一种针对 XSS 漏洞的常见防御措施，但可以通过调整漏洞利用来绕过过滤器检测模式。

客户端过滤器（例如XSS auditor）也被用作防御，但它们也遭受类似的攻击。研究人员检查了一系列已知的 DOM XSS 漏洞能力，并表明在 73% 的情况下，XSS auditor未能过滤攻击。与使用此类启发式相比，本文训练 ML 模型以学习过滤策略并检测 DOM XSS 漏洞。 ML 模型可能会推断出源代码和漏洞之间更深层次的关系，并且攻击者可能更难以绕过。

C.JavaScript的静态分析

静态分析技术可以通过分析源代码来检测感兴趣的属性，从而了解程序可能采用的所有可能的执行路径。JavaScript 静态分析的几种实现可在商业工具中使用，包括 IBM Security AppScan、Trustwave App Scanner、Coverity 的 JavaScript 扫描器和 Burp Suite Pro。然而，静态分析 JavaScript 尤其具有挑战性，因为它是一种动态语言，缺乏严格的类型信息。此外，静态分析对于本研究设置来说过于昂贵，因此不考虑在解决方案中使用静态分析。

D.JavaScript的动态分析

动态分析也常用于 Javascript，但仅对程序执行期间收集的观察进行操作，并没有分析未执行的代码。此外，此类方法会产生运行时开销，并且需要大量工程工作来修改复杂的运行时环境（在示例中为 JavaScript 引擎）。

识别 DOM XSS 漏洞最相关的动态分析是污点跟踪。该技术将来自潜在攻击者控制的来源的数据标记为受污染，并在执行时传播污染信息。当在敏感接收器中使用受污染的字符串时，污点跟踪引擎会将此信息流标记为潜在的 DOM XSS 漏洞；称之为未经证实的漏洞。

污点跟踪：识别 DOM XSS 漏洞最相关的动态分析是污点跟踪。该技术将来自潜在攻击者控制的来源的数据标记为受污染，并在执行时传播污染信息。当在敏感接收器中使用受污染的字符串时，污点跟踪引擎会将此信息流标记为潜在的 DOM XSS 漏洞；称之为未经证实的漏洞。第一个使用污点跟踪来发现 DOM XSS 漏洞的工具是基于 Firefox 的 DOMinator。后来，通过添加字节精确污点跟踪来提高其精度，将污点信息附加到 JavaScript 引擎中的特定字节，减少误报。

虽然污点跟踪可以在运行时有效地防御 DOM XSS 漏洞，但这是以某些基准测试中 7% 到 17% 的开销为代价的 。浏览器供应商对性能开销异常敏感，本文解决方案提供了一个机会，通过使用 ML 在分类器确定代码可能易受攻击时有选择地启用污点跟踪来缓解这种性能下降。

由于受污染的数据可能会被程序员清理，因此此类流可能不一定是可利用的。研究人员使用启发式方法自动生成漏洞来确认这些漏洞。在之前的工作中，研究人员通过分析受污染字符串周围的上下文来生成漏洞利用，使用预先配置的导致漏洞利用的注入列表或符号分析来确认具有测试注入的流。在本文工作中，利用上述解决方案来生成已确认漏洞的标记实例。

E.程序分析中的机器学习

有几个项目使用 ML 来分析 JavaScript 中的程序，成功识别出许多恶意 JavaScript例子。然而，这些解决方案依赖于手工设计的特征（例如流的位置、流中涉及的函数数量、流的源和汇）。本文避免使用此类技术，使解决方案可以推广到不同的上下文并适应不断变化的源代码习语。从数据中进行程序分析的构建块也可以通过训练决策树来学习。相比之下，本文工作选择了深度学习，它可以学习复杂数据的潜在表示。

最密切相关的工作是使用深度学习来分析程序中的信息流，以便在C中更有效地进行污点跟踪或漏洞检测。在这些项目中，ML模型必须识别程序中的关键点以进行分析信息流，依赖于C程序的高度静态性。本文工作关注浏览器中的 DOM XSS 漏洞，主要执行动态 JavaScript 代码。这使得很难自信地确定程序的关键点并提取数据依赖关系，因此上述解决方案不适用于本文设置。

研究人员开发了 code2vec，它通过将起始节点和终止节点与 AST 树的一系列上下运动联系起来，将 AST 转换为用于机器学习的向量。树卷积分析树结构上的 AST 节点信息，其方式类似于卷积神经网络处理其像素上的图像。树卷积基于使用神经网络卷积在靠近它的节点上对每个节点进行分类，并且之前已用于从源代码中检测算法性能错误。

在分析用于程序分析的图形结构数据方面也进行了工作。还探索了一种使用门控图神经网络的方法，该网络最近已被用于对源代码的某些属性进行建模，例如惯用的编码风格。然而通过实验发现这些技术无法准确地模拟 JavaScript 语义。

0x03 Data Collection Methodology

本章描述了收集两个真实数据集以训练和评估 ML 分类器的方法。使用启用污点跟踪的浏览器来收集大规模网络爬行中未经证实的漏洞（数据集1），然后将这些未经证实的漏洞的实例标记为已确认的漏洞（数据集2），最后讨论数据收集的属性和局限性。

A.数据收集

利用先前工作中修改后的启用污点跟踪的 Chromium 浏览器版本来收集一系列网站执行跟踪，识别可能容易受到 DOM XSS 注入攻击的代码。修改后的浏览器由与服务器端数据库交互的扩展程序驱动，通过 HTTP 交互引导爬取活动并存储受污点流的记录。

浏览器的 V8 引擎和 WebKit 基础设施通过污点跟踪进行了修改，以识别潜在的易受攻击的流。在每个网页的 JavaScript 执行期间，修改后的浏览器存储：所有浏览器执行的源代码的记录、该源代码的解析 V8 表示、所有受污染的接收器执行和其他簿记信息。对于带有污染数据的接收器的每次执行，额外记录：污染参数的值、特定的污染字符、是否应用了任何特定的内置编码方法（例如，escape 或 encodeURI），以及完整的跟踪JavaScript 调用堆栈。

总共爬取了 Alexa 前 10,000的网站，并访问了这些网站上的 289,392 个网页。通过访问网站的根网页并在同一域内对 40 个子链接进行采样，总共尝试了 410,000 次网页访问。在爬取过程中，并非所有页面都被加载；遵守了 robots.txt规则，其他网页在爬取过程中没有正确加载。如果单个网页未成功加载，会尽可能尝试加载同一域中的另一个示例网页。在加载网页时，爬虫首先等待页面就绪事件，然后再等待 90 秒以执行页面。凭经验观察到 90 秒足以检测绝大多数污点汇聚点。

由于爬虫是非确定性的，因此汇总了多次执行的结果。使用 GZIP 压缩时，抓取的执行日志文件为 26TB。许多脚本在多次爬取中重复，因此删除了所有重复的源代码，将聚合数据库的压缩大小减少到 382GB。

B.标记和确认流

接下来，检测哪些脚本包含潜在易受攻击的接收器的受污染参数以及这些接收器的位置。如果流在任何执行中被标记为易受攻击，将在聚合中将其标记为易受攻击。为了在源代码中定位对 sink 函数的特定调用，在执行期间输出函数调用的带注释的堆栈跟踪，其中包含所有已执行 JavaScript 的解析 AST。使用最靠近调用堆栈底部的 JavaScript 堆栈帧的 AST 节点作为漏洞的指示。不在堆栈跟踪中使用其他函数，因为没有关于受污点流源位置的信息，也无法标记此类节点。下图显示了如何转换和标记地面实况数据的概述。

为了确定敏感接收器是否应该被标记为未经证实的漏洞，观察应用于受污染数据的编码方法是否与应用污点的上下文相匹配，使用与先前工作类似的逻辑。例如，如果污点跟踪表明document.write函数是使用来自网页 URL 的受污染参数调用的，而没有应用任何编码函数，就会将该流程标记为未经证实的漏洞。但是，如果 encodeURI 函数后来在接收器中使用之前应用于受污染的字节，那么会将函数标记为安全的，因为 encodeURI 函数会清理输入并防止漏洞。根据数据爬取结果，收集了大约 32,000,000 个未经证实的漏洞实例，发生在大约 180,000 个不同的、独特的函数中。

对于剩余的未确认漏洞，通过利用先前工作中的技术生成确认测试注入。结合应用编码函数的知识为每个未确认的漏洞生成概念验证测试注入，并使用测试注入重新执行网页以查看注入是否成功。这一步是必要的，因为开发人员可以在不使用内置编码方法的情况下对流进行临时清理，例如检查受污染的输入是否与数字的正则表达式匹配，这种技术可以消除未经证实的漏洞.在使用概念验证漏洞利用后，收集了大约 4,500,000 个已确认漏洞的实例，发生在 2,300 多个不同的独特函数中。

因此创建了两个用于训练 ML 模型的数据集：（1）基于污点跟踪浏览器输出的未确认漏洞数据集，以及（2）基于已确认漏洞的数据集概念验证测试注入。已确认漏洞集是未确认漏洞的子集；使用这些数据集训练两个单独的分类器并在两者上执行实验。

C.真实数据集的属性

在收集真实数据后，想了解常用脚本（如 jQuery）对训练和评估的影响程度。如果一小组频繁脚本占数据集的很大一部分，则 ML 模型的性能可能取决于其识别这些频繁脚本的能力。数据集和漏洞分布的总结如下表所示。发现虽然数据集包含一些频繁出现的脚本，但也有明显的长尾独特脚本；数据集包括 23,013,705 个独特脚本的 240,830,867 个观察结果。该数据集明显是片面的：与负标签（非脆弱函数）相比，正标签（漏洞）极为罕见。所有函数中只有 0.17% 是未确认漏洞，所有函数中只有 0.024% 是已确认漏洞。此外在考虑独特脚本时，这些比例甚至更小（0.038% 和 0.0005%）。

D.限制

本研究的浏览器基础架构基于旧版 Chromium，版本 57（2016 年 8 月的版本）。原则上观察到的漏洞可能不适用于其他浏览器。此版本的 Chromium 处理散列后值的编码与最新版本的 Chromium 不同，这可能会影响未经证实的漏洞是否可利用。但是，较新版本的 Chromium 中的防御机制在其他浏览器中并不普遍，因此依赖较新版本的 Chromium 可能会忽略仍然影响许多浏览器的漏洞。

真实数据也受到用于标记的动态分析的限制。数据仅包含来自实际执行的标记 AST 节点，不能对未执行的代码做出声明。然而，虽然数据集包含误报，但它不包含误报：所有 2,326 个已确认的漏洞都被证明在至少一个生成的概念验证漏洞中容易受到攻击。

如果一个函数的任何实例被标记为易受攻击，那么将该函数的所有实例都标记为易受攻击。但是，利用该漏洞可能需要仅出现在某些网页上的跨函数交互。可以说，将此类函数标记为易受攻击仍然是合适的，因为它们在所有情况下都不是安全的。在任何一种情况下，分析此类跨职能交互都很复杂，超出了这项工作的范围。

0x04 Classifier Design

A.攻击者能力：投毒攻击和逃避攻击

将 ML 用于安全任务可能会使系统面临新的攻击。例如，在投毒攻击中，攻击者将恶意训练数据注入系统，在逃避攻击中，攻击者构建看似良性但逃避检测的输入。就本研究的设计而言，不考虑此类攻击。

尽管攻击者可能会建立一个恶意网站，网络爬虫随后会使用该网站来收集中毒的训练数据，但假设这对于攻击者来说是非常昂贵的（因为爬取 10,000 个最受欢迎的网站）并且训练数据用于训练模型不会被对手投毒。

关于逃避攻击，系统旨在检测意外漏洞（例如，帮助保护对其网站上的 JavaScript 具有控制权的网站开发人员）。如果攻击者能够操纵网站上的代码，则该网站已经被承诺，攻击者无需逃避检测基础设施。攻击者模型假设 JavaScript 代码是良性的，但可能存在漏洞；攻击者向网站提供恶意输入以利用 DOM XSS 漏洞，但不控制系统。

B.特征提取与数据准备

在能够对源代码片段进行训练和分类之前，必须将这些代码转换为神经网络可以使用的形式。在本节中将描述将标记的 AST 节点转换为用于训练的特征向量的方法。

给定一块带标签的源代码，选择通过其函数调用来分割代码。对于这项工作中提出的实验，位于单个函数调用中的代码用作训练和分类的单个单元。还尝试基于脚本对代码进行分段，并使用在固定语义距离内包含周围 AST 节点的分段；然而，按函数分割代码为训练模型产生了最好的结果。按整个脚本分段选择过大的代码片段，而固定语义距离策略产生过小的代码片段。在预测漏洞时，这两种表示都会阻止分类器学习有意义的特征。

在标记的源代码被转换成段后，为的 ML 模型提取输入特征。对于此处显示的实验，使用词袋表示：每个函数都由包含在函数调用中的解析 AST 标记的词频字典唯一标识。将所有相关的符号和操作（变量名、操作名、方法名、属性名等）存储在这个字典中。尽管变量和方法名称可能会改变，但相信这种表示在源代码中的微小变化（例如不同的库版本）时是健壮的，因为通常跨版本维护大量的变量名称和函数名称。

还尝试了先前工作中从 C 中提取程序切片的方法，但发现 Javascript 的高度动态性使研究者无法自信地确定切片所需的程序关键点。还对使用基于门控图神经网络 的模型的先前工作进行了实验，但发现这些技术产生的模型不稳定且性能不佳，这也可能是由于 Javascript 的动态性。

将数据集划分为多个子集：80% 的“训练”用于训练模型，10% 的“验证”用于在超参数探索期间评估竞争模型，以及 10% 的“测试”用于测量最终模型的性能。在划分时，按函数源自的脚本进行拆分（对于收集的数据集中的每个脚本，其函数调用有 80% 的机会用于训练，10% 的机会用于测试，10% 的机会用于验证）。执行此拆分是为了评估模型在之前从未见过的完整脚本上的性能，并捕获更真实的设置，在该设置中，模型呈现完整的脚本（然后按函数分段）。

此外，希望根据每个函数在爬行中观察到的频率来增加其重要性。与相对不常见的代码相比，在非常常见的库中定义的函数对于正确分类更重要。为此，在混洗数据之前对训练集中的频繁代码实例进行过采样。这比在训练期间应用权重更可取，因为在实验中，模型在呈现大量超过其他函数的极其常见的函数时不会收敛。如果在训练阶段结束时观察到一个共同的函数，模型就会发生巨大的变化。然而，通过多次重复实例，这些影响会在训练期间得到平滑。

使用数据进行训练的另一个问题是标签之间的大量类别不平衡：非易受攻击的函数远多于易受攻击的函数（只有 0.024% 的函数被确认为易受攻击）。因此，在训练期间通过相应地惩罚损失函数为正标签添加了权重。对 1、10、100 和 1,000 的惩罚项进行了试验，发现 100 是最佳的——惩罚越低，分类器永远不会将函数预测为易受攻击的，而惩罚项为 1,000，分类器不会收敛。

使用特征散列来表示稀疏数据，这允许无界词通过散列到特定桶的术语表示为向量。这种技术的缺点是当散列函数发生冲突时它会引入歧义。为了减轻冲突的影响，使用了 2×18 的特征大小，这是平衡内存需求和冲突概率的推荐大小。使用嵌入层将稀疏的词袋编码为密集的向量空间。这种嵌入是模型架构的第一部分，作为第一个隐藏层的输入，也在训练期间进行了优化。

C.实施

在 TensorFlow中构建模型并使用 Adagrad 优化器训练模型（学习率为 0.05，批量大小为 64）。对于最小的模型，训练时间为每秒 11K 个函数，这意味着使用 64GB 虚拟机和 16GB NVIDIA Tesla P100 GPU 对总数据的 5% 进行训练大约需要 20 小时。

D.性能指标

对于任何类别不平衡的任务，准确性不是一个有用的度量标准，因为分类器可以通过预测所有函数都不会受到攻击来达到近乎完美的准确性。由于正在评估 ML 模型是否可以与其他技术结合使用，因此在调整准确率和开销之间的权衡时，精度-召回率的权衡更有用。将准确率定义为预测的漏洞确实被标记为漏洞的比例，召回率定义为被正确预测为漏洞的标记漏洞的比例。

由于在常见漏洞上表现良好尤其会影响召回率，因此还考虑了对不同漏洞的表现。将不同召回定义为模型正确识别的不同标记漏洞的比例，而真实召回定义为所有标记漏洞被正确识别的比例。在计算真实召回率时，每个函数都以其真实的观察频率加权；所以真正的召回代表对算法在部署时会遇到的真实数据的召回。

0x05 Results

首先，使用验证数据集来调整模型类型和模型大小等参数。然后在测试数据集上评估性能最佳的模型，包括未确认和已确认的漏洞。

在本节中，显示的结果是未确认漏洞的 3 倍平均值，以及已确认漏洞的 5 倍平均值。由于已确认漏洞的数量明显低于未确认漏洞的数量，发现 3 折不足以确认漏洞，因此在这些实验中使用了 5 折。还发现收敛不需要使用整个训练数据集。在训练期间监控模型的性能，并最终决定对于每个折叠，使用 20% 的可用训练数据（总数据集的 16%）就足够了。

A.模型大小和类型

尝试了不同大小的深度神经网络模型。对于这些实验，报告了 3 层全连接 DNN 的结果。对于每个架构，通常在每一层之后将层大小减半，从而形成层大小为 [N, N/2, N/4] 的全连接架构，其中 N 是第一个隐藏层的大小。还试验了线性模型，并将它们的性能与 DNN 进行了比较。下图突出显示了ML 架构的不同组件，并显示了评估的各种超参数。

首先在神经网络中尝试了嵌入层的大小，如 Sec. 4.2.5.嵌入层是一个密集的全连接层，它在散列空间（在实现中为 2×18）中转换稀疏标记，并将密集向量输出到第一个 DNN 隐藏层。下图显示了 N=500 的 3 层 DNN 的 64、256 和 1024 的各种嵌入大小，经过训练以预测未确认的漏洞。同样没有发现嵌入层大小之间的显着差异，并为所有未来的实验选择了最小的嵌入大小 64，以最大限度地减少用例中的大小和推理时间。

通过改变 [N, N/2, N/4] DNN 架构中隐藏层的大小来探索模型大小的影响。对于未确认和已确认的漏洞，训练了 DNN，其中 N = 100、200、500、1000 和 2000。未确认漏洞的结果如下图a 所示，已确认漏洞的结果如下图b 所示。正如预期的那样，预测未确认漏洞的性能明显优于预测已确认漏洞的性能。在这两个实验中，发现模型大小对数据的性能也没有显着影响。由于减小模型大小不会对预测性能产生不利影响，因此选择使用最小的评估模型架构（3 个隐藏层，大小为 100、50 和 25）在进一步的实验中针对已确认和未确认的漏洞。

在提出的用例中，较小的模型是首选，因为它们的推理时间较短且存储大小较小。在没有任何优化的情况下，选择的模型大小为 65MB。由于大多数模型都小到可以在 12GB GPU 中完全处理，因此推理时间在很大程度上不受模型大小的影响。为了更好地理解模型在其他设置中的开销，还测量了 GPU 硬件上的推理时间，并将结果显示在下表中。对于选择的 N = 100 和嵌入大小为 64 的模型，平均时间在 24GB RAM、4 核 Intel i5-6400 3.30GHz CPU 和 Titan X Pascal 12GB GPU、17

BY:先知论坛