4月份起，SECUTITY PATCH 2019-05-01及之后的版本需要通过所有STS测试。
如有失败项需申请豁免，请参考后文描述；
| We’re starting the waiver process for STS from April |
We appreciate your collaboration with the new process to roll out the STS (Security Test Suite), a test suite that helps validate whether your Android Software build is vulnerable to CVEs (common vulnerabilities and exposures) that were reported in the security bulletins up to the reported SECURITY_PATCH.
Starting April, all software builds declaring the SECURITY_PATCH 2019-05-01 or later will only be approved when every STS failure is addressed. We recognize there will be cases where waivers will be needed, so we are planning to align the process dealing with the STS test failures with the process you already are familiar with for other test suites (CTS, GTS) as below.
Upon encountering a failure, you must:
- Analyze whether your software build is actually vulnerable to the CVE or if the STS test is inaccurately reporting the build as vulnerable. If you believe the STS test is inaccurate, do the following:
-
- Prepare a statement indicating why the software build is not vulnerable (e.g. if you did not take the patch directly from AOSP, provide the patch you used or if you believe your device is not vulnerable for other reasons articulate those reasons).
- Request a waiver for the STS failure, accompanied with the other information requested in the Buganizer template, by assigning it to android-waiver-request@google.com,.
- Upon receipt of a complete waiver bug, the Android Security team will review the request. If the request is found reasonable, the Buganizer item will be added to a waiver hotlist to indicate that the waiver is approved similar to how CTS and GTS failures are being reviewed.
- If your build is actually vulnerable to the CVE, there will be no waivers. Address the root cause and submit a new software build approval request.
We also want to use this opportunity to clarify that the “partners are not required to pass STS” in the previous announcement must not be interpreted that it is acceptable to override the CDD section 3.2.2 requirement that a software build has addressed all the CVEs leading up to the reported SECURITY_PATCH level. It only means that the GMS license approval is not blocked by resolving the technical failures encountered while running STS or the test failure that is incorrectly reported by STS.
我们从四月开始对STS进行豁免
我们感谢您与新流程的合作，推出了STS（安全测试套件），这是一个测试套件，可帮助验证您的Android软件构建是否容易受到安全公告中报告的CVE（常见漏洞和风险）的影响。报道了SECURITY_PATCH。
从4月开始，声明SECURITY_PATCH 2019-05-01或更高版本的所有软件版本仅在每个STS故障得到解决时才会被批准。我们认识到将会出现需要弃权的情况，因此我们计划将处理STS测试失败的过程与您已熟悉的其他测试套件（CTS，GTS）的过程对齐，如下所示。
遇到失败时，您必须：
分析您的软件构建是否实际上容易受到CVE的攻击，或者STS测试是否不准确地将构建报告为易受攻击。如果您认为STS测试不准确，请执行以下操作：
准备一份声明，说明为什么软件构建不容易受到攻击（例如，如果您没有直接从AOSP获取补丁，提供您使用的补丁，或者您认为您的设备由于其他原因而不易受到这些原因的影响）。
通过将其分配给android-waiver-request@google.com，请求豁免STS失败，并附上Buganizer模板中要求的其他信息。
收到完整的豁免错误后，Android安全团队将审核该请求。如果发现请求合理，则Buganizer项目将被添加到豁免热门列表中，以表明豁免被批准类似于如何审查CTS和GTS故障。
如果您的构建实际上容易受到CVE的攻击，那么就不会有豁免。解决根本原因并提交新的软件构建批准请求。
我们还想利用这个机会澄清在前一个公告中“合作伙伴不需要通过STS”，不得解释为可以覆盖CDD第3.2.2节要求软件构建已满足所有CVE的要求导致报告的SECURITY_PATCH级别。这仅表示通过解决运行STS时遇到的技术故障或STS错误报告的测试故障，不会阻止GMS许可证批准。