忽然有一天，我想要做一件事：去代码中去验证那些曾经被“灌输”的理论。
-- 服装学院的IT男
本篇主要目的是分享如何找到 STS 测试的 case 具体对应的是哪个 CVE 。想直接看答案的可直接拉到末尾第二小节。 第一节是对 STS BTS 的 CVE 问题的分享。
1. 经验分享
STS 测试 security patch相关，一般来说就是每个月释放的 CVE 有没有合入到代码里。所以处理 STS 的方法和 BTS 处理 CVE 问题的方式是一样的。
这一小节后面是对 CVE 问题的描述，不只针对 STS。
绝大部分的情况只要合入l CVE 就不会报 STS BTS 问题，但是! 事情总不会那么的顺利，一般合完每个月 CVE 后还是有可能会出现 CVE 问题。 也有一些特殊情况，可以分为两类：
-
- CVE 没有合入到编译产物
-
- google 测试规则问题
1.1 CVE 没有合入到编译产物
看似有点矛盾，明明说了是合了每个月 CVE 的前提，为什么还存在没合入到编译产物的情况。
目前绝大部分的 CVE 问题都是编译产物没有 CVE ，补上就能 pass 。而出现这种情况的原因
-
- 使用的是 vendor 下的文件，但是合 CVE 只合入了 framework 。所以最终的编译产物里是没有 CVE 内容的。这类问题常常出现在高通项目，因为 MTK 释放 SPL 的适合会补充 vendor 下的，而高通不会，特别是高通项目的蓝牙模块，经常出现 CVE 问题。
-
- 实际用引用的产物是 jar 形式，这样就算项目代码里合入了 CVE ，但是实际用的是之前的 jar 文件，所以还是会报 CVE 问题。
问题本质都是测试扫描的编译产物文件里没有相应的 CVE ，怎么去定位呢？也有2种方式
-
- 公司一般都会提供源码搜索平台，直接搜 CVE 对应的类， 看看是不是存在多个，并且有的类是在 vender 但是没合 CVE
-
- 根据 BTS 报告上报错的内容，会指到具体的 apk 或者 jar 文件。反编译看看这个文件是不是没有 CVE ，如果确认没有的话，再根据具体的文件看对 CVE 这个类的引用文件来源
确认是 CVE 内容没合入到编译产物，则把 CVE 补上验证即可。
1.2 google 测试规则问题
google 的测试规则导致的 CVE 问题概率虽然很小，但是也确实存在。
有的时候明明已经确认 CVE 合入的没有问题，并且 1.1 小节也验证了报错的 apk / jar 文件里对应的 CVE ，但是还是报错。这种情况就是 google 的问题了， google 自己没搞明白怎么合这笔 CVE ，也没搞明白怎么去验证这笔 CVE 。比如 CVE-2023-21266 这笔，反反复复合入然后出现了好几次问题，也提过 google case 确认是他们的问题。
1.3 STS CVE 问题描述
当然 google 出问题的概率很小，所以大部分 STS BTS 出现的 CVE 问题还是以为项目里没有正确合入。
而 BTS 会明确指出是哪个 CVE ，STS 却不一定，比如下面这条 STS 的测试项就明确指出是 CVE-2023-21139 。
android.security.cts.CVE_2023_21139#testPocCVE_2023_21139
但是下面的这条 STS 报错，就不知道到底是哪里的问题了。
这个时候一般测试会拿上一个版本来跑这条case，发现是“skip”，比如项目的 SPL 是7月，则执行 STS 测 8 月 fail 的 case 测试结果就是：“skip”。
这说明 STS 的测试逻辑里，是有对每个月 SPL 的测试项映射规则的。而这个映射规则就是根据每条 case 方法上的注解。
2. STS找对应CVE具体方式
case 方法上带 CVE 的直接找就好，下面的 case 方法不带 CVE 的处理方式。
- 反编译套件，找到对应case的测试方法
- 根据方法上的注解，找到对应的 cveBugId
如图：测试用例方法上有注解： @AsbSecurityTest(cveBugId = {225880325})
- 根据 cveBugId 在 google 每个月释放的 SPL 文件中找到对应的 CVE 如图：
- 找到了具体的 CVE 就和以前的方式一样处理就好了
