長期的な Android セキュリティのメーカーガイド

このガイドでは、Android 互換性テストスイート（CTS）で評価されたセキュリティパッチを適用するための、Google が推奨するベストプラクティスについて説明します。このガイドは、3 年以上サポートされる Android 互換 OEM デバイスのメーカー（以下「メーカー」）を対象としています。デバイスの種類には、車両、テレビ、セットトップボックス、家電製品などがあります。このガイドはエンドユーザー（車両の所有者など）を対象としていません。

確認と免責事項

このガイドは、Google または他のメーカーを法的にまたは契約上拘束するものではなく、一連の要件を構成することを意図したものでもありません。このガイドは、推奨される実装を紹介するための補足的なリファレンスです。

フィードバック

このガイドは網羅的なものではなく、改訂版が追加される予定です。フィードバックがある場合は、manufacturers-guide-android@googlegroups.com までお送りください。

用語集

用語	定義
ACC	Android 互換性のコミットメント。旧称 Android 断片化防止契約（AFA）。
AOSP	Android オープンソースプロジェクト
ASB	Android のセキュリティに関する公開情報
BSP	ボードサポートパッケージ
CDD	互換性定義ドキュメント
CTS	互換性テストスイート
FOTA	無線ファームウェア
GPS	グローバルポジショニングシステム
MISRA	自動車産業ソフトウェア信頼性協会
NIST	国立標準技術研究所
ODB	オンボード診断（OBD-II は機能性と標準化の両面で OBD-I を改良したものです）
OEM	相手先ブランド製品製造企業
OS	オペレーティングシステム
SEI	ソフトウェア工学研究所
SOC	システムオンチップ
SOP	量産開始
SPL	セキュリティパッチレベル
TPMS	タイヤ圧監視システム

Android OS について

Android は、さまざまな種類のデバイスおよびフォームファクタ向けに設計された、Linux ベースのオープンソースの完全なソフトウェアスタックです。2008 年の最初のリリース以来、Android は最も人気のあるオペレーティングシステム（以下「OS」）となり、世界中で 1 億 4,000 万台以上のデバイスに搭載されています（2016 年のデータ）。2017 年 3 月の時点で、これらのデバイスの約 67% は Android 5.0（Lollipop）以降を採用しています（最新の数値については Android ダッシュボードをご覧ください）。こうしたデバイスの大部分は携帯電話とタブレットですが、スマートウォッチ、テレビ、車載インフォテインメント（IVI）デバイスでも Android の使用が増加しています。

Google Play ストアで公開されている Android アプリの数は、2016 年には 220 万以上に達しました。Android アプリの開発は、互換性定義ドキュメント（CDD）を通じて一連の要件を定義し、互換性テストスイート（CTS）を通じてテストツールを提供する Android 互換性プログラムによって支えられています。Android 互換性プログラムは、あらゆる Android アプリが、アプリに必要な機能をサポートするあらゆる Android 互換デバイスで実行できることを保証するものです。

Google は、新しい OS バージョン、OS セキュリティアップデート、検出された脆弱性に関する情報を定期的に発信しています。メーカーは定期的に Android のセキュリティに関する公開情報を確認して、Android OS でサポートされている製品のこうしたアップデートの適用性を理解する必要があります。Android のセキュリティ、互換性、ビルドシステムについて詳しくは、以下をご覧ください。

接続された車両（標準化された長期運用型製品）について

1920 年代に AM ラジオが導入されたことに伴い、車両の接続が実現しました。それ以来、外部機器との物理的な接続やワイヤレス接続の数が増加し始めました。規制当局や自動車メーカーが、診断とメンテナンスの簡素化（たとえば OBD-II ポートの使用による）や安全性の強化（たとえば TPMS の使用による）を図り、燃費目標を達成するために電子機器に目を向けるようになった背景があります。その後の接続性能の改善により、リモートキーレスエントリ、テレマティックスシステム、さらに Bluetooth、Wi-Fi、スマートフォン投影のような高度なインフォテインメント機能など、ドライバーにとって便利なさまざまな機能が導入されました。現在、統合センサーと接続機能（GPS など）は安全性をさらに向上させ、半自律運転をサポートしています。

車両接続の数が増加すると、車両の潜在的な攻撃対象領域も増加します。家電製品と同様に、こうした接続により車両はあらゆるサイバーセキュリティ問題にさらされます。ただし、家電製品の一般的な問題は、多くの場合、再起動、日々のパッチアップデート、原因不明の動作ですが、安全性が重要であるシステムを搭載した製品（車両など）では状況が異なります。

メーカーは、使用中の製品の継続的な安全性を確保するための対策を積極的に講じる必要があります。つまり、メーカーは製品の既知のセキュリティの脆弱性を認識し、これらの問題をリスクベースのアプローチで解決する必要があります。

長期的な安全性の確保

接続された車両には、OS、ライブラリ、ユーティリティなどのさまざまなソフトウェアコンポーネントを含む 1 つ以上の電子制御ユニット（ECU）が搭載されています。メーカーはこのようなコンポーネントを追跡し、既知の公開された脆弱性を次のように積極的に分析および特定する必要があります。

一般的な脆弱性や漏洩（CVE）データベースに基づいて製品を定期的に評価する。
製品に関連するセキュリティの脆弱性に関する情報を収集する。
セキュリティテスト
Android のセキュリティに関する公開情報を積極的に分析する。

OS とセキュリティパッチアップデートの例（IVI が Android を実行している状態）:

図 1. 車両のライフサイクル中の主要な OS とセキュリティアップデートがリリースされるときの例

#	ステップ	アクティビティ
①	開発ブランチ	メーカーは Android のバージョン（Android X）を選択します。この例では、メーカーは、量産開始（SOP）の 2 年前に車両に搭載する基本システムとして「AndroidX」を選択しました。
②	初回リリース	Android X（最初の OS バージョン）を製品に搭載して発売する数か月前に、メーカーは、セキュリティアップデートを Android のセキュリティに関する公開情報（ASB）から、また場合によってはメーカーが信頼できるとみなした他のソースから入手しました。y2 とは Android X バージョンの 2 番目のセキュリティ公開情報バージョンであり、メーカーによって（バックポートされて）AndroidX に適用されます。このアップデートは製品に適用され、AndroidX.y2 を搭載した製品は 0 年以内に生産が開始されます。この例では、メーカーは最新の Android X+1 年間リリースを適用しないと決定しました。最新リリースを適用する理由としては、このリリースに新しい機能が追加されること、新しいセキュリティの脆弱性に対処すること、Google またはサードパーティのサービスが Android の新しいバージョンを必要とすることが挙げられます。最新リリースを適用しない理由としては、車両の開発やリリースプロセスの所定の期間内に、統合、テスト、変更の検証（すべての規制および認証要件への準拠を含む）を行うための時間がないことが挙げられます。
③	完全な OS アップデート	SOP の後、メーカーは自社の車両で Android X+2 OS アップデートをリリースしました。これは、最初の製品で使用された Android リリース（Android X0）の 2 番目のアップデートです。ASB セキュリティアップデートは（リリース日から）API レベルで発生したので、アップデートされたバージョン X+2.y0 は、メーカーの SOP から約 1.25 年後にリリースされました。この OS アップデートは、使用されている製品と互換性があるとは限りません。互換性がある場合は、販売された車両をアップデートする計画を立てることができます。他のビジネス契約が別途締結されていない限り、完全な OS アップデートを完全に実行するかどうかは、メーカーの裁量に委ねられています。
④	セキュリティアップデート	メーカーは、車両の製造から 2 年以内に Android X+2 OS にパッチを適用しました。この決定は、メーカーのリスク評価に基づいています。メーカーは、バージョン X+2 の 3 番目の ASB セキュリティアップデートをアップデートの基礎として選択しました。セキュリティアップデートを受け取った製品は、（X+2.y3）OS + Android セキュリティパッチレベルになりました。メーカーは任意の ASB から 1 つのセキュリティパッチを選択できますが、その公開情報（たとえば 2017 年 2 月 5 日リリース）に関連付けられた Android セキュリティパッチレベル（SPL）を使用する前に、その公開情報で必要となるすべての問題を修正する必要があります。メーカーには、サポートされている製品のバックポートとセキュリティリリースを行う責任があります。
⑤	完全な OS アップデート	ステップ 3（完全な OS アップデート）を繰り返します。車両の製造から 3 年以内の 2 回目の完全な OS アップデートにより、製品が Android X+4 にアップグレードされます。メーカーはここで、最新の Android バージョンの新しいハードウェア要件を自社製品のハードウェアと比較し、Android OS をアップデートすることで得られるユーザーのメリットを測定します。メーカーはシステムアップデートをリリースしていますが、それにセキュリティアップデートは含まれていないため、その製品は現在（X+4.y0）OS + Android セキュリティパッチレベルになっています。この例では、ハードウェアの制限により、X+4 がこの製品に提供される最後のメジャー Android システムバージョンになりましたが、この製品にはライフサイクルにおいて 6 年以上のセキュリティサポートが必要であると予想されます。
⑥	セキュリティアップデート	ステップ 4（セキュリティアップデート）を繰り返します。メーカーの任務は、新しいバージョンの Android（X+6）の ASB セキュリティアップデートを取得し、アップデートの一部またはすべてを Android X+4 に移植することです。メーカーは、アップデートのマージ、統合、実施（またはサードパーティとの連携）に対する責任を負います。メーカーはまた、Android バージョンでサポートされなくなったセキュリティの問題が ASB の対象とならないことにも注意する必要があります。
⑦	セキュリティアップデート	車両の生産ライフサイクルの 8 年目に、ステップ 5 の最後の OS アップデート（完全な OS アップデート）以降、さらに 4 つの Android バージョンをリリースしました。Android X が指定されてから 10 年目に、公開リリースから 3 年後の API レベルを超えるバージョンのセキュリティパッチを選択してバックポートする責任は、すべてメーカーが負います。

セキュリティに関するベストプラクティス

セキュリティ侵害をより難しくするため、Google は、セキュリティの実装で説明しているように、一般的に受け入れられているセキュリティとソフトウェアエンジニアリングのベストプラクティスの使用を推奨し、それらを採用しています。

セキュリティガイドライン

セキュリティに関して推奨される実装は次のとおりです。

最新バージョンの外部ライブラリとオープンソースコンポーネントを使用する。
OS のリリースバージョンに妨害的なデバッグ機能を追加しない。
使用されていない機能を削除する（不要な攻撃対象領域を減らすため）。
最小権限の原則とその他の Android アプリ開発のベストプラクティスを使用する。

ソフトウェア開発ガイドライン

システムのライフサイクルにおいて、安全なソフトウェア開発を行うために次の実装が推奨されます。

脅威モデリングを実行して、資産、脅威、潜在的な緩和策をランク付けして特定する。
アーキテクチャや設計に関するレビューを行い、設計の安全性と安定性を確保する。
コードを定期的に見直し、アンチパターンとバグを可能な限り迅速に特定する。
以下のテストを含む、コードカバレッジの高い単体テストを設計、実装、および実行します。
- 機能テスト（ネガティブテストケースを含む）
- 定期的な回帰テスト（修正されたバグが再発しないことを確認するため）
- ファズテスト（単体テストスイートの一部として）
静的ソースコード分析ツール（scan-build、lint など）を使用して、潜在的な問題を特定する。
AddressSanitizer、UndefinedBehaviorSanitizer、FORTIFY_SOURCE（ネイティブコンポーネント用）などの動的ソースコード分析ツールを使用して、システム開発中に発生する可能性のある問題を特定し、軽減する。
ソフトウェアソースコードを開発し、構成とバージョンの管理方針を作成する。
ソフトウェアパッチの生成とデプロイのためのパッチ管理方針を作成する。

セキュリティバックポートポリシー

現在 Google は、API レベルの公開リリースから 3 年以内にセキュリティ脆弱性が発見されて報告された場合、セキュリティバックポートのサポートを積極的に提供しています。積極的なサポートには、次のものが含まれます。

脆弱性レポートを受信して調査する。
セキュリティアップデートを作成、テスト、リリースする。
セキュリティアップデートやセキュリティ情報の詳細を定期的にリリースする。
所定のガイドラインに沿って重大度評価を実施する。

API レベルの公開リリース日から 3 年が経過したら、次のガイドラインに従うことをおすすめします。

API リースから 3 年以上経過した OS セキュリティアップデートについては、バックポートのサポートにサードパーティ（SoC ベンダーやカーネルプロバイダなど）を使用してください。
一般公開で提供された ASB を使用して、サードパーティのサポートでコードレビューを行います。ASB は現在サポートされているバージョンの脆弱性を識別できますが、メーカーは提供された情報を使用して、新しくリリースされたアップデートを以前のバージョンと比較できます。このデータは、インパクト分析の実施に使用でき、API がリリースされてから 3 年以上経過した OS バージョンの同様のパッチを生成するために使用できます。
必要に応じて、セキュリティアップデートを Android オープンソースプロジェクト（AOSP）にアップロードします。
メーカーは、ベンダー固有のコード（独自のデバイスのコードなど）に対するセキュリティアップデートの処理を調整する必要があります。
メーカーは、NDA の Android のセキュリティに関する公開情報パートナープレビュー通知グループに参加する必要があります（デベロッパー NDA などの法的契約に署名する必要があります）。公開情報には次のものを含める必要があります。
- お知らせ
- CVE や重大度など、パッチレベルごとに要約された問題
- 脆弱性の詳細（該当する場合）

その他の関連情報

安全なコーディングとソフトウェア開発を実施する手順については、以下をご覧ください。

推奨される製品の実装

以下の実装が推奨されます。

リリースに関する一般的なガイドライン

一般に、関連するすべての製品を最新の OS バージョンでリリースすることをおすすめします。つまり、メーカーは製品をリリースする前に、可能な限り最新の OS バージョンを使用する必要があります。テストと検証の前にバージョンをロックすると安定性が向上しますが、メーカーは、OS の下位バージョンと新しいバージョンから得られる製品の安定性を比較検討する必要があります。これは、新しい OS バージョンでは、既知のセキュリティの脆弱性が少なくなり、セキュリティ保護が強化されることが多いためです。

推奨されるガイドラインは次のとおりです。

車両開発プロセスに固有のリードタイムが長いため、メーカーは n-2 以前の OS をリリースする必要がある場合があります。
無線（OTA）キャンペーンを通じて、リリースされた Android OS の各バージョンが Android との互換性を維持するようにします。
製品の Android ファームウェア無線（FOTA）機能を実装して、迅速で顧客に負担のかからないアップデートを実現します。FOTA は、セキュリティのベストプラクティス（製品と IT バックオフィスの間のコード署名や TLS 接続など）を使用して行う必要があります。
個別に特定された Android のセキュリティ脆弱性を Android セキュリティチームに送信します。

注: Google は、Android のセキュリティに関する公開情報において、デバイスタイプや業界ごとの通知を発行することを検討しています。ただし、Google では特定のデバイス（自動車、テレビ、ウェアラブル、スマートフォンなど）のカーネル、ドライバ、チップセットは把握できないため、特定のセキュリティ上の問題をデバイスタイプにラベル付けする決定的な方法はありません。

製品サイクルガイドライン

製品の改善期間中、メーカーは最新の OS バージョンまたは使用されているバージョンのセキュリティアップデートの使用を試みる必要があります。OS アップデートは、定期的な製品のアップデートで実施できます。または修正プログラムのアップデートを実施して、品質などに関する問題を解決できます。以下の方法が推奨されます。

ドライバ、カーネル、プロトコルのアップデートに関する問題を解決するための計画を作成します。
業界に適した方法を使用して、販売された車両にアップデートを提供します。

互換性定義ドキュメント（CDD）

互換性定義ドキュメント（CDD）は、Android 互換であると見なされるデバイスの要件を記述したものです。CDD は一般公開されており、誰でも利用できます。CDD バージョンは、Android 1.6 から最新バージョンまで source.android.com からダウンロードできます。

製品をこれらの要件に準拠させるには、次の基本的なステップを実施する必要があります。

パートナーは Google に対して Android 互換性コミットメント（ACC）に署名します。署名すると、テクニカルソリューションコンサルタント（TSC）がガイドの担当になります。
パートナーは、製品の Android OS バージョンについて CDD の審査を行い、
審査結果で Android 互換性が認められるまで、CTS 結果（後述）を実施して送信します。

互換性テストスイート（CTS）

互換性テストスイート（CTS）テストツールは、製品の実装が Android 互換かどうか、および最新のセキュリティパッチを含んでいるかどうかを検証するものです。CTS は一般公開されているオープンソースであり、誰でも利用できます。CTS バージョンは、Android 1.6 から最新バージョンまで source.android.com からダウンロードできます。

一般公開されている Android ソフトウェアの各ビルド（工場出荷時のインストールとフィールドアップデートイメージ）は、CTS の結果を通じて Android の互換性を証明する必要があります。たとえば、デバイスに Android 7.1 が搭載されている場合、リリースを意図したビルドイメージを作成してテストするときは、対応する最新バージョンの CDD 7.1 と CTS 7.1 を参照する必要があります。メーカーには、問題の発見と解決のため、早めにかつ頻繁に CTS を使用することを強くおすすめします。

注: Google モバイルサービス（GMS）などの他の契約を締結するパートナーは、場合によっては追加の要件を満たす必要があります。

CTS のワークフロー

CTS のワークフローには、テスト環境のセットアップ、テストの実施、結果の解釈、CTS ソースコードの分析が含まれます。次のガイドラインは、CTS ユーザー（デベロッパー、メーカーなど）が CTS を効果的かつ効率的に使用できるよう支援することを目的としています。

テストを頻繁に実施する。CTS は、ビルドシステムに統合する自動化ツールとして設計されています。CTS を頻繁に実施すると、ソフトウェアの品質低下や回帰が発生したときに、初期段階で速やかに欠陥を見つけることができます。
CTS のソースコードをダウンロードして調べる。完全な CTS ソースコードは、誰でもダウンロードして使用できるオープンソースソフトウェアです（ダウンロードしたソースコードは完全にビルドおよび実行可能です）。デバイスでテストが失敗したときは、ソースコードの関連部分を調べると、原因の特定が容易になります。
最新の CTS を入手する。新しい Android リリースでは、バグの修正、改善、新しいテストで CTS をアップデートできます。CTS のダウンロードを頻繁に確認し、必要に応じて CTS プログラムをアップデートしてください。メーカーと Google は、CTS のアップデートが継続している間、ある時点で製品を凍結させる必要があるため、製品のリリース段階で使用する CTS バージョンについて合意する必要があります。

CTS の合格

Android 互換製品の場合、Google はデバイスの CTS と CTS 検証レポートのテスト結果が許容できるものであることを確認します。原則として、すべてのテストに合格する必要があります。ただし、デバイスが Android 互換性要件に準拠していないという理由以外の理由でテストに不合格となった場合は、そのテストは Google による審査の対象となります。このプロセスでは以下の処理が行われます。

メーカーは、立証のために、提案された CTS パッチ、パッチ検証、理由を Google に提供するものとします。
Google は提出された資料を確認し、承認された場合は、デバイスが次のバージョンの CTS に合格できるように、関連する CTS テストをアップデートします。

セキュリティパッチの適用後に CTS テストが突然失敗した場合、メーカーは互換性を損なわないようにパッチを修正するか、またはテストに誤りがあることを示してテストに対する修正を提供する必要があります（上記の説明を参照）。

CTS は、テストに対する修正を確認できるように、オープンな状態に保たれています。たとえば、Android 4.4 は引き続き修正を受け入れます（https://android-review.googlesource.com/#/c/273371/ を参照）。

よくある質問（FAQ）

Q: 特定の Android の実装にセキュリティアップデートを適用する責任は誰にありますか？

A: デバイスを直接提供するメーカーが責任を負います。Google は当事者ではありません。Google は、特定のデバイス（車両など）のセキュリティアップデートではなく、AOSP でセキュリティアップデートをリリースします。

Q: Google は Android のセキュリティに関する問題にどのように対応していますか？

A: Google は継続的に問題を調査して、考えられる修正プログラムを開発し、定期的なセキュリティアップデートプロセスを通じてすべてのサポート対象の API レベルで修正プログラムを提供します。2015 年 8 月以降、Google は定期的にお知らせを公開し、source.android.com へのリンクを更新します。Google は、主要な OS バージョンがリリースされたときにセキュリティアップデートもリリースします。セキュリティバックポートポリシーもご覧ください。

Q: メーカーが ASB からの AOSP パッチをすべて統合したものの、同じ公開情報に記録された BSP ベンダーからのパッチを統合しなかった場合でも、セキュリティレベルを上げる（たとえば、プラットフォーム / ビルドに対応するパッチを適用する）ことはできますか？

A: メーカーが Android セキュリティパッチレベル（SPL）を宣言するには、Android のセキュリティに関する公開情報（過去の公開情報を含む）で公開され、特定の Android SPL にマッピングされている、対処が必要な問題にすべて対処する必要があります。たとえば、あるメーカーは 2017 年 3 月のセキュリティに関する公開情報（2017 年 3 月 1 日 SPL）を使用して、2017 年 3 月の公開情報に記録された SPL の必要なすべての問題と、以前のすべてのアップデートに対処しています。これらのアップデートには、以前のすべての Android のセキュリティに関する公開情報のデバイス固有のアップデート（2017 年 2 月 5 日 SPL に関連するデバイス固有のアップデートなど）が含まれます。

Q: メーカーが BSP ベンダーによって提供されるセキュリティアップデートに同意しない場合、またはベンダーが ASB によって義務付けられているセキュリティアップデートを提供しない場合はどうなりますか？

A: ASB は、セキュリティの脆弱性（CVE リストで列挙）について説明し、通常は該当のセキュリティテストを提供します。この目的は、リストされた脆弱性がデバイスで再現されないこと、デバイスが関連するセキュリティテストに合格できることを確認することです。したがって、問題は、Google またはサードパーティベンダーが提供するセキュリティアップデートを採用するかどうかではなく、デバイスが ASB の CVE リストに掲載されている脆弱性に対して脆弱であるかどうかをメーカーが証明できるかどうかです。メーカーは、提供されているセキュリティアップデートを自由に使用できます。または、デバイスにより適したアップデートがある場合は、代わりにこのアップデートを使用できます。

たとえば、Google がコードを変更することで AOSP セキュリティの脆弱性を解決するとします。これにより、コンポーネントの正常な動作と CDD への準拠を維持できます。デバイスにコンポーネントが不要であるとメーカーが判断した場合、または CDD（または関連する認定テスト）が必須ではない場合は、コンポーネントを削除して、将来のメンテナンス要件を減らし、攻撃対象領域を小さくすることができます。このメーカーは提供されたセキュリティアップデートを使用しませんでしたが、セキュリティに関する公開情報に掲載されている CVE に対してデバイスが脆弱でないことを保証しました。ただし、推奨されるセキュリティアップデートが採用されていない場合、メーカーは、問題を誤って解決する、新しいセキュリティの脆弱性をまねく、最終的なビルドの機能を低下させるといったリスクを負うことになります。

Google は、ASB のすべての問題が確実に解決されるように、すべての SoC パートナーと協力することをお約束します。したがって、メーカーは、デバイスのライフサイクル全体を通じて SoC ベンダーとサービス契約を締結することをおすすめします。SoC はチップセットのサービスサポートを早期に停止する可能性があるため、デバイスチップセットを選択する前に契約を締結することは、デバイスリリースプロセスの重要な部分です。

最後に、ASB に記録された問題の修正を直接取得したり個別に作成したりできない場合、メーカーは以前の Android SPL を維持し、利用可能な新しい修正をビルドに追加できます。ただしこの方法では、最終的にビルド認証で問題が発生します（Android は認証されたデバイスで最新のセキュリティパッチレベルを利用できることを保証するため）。こうした事態を避けるため、事前に SoC と協議することをおすすめします。

Q: ASB アイテムが自社の製品に適用できないとメーカーが判断した場合でも、他の Google 要件を満たすため、または CTS テストに合格するために、この項目を適用するか、この項目のパッチを採用する必要がありますか？

A: Android セキュリティパッチレベル（SPL）を宣言するためにパッチを使用する必要はありません。ただし、メーカーは、自社のビルドが問題の影響を受けにくいことを証明する必要があります。

たとえば、メーカーのシステムにパッチ処理が必要なコンポーネントがない場合や、問題を解決するためにコンポーネントがメーカーのシステムから削除されている場合などです。この場合、メーカーは要件を満たすためにパッチを適用する必要はありません。

これは、たとえば、メーカーが重要なパッチのみを修正したいと考えており、セキュリティテストで不合格になる可能性のある他の利用可能なパッチは使用しない状況とは異なります。この場合、SPL は満たされていないと見なされます。