本指南将介绍 Google 推荐的应用安全补丁的最佳实践（补丁已通过 Android 兼容性测试套件 [CTS] 评估）。本指南面向的是将享有三年以上支持服务的 Android 兼容 OEM 设备的制造商（以下简称“制造商”），此类设备包括车辆、电视、机顶盒、家用电器等。本指南不适用于最终用户（例如车主）。
致谢和免责声明
本指南对 Google 和其他制造商不具有法律效力或合同约束力，也不作为强制要求。本指南仅作为一份介绍建议做法的辅助参考资料。
反馈
本指南并非详尽无遗，且计划进行多次修订。如有任何反馈意见，请提交至 manufacturers-guide-android@googlegroups.com。
术语库
| 术语 | 定义 |
|---|---|
| ACC | Android 兼容性承诺。以前称为 Android 反碎片化协议 (AFA)。 |
| AOSP | Android 开源项目 |
| ASB | Android 安全公告 |
| BSP | 板级支持包 |
| CDD | 兼容性定义文档 |
| CTS | 兼容性测试套件 |
| FOTA | 固件无线下载 |
| GPS | 全球定位系统 |
| MISRA | 汽车产业软件可靠性协会 |
| NIST | 美国国家标准与技术研究院 |
| OBD | 车载诊断系统（OBD-II 是 OBD-I 在功能性和标准化方面的改进版本） |
| OEM | 原始设备制造商 |
| 操作系统 | 操作系统 |
| SEI | 美国软件工程研究所 |
| SoC | 系统芯片 |
| SOP | 开始量产 |
| SPL | 安全补丁程序级别 |
| TPMS | 轮胎压力监测系统 |
关于 Android 操作系统
Android 是一个基于 Linux 的完整开源软件堆栈，针对多种不同设备类型打造。自 2008 年首次发布以来，Android 已成为最受欢迎的操作系统，为全球超过 14 亿台设备提供支持（2016 年数据）。截至 2017 年 3 月，这些设备中大约有 67% 已采用 Android 5.0 (Lollipop) 或更高版本（如需更多最新数据，请访问 Android 信息中心）。虽然大多数设备都是手机和平板电脑，但 Android 在智能手表、电视和车载信息娱乐系统 (IVI) 设备上的使用率也在增长。
Google Play 商店内提供的 Android 应用数量已超过 220 万（2016 年数据）。Android 应用开发由 Android 兼容性计划提供支持，该计划通过兼容性定义文档 (CDD) 规定了一系列要求，并通过兼容性测试套件 (CTS) 提供测试工具。Android 兼容性计划可确保任何 Android 应用都可在任何支持应用所需功能的 Android 兼容设备上运行。
Google 会定期发布新的操作系统版本、操作系统安全更新以及有关已发现漏洞的信息。制造商应定期查看 Android 安全公告，以了解这些更新对搭载 Android OS 的产品的适用性。如需查看 Android 的安全性、兼容性和构建系统信息，请参阅以下部分：
关于联网车辆（规范化长期运行型产品）
在 20 世纪 20 年代引入调频广播时，汽车便开始实现联网。自那之后，监管部门和汽车制造商转而采用电子设备来简化车辆的诊断和维修（例如，使用车载诊断系统 OBD-II 端口），提升车辆安全性（例如，使用轮胎压力监测系统 [TPMS]），以及达到燃油经济性目标，因此外部有线连接和无线连接也开始增多。随后汽车的联网性能又经历了一轮变革，引入了各种对驾驶者而言十分便捷的功能，例如遥控车门开关、远程信息处理系统，以及蓝牙、Wi-Fi 和智能手机投屏等高级信息娱乐功能。如今，集成式传感器和联网技术（例如 GPS）可进一步提高安全性并支持半自动驾驶。
随着车辆连接数量的增加，汽车的潜在受攻击面也在增大。与家用电子产品一样，汽车也由于这些连接而面临一系列类似的网络安全问题。但是，对于家用电器而言，重新启动、每日补丁更新以及原因不明的行为问题很常见，而对于车辆等搭载安全关键系统的产品来说，情况不尽相同。
制造商必须积极采取措施，确保实际应用中产品的持续安全性。简而言之，制造商必须知道产品中已知的安全漏洞，并采取风险防范的方式解决这些问题。
确保长期安全
联网车辆通常拥有一个或多个电子控制单元 (ECU)，其中包含多种软件组件，例如操作系统、库、实用程序等。制造商应跟踪此类组件，并积极分析，识别已知、已发布的漏洞，分析措施包括：
- 根据通用漏洞披露 (CVE) 数据库定期对产品进行评估。
- 收集与产品相关的安全漏洞信息。
- 安全性测试。
- 积极分析 Android 安全公告。
操作系统更新和安全补丁程序更新示例（搭载 Android 的 IVI）：
图 1. 车辆生命周期内的重大操作系统更新和安全更新发布示例。
| # | 步骤 | 活动 |
|---|---|---|
|
① |
开发分支 | 制造商选择 Android 版本 (Android X)。在此示例中，制造商于开始量产 (SOP) 车辆的两年前选定“Android X”作为将在车辆中搭载的基础系统。 |
| ② | 首次发布 | 在将 Android X 作为首个操作系统版本搭载到其产品中的几个月前，制造商从 Android 安全公告 (ASB) 以及其认为可靠的其他来源获取更新。y2 = Android X 版本的第二个安全公告，由制造商应用（向后移植）到 Android X。此更新将被应用到产品中，之后搭载 Android X.y2 的产品于第 0 年开始投入生产。 在该示例中，制造商决定不搭载最新的 Android X+1 年度版本。搭载最新版本的理由包括：该版本添加了新功能、解决了新的安全漏洞和/或搭载的 Google 或第三方服务需要采用最新的 Android 版本。不搭载最新版本的理由为：在车辆开发和发布过程中，没有时间集成、测试和验证变更（包括达到所有监管和认证要求）。 |
| ③ | 操作系统全面更新 | 在 SOP 之后，制造商发布了 Android X+2 操作系统更新，新版本比起初始产品所用 Android 版本 (Android X0)，已经过了两次版本更新。相应的 API 级别有可用的 ASB 安全更新（截至此操作系统全面更新发布之日），因此操作系统全面更新在制造商 SOP 后大约 1.25 年发布为 X+2.y0。此操作系统更新不一定会与已在使用中的产品兼容。如果兼容，则可以制定计划来更新已部署的车辆。
除非有其他业务协议，否则是否进行操作系统全面更新完全由制造商自行酌情决定。 |
| ④ | 安全更新 | 制造商在车辆投产两年后，为 Android X+2 操作系统应用了补丁。此决定基于制造商的风险评估。制造商选择版本 X+2 的第三次 ASB 安全更新作为更新基础。获得安全更新的产品现在所处阶段为 (X+2.y3) 操作系统 + Android 安全补丁程序级别。
虽然制造商可以从任何一次 ASB 中选择单个安全补丁，但他们必须修复公告中要求解决的所有问题，才能使用与公告（例如 2017-02-05）关联的 Android 安全补丁级别 (SPL)。制造商负责为受支持的产品执行向后移植和应用安全版本。 |
| ⑤ | 操作系统全面更新 | 重复执行第 3 步（操作系统全面更新），在车辆投产 3 年后进行第二次操作系统全面更新，这会将产品提升到 Android X+4 版本。现在，制造商会研究最新 Android 版本的新版硬件要求，并将其与产品中的硬件及更新后的 Android OS 所能为用户带来的益处进行权衡对比。制造商发布系统更新，但不包含安全更新，因此其产品现在所处阶段为 (X+4.y0) 操作系统 + Android 安全补丁级别。 在本示例中，尽管在该产品预期超过 6 年的生命周期内仍然需要安全支持，但是因为硬件限制，X+4 是将针对该产品提供的最后一个主要 Android 系统版本。 |
| ⑥ | 安全更新 | 重复执行第 4 步（安全更新）。制造商负责从新得多的 Android (X+6) 版本获取 ASB 安全更新，并将部分或全部更新向后移植到 Android X+4。制造商还负责合并、集成和执行更新（或与第三方签订合同执行这些操作）。此外，制造商还应知晓，不再受支持的 Android 版本中的安全问题也不在 ASB 的涵盖范围内。 |
| ⑦ | 安全更新 | 在进入汽车生产生命周期的 8 年来，自第 5 步中最后一次操作系统更新（操作系统全面更新）后又发布了四个 Android 版本；自指定 Android X 以来的 10 年中，对于在 API 级别公开发布超过三年后发布的版本，挑选和向后移植安全补丁的责任便完全由制造商负责。 |
安全性最佳实践
为了加大安全漏洞被攻击的难度，Google 采用并且也建议制造商采用公认的安全和软件工程最佳实践，如实现安全性中所述。
安全准则
为确保安全建议采用的做法包括：
- 使用最新版本的外部库和开源组件。
- 请勿在 OS 的发布版本中添加干扰性调试功能。
- 移除未使用的功能（以减少不必要的受攻击面）。
- 采用最小权限原则以及其他 Android 应用开发最佳实践。
软件开发指南
在系统生命周期内为确保软件开发安全建议采用的做法包括：
- 执行威胁建模，对资源、威胁和潜在缓解措施进行排名和识别。
- 执行架构/设计审核，确保设计安全稳定。
- 定期审核代码，尽快识别反模式和 bug。
- 设计、实现和运行高代码覆盖率单元测试，包括：
- 执行功能测试（包括负面测试用例）
- 执行定期回归测试（确保已修复的错误不会重新出现）
- 执行模糊测试（单元测试套件的一部分）
- 使用静态源代码分析工具（scan-build、lint 等）识别潜在问题。
- 使用 AddressSanitizer、UndefinedBehaviorSanitizer 和 FORTIFY_SOURCE（用于原生组件）等动态源代码分析工具来识别和缓解系统开发过程中的潜在问题。
- 制定软件源代码和发布配置/版本的管理策略。
- 制定用于生成和部署软件补丁的补丁管理策略。
安全向后移植政策
目前，自 API 级别公开发布三 (3) 年内，如果发现并报告漏洞，Google 会主动提供安全向后移植支持。主动支持包括以下各项：
- 接收和调查漏洞报告。
- 创建、测试和发布安全更新。
- 定期发布安全更新和安全公告详情。
- 根据既定的准则执行严重程度评估。
在超过 API 级别公开发布日期三年后，Google 建议遵循以下准则：
- 对于 API 发布超过三年之后的操作系统更新，请通过第三方（例如 SoC 供应商或内核提供程序）获得向后移植支持。
- 通过第三方使用公共 ASB 执行代码审核。虽然 ASB 可以识别当前受支持版本的漏洞，但制造商可以使用提供的信息将新发布的更新与先前版本进行比较。这些数据可用于执行影响分析，并可能用于为在 API 发布超过三年之后的操作系统版本生成相似补丁程序。
- 在适当情况下，将安全更新上传到 Android 开源项目 (AOSP)。
- 制造商必须协调对供应商专用代码（例如，专有设备专用代码）的安全更新处理。
- 制造商应加入保密协议 Android 安全公告合作伙伴预览通知组（需要签署《开发者保密协议》等法律协议）。公告应包含：
- 通告
- 按补丁程序级别汇总的问题，包括 CVE 和严重程度
- 漏洞详情（如果适用）
其他参考资料
如需有关安全编码和软件开发做法的说明，请参阅以下内容：
建议的产品做法
Google 建议采用下列推荐做法。
一般发布指南
通常建议以最新的操作系统版本发布所有关联产品，且制造商在发布产品之前应尽可能采用最新的操作系统版本。虽然在测试和验证之前锁定操作系统版本有助于提升稳定性，但较旧的操作系统版本有助于保障产品稳定性，而较新的操作系统版本往往已知安全漏洞更少且安全保护功能更强大，因此制造商必须对这两方面进行权衡。
建议的准则包括：
- 由于车辆开发流程的固有开发周期较长，因此制造商可能需要在发布时搭载 n-2 或更早版本的操作系统。
- 通过无线下载 (OTA) 推广活动，使每个已发布的 Android OS 版本都满足 Android 兼容性要求。
- 实现产品 Android 固件无线下载 (FOTA) 功能，以实现快速便捷的更新。FOTA 应采用安全最佳实践（例如产品与 IT 后台之间的代码签名和 TLS 连接）完成。
- 将独立识别到的 Android 安全漏洞提交给 Android 安全团队。
注意：Google 已考虑在 Android 安全公告中按设备类型或按行业对通知进行分类。但是，由于 Google 不了解特定设备（车辆、电视、穿戴式设备、手机等）的内核、驱动程序或芯片组，Google 无法确定将任何给定安全问题划入何种设备类型。
产品周期指南
在产品周期的改进增强期间，制造商应尽力尝试对所使用的版本使用最新的操作系统版本或安全更新。可在周期性产品更新期间执行更新，或获取修补程序来解决质量和/或其他问题。建议的做法包括：
- 制定计划以解决驱动程序、内核和协议更新方面的问题。
- 利用行业适用方法来为已部署的车辆提供更新。
兼容性定义文档 (CDD)
兼容性定义文档 (CDD) 描述了设备被视为 Android 兼容设备所需满足的要求。CDD 是公开的，人人均可使用；您可以从 source.android.com 下载从 Android 1.6 到最新版本的 CDD。
要使产品满足这些要求，需要执行以下基本步骤：
- 合作伙伴与 Google 签署 Android 兼容性承诺 (ACC)。然后指派一名技术解决方案顾问 (TSC) 担任指导。
- 合作伙伴针对该产品的 Android 操作系统版本完成 CDD 审核。
- 合作伙伴运行 CTS 并提交结果（如下所述），直到结果符合 Android 兼容性的要求。
兼容性测试套件 (CTS)
兼容性测试套件 (CTS) 测试工具可验证产品实现是否与 Android 兼容，以及是否包含最新的安全补丁。CTS 是公开的、开源的，人人均可使用；您可以从 source.android.com 下载从 Android 1.6 到最新版本的 CTS。
每个公开发布的 Android 软件 build（出厂安装和现场更新映像）必须通过 CTS 结果证明 Android 兼容性。例如，如果设备搭载 Android 7.1，则在创建并测试旨在发布的 build 映像时，应参照最新的相应版本 CDD 7.1 和 CTS 7.1。强烈建议制造商尽早且频繁使用 CTS 来识别和解决问题。
CTS 工作流
CTS 工作流涉及设置测试环境、运行测试、解读结果以及了解 CTS 源代码。以下准则旨在帮助 CTS 用户（例如开发者、制造商）高效地使用 CTS。
- 频繁运行测试。CTS 设计为一款可集成到构建系统中的自动化工具。高频次运行 CTS 可帮助您在软件发生降级或回归时尽早快速找出缺陷。
- 下载并检查 CTS 源代码。完整的 CTS 源代码为开源软件，人人均可下载和使用（下载的源代码完全可构建且可运行）。当测试在设备上运行失败时，检查源代码的相关部分可以帮助您确定原因。
- 获取最新的 CTS。新的 Android 版本可以通过 bug 修复、改进和新测试来更新 CTS。请经常查看 CTS 下载，并根据需要更新 CTS 计划。制造商和 Google 应就产品发布所应通过的 CTS 版本达成一致，因为产品必须在特定时间点冻结，而 CTS 会持续不断更新。
通过 CTS 测试
对于与 Android 兼容的产品，Google 可确保设备的 CTS 和 CTS 验证程序报告测试结果是可接受的。原则上，必须通过所有测试。但是，如果设备并非因不符合 Android 兼容性要求而未通过测试，则需接受 Google 审核。在此过程中：
- 制造商应向 Google 提供提议的 CTS 补丁、补丁验证和理由来证明其论点。
- Google 会检查制造商提交的材料，如果接受这些材料，则会更新相关 CTS 测试，以便设备通过下一版本的 CTS。
如果 CTS 测试在应用安全补丁后突然失败，则制造商必须修改此补丁以确保不会破坏兼容性，或者证明测试有误并为该测试提供修复程序（如上所述）。
CTS 仍保持开放状态，以便对测试修复程序进行审核。例如，Android 4.4 仍继续接受修复程序（请参阅 https://android-review.googlesource.com/#/c/273371/）。
常见问题解答 (FAQ)
问：谁负责将安全更新应用于特定 Android 实现？
答：由直接提供设备的制造商负责。该实体不是 Google。Google 发布 AOSP 中的安全更新，而不是针对特定设备（例如车辆）的安全更新。
问：Google 如何处理 Android 中的安全问题？
答：Google 会持续调查问题并开发潜在的修复方案，并且会在常规安全更新流程中向所有受支持的 API 级别提供修复方案。自 2015 年 8 月起，Google 会在 source.android.com 定期发布公告和更新链接；Google 还会在主要操作系统版本发布时发布安全更新。另请参阅安全向后移植政策。
问：如果制造商集成了某个 ASB 中的所有 AOSP 补丁，但未集成同一公告中提到的 BSP 供应商提供的补丁，这是否仍然可以提高安全级别（例如，将相应的补丁应用到平台/build）？
答：为了声明 Android 安全补丁级别 (SPL)，制造商必须解决在 Android 安全公告（包括之前的公告）中发布的所有必须解决的问题，并将其映射到特定 Android 设备 SPL。例如，如果制造商使用 2017 年 3 月安全公告 (2017-03-01 SPL)，就应已解决 2017 年 3 月公告中记录的该 SPL 必须解决的所有问题并且应用了之前的所有更新，包括先前所有 Android 安全公告的设备专用更新（包括与 2017-02-05 SPL 相关的设备专用更新）。
问：如果制造商不同意 BSP 供应商提供的安全更新或者供应商未提供 ASB 强制要求的安全更新，会出现什么情况？
答：ASB 会描述安全漏洞（通过 CVE 列表枚举），并且通常会提供匹配的安全测试。目的是确保所列的漏洞不会在设备上重现，并确保设备能够通过相关安全测试。因此，问题不在于是否采用由 Google 或第三方供应商提供的安全更新，而在于制造商必须能证明设备不会受到 ASB 中 CVE 列表上所列漏洞的影响。制造商可以自由地使用 Google 所提供的安全更新，或者如果他们的更改更适用于自己的设备，可改用此更改。
例如，假设 Google 通过更改代码解决了一个 AOSP 安全漏洞问题，这可以使该组件保持正常运行并符合 CDD。如果制造商确定设备不需要该组件，或 CDD（或相关认证测试）没有强制要求，则可以移除该组件以减少将来的维护需求并缩小受攻击面。虽然制造商未使用 Google 提供的安全更新，但确实已确保设备不易受到安全公告中所述的 CVE 的攻击。但是，若不采用推荐的安全更新，制造商可能会面临以下风险：对问题解决不当、引入新的安全漏洞或在其他方面降低最终 build 的功能。
我们致力于与所有 SoC 合作伙伴共同努力，确保 ASB 中的所有问题都得到解决，因此建议制造商在设备的整个生命周期内与其 SoC 供应商签订服务协议。SoC 可能会提前停止对芯片组的服务支持，因此在选择设备芯片组之前签订协议是设备发布过程的一个重要环节。
最后，如果无法直接获取或单独为 ASB 中记录的问题创建修复方案，制造商可以维护之前的 Android SPL，并且仍可向 build 添加可用的新修复程序。不过，这种做法最终会导致 build 认证出现问题（因为 Android 可以确保在经过认证的设备上提供最新的安全补丁程序级别）。Google 建议提前与您的 SoC 开展合作，以避免发生这种情况。
问：如果制造商确定某个 ASB 项不适用于其产品，是否仍需应用该项或采用该项的补丁，以便满足其他 Google 要求或通过 CTS 测试？
答：我们不要求为了声明 Android 安全补丁级别 (SPL) 而采用补丁；但我们要求制造商证明他们的 build 不会受到相应问题影响。
例如，如果某个组件需要修补，但制造商的系统中不存在该组件，或者制造商从其系统中移除了该组件来解决相应问题，在这种情况下，制造商不需要采用该补丁来使其系统符合要求。
但是，如果制造商只希望执行关键补丁修复，而不采用其他可能导致安全测试失败的可用补丁，则与上文属于截然不同的情况。在这种情况下，系统会被视为未满足 SPL 要求。