2011 年 1.1 - 1.1.1 版本。Juliet 1.1 版本 是 Juliet 的开发团队根据多个因素为选定的缺陷创建了测试用例，包括团队的经验、缺陷的重要性或严重性以及其出现的频率。测试用例涵盖了 2011 年 CWE/SAN TOP 25 个最危险的编程错误中的 14 个。剩下的 11 个缺陷是设计问题，例如 CWE-862 授权机制缺失 和 CWE-250 带着不必要的权限执行，这些问题不适合用静态分析的方式来检测，所以未包含在测试用例中。

2012 年 1.2 版本。2012 年的 Juliet 1.2 版本。基本形成了现在使用版本。是我们现在使用最多的版本，程序分析、自动修复、深度学习的论文基本上都使用了这里面的用例，用于证明理论、工具的有效性。

2017 年 1.3 版本。只对1.2 版本的个别错误进行了修正。

• Juliet C/C++ 涵盖 118 个 CWE 问题，1689 个场景，用例数: 181,140, 其中正例：117,041, 反例：64,099。
• Juliet Java 涵盖 112 个 CWE 问题，933 个场景，用例数: 96,537, 其中正例：67,656, 反例：28,881。

2022 年 1.3.1 版本。增加了SARIF 的支持，试图通过SARIF 精确的给出告警的位置信息，但对数据流的支持的并不好，不能完全依靠现有的SARIF版本。

注：关于 SARIF请参考：

2.3. Juliet 用例构造的特点

2.3.1. 统一明确的命名方式

测试用例使用CWE作为命名和组织的基础。测试用例力求对目标缺陷使用最具体的CWE条目。每个测试用例文件与一个CWE条目相关联。

2.3.1.1. 测试用例文件名命名规范

测试用例名由四个元素的组合唯一标识：

单文件用例：

CWE190_Integer_Overflow__byte_console_readLine_add_01.java

• CWE190： CWE 的编号，可以在CWE网站上查询到这个编号对应的问题：https://cwe.mitre.org/data/definitions/190.html;
• Integer_Overflow：CWE190 描述的简写，整型溢出。CWE190 的完整描述是：整型溢出或越界折返;
• byte_console_readLine_add： 场景描述：通过readLine函数从控制界面读取字节流；
• 01：代表基础用例。

多文件用例, 下面的一组文件构成了一个用例：

• CWE190_Integer_Overflow__byte_console_readLine_add_81_bad.java
• CWE190_Integer_Overflow__byte_console_readLine_add_81_base.java
• CWE190_Integer_Overflow__byte_console_readLine_add_81_goodB2G.java
• CWE190_Integer_Overflow__byte_console_readLine_add_81_goodG2B.java
• CWE190_Integer_Overflow__byte_console_readLine_add_81a.java
  • CWE190： CWE 的编号，可以在CWE网站上查询到这个编号对应的问题：https://cwe.mitre.org/data/definitions/190.html;
  • Integer_Overflow：CWE190 描述的简写，整型溢出。CWE190 的完整描述是：整型溢出或越界折返;
  • byte_console_readLine_add： 场景描述：通过readLine函数从控制界面读取字节流；
  • 81: 数据流案例，案例将参数传递给通过引用调用的抽象方法；
  • _bad: 表示这是个反例的文件；
  • _base: 表示这个是用例的主文件；
  • _goodB2G: good 表示这是个正例的文件，同时 B2G 表示污点（Bad）会经过清洗到达（2(to)）爆发点，但由于做了清洗，变成了无污染的，不会引起问题（Good）;
  • _goodG2B: good 表示这是个正例的文件，同时 G2B 表示污点经过清洗变成无污染（Good）到达（2(to)）爆发点（Bad），但由于是无污染的数据，也不会引起问题;
  • a: 表示这是个辅助文件。

2.3.1.2. 测试用例函数名命名规范

有问题（反例）函数，通常以bad命名, 并可使用正则表达式匹配：^bad$;

没问题（正例）的函数，通常以good命名, 并可使用正则表达式匹配：^good$;

对于用例中存在多个正例的函数，有以下三种命名方式，可使用正则表达式匹配：^good(\d+|G2B\d*|B2G\d*)$;

• 默认或通用的方式，采用例如： good1（）、good2（）、good3（）的命名方式；
• 当一个好的源将安全数据传递到一个潜在的坏接收器时，采用例如：goodG2B（）、goodG2B1（）、goodG2B2（）、goodG2B3（） 的方式命名;
• 当不良源将不安全或潜在不安全的数据传递给良好源时，采用例如：goodB2G（）、goodB2G1（）、goodB2G2（）、goodB2G3（）的方式命名；

• 对于数据流用例还遵守以下命名方式：有问题的污染源，采用正则表达式：^badSource$；有问题的爆发点，采用正则表达式：^badSink$；无问题的污染源，采用正则表达式：^good(G2B\d*|B2G\d*)?Source$；无问题的爆发点，采用正则表达式：^good(G2B\d*|B2G\d*)?Sink$。

2.3.1.3. 命名规则在测试中带来的好处

从文件名就能判断出检测问题、场景、适用的案例类型，有的还可以知道文件是正例、还是反例；

从发生问题的函数名就可以知道，所处的函数是正例，还是反例；

通常检测工具都会给出问题所在的文件和函数，这样在查看问题的时候能够立刻判断出检测结果的有效性；

严格的命名方式，也便于使用程序自动化的检查结果做出快速的判断。

2.3.2. 每个问题给出发生问题的可能场景

Juliet 还为每个问题（CWE）枚举了一些发生场景，一些场景还使用模板结合控制流和数据流进行了枚举，从而测试更加广泛的问题发生的可能性，以提高问题的覆盖率。

Juliet 一共采用了三类模板：

• 控制流模板（point-flaw）
• 单一污点源和爆发点模板（source-sink）；
• 多污点源和爆发点模板（sources-sinks);

Juliet Java

• Juliet Java 一共 122 个 CWE, 覆盖 933 个场景。
• 用模板生成的场景 823 个，这包括：point-flaw： 92 个场景；sources-sink： 197 个场景；sources-sinks： 534 个场景;

• 单一场景 110 个。

Juliet C/C++

• Juliet C/C++ 一共 118 个 CWE, 覆盖 1689 个场景。
• 用模板生成的场景 1509 个，这包括：

而单一场景 180 个。

2.3.3. 每个场景使用不同的案例进行覆盖

Juliet 用例还真对每个场景结合控制流和数据流进行了枚举，以达到每个场景在不同代码条件下的检测能力的覆盖。

从下表我们看到类型基本上涵盖了编程语言通常所需要的基本语法，例如条件判断（if），条件分支（swith），循环（while，for），函数间和程序间不同层数的调用，以及不同类型的参数传递方式。

案例类型明细

2.3.4. 缺点

Juliet 可以说是堪称完美的测试用例集，但随着时间的推移，编程语言的迭代，它也显现出一些缺点：

• 一些用例的写法开始变得老旧，可能不能胜任新的场景；
• 没有对语言的所有语法特点做覆盖，特别是新的一些语法类型；比如：lamda 表达式；
• 用例的设计存在大量的重叠，特别是对数据流的检测，每个场景都使用了相同的模板，产生了大量的用例。其实对于数据流的处理，完全可以分成：污染源、污染传递、污染清理、以及爆发四个不同的维度进行分别测试，这样可以大大提升测试效率。

3. OwaspBenchmark 测试用例集

3.1. 用例背景

OWASP(Open Worldwide Application Security Project (OWASP)) 基金会致力于通过其社区主导的开源软件项目、全球数百个分会、数万名成员以及举办当地和全球会议来提高软件的安全性。

3.2. 用例简介

OWASP Benchmark Project 是一个 Java 测试套件，旨在评估自动化软件漏洞检测工具的准确性、覆盖率和速度。

• 1.0 版本于 2015年4月15日发布，共有 20983 个测试用例。
• 1.1 版本于 2015年5月23日发布。1.1版本在前一版本的基础上进行了改进，确保每个漏洞区域都有真阳性和假阳性。
• 1.2 版本于 2016年6月5日首次发布（1.2测试版于2015年8月15日发布）。自那以后，v1.2版本一直在不断调整。1.2 版本将测试用例数量控制在小于3000个测试用例，以便快速得到测试结果。

3.3. 用例设计和组成方式

下面以 1.2 版本为例进行说明。

3.3.1. 用例问题的覆盖

从下面这个表可以看出 Benchmark 更多的注重覆盖 Web 类的问题的检查，同时重点覆盖了 OWASP TOP 10 中的主要能够通过静态检查工具检查的问题。关于 OWASP TOP 10 可以参考:CWE 4.6 和 OWASP TOP10(2021)。

Benchmark 用例集主要以加密问题，以及注入类问题为主，这也巧合的与静态检查技术相互匹配。加密问题多用抽象语法树（AST）的遍历来返现加密函数，并对其做出判断。而注入类问题多用数据流的污点分析技术来追踪外部输入是否会对爆发点形成可达的路径。有关污点分析技术，可以参考:使用污点分析检查log4j问题。

3.3.2. 问题场景的覆盖

Benchmark 用例对每个问题采用: 场景枚举 + 组合的方式完成用例的设计，并通过此方法形成问题的覆盖。

这里以我们熟悉的：CWE89 SQL注入问题来说明这种用例的设计方式。用例集中CWE 89 SQL注入问题一共有 232 个正例，272 个反例，共计504 个用例。

因为 SQL 是注入是通过外部不可信数据，传播到 SQL 脚本执行的位置而导致的安全问题。这个外部数据传播的过程可以分为：

用例使用了我们常用的从 http 请求中得到外部数据，然后将数据以不同方法存入不同类型的字段。用例中列举了下面 9 种不同的方法。例如放入：字符串、枚举、数组等。

用例接收到数据后，使用不同的传递方式，向程序内传递，并对信息采用不同的操作方式进行加工。用例中列举了下面 10 种不同的方法。例如：通过 创建一个新类然后调用函数传递、if 条件表达式、内部类等。

最终数据会拼装成 SQL 语句，并通过不同的调用方式执行。用例中列举了 3 类，28 种不同的执行方式。

得到上面三种基本节点后，通过组合的方式形成用例。下表列举了 CWE89 SQL注入 272个反例组合的场景：

3.3.3. OwaspBenchmark 用例集的缺点

OwaspBenchmark 应为涵盖了Web应用的主要安全问题，使用例集基本上成为了Web 应用安全测试的基本用例集。但它也存在一些缺点。

• 用例名只采用了简单的编号方式，从用例看不出测试目标：用例反应的问题、场景、正例、反例这些基本信息，而不得不给每个用例加了一个xml文件来说明这些用例的基础信息。
• 用例缺少场景的描述，工具测试后，无法得到覆盖场景和非覆盖场景的统计信息，只知道覆盖率。具体哪些场景缺失，要一个个用例去自己分析。
• 缺少检测语言语法级别的场景的覆盖，例如lamda表达式，工具在数据流的分析过程中，任何一个语法的不适配都会导致分析中断。

4. Alipay 测试用例集

4.1. 用例背景

针对xAST领域缺乏有效衡量技术能力标准的业界痛点，蚂蚁安全团队联合蚂蚁程序分析团队、浙江大学网络空间安全学院的20余位专家学者，共同设计了xAST评价体系及其测试样本套件Benchmark，致力于成为应用安全测试工具的“度量衡”。

• 目标：打造具备行业共识的xAST能力评价体系技术标准

• 价值：衡量xAST产品技术能力，指引xAST技术发展方向，辅助企业产品选型

4.2. 用例设计和组成方式

用例设计的核心思想是：分层设计，降低评价复杂度。

从底层到上层分成引擎能力、规则能力和产品化能力这三层。对这三层分别设计评价体系和测试样本，既降低了每一层评价的复杂度，又使测试结果可以直接反映问题出在哪一层。

看的出，用例集的设计者试图希望结合Juliet、Owaspbenchmark 的优点，在形成一种分层的评估测试方式。来完善前面两个用例集在语法层面的不足。

目前用例集只推出了一个雏形，还在建设中。

5. 理想的测试用例集

最后再来总结下，理想的测试用例集应该是怎样的。

• 能够从用例的命名上，清楚的反映：测试问题、场景、正例、反例；或从目标函数上明确知道在这个函数内的告警是正确的告警，还是误报；
• 能够覆盖业界主要的安全问题，例如：CWE TOP 25、OWASP TOP 10等常见的问题；
• 能够覆盖检测语言的主要语法和语言的主要使用方式；
• 能够有一定的场景枚举和组合，以增加测试用例的复杂度，这有点类似 fuzzy 测试了。

写在最后，测试用例集的结果，只能反映一个工具的基础能力，并不能取代通过实际的工程来打磨检查工具。

一般的程序员只需要在问题和实现上建立一条通道就好，但程序分析的程序员却需要考虑各种程序员实现问题的可能性。

点击关注，第一时间了解华为云新鲜技术~