本指南介紹了 Google 推薦的應用由 Android 兼容性測試套件 (CTS) 評估的安全補丁的最佳做法。它適用於支持超過三 (3) 年的 Android 兼容 OEM 設備製造商（製造商），例如車輛、電視、機頂盒、家用電器等。本指南不適用於最終用戶（例如，車主）。
致謝與免責聲明
本指南不以法律或合同方式約束 Google 或其他製造商，也不打算作為一組要求。相反，本指南是描述推薦做法的指導性幫助。
反饋
本指南並不全面；計劃進行更多修訂。向製造商指南-android@googlegroups.com 提交反饋。
詞彙表
| 學期 | 定義 |
|---|---|
| ACC | Android 兼容性承諾。以前稱為 Android 反碎片協議 (AFA)。 |
| AOSP | 安卓開源項目 |
| ASB | Android 安全公告 |
| BSP | 板級支持包 |
| 客戶盡職調查 | 兼容性定義文檔 |
| 中旅 | 兼容性測試套件 |
| FOTA | 無線固件 |
| 全球定位系統 | 全球定位系統 |
| MISRA | 汽車工業軟件可靠性協會 |
| NIST | 美國國家標準與技術研究院 |
| OBD | 車載診斷（ OBD-II 是對 OBD-I 在能力和標準化方面的改進） |
| OEM | 原始設備製造商 |
| 操作系統 | 操作系統 |
| SEI | 軟件工程學院 |
| SOC | 片上系統 |
| 標準作業程序 | 開始生產 |
| 聲壓級 | 安全補丁級別 |
| 胎壓監測系統 | 胎壓監測系統 |
關於安卓操作系統
Android 是一個開源的、基於 Linux 的完整軟件堆棧，專為各種設備和外形尺寸而設計。自 2008 年首次發布以來，Android 已成為最受歡迎的操作系統 (“OS”)，為全球超過 1.4 億台設備提供支持（2016 年）。截至 2017 年 3 月，這些設備中約有 67% 使用 Android 5.0 (Lollipop) 或更新版本（ Android Dashboard上提供了最新數據）。雖然絕大多數設備是手機和平板電腦，但 Android 在智能手錶、電視和汽車車載信息娛樂 (“IVI”) 設備方面正在增長。
Google Play 商店中可用的 Android 應用程序數量已達到2.2+ 萬（2016 年）。 Android 應用程序開發由 Android 兼容性計劃提供支持，該計劃通過兼容性定義文檔 (CDD)定義一組要求，並通過兼容性測試套件 (CTS)提供測試工具。 Android 兼容性程序確保任何 Android 應用程序都可以在任何支持應用程序所需功能的 Android 兼容設備上運行。
Google 會定期發布新的操作系統版本、操作系統安全更新以及有關已發現漏洞的信息。製造商應查看Android 安全公告，了解這些更新對 Android 操作系統支持的產品的適用性。有關 Android 安全性、兼容性和構建系統的評論，請參閱以下內容：
關於聯網車輛（典型的長壽命產品）
1920 年代，隨著 AM 收音機的引入，車輛開始連接起來。從那裡開始，隨著監管機構和汽車製造商轉向電子設備以簡化診斷和服務（例如 OBD-II 端口）、提高安全性（例如 TPMS）並滿足燃油經濟性目標，外部物理和無線連接的數量開始增長.接下來的連接浪潮引入了駕駛員便利功能，例如遠程無鑰匙進入、遠程信息處理系統和先進的信息娛樂功能，例如藍牙、Wi-Fi 和智能手機投影。如今，集成傳感器和連接（例如 GPS）支持安全和半自動駕駛系統。
隨著車輛連接數量的增加，潛在車輛攻擊面的面積也會增加。連接帶來了與消費電子產品類似的網絡安全問題。然而，雖然重啟、每日補丁更新和無法解釋的行為是消費電子產品的常態，但對於車輛等具有安全關鍵系統的產品來說，它們是不一致的。
製造商必須採取積極主動的方法來確保產品在該領域的持續安全和安全態勢。簡而言之，製造商必須了解產品中已知的安全漏洞，並採取基於風險的方法來解決這些漏洞。
確保長期安全
聯網車輛通常具有一個或多個電子控制單元 (“ECU”)，其中包括多個軟件組件，例如操作系統、庫、實用程序等。製造商應跟踪此類組件並通過主動分析識別已知的已發布漏洞，包括：
- 根據常見漏洞和暴露 (CVE) 數據庫定期評估產品。
- 收集與產品相關的安全漏洞的情報。
- 安全測試。
- 積極分析 Android 安全公告。
操作系統和安全補丁更新示例（運行 Android 的 IVI）：
圖 1.在車輛生命週期內推出的主要操作系統和安全更新示例。
| # | 步 | 活動 |
|---|---|---|
① | 發展分部 | 製造商選擇一個 Android 版本 (Android X)。在此示例中，“Android X”成為在初始開始生產 (SOP) 兩年前將在車輛中發貨的基礎。 |
| ② | 初次啟動 | 在 Android X 成為該產品中的第一個操作系統版本之前的幾個月，安全更新取自 Android 安全公告 (ASB) 以及製造商認為有價值的其他潛在來源。 y2 = Android 版本 X 的第二個安全公告，由製造商應用（向後移植）到 Android X。此更新隨產品一起提供，並且生產時鐘在 Android X.y2 的第 0 年開始計時。 在此示例中，製造商決定不發布更新的 Android X+1 年度版本。發布最新版本的原因包括添加新功能、解決新的安全漏洞和/或發布需要較新 Android 版本的 Google 或第三方服務。反對與最新版本一起發布的原因是車輛開發和發布過程缺乏集成、測試和驗證更改所需的時間，包括符合所有法規和認證要求。 |
| ③ | 完整的操作系統更新 | 在 SOP 之後，製造商發布 Android X+2 操作系統更新，這是在初始產品（Android X0）使用的版本之後的兩個 Android 版本。 ASB 安全更新可用於 API 級別（截至發貨日期），因此更新在 SOP 大約 1.25 年後以 X+2.y0 的形式發布。此操作系統更新可能與現場產品兼容，也可能不兼容。如果是，則可以製定計劃來更新部署的車輛。 除非有其他業務協議，否則是否進行完整操作系統更新的決定完全由製造商自行決定。 |
| ④ | 安全更新 | 在車輛的生產壽命兩年內，製造商修補了 Android X+2 操作系統。該決定基於製造商的風險評估。製造商選擇版本 X+2 的第三個 ASB 安全更新作為更新的基礎。接收安全更新的產品現在處於 (X+2.y3) OS + Android 安全補丁級別。 雖然製造商可以從任何單獨的 ASB 中選擇單獨的安全補丁程序，但他們必須修復公告中的所有必需問題才能使用與公告相關的 Android 安全補丁程序級別 (SPL)（例如，2017-02-05）。製造商有責任為受支持的產品執行反向移植和安全發布。 |
| ⑤ | 完整的操作系統更新 | 重複第 3 步（完整操作系統更新），第二次完整操作系統更新將產品升級到 Android X+4，車輛的生產壽命為三年。製造商現在正在平衡最新 Android 版本的新硬件要求與產品中的硬件，並且用戶可以從更新的 Android 操作系統中受益。製造商發布了沒有安全更新的更新，因此該產品現在處於 (X+4.y0) OS + Android 安全補丁級別。 在此示例中，由於硬件限制，X+4 是將為該產品提供的最後一個主要 Android 版本，儘管車輛的 6 年以上預期壽命仍需要安全支持。 |
| ⑥ | 安全更新 | 重複第 4 步（安全更新）。製造商的任務是從更高版本的 Android (X+6) 獲取 ASB 安全更新，並將部分或全部更新移植回 Android X+4。製造商有責任合併、集成和執行更新（或與第三方簽訂合同）。此外，製造商應注意，不再支持的 Android 版本中的安全問題將不會包含在 ASB 中。 |
| ⑦ | 安全更新 | 車輛生產生命週期八年後，自第 5 步中的最後一次操作系統更新（完整操作系統更新）以來的四個 Android 版本，以及自指定 Android X 以來的十年，策劃和向後移植安全補丁的負擔完全由製造商承擔API 級別公開發布三年以上的版本。 |
安全最佳實踐
為了使安全妥協更加困難，Google 建議並採用普遍接受的安全和軟件工程最佳實踐，如實施安全中所述。
安全指南
推薦的安全實踐包括：
- 使用最新版本的外部庫和開源組件。
- 不要在操作系統的發布版本中包含侵入式調試功能。
- 刪除未使用的功能（以減少不需要的攻擊面）。
- 使用最小權限原則和其他Android 應用程序開發最佳實踐。
軟件開髮指南
針對系統生命週期的安全軟件開發的推薦做法包括：
- 執行威脅建模以對資產、威脅和潛在緩解措施進行排名和識別。
- 執行架構/設計審查以確保安全和合理的設計。
- 執行定期代碼審查以盡快識別反模式和錯誤。
- 設計、實施和運行高代碼覆蓋率單元測試，包括：
- 功能測試（包括負面測試用例）
- 定期回歸測試（以確保已修復的錯誤不會重新出現）
- 模糊測試（作為單元測試套件的一部分）
- 使用靜態源代碼分析工具（scan-build、lint 等）來識別潛在問題。
- 使用動態源代碼分析工具，例如 AddressSanitizer、UndefinedBehaviorSanitizer 和 FORTIFY_SOURCE（用於原生組件）來識別和緩解系統開發過程中的潛在問題。
- 有軟件源代碼和發布配置/版本的管理策略。
- 具有用於生成和部署軟件補丁的補丁管理策略。
安全反向移植策略
Google 目前在API 級別公開發布後的三 (3) 年內為已發現和報告的安全漏洞的安全反向移植提供積極支持。主動支持包括以下內容：
- 接收和調查漏洞報告。
- 創建、測試和發布安全更新。
- 提供定期發布的安全更新和安全公告詳細信息。
- 根據既定指南執行嚴重性評估。
自 API 級別公開發布之日起三年後，Google 建議遵循以下準則：
- 使用第三方（例如 SoC 供應商或內核提供商）為 API 發布後三年以上的操作系統安全更新提供反向移植支持。
- 使用第三方使用公開提供的 ASB 執行代碼審查。雖然 ASB 識別當前支持版本的漏洞，但製造商可以使用提供的信息將新發布的更新與以前的版本進行比較。此數據可用於執行影響分析，並可能為 API 發布後三年以上的操作系統版本生成類似的補丁。
- 在適當的時候，將安全更新上傳到 Android 開源項目 (AOSP)。
- 製造商必須協調供應商特定代碼（例如，專有設備特定代碼）的安全更新處理。
- 製造商應加入 NDA Android 安全公告合作夥伴預覽通知組（需要簽署開發者 NDA 等法律協議）。公告應包括：
- 公告
- 按補丁級別匯總的問題，包括 CVE 和嚴重性
- 適當的漏洞詳細信息
附加參考
有關安全編碼和軟件開發實踐的說明，請參閱以下內容：
推薦的產品實踐
Google 鼓勵使用以下推薦做法。
一般發布指南
通常建議任何已連接的產品使用最新的操作系統版本啟動，製造商應在啟動產品之前嘗試使用最新的操作系統版本。雖然鎖定版本對於在測試和驗證之前提高穩定性是必要的，但製造商必須平衡從舊操作系統版本獲得的產品穩定性與具有較少已知安全漏洞和增強安全保護的新操作系統版本。
推薦的指南包括：
- 由於車輛開發過程固有的較長開發週期，製造商可能需要使用操作系統版本 n-2 或更早版本發布。
- 通過無線 (OTA) 活動，為每個已發布的 Android 操作系統版本保持與 Android 兼容性的一致性。
- 實施產品 Android Firmware-over-the-air (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將 CTS 版本從 Android 1.6 下載到最新版本。
向公眾發布的每個版本的 Android 軟件（出廠安裝和現場更新映像）都必須通過 CTS 結果證明 Android 兼容性。例如，如果設備運行 Android 7.1，則在創建和測試發布意圖構建映像時，應參考 CDD 7.1 和 CTS 7.1 的最新相應版本。強烈建議製造商儘早並經常使用 CTS 來識別和修復問題。
CTS 工作流程
CTS 工作流程涉及設置測試環境、運行測試、解釋結果和理解 CTS 源代碼。以下指南旨在幫助 CTS 用戶（例如，開發人員、製造商）有效且高效地使用 CTS。
- 經常運行測試。 CTS 被設計為集成到您的構建系統中的自動化工具。頻繁運行 CTS 可以幫助您在軟件降級或退化時儘早發現缺陷。
- 下載並檢查 CTS 源代碼。完整的 CTS 源代碼是任何人都可以下載和使用的開源軟件（下載的源代碼是完全可構建和可運行的）。當設備上的測試失敗時，檢查源代碼的相關部分可以幫助您找出原因。
- 獲取最新的 CTS 。新的 Android 版本可以通過錯誤修復、改進和新測試來更新 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，它在 AOSP 中發布安全更新，而不是針對特定設備（例如車輛）。
問：Google 如何處理 Android 中的安全問題？
答：Google 會不斷調查問題並開發潛在的修復程序，作為常規安全更新過程的一部分，Google 將這些修復程序提供給所有受支持的 API 級別。自 2015 年 8 月以來，Google 一直保持定期發佈公告和指向source.android.com更新鏈接的節奏； Google 還會在主要操作系統版本中發布安全更新。另請參閱安全反向端口策略。
問：如果製造商集成了 ASB 的所有 AOSP 補丁，但沒有集成同一公告中提到的 BSP 供應商的補丁，它是否仍然可以提高安全級別（例如，將相應的補丁應用於平台/構建） ？
答：要聲明 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 使用代碼更改來解決 AOSP 安全漏洞，該代碼更改允許組件保持完整功能並符合 CDD。如果製造商確定設備上不需要該組件或 CDD（或相關認證測試）未強制要求該組件，則製造商可以移除該組件以減少未來的服務需求並減少攻擊面。儘管製造商沒有使用提供的安全更新，但它確實確保了設備不會受到安全公告中記錄的 CVE 的攻擊。但是，在偏離推薦的安全更新時，製造商冒著錯誤地解決問題、引入新的安全漏洞或以其他方式減少最終構建的功能的風險。
雖然我們與所有 SoC 合作夥伴合作以確保 ASB 中的所有問題都存在修復程序，但我們建議製造商與他們的 SoC 供應商就設備的生命週期簽訂服務協議。 SoC 可能會提前停止為芯片組提供服務，因此在選擇設備芯片組之前建立協議是設備啟動過程的重要組成部分。
最後，如果無法直接獲取或獨立創建 ASB 中記錄的問題的修復程序，製造商可以維護之前的 Android SPL 並仍將新的可用修復程序添加到構建中。但是，這種做法最終會導致構建認證出現問題（因為 Android 會確保在認證設備上提供最新的安全補丁級別）。 Google 建議提前使用您的 SoC 以避免這種做法。
問：如果製造商確定 ASB 項目不適用於他們的產品，是否仍需要應用或修補該項目才能滿足其他 Google 要求或通過 CTS？
答：我們不需要為了聲明 Android 安全補丁級別 (SPL) 而安裝補丁；我們確實要求製造商證明他們的構建不會受到該問題的影響。
一個例子是製造商的系統中不存在正在修補的組件，或者從製造商的系統中刪除了一個組件以解決問題。在這種情況下，系統可能是合規的，而無需製造商提供補丁。
這與製造商希望僅修復關鍵補丁，而不採用其他會導致安全測試失敗的適用補丁的製造商有著根本的不同。在這種情況下，假定未滿足 SPL。