導入Rust讓Android記憶體漏洞降至兩成以下，還提升交付效率

Google的Android團隊公布2025年最新資安統計，指出Android平臺中屬於記憶體安全類型的漏洞占比，首次降到所有漏洞數量的兩成以下。團隊將關鍵因素歸結為近年在系統層大量導入Rust，且新寫程式碼優先改用記憶體安全語言，逐步壓低整體風險。

Android團隊強調，他們刻意把觀察焦點放在新增與仍在活躍開發的程式碼，因為歷史資料顯示，多數嚴重漏洞來自新變更。

Google在Android平臺把Rust當作C與C++的直接替代方案，引入作業系統層所需的低階控制與可預測性，同時利用語言本身的記憶體安全特性。從內部統計來看，新增加的Rust程式碼量已經與C++相當，Android平臺累積Rust程式碼約有500萬行，規模足以進行跨語言的品質與效率比較。

Android團隊估算，目前Rust程式碼的記憶體安全漏洞密度約為每百萬行0.2個，相較之下，歷年C與C++程式碼的密度大約落在每百萬行1,000個記憶體安全漏洞的等級，兩者相差約千倍。Rust仍可能出現記憶體安全問題，但Android團隊認為，關鍵不在於會不會有，而是出現的頻率與密度可降低的程度。

Android團隊分享了一個差點出現在正式版本的Rust記憶體安全問題，他們在CrabbyAVIF元件發現線性緩衝區溢位，在一般情況下可能形成無明顯症狀的記憶體破壞，但因Android預設採用Scudo強化配置器，會在特定配置的記憶體區塊周邊加入防護頁面，讓問題直接表現為可觀察的當機，才得以在測試階段被攔截。這個案例說明了Rust本身無法消除所有風險，同時展示語言層安全與記憶體配置器等多層防禦機制如何互相補強。

Android使用產業常見的DORA指標衡量軟體交付表現，從同樣規模的變更比較Rust與C++。團隊內部統計顯示，在Android第一方程式碼中，Rust變更在程式碼審查階段被要求修改的次數比C++少約兩成，待在審查流程中的時間也短約四分之一，更重要的是，中大型變更被迫回退的比例，Rust約只有C++的四分之一，也就是說Rust變更一旦部署，較少需要撤回重來。

即便導入記憶體安全語言，作業系統與硬體驅動開發仍不可避免要使用unsafe Rust或C、C++處理FFI與硬體操作。Android團隊坦言，不可能禁止unsafe，但可以集中在少數受控區域，並提供更完整的教育與審查。他們在自家Comprehensive Rust教材中新增unsafe專章，協助開發者理解soundness、未定義行為，以及如何撰寫安全註解與封裝unsafe區塊。從內部統計來看，大約只有4%程式碼落在unsafe區塊內，而整體漏洞密度仍遠低於C與C++的水準。