Android 安全性團隊的職責是管理 Android 平台中找到的安全漏洞，以及 Android 裝置隨附的許多核心 Android 應用程式。
Android 安全性團隊會透過內部研究找出安全漏洞，也會對第三方回報的錯誤做出回應。外部錯誤的來源很多，包括透過安全漏洞表單回報的問題、已發布和預先發布的學術研究、上游開放原始碼專案維護人員、裝置製造商合作夥伴的通知，以及網誌或社群媒體上公開揭露的問題。
回報安全性問題
不論是開發人員、Android 使用者或安全性研究人員，都可以透過安全漏洞表單將潛在的安全性問題告知 Android 安全性團隊。
標示為安全性問題的錯誤不會對外公開，但可能會在問題評估或解決後顯示。如果您預計提交修補程式或 Compatibility Test Suite (CTS) 測試來解決安全性問題，請在錯誤報告中提供相應附件。等到接獲回覆後，再將程式碼上傳到 Android 開放原始碼計畫中。
將錯誤分類
處理安全漏洞時，首先要做的是判別錯誤嚴重程度，並瞭解哪個 Android 元件受到影響。嚴重程度會決定問題的優先處理順序，而元件則用於判定應由誰修正錯誤、要通知哪些對象，以及如何為使用者部署修正內容。
環境類型
下表列出硬體和軟體安全環境的定義。環境可以按其一般所處理資料的機密程度來定義，也可按執行範圍定義，並非所有安全環境都適用於所有系統。下表將依特殊權限多寡，由低到高列出各種環境。
| 環境類型 | 類型定義 |
|---|---|
| 受限的環境 |
僅提供最少權限的受限執行環境。 例如，受信任的應用程式在沙箱環境中處理不受信任的資料。 |
| 沒有特殊權限的環境 |
適合沒有特殊權限的程式碼執行的典型環境。 舉例來說，Android 應用程式在具有 untrusted_app_all 屬性的 SELinux 網域中執行，就屬於這種情況。
|
| 具有特殊權限的環境 |
具有特殊權限的執行環境，可能可以使用進階權限、處理多個使用者 PII，及/或維護系統完整性。 舉例來說，Android 應用程式含有遭 SELinux untrusted_app 網域禁止的功能，或是具備 privileged|signature 權限，就屬於這種情況。
|
| OS 核心 |
功能：
|
| 受信任的硬體基礎 (THB) | 獨立的硬體元件，通常位於 SoC，可依據裝置核心用途提供重要功能 (例如行動網路基頻、DSP、GPU 和機器學習處理器)。 |
| 系統啟動載入程式鏈結 | 裝置啟動時，此元件可設定裝置，然後將控制權交給 Android 作業系統。 |
| 受信任的執行環境 (TEE) | 此元件經過設計，即使遭受惡意 OS 核心攻擊也能安全無虞。舉例來說，TrustZone 和管理程序 (例如 pKVM) 可以防止虛擬機器受到 OS 核心影響。 |
| 安全隔離區/安全元件 (SE) |
選用的硬體元件，旨在防止物理攻擊，避免受到裝置上所有其他組件的影響，如「Introduction to Secure Elements」(安全元件簡介) 所述。 包括部分 Android 裝置內建的 Titan M 晶片。 |
嚴重程度
一般來說，錯誤的嚴重程度能反映有心人士成功利用錯誤後，可能造成怎樣的潛在危害。判斷嚴重程度時，請以下列條件為基準。
| Rating | 漏洞遭到利用的後果 |
|---|---|
| 最高 |
|
| 高 |
|
| 中等 |
|
| 低 |
|
| 可忽略的安全性影響 (NSI) |
費率調節係數
安全漏洞的嚴重程度通常很容易辨識，但分級可能會因情況而有所改變。
| 原因 | 效果 |
|---|---|
| 需要在具有特殊權限的環境下執行，才能發動攻擊 (不適用於 TEE、SE 和 pKVM 這類管理程序) | 嚴重程度降低 1 級 |
| 因閱讀特定安全漏洞詳情，有效控制了問題的影響程度 | 嚴重程度降低 1 級 |
| 規避生物特徵辨識驗證。這類驗證方式必須直接從裝置擁有者身上取得生物特徵辨識資訊 | 嚴重程度降低 1 級 |
| 編譯器或平台設定緩解了原始碼中的安全漏洞 | 如果基本安全漏洞問題的嚴重程度為「中等」以上，則此處嚴重程度降為「中等」 |
| 需實際存取裝置內部，如果裝置已關機 (或開機後尚未解鎖)，則仍然可以存取 | 嚴重程度降低 1 級 |
| 在裝置開機且先前曾解鎖的情況下，需要實際存取裝置內部 | 嚴重程度降低 2 級 |
| 需要解鎖系統啟動載入程式鏈結，才能發動本機攻擊 | 不高於「低」 |
| 需要在裝置上啟用「開發人員模式」或任何常駐的開發人員模式設定 (且本身不是「開發人員模式」中的錯誤)，才能發動本機攻擊。 | 不高於「低」 |
| 沒有任何 SELinux 網域可在 Google 提供的 SEPolicy 下執行操作 | 可忽略的安全性影響 |
本機、鄰近與遠端
所謂遠端攻擊向量，是指攻擊者在利用錯誤時，可以不安裝應用程式或不實際存取裝置。這包括因瀏覽網頁、讀取電子郵件、接收簡訊或連上惡意網路而觸發的種種錯誤。
鄰近攻擊向量視為遠端攻擊向量。這包括只能由實際位於目標裝置附近的攻擊者利用的錯誤，例如需要傳送格式有誤的 Wi-Fi/藍牙封包的錯誤。我們將超寬頻 (UWB) 和 NFC 式的攻擊視為鄰近攻擊，因此也可說是遠端攻擊。
攻擊者必須先取得受害者的存取權，才能發動本機攻擊。在假設的僅限軟體範例中，這可能是透過受害者安裝的惡意應用程式，或是他們同意執行的免安裝應用程式。
已成功配對的裝置 (例如藍牙隨附裝置) 會視為本機。我們會區分已配對的裝置，以及參與配對流程的裝置。
- 會降低使用者識別配對裝置的能力 (即驗證) 的錯誤，會被視為近端錯誤，因此屬於遠端錯誤。
- 在配對流程中發生的錯誤，如果發生在使用者同意 (即授權) 之前，就會被視為近端錯誤，因此是屬於遠端錯誤。
- 在取得使用者同意聲明後發生的錯誤，即使最終配對失敗，也視為本機錯誤。
實體攻擊向量視為本機攻擊向量。這包括僅可由實際操作裝置的攻擊者發動的錯誤，例如螢幕鎖定中的錯誤，或是需要插入 USB 傳輸線的錯誤。由於裝置在插入 USB 時經常會解鎖，因此無論裝置是否需要解鎖，只要攻擊牽涉到 USB 連線，嚴重程度也就相同。
網路安全
Android 會假設所有網路都含有惡意內容，這些內容可能發動注入式攻擊或監視流量。雖然連結層的安全防護機制 (例如 Wi-Fi 加密) 可以保護裝置和所連存取點間的通訊，但這樣做並不會保護裝置與目標通訊伺服器間鏈結的其餘連結。
相比之下，HTTPS 通常會以端對端的方式保護整個通訊過程，做法是在來源位置加密資料，僅在資料抵達最終目的地時才解密及驗證資料。因此，如果漏洞會危及連結層的網路安全，嚴重程度分級就會低於 HTTPS/TLS 中的安全漏洞，因為單靠 Wi-Fi 加密並不足以支援網際網路上的多半通訊作業。
生物特徵辨識驗證
生物特徵辨識驗證這個領域很有挑戰性，即使是最頂尖的系統都可能被「近似比對」的手法欺騙 (請參閱「Android 開發人員網誌：Android 11 的螢幕鎖定和驗證強化項目」)。此領域的嚴重程度分級區分了兩種攻擊，旨在反映使用者實際面臨的風險。
第一類攻擊能以一般化的方式規避生物特徵辨識驗證，而不要求擁有者提供高品質的生物特徵辨識資料。舉例來說，假設攻擊者只要在指紋感應器上放一塊口香糖沾取殘餘指紋，就可以獲得存取裝置的權限，那麼他在任何易受影響的裝置上都可以輕鬆發動攻擊，即使完全不瞭解裝置擁有者也無妨。由於這類攻擊可一般化，且可能影響大量使用者，因此嚴重程度評定為滿級分 (舉例來說，如果攻擊者能規避螢幕鎖定，嚴重程度則屬於「高」)。
另一類攻擊通常涉及一種手段，也就是冒用裝置擁有者的身分 (假冒)。有時，這類生物特徵辨識資訊相對容易取得 (舉例來說，如果光靠某人在社群媒體上的個人資料相片，就足以騙過生物特徵辨識驗證機制，那麼對於規避生物特徵辨識的行為，嚴重程度會評定為滿級分)。不過，假如攻擊者需要直接向裝置擁有者取得生物特徵辨識資料 (例如臉部的紅外線掃描資訊)，這樣就會造成足夠程度的阻礙，從而限制了受攻擊影響的人數，因此修正後的嚴重程度會降低 1 級。
SYSTEM_ALERT_WINDOW 和 Tapjacking
如要瞭解有關 SYSTEM_ALERT_WINDOW 和 Tapjacking 的政策，請前往 BugHunter University 的「
沒有安全性影響的錯誤」頁面，閱讀「Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen」(非攸關安全畫面上的 Tapjacking/overlay SYSTEM_ALERT_WINDOW 安全漏洞) 一節。
Android Automotive OS 中的多使用者安全性
Android Automotive OS 採用不同於其他板型規格的多使用者安全性模型。每個 Android 使用者身分，都是由獨立的自然人使用。舉例來說，車主可以為借車的朋友指派臨時訪客使用者身分。為了因應這類用途，使用者在預設情況下即可存取使用車輛所需的各種必要元件，例如 Wi-Fi 和行動網路設定。
受影響的元件
要由哪個開發團隊負責修正錯誤，需視錯誤所在的元件而定。這可能是 Android 平台的核心元件、原始設備製造商 (OEM) 提供的核心驅動程式，或是 Pixel 裝置上預先載入的其中一款應用程式。
如果 Android 開放原始碼計畫 (AOSP) 程式碼中出現錯誤，Android 工程團隊會負責修正。假設出現嚴重程度「低」的錯誤、特定元件內的錯誤，或眾所周知的錯誤，可能會直接在公開發布的 AOSP 主要分支版本中修正；其餘錯誤則先在內部存放區中修正。
使用者如何接收更新，也會受到元件影響。如果是架構或核心中的錯誤，就必須用到無線更新 (OTA)，所有原始設備製造商 (OEM) 都需推送這個韌體更新。如果錯誤來自 Google Play 中發布的應用程式或程式庫 (例如 Gmail、Google Play 服務或 WebView)，則可能會由 Google Play 傳送更新給 Android 使用者。
通知合作夥伴
修正 Android 開放原始碼計畫的安全漏洞後，我們會利用 Android 安全性公告將問題詳情告知 Android 合作夥伴，並提供修補程式。具體有哪些向後移植的支援版本，會隨著每次 Android 新版本發布而變化。如需支援的裝置清單，請與您的裝置製造商聯絡。
將程式碼發布到 Android 開放原始碼計畫
如果 Android 開放原始碼計畫元件出現安全性錯誤，我們會先向使用者發布 OTA，然後再將相關修正程式推送至 Android 開放原始碼計畫。如果問題的嚴重程度低，修正程式可能會直接提交至 Android 開放原始碼計畫的主要分支版本，再透過 OTA 向裝置發布。
接收 Android 更新
Android 系統如有更新，通常會透過 OTA 更新套件的形式提供給裝置。這些更新可能來自生產裝置的原始設備製造商 (OEM) 或為裝置提供服務的電信業者。如過是 Google Pixel 裝置的更新，會由 Google Pixel 團隊在完成電信業者的技術驗收 (TA) 測試程序後提供。Google 也會發布 Pixel 原廠映像檔，供使用者側載至裝置。
更新 Google 服務
除了提供安全性錯誤的修補程式外，Android 安全性團隊也會審查安全性錯誤，判斷是否有其他保護使用者的方式。舉例來說，Google Play 會掃描所有應用程式，並移除任何嘗試利用安全性錯誤的應用程式。對於從 Google Play 外部安裝的應用程式，搭載 Google Play 服務的裝置也可能會使用「 驗證應用程式」功能，警告使用者注意可能有害的應用程式。
其他資源
Android 應用程式開發人員須知： https://developer.android.com
您可以在 Android 開放原始碼和開發人員網站上找到安全性資訊。建議參考以下網址：
報表
Android 安全性團隊有時會發布報告或白皮書。詳情請參閱「安全性報告」。