本指南說明 Google 建議的最佳做法，說明如何套用由 Android 相容性測試套件 (CTS) 評估的安全性修補程式。這項計畫適用於支援 Android 的 OEM 設備 (製造商)，這些設備的支援時間超過三年，例如車輛、電視、機上盒和家電。本指南不是針對終端使用者 (例如車輛車主) 編寫。
特別聲明和免責事項
本指南不會以法律或合約形式約束 Google 或其他製造商，也不打算成為一套規定。本指南是說明建議做法的輔助教材。
意見回饋
本指南並非完整指南，我們將另行修訂。請將意見回饋提交至 manufacturers-guide-android@googlegroups.com。
詞彙解釋
| 字詞 | 定義 |
|---|---|
| ACC | Android 相容性承諾。原名為 Android 反分散協議 (AFA)。 |
| Android 開放原始碼計劃 | 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 已成為最受歡迎的作業系統 (OS)，在 2016 年時，全球有 14 億部以上裝置採用 Android。截至 2017 年 3 月，這些裝置中約有 67% 使用 Android 5.0 (Lollipop) 以上版本 (最新數據請見 Android 資訊主頁)。雖然大多數裝置都是手機和平板電腦，但 Android 也逐漸應用在智慧手錶、電視和車用資訊娛樂 (IVI) 裝置上。
在 Google Play 商店中提供的 Android 應用程式數量已達 220 多萬個 (2016 年)。Android 應用程式開發作業由 Android 相容性計畫提供支援，該計畫透過 相容性定義說明文件 (CDD) 定義一組要求，並透過 相容性測試套件 (CTS) 提供測試工具。Android 相容性計畫可確保任何 Android 應用程式都能在任何支援應用程式所需功能的 Android 相容裝置上執行。
Google 會定期發布新的 OS 版本、OS 安全性更新，以及已發現的安全漏洞相關資訊。製造商應查看 Android 安全性公告，瞭解這些更新是否適用於 Android 作業系統支援的產品。如要查看 Android 安全性、相容性和建構系統的總覽，請參閱以下資源：
關於連網車輛 (標準長壽產品)
自 1920 年代推出 AM 收音機後，車輛就開始連線。從那時開始，隨著監管機構和汽車製造商轉向使用電子產品來簡化診斷和維修作業 (例如 OBD-II 通訊埠)、提升安全性 (例如胎壓偵測系統)，以及達成燃油經濟目標，外部實體和無線連線的數量開始增加。後續的連線技術浪潮推出了駕駛者便利功能，例如遙控無鑰匙進入系統、車載通訊系統，以及藍牙、Wi-Fi 和智慧型手機投影等進階資訊娛樂功能。目前，整合式感應器和連線功能 (例如 GPS) 可支援安全和半自動駕駛系統。
隨著車輛連線數量增加，潛在的車輛攻擊面積也會隨之增加。連線會帶來與消費性電子產品類似的網路安全疑慮。不過，雖然重新啟動、每日修補程式更新和不明行為是消費性電子產品的常態，但對於車輛等具備安全關鍵系統的產品而言，這些行為則不一致。
製造商必須採取主動措施，確保產品在現場持續維持安全性。簡而言之，製造商必須瞭解產品中已知的安全漏洞，並採取以風險為基礎的方法加以解決。
確保長期安全
連網車輛通常會有一或多個電子控制單元 (ECU)，其中包含多個軟體元件，例如作業系統、程式庫、公用程式等。製造商應追蹤這類元件，並透過主動分析找出已知的已發布漏洞，包括：
- 定期根據常見安全漏洞與資料外洩風險 (CVE) 資料庫評估產品。
- 收集產品相關安全漏洞的情報。
- 安全性測試。
- 積極分析 Android 安全性公告。
作業系統和安全性修補程式更新範例 (搭載 Android 的 IVI)：
圖 1. 車輛生命週期內的主要 OS 和安全性更新發布時程示例。
| # | 步驟 | 活動 |
|---|---|---|
|
① |
開發分支 | 製造商選取 Android 版本 (Android X)。在這個範例中，「Android X」會成為初始量產 (SOP) 前兩年內，在車輛中出貨的基礎。 |
| ② | 首次發布 | 在 Android X 成為產品中第一個出貨的 OS 版本前幾個月，安全性更新會從 Android 安全性公告 (ASB) 和製造商認為有價值的其他來源取得。y2 = Android X 版本的第二個安全性公告，由製造商套用 (回溯) 至 Android X。這項更新會隨產品出貨，而生產時鐘會在 Android X.y2 的零年開始運作。 在這個範例中，製造商決定不出貨較新的 Android X+1 年度版本。發布最新版本的原因包括新增功能、解決新的安全漏洞，以及/或發布需要較新 Android 版本的 Google 或第三方服務。不建議 使用最新版本的原因在於，車輛開發和推出程序需要整合、測試及驗證變更，包括符合所有法規和認證規定，因此不夠時間進行這些作業。 |
| ③ | 完整 OS 更新 | 在 SOP 後，製造商會發布 Android X+2 OS 更新，也就是在初始產品 (Android X0) 使用的版本後兩個 Android 版本。ASB 安全性更新適用於 API 級別 (自出貨日期起算)，因此更新內容會在 SOP 後約 1.25 年推出，版本號碼為 X+2.y0。這項 OS 更新可能與已部署的產品相容，也可能不相容。如果是，您可以建立企劃書來更新已部署的車輛。 除非另有商業協議，否則是否要進行完整的作業系統更新，完全由製造商自行決定。 |
| ④ | 安全性更新 | 在車輛生產壽命的兩年後，製造商會為 Android X+2 OS 進行修補。這項決定是根據製造商的風險評估做出。製造商選擇第 3 版 ASB 安全性更新，做為版本 X+2 的更新基礎。接收安全性更新的產品目前已達到 (X+2.y3) OS + Android 安全性修補程式等級。 雖然製造商可以從任何個別 ASB 中選取個別安全性修補程式，但必須修正公告中的所有必要問題，才能使用與該公告相關的 Android 安全性修補程式等級 (例如 2017-02-05)。製造商有責任為支援的產品執行回移植和安全性發布作業。 |
| ⑤ | 完整 OS 更新 | 重複執行步驟 3 (完整的作業系統更新)，第二次完整的作業系統更新會將產品升級至 Android X+4，這代表車輛的生產壽命已達三年。製造商現在會根據產品中的硬體，平衡最新 Android 版本的新硬體需求，使用者也能從更新的 Android 作業系統中獲得好處。製造商發布了沒有安全性更新的更新，因此產品目前處於 (X+4.y0) OS + Android 安全性修補程式等級。 在這個範例中，由於硬體限制，X+4 是此產品將提供的最後一個主要版本的 Android，但車輛的預期使用壽命為 6 年以上，因此仍需要安全性支援。 |
| ⑥ | 安全性更新 | 重複步驟 4 (安全性更新)。製造商必須從較新版本的 Android (X+6) 取得 ASB 安全性更新，並將部分或全部更新移植回 Android X+4。合併、整合及執行更新 (或與第三方簽訂合約) 是製造商的責任。此外，製造商應注意，ASB 不涵蓋已不再支援的 Android 版本中的安全性問題。 |
| ⑦ | 安全性更新 | 車輛的生產週期為八年，自步驟 5 的最後一次作業系統更新 (完整作業系統更新) 以來的 Android 版本為四個，而自 Android X 指定以來的時間為十年，因此，對於 API 級別公開發布後三年以上的版本，製造商必須負擔整理和回移植安全性修補程式的負擔。 |
安全性最佳做法
為了讓安全性妥協難以達成，Google 建議並採用了一般公認的安全性和軟體工程最佳做法，如「實施安全性」一文所述。
安全性指南
安全性建議做法包括：
- 使用最新版本的外部程式庫和開放原始碼元件。
- 請勿在 OS 的發布版本中加入侵入式偵錯功能。
- 移除未使用的功能 (以減少不必要的攻擊面)。
- 請遵循最低權限原則和其他 Android 應用程式開發最佳做法。
軟體開發指南
系統生命週期安全軟體開發的建議做法包括：
- 執行威脅模型，找出資產、威脅和潛在的緩解措施，並對這些項目進行排名。
- 進行架構/設計審查，確保設計安全可靠。
- 定期進行程式碼審查，盡快找出反面模式和錯誤。
- 設計、實作及執行高程式碼涵蓋率單元測試，包括：
- 功能測試 (包括負面測試案例)
- 定期進行迴歸測試 (確保已修正的錯誤不會再次出現)
- 模糊測試 (做為單元測試套件的一部分)
- 使用靜態原始碼分析工具 (掃描建構、Linter 等) 找出潛在問題。
- 使用動態原始碼分析工具 (例如 AddressSanitizer、UndefinedBehaviorSanitizer 和 FORTIFY_SOURCE (適用於原生元件))，在系統開發期間找出並減輕潛在問題。
- 針對軟體原始碼和版本發布設定，制定管理策略。
- 制定修補程式管理策略，以便產生及部署軟體修補程式。
安全性回溯政策
Google 目前針對發現和回報的安全性漏洞，提供API 級別公開發布後三 (3) 年的積極支援。積極支援包括以下內容：
- 接收並調查安全漏洞報告。
- 建立、測試及發布安全性更新。
- 定期發布安全性更新和安全性公告詳細資料。
- 依據既定指南進行嚴重性評估。
自 API 級別公開發布日期起算三年後，Google 建議遵循下列規範：
- 使用第三方 (例如 SoC 供應商或核心供應商) 提供回溯支援，以便針對 API 發布後三年以上的作業系統安全性更新提供支援。
- 使用第三方工具，透過公開提供的 ASB 執行程式碼審查。雖然 ASB 可找出目前支援版本的安全漏洞，但製造商可以使用提供的資訊，將新發布的更新版本與先前版本進行比較。這項資料可用於執行影響分析，並為 API 發布後三年以上的 OS 版本產生類似的修補程式。
- 視情況將安全性更新上傳至 Android 開放原始碼計畫 (AOSP)。
- 製造商必須協調處理供應商專屬程式碼 (例如專屬裝置程式碼) 的安全性更新。
- 製造商應加入 NDA Android 安全性公告合作夥伴預覽通知群組 (需要簽署法律協議，例如開發人員 NDA)。公告應包含：
- 公告事項
- 依修補程式等級劃分的問題摘要，包括 CVE 和嚴重程度
- 安全漏洞詳情 (如有)
其他參考資料
如需安全程式碼編寫和軟體開發作業的操作說明，請參閱以下內容：
產品最佳做法
Google 鼓勵您採用下列建議做法。
一般發布指南
一般來說，我們建議所有連網產品都採用最新的 OS 版本推出，而製造商應在推出產品前，嘗試使用最新的 OS 版本。雖然鎖定版本是測試和驗證前提升穩定性的必要做法，但製造商必須在舊版作業系統和新版作業系統之間取得平衡，因為新版作業系統的已知安全漏洞較少，且安全防護功能更完善。
建議的規範包括：
- 由於車輛開發程序本身就需要較長的開發前置時間，因此製造商可能需要使用 n-2 以下版本的作業系統推出產品。
- 透過無線更新 (OTA) 活動，確保每個已發布的 Android 作業系統版本都符合 Android 相容性。
- 實作支援 Android 無線韌體更新 (FOTA) 的產品，以便快速提供對消費者友善的更新。應採用安全性最佳做法 (例如程式碼簽署和產品與 IT 後端之間的 TLS 連線) 執行 FOTA。
- 提交您獨立發現的 Android 安全漏洞，給 Android 安全團隊。
注意：Google 已在 Android 安全性公告中考慮裝置類型或特定產業的通知。不過，Google 不瞭解特定裝置 (車輛、電視、穿戴式裝置、手機等) 的核心、驅動程式或晶片組，Google 無法確定任何特定安全性問題與裝置類型之間的關聯。
產品生命週期指南
製造商應盡力使用最新的 OS 版本或安全性更新，以便在產品週期改善期間使用當前版本。更新作業可在定期產品更新期間執行，也可以用於解決品質和/或其他問題的修補程式。建議做法包括：
- 制定計畫，處理驅動程式、核心和通訊協定更新。
- 使用適合業界的方法，為已部署的車輛提供更新。
相容性定義說明文件 (CDD)
相容性定義說明文件 (CDD) 說明裝置必須符合哪些條件，才能視為 Android 相容裝置。CDD 是公開的，所有人都可以使用；您可以前往 source.android.com 下載 CDD 版本，從 Android 1.6 到最新版本皆可。
如要讓產品符合這些規定，請按照下列基本步驟操作：
- 合作夥伴與 Google 簽署 Android 相容性承諾 (ACC)。並指派技術解決方案顧問 (TSC) 擔任導覽員。
- 合作夥伴完成產品 Android OS 版本的 CDD 審查。
- 合作夥伴執行並提交 CTS 結果 (如下所述)，直到結果符合 Android 相容性要求為止。
Compatibility Test Suite (CTS)
Compatibility Test Suite (CTS) 測試工具可驗證產品實作是否與 Android 相容，以及是否包含最新的安全性修補程式。CTS 是公開的開放原始碼，可供所有人使用；您可以從 source.android.com 下載 Android 1.6 到最新版本的 CTS 版本。
每個向大眾發布的 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，而是在 Android 開放原始碼計畫中發布安全性更新，而非針對特定裝置 (例如車輛) 發布。
問：Google 如何處理 Android 的安全性問題？
答：Google 會持續調查問題並開發可能的修正方式，並在定期安全性更新程序中提供給所有支援的 API 級別。自 2015 年 8 月起，Google 已定期發布 source.android.com 的電子報和更新連結；此外，Google 也會在主要作業系統版本中發布安全性更新。另請參閱安全性回溯移植政策。
問：如果製造商整合了 ASB 的所有 AOSP 修補程式，但未整合同一份公告中提到的 BSP 供應商修補程式，是否仍可提高安全性等級 (例如，將對應的修補程式套用至平台/版本)？
答：如要宣告 Android 安全性修補程式等級 (SPL)，製造商必須解決 Android 安全性公告 (包括先前的公告) 中發布的所有必要問題，並對應至特定 Android SPL。舉例來說，如果製造商使用 2017 年 3 月安全性公告 (2017-03-01 SPL)，就必須解決該公告和所有先前更新中記錄的所有必要問題，包括所有先前 Android 安全性公告的裝置專屬更新，以及與 2017-02-05 SPL 相關的裝置專屬更新。
問：如果製造商不同意 BSP 供應商提供的安全性更新，或是供應商未提供 ASB 規定的安全性更新，會發生什麼情況？
答：ASB 會說明安全漏洞 (由 CVE 清單列舉)，並通常提供相符的安全性測試。目的是確保裝置無法再重現所列漏洞，且裝置能夠通過相關安全性測試。因此，問題並非是採用 Google 或第三方供應商提供的安全性更新，而是製造商證明裝置不會受到 ASB 中 CVE 清單的影響。製造商可以自由使用提供的安全性更新，如果他們有更適合其裝置的變更，也可以改用該變更。
舉例來說，假設 Google 使用程式碼變更來解決 Android 開放原始碼計畫的安全漏洞，讓元件能夠維持完整功能並符合 CDD。如果製造商判斷裝置不需要該元件，或該元件並非 CDD (或相關認證測試) 規定的必要元件，則製造商可以移除該元件，以減少日後的維修需求，並減少攻擊面。雖然製造商未使用提供的安全性更新，但確保裝置不會受到安全性公告中記錄的 CVE 影響。不過，如果製造商偏離建議的安全性更新，就可能會錯誤處理問題、引入新的安全漏洞，或降低最終版本的功能。
雖然我們會與所有 SoC 合作夥伴合作，確保 ASB 中的所有問題都有修正程式，但我們建議製造商與 SoC 供應商簽訂服務協議，以便在裝置的整個生命週期中提供服務。SoC 可能會提早停止為某個晶片組提供服務，因此在選擇裝置晶片組之前建立協議，是裝置推出程序的重要環節。
最後，如果無法直接取得 ASB 中記錄的問題修正項目，或無法自行建立修正項目，製造商可以保留先前的 Android SPL，並在版本中新增可用的修正項目。不過，這種做法最終會導致版本認證問題 (因為 Android 會確保已認證裝置可使用最新的安全性修補程式等級)。Google 建議您事先與 SoC 合作，避免採用這種做法。
問：如果製造商判定某項 ASB 項目不適用於自家產品，是否仍需套用或修補該項目，才能符合其他 Google 規定或通過 CTS？
答：我們並未要求必須採用修補程式，才能宣告 Android 安全性修補程式等級 (SPL)；但我們確實要求製造商證明其版本不易受到問題影響。
舉例來說，如果要修補的元件不在製造商系統中，或是製造商系統中已移除元件來解決問題，在這種情況下，系統可能符合規定，而不需要製造商安裝修補程式。
這與製造商只想修正重大修補程式的做法截然不同，例如，製造商不採用其他適用的修補程式，導致安全性測試失敗。在這種情況下，系統會假設未達到 SPL。