Php/level reclassification (#157)

feat: 新增 sast-php 引擎能力评测靶场 (290 case)

覆盖 accuracy（准确度）和 completeness（完整度）两大维度共 63 个评价项：

accuracy: 13 子维度 64 case（上下文敏感/路径敏感/流敏感/对象域敏感）
completeness/single_app_tracing: 47 子维度 214 case（别名/控制流/跨文件/数据类型/异常/表达式/函数调用/OOP/变量作用域）
completeness/dynamic_tracing: 3 子维度 12 case（eval/可变变量/compact-extract）

PHP 特有语法全覆盖：引用赋值、魔术方法、trait、闭包use、match、nullsafe、 heredoc、spread、解构、named args、enum、readonly、generator、超全局变量、 autoload、可变函数、late static binding、匿名类、first-class callable 等。

全部 290 文件通过 php -l 语法校验（PHP 8.5.4）。

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

feat(sast-php): 为全部 PHP case 生成成熟度分级 config.json

新增 generate-config.ts 脚本，解析 290 个 PHP case 注释，按叶子目录生成 config.json
生成 26 个 config.json，覆盖 262 个 case（含 28 个跨文件 case）
格式与 Go/Java benchmark 一致：evaluation_item / level / scene / compose
支持三种 T/F 配对模式：同编号、连续编号、混合命名
同步 config.json 到 yasa2 测试目录

验证：脚本运行通过，所有 config.json JSON 合法，257 个文件引用全部存在

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

feat(sast-php): 添加成熟度达成度计算脚本

基于 config.json compose 规则和 benchmark 检测结果，按 L1-L4 级别计算 PHP 成熟度达成率。

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

refactor(sast-php): 修正 case 成熟度分级，对齐等级定义

原分级与等级定义不匹配：

L1 case 全部含数据流追踪，但 L1 定义为”语法识别，无数据流”
L2 准确度 case（流/路径/上下文/对象域敏感）本质是精确建模，应为 L3
L3 动态特性（$name、eval、compact/extract）应为 L4

调整规则：

L1 → L2：13 个完整度基础 scene（含数据流追踪）
L2 准确度 → L3：32 个精确建模 scene
L3 → L4：6 个动态特性 scene
L2 完整度不变：80 个 scene

调整后：L1=0, L2=93, L3=32, L4=6（总计 131 不变）

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

Co-authored-by: Claude Opus 4.6 noreply@anthropic.com

项目官网

简体中文 / English

项目简介

应用安全测试技术（xAST）对于保障软件安全可靠发挥着越来越重要的作用，目前每一类应用安全测试产品（SAST/IAST/DAST/SCA/MAST等）都有至少数十款商业化或开源产品供客户选择。与此同时，一些甲方企业也在自研xAST产品。不管是商业采购还是选择开源产品还是自研，大家都面临一个共同的难题，如何客观衡量一款xAST产品的技术水平？

目前工业界和学术界都没有对xAST产品技术能力进行衡量的评价标准，通常是使用若干漏洞样本集的测试结果进行技术评价，业界常见的漏洞样本集见图1，测试结果示例见图2。

图1 业界常见漏洞样本集

图2 不同开源SAST在Juliet Java漏洞样本集上的测试结果示例

一方面，由图1可以看出各样本集之间差异巨大（从数十个样本到十万个样本），究其根源在于漏洞样本集缺乏体系化设计，都是漏洞样本的简单堆砌，测试结果的完整性得不到保障；漏洞样本集所测试的功能点分布不均，测试结果也缺乏合理性。

另一方面，由图2可以看出，由于缺乏评价体系，评价结果对用户是个“黑盒”，评价结果只能给出总体的召回率和误报率数据，无法细粒度的刻画产品的技术优势与不足。

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

项目目标与价值

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

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

技术亮点

业界首个评价体系驱动式Benchmark

传统漏洞样本集普遍没有做评价项设计，一般是简单的通过堆砌样本来体现其“完整度”，很可能有较多的样本都在测试同一个功能点，这势必导致测试结果既不能保证完备性，也不能保证测试结果的合理性。

我们在设计测试样本集之前，在业界首次设计了一套包含各个维度评价项的评价体系，再基于评价体系设计对应的测试样本集，较传统方式提高了完备性和合理性。

图3 业界首个评价体系设计驱动式Benchmark

业界首个面向工具视角的Benchmark

传统漏洞样本集一般都是以漏洞类型作为评价视角，不同漏洞类型的样本组成了样本集，不同类型的xAST产品都在同一套漏洞样本集上进行测试。但xAST技术原理各异，样本集在不同类型产品之间很难通用。如测试静态分析SAST路径敏感的样本对于动态分析IAST来说就没有太多意义，这也将影响测试结果的合理性。

针对这种情况，我们转换了评价视角，在业界首次从漏洞视角转化成工具视角，不同工具不同评价项，不同语言不同评价项，评价项和样本的设计更合理。

图4 业界首个面向工具视角的Benchmark

评价体系分层设计，降低评价复杂度

本质上，xAST的能力是分层的。有的能力比较底层，如对污点数据的跟踪能力，这类能力通常实现的难度较大，成本较高，是需要用户重点关注的；有的能力属于比较上层，如对某个规则或框架的sink点支持，通过简单的配置就可以支持，重要度相比引擎能力没那么高。传统漏洞样本集没有对这些能力做区分，“眉毛胡子一把抓”，测试结果无法区分究竟是规则没有配置导致的不支持还是引擎能力上不支持。

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