2025年に更新されたAndroidのデータによると、メモリー安全性脆弱性は初めて全脆弱性の20%未満に減少した。これは、プラットフォームの新規部分および活発に開発されている部分でRustの利用が拡大するのと同時に起きている。2025年11月12日にGoogle Security Blogで公開された分析によれば、CおよびC++からRustへの移行の効果はセキュリティーリスクの低減にとどまらず、コードレビューの迅速化と変更の安定性向上にも及んでいる。
このデータは、Googleが直接開発するAndroidコードと、第三者が管理するオープンソースコードの双方における変更を対象とし、C、C++、Java、Kotlin、Rustを含んでいる。分析は2025年末の数か月前に公開されたため、Googleは、標準的な90日間の修正期間により結果は最終的な数値に非常に近く、必要に応じて修正を前倒しできると説明した。
より高い安全性とより迅速な提供
Googleは、低レベルプログラミングにおいてCおよびC++の直接的な代替としてRustをAndroidに導入した。これにより、同程度の制御性と予測可能性を維持しながら、メモリー安全性に関連するリスクの多くを低減している。分析によると、新規Rustコードの量は急増する一方、新規C++コードは緩やかかつ継続的に減少している。その結果、最近追加されたRustの量はC++の量に近づき、両開発経路をより信頼性高く比較できるようになった。
Googleは、生産性と安定性の両面を測定するためDORAフレームワークを使用した。言語間の比較の難しさを抑えるため、規模が近い変更と、Androidプラットフォームに携わる類似した開発者グループに焦点を当て、Rustの採用拡大に伴う時系列の傾向も追跡した。
同程度の規模のRust変更は、C++の同等の変更よりレビュー回数が約20%少ない。また、現在ではコードレビューに要する時間も約25%短い。Googleは断定ではなく推測として、2023年から2024年にかけての顕著な改善は、AndroidチームがRustに習熟したことによるものだとしている。
安定性の面では、中規模および大規模のRust変更は、C++変更と比べてリバート率が約4分の1となっている。Googleは、リバートの減少は変更の品質を反映するだけでなく、生産性も高めると強調している。リバートは、再作業、追加レビュー、再ビルド、インシデント後の報告、他チームの業務停止につながる可能性があるためだ。
システムサービスとライブラリーを越えて広がるRust
Googleによると、Androidのシステムサービスとライブラリーを構築するためのRustサポートは成熟した。そのため、エコシステムの他の層へ利用を拡大している。
- カーネル：Android向けLinux 6.12カーネルは、GoogleにとってRustサポートを有効にした初のカーネルであり、初の本番用Rustドライバーも含んでいる。GoogleはArmおよびCollaboraと、カーネルモードで動作するGPU用ドライバーについて引き続き協力している。
- ファームウェア：Googleは、高い権限、性能上の制約、一部の保護手段の制限により、ファームウェアは高リスクで保護が難しいと考えている。同社は数年前からファームウェアでRustを使用し、コミュニティー向けにトレーニング教材とコードを提供している。特に、ArmとのRusted Firmware-Aにおける協力に注力している。
- Googleのアプリケーション：Bluetoothを介して近隣のデバイスを安全かつプライベートに検出するために使用されるNearby Presenceプロトコルは、Google Play Services内でRustにより動作している。また、RCSを介した安全なメッセージング用のMLSプロトコルは、将来のリリースでGoogle Messagesアプリに組み込まれる予定だ。
- Chromium：PNGおよびJSONのパーサーとウェブフォントは、Rustで記述されたメモリー安全な実装に置き換えられた。これにより、Chromiumのエンジニアは、Rule of 2に従いながらウェブから届くデータを扱いやすくなった。
ユーザーに届きかけた脆弱性
Rustの利点に焦点を当てる一方で、GoogleはAndroidにおけるRustベースの初のメモリー安全性脆弱性の記録に近づいた事例を紹介している。CrabbyAVIFでバッファー容量の線形オーバーフローが一般公開版に到達する前に発見され、修正にはCVE-2025-48530の識別子が付与された。これにより、高い優先度を付け、リリースチャネルを通じた到達状況を追跡できるようにした。
分析によると、Scudo Hardened Allocatorメモリーアロケーターは、二次割り当てを囲むガードページのおかげで、脆弱性の悪用を確実に不可能にした。また、Scudoはオーバーフローをメモリーの無言の破損から明確なクラッシュへと変え、問題の発見に役立った。一方、この事案は障害報告システムの不備も明らかにした。クラッシュがオーバーフローによるものだと明確に示されなかったため、トリアージと対応が遅れた。Googleによると、この不備は修正され、現在のシステムはScudoのガードページへのオーバーフローが発生した際に明確なシグナルを提供する。
unsafeが存在するにもかかわらず、なぜRustが重要なのか
Googleは、C、C++、Rustのいずれであっても、安全でないコードを禁止することは、オペレーティングシステム開発における現実的な解決策ではないと考えている。APIやハードウェアとの連携を扱う必要があるためだ。そのため、同社はComprehensive Rustトレーニング内で安全でないコードに関する上級モジュールを開発し、開発者に対して、そのコードの安全性と未定義動作を評価する方法、安全性に関するコメントを使用する方法、安全でない部分を安全な抽象化の中にカプセル化する方法を教えている。
Androidプラットフォームにおける約500万行のRustと、リリース前に対処された潜在的な事例が1件存在することに基づき、GoogleはRustのメモリー安全性脆弱性密度を100万行当たり約0.2件と推定している。これを、CおよびC++における過去の密度である100万行当たり約1,000件と比較すると、同社の推定では1,000倍を超える低下となる。また、コードの約4%がunsafe{}ブロック内に記述されていると指摘しているが、Rustの安全でないコードの各行がCやC++と同じリスクにさらされると仮定することは、リスクを過大評価すると述べている。Rustのチェックの大部分が継続して適用され、安全でないコードをカプセル化でき、追加の監査を受けるためだ。
Googleは、Rustの採用によって、セキュリティーの向上には性能、手順、機能リリースの速度における追加コストが伴うという従来の構図が変わると結論付けている。多層防御の一部としてC、C++、ソフトウェアおよびハードウェアの保護機構が引き続き重要である一方、同社はRustへの移行が、まず急いで後から結果に対処するのではなく、より安全で効率的な道筋を同時に提供すると考えている。