Panduan ini menjelaskan praktik terbaik yang direkomendasikan Google untuk menerapkan patch keamanan yang dievaluasi oleh Android Compatibility Test Suite (CTS). Ini ditujukan untuk produsen peralatan OEM yang kompatibel dengan Android (produsen) yang akan didukung lebih dari tiga tahun seperti kendaraan, TV, dekoder, dan peralatan rumah tangga. Panduan ini tidak ditujukan untuk pengguna akhir (misalnya pemilik kendaraan).
Ucapan terima kasih dan penafian
Panduan ini tidak mengikat Google atau produsen lain secara hukum atau kontrak dan tidak dimaksudkan sebagai serangkaian persyaratan. Sebaliknya, panduan ini merupakan bantuan instruksional yang menjelaskan praktik-praktik yang direkomendasikan.
Masukan
Panduan ini tidak dimaksudkan untuk komprehensif; revisi tambahan direncanakan. Kirim masukan ke produsen-guide-android@googlegroups.com.
Glosarium
| Ketentuan | Definisi |
|---|---|
| ACC | Komitmen Kompatibilitas Android. Sebelumnya dikenal sebagai Perjanjian Anti-Fragmentasi Android (AFA). |
| AOSP | Proyek Sumber Terbuka Android |
| ASB | Buletin Keamanan Android |
| BSP | Paket Dukungan Dewan |
| CDD | Dokumen Definisi Kompatibilitas |
| CTS | Rangkaian Uji Kompatibilitas |
| FOTA | firmware melalui udara |
| GPS | sistem penentuan posisi global |
| MISRA | Asosiasi Keandalan Perangkat Lunak Industri Motor |
| NIST | Institut Standar dan Teknologi Nasional |
| obd | diagnostik on-board ( OBD-II merupakan peningkatan dari OBD-I baik dalam kemampuan maupun standardisasi ) |
| OEM | produsen peralatan asli |
| sistem operasi | sistem operasi |
| SEI | Institut Rekayasa Perangkat Lunak |
| SoC | sistem pada chip |
| SOP | dimulainya produksi |
| SPL | Tingkat Patch Keamanan |
| TPMS | sistem pemantauan tekanan ban |
Tentang OS Android
Android adalah tumpukan perangkat lunak lengkap berbasis Linux sumber terbuka yang dirancang untuk berbagai perangkat dan faktor bentuk. Sejak dirilis pertama kali pada tahun 2008, Android telah menjadi Sistem Operasi (OS) paling populer, mendukung 1,4+ miliar perangkat di seluruh dunia (2016). Sekitar 67% dari perangkat tersebut menggunakan Android 5.0 (Lollipop) atau lebih baru pada Maret 2017 (angka terbaru tersedia di Dasbor Android ). Meskipun sebagian besar perangkatnya adalah ponsel dan tablet, Android berkembang di jam tangan pintar, TV, dan perangkat infotainment dalam kendaraan (IVI) otomotif.
Jumlah aplikasi Android yang tersedia di Google Play Store telah mencapai 2,2+ juta (2016). Pengembangan aplikasi Android didukung oleh program Kompatibilitas Android, yang mendefinisikan serangkaian persyaratan melalui Dokumen Definisi Kompatibilitas (CDD) dan menyediakan alat pengujian melalui Compatibility Test Suite (CTS) . Program kompatibilitas Android memastikan aplikasi Android apa pun dapat berjalan di perangkat apa pun yang kompatibel dengan Android yang mendukung fitur yang diperlukan untuk aplikasi tersebut.
Google merilis versi OS baru, pembaruan keamanan OS, dan informasi tentang kerentanan yang ditemukan secara rutin. Buletin Keamanan Android harus ditinjau oleh produsen untuk mengetahui penerapan pembaruan ini pada produk yang didukung OS Android. Untuk tinjauan keamanan, kompatibilitas, dan sistem build Android, lihat yang berikut:
- Amankan Perangkat Android
- Pembaruan dan Sumber Daya Keamanan
- Rangkaian Uji Kompatibilitas
- Nama Kode, Tag, dan Nomor Pembuatan
Tentang kendaraan yang terhubung (produk kanonik berumur panjang)
Kendaraan mulai terhubung dengan diperkenalkannya radio AM pada tahun 1920-an. Dari sana, jumlah koneksi fisik dan nirkabel eksternal mulai bertambah ketika regulator dan produsen mobil beralih ke perangkat elektronik untuk memudahkan diagnostik dan servis (misalnya, port OBD-II), meningkatkan keselamatan (misalnya, TPMS), dan memenuhi target penghematan bahan bakar. . Gelombang konektivitas berikutnya memperkenalkan fitur kenyamanan pengemudi seperti remote keyless entry, sistem telematika, dan fitur infotainment canggih seperti Bluetooth, Wi-Fi, dan proyeksi ponsel cerdas. Saat ini, sensor dan konektivitas terintegrasi (misalnya GPS) mendukung keselamatan dan sistem mengemudi semi-otonom.
Ketika jumlah sambungan kendaraan meningkat, maka luas permukaan potensi serangan kendaraan juga meningkat. Koneksi membawa serta kumpulan kekhawatiran keamanan siber yang serupa dengan yang terjadi pada barang elektronik konsumen. Namun, meskipun reboot, pembaruan patch harian, dan perilaku yang tidak dapat dijelaskan adalah hal yang biasa terjadi pada perangkat elektronik konsumen, hal tersebut tidak konsisten untuk produk dengan sistem yang sangat mengutamakan keselamatan seperti kendaraan.
Produsen harus mengambil pendekatan proaktif untuk memastikan keberlangsungan postur keamanan dan keselamatan suatu produk di lapangan. Singkatnya, produsen harus menyadari kerentanan keamanan yang diketahui pada produknya dan mengambil pendekatan berbasis risiko untuk mengatasinya.
Pastikan keamanan jangka panjang
Kendaraan yang terhubung sering kali memiliki satu atau lebih unit kontrol elektronik (ECU) yang mencakup beberapa komponen perangkat lunak seperti OS, perpustakaan, utilitas, dll. Produsen harus melacak komponen tersebut dan mengidentifikasi kerentanan yang diketahui dan dipublikasikan dengan analisis proaktif, termasuk:
- Mengevaluasi produk secara berkala berdasarkan database Common Vulnerabilities and Exposures (CVE).
- Pengumpulan intelijen untuk kelemahan keamanan terkait produk.
- Pengujian keamanan.
- Secara aktif menganalisis Buletin Keamanan Android.
Contoh pembaruan OS dan patch keamanan (IVI yang menjalankan Android):
Gambar 1. Contoh peluncuran OS utama dan pembaruan keamanan sepanjang masa pakai kendaraan.
| # | Melangkah | Kegiatan |
|---|---|---|
① | Cabang Pengembangan | Pabrikan memilih versi Android (Android X). Dalam contoh ini, "Android X" menjadi dasar dari apa yang akan dikirimkan ke dalam kendaraan dua tahun sebelum Mulai Produksi (SOP) awal. |
| ② | Peluncuran Awal | Beberapa bulan sebelum Android X menjadi versi OS pertama yang dikirimkan dalam produk, pembaruan keamanan diambil dari Buletin Keamanan Android (ASB) dan mungkin sumber lain yang dianggap berharga oleh produsen. y2 = Buletin Keamanan kedua untuk Android versi X, yang diterapkan (di-backport) oleh produsen ke Android X. Pembaruan ini disertakan dalam produk dan jam produksi mulai berdetak pada Tahun Nol dengan Android X.y2. Dalam contoh ini, pabrikan mengambil keputusan untuk tidak mengirimkan rilis tahunan Android X+1 yang lebih baru. Alasan pengiriman rilis terbaru mencakup penambahan fitur baru, mengatasi kerentanan keamanan baru, dan/atau pengiriman layanan Google atau pihak ketiga yang memerlukan versi Android yang lebih baru. Alasan penolakan pengiriman dengan rilis terbaru adalah kurangnya waktu yang melekat pada proses pengembangan dan peluncuran kendaraan yang diperlukan untuk mengintegrasikan, menguji, dan memvalidasi perubahan, termasuk kepatuhan terhadap semua persyaratan peraturan dan sertifikasi. |
| ③ | Pembaruan OS Lengkap | Pasca SOP, pabrikan merilis pembaruan OS Android X+2, yaitu dua rilis Android setelah versi yang digunakan untuk produk awal (Android X0). Pembaruan keamanan ASB tersedia untuk tingkat API (sejak tanggal pengiriman), sehingga pembaruan akan dirilis pada X+2.y0 sekitar 1,25 tahun setelah SOP. Pembaruan OS ini mungkin kompatibel atau tidak dengan produk yang dikirimkan. Jika ya, sebuah rencana dapat dibuat untuk memperbarui kendaraan yang dikerahkan. Kecuali ada perjanjian bisnis lain, keputusan untuk melakukan pembaruan OS sepenuhnya sepenuhnya merupakan kebijaksanaan pabrikan. |
| ④ | Pembaruan Keamanan | Dua tahun setelah masa produksi kendaraan, pabrikan menambal OS Android X+2. Keputusan ini didasarkan pada penilaian risiko pabrikan. Pabrikan memilih pembaruan keamanan ASB ketiga untuk rilis X+2 sebagai dasar pembaruan. Produk yang menerima pembaruan keamanan kini berada pada (X+2.y3) Tingkat Patch Keamanan OS + Android. Meskipun produsen dapat memilih patch keamanan individual dari ASB mana pun, mereka harus memperbaiki semua masalah yang diperlukan dalam buletin untuk menggunakan level patch keamanan (SPL) Android yang terkait dengan buletin tersebut (misalnya, 05-02-2017). Merupakan tanggung jawab pabrikan untuk melakukan backport dan rilis keamanan untuk produk yang didukung. |
| ⑤ | Pembaruan OS Lengkap | Pengulangan langkah 3 (Pembaruan OS Lengkap), pembaruan OS lengkap kedua membawa produk hingga Android X+4, tiga tahun setelah masa produksi kendaraan. Pabrikan kini menyeimbangkan persyaratan perangkat keras yang lebih baru dari versi Android terbaru dengan perangkat keras dalam produk dan pengguna mendapatkan manfaat dari OS Android yang diperbarui. Pabrikan merilis pembaruan tanpa pembaruan keamanan, sehingga produk sekarang berada pada (X+4.y0) OS + Tingkat Patch Keamanan Android. Dalam contoh ini, karena keterbatasan perangkat keras, X+4 adalah versi utama Android terakhir yang akan disediakan untuk produk ini, meskipun perkiraan masa pakai kendaraan lebih dari 6 tahun masih memerlukan dukungan keamanan. |
| ⑥ | Pembaruan Keamanan | Pengulangan langkah 4 (Pembaruan Keamanan). Pabrikan mempunyai tugas untuk mengambil pembaruan keamanan ASB dari versi Android yang jauh lebih baru (X+6) dan mem-porting beberapa atau semua pembaruan tersebut kembali ke Android X+4. Merupakan tanggung jawab produsen untuk menggabungkan, mengintegrasikan, dan melakukan pembaruan (atau membuat kontrak dengan pihak ketiga). Selain itu, pabrikan harus menyadari bahwa masalah keamanan pada versi Android yang tidak lagi didukung tidak tercakup dalam ASB. |
| ⑦ | Pembaruan Keamanan | Delapan tahun dalam siklus hidup produksi kendaraan, empat rilis Android sejak pembaruan OS terakhir pada Langkah 5 (Pembaruan OS Lengkap), dan sepuluh tahun sejak Android X ditetapkan, beban kurasi dan backporting patch keamanan sepenuhnya menjadi tanggung jawab pabrikan. versi tersebut lebih lama dari tiga tahun sejak rilis publik tingkat API. |
Praktik terbaik keamanan
Untuk mempersulit kompromi keamanan, Google merekomendasikan dan menerapkan penggunaan praktik terbaik yang diterima secara umum untuk keamanan dan rekayasa perangkat lunak, seperti yang dijelaskan dalam Menerapkan Keamanan .
Pedoman keamanan
Praktik keamanan yang direkomendasikan meliputi:
- Gunakan versi terbaru perpustakaan eksternal dan komponen sumber terbuka.
- Jangan sertakan fungsionalitas debug yang mengganggu dalam versi rilis OS.
- Hapus fungsionalitas yang tidak digunakan (untuk mengurangi permukaan serangan yang tidak diperlukan).
- Gunakan prinsip hak istimewa terendah dan praktik terbaik pengembangan aplikasi Android lainnya.
Pedoman pengembangan perangkat lunak
Praktik yang direkomendasikan untuk pengembangan perangkat lunak yang aman untuk siklus hidup sistem meliputi:
- Lakukan pemodelan ancaman untuk menentukan peringkat dan mengidentifikasi aset, ancaman, dan potensi mitigasi.
- Lakukan tinjauan arsitektur/desain untuk memastikan desain yang aman dan sehat.
- Lakukan peninjauan kode secara berkala untuk mengidentifikasi anti-pola dan bug sesegera mungkin.
- Rancang, terapkan, dan jalankan pengujian unit cakupan kode tinggi, termasuk:
- Pengujian fungsional (termasuk kasus uji negatif)
- Pengujian regresi reguler (untuk memastikan bug yang diperbaiki tidak muncul kembali)
- Pengujian fuzz (sebagai bagian dari rangkaian pengujian unit)
- Gunakan alat analisis kode sumber statis (scan-build, lint, dll.) untuk mengidentifikasi potensi masalah.
- Gunakan alat analisis kode sumber dinamis, seperti AddressSanitizer, UndefinisiBehaviorSanitizer, dan FORTIFY_SOURCE (untuk komponen asli) untuk mengidentifikasi dan mengurangi potensi masalah selama pengembangan sistem.
- Memiliki strategi manajemen untuk kode sumber perangkat lunak dan konfigurasi/versi rilis.
- Memiliki strategi manajemen patch untuk pembuatan dan penerapan patch perangkat lunak.
Kebijakan backport keamanan
Google saat ini memberikan dukungan aktif untuk backport keamanan dari kerentanan keamanan yang ditemukan dan dilaporkan selama tiga (3) tahun sejak rilis publik tingkat API . Dukungan aktif terdiri dari berikut ini:
- Menerima dan menyelidiki laporan kerentanan.
- Membuat, menguji, dan merilis pembaruan keamanan.
- Menyediakan rilis berulang pembaruan keamanan dan rincian buletin keamanan.
- Lakukan penilaian tingkat keparahan sesuai pedoman yang ditetapkan.
Setelah tiga tahun sejak tanggal rilis publik tingkat API, Google merekomendasikan pedoman berikut:
- Gunakan pihak ketiga (seperti vendor SoC atau penyedia Kernel) untuk dukungan backport untuk pembaruan keamanan OS yang lebih lama dari tiga tahun sejak rilis API.
- Gunakan pihak ketiga untuk melakukan tinjauan kode menggunakan ASB yang disediakan secara publik. Meskipun ASB mengidentifikasi kerentanan untuk versi yang didukung saat ini, produsen dapat menggunakan informasi yang diberikan untuk membandingkan pembaruan yang baru dirilis dengan versi sebelumnya. Data ini dapat digunakan untuk melakukan analisis dampak dan berpotensi menghasilkan patch serupa untuk versi OS yang lebih lama dari tiga tahun sejak rilis API.
- Jika perlu, upload update keamanan ke Android Open Source Project (AOSP).
- Pabrikan harus mengoordinasikan penanganan pembaruan keamanan untuk kode khusus vendor (misalnya, kode khusus perangkat eksklusif).
- Pabrikan harus bergabung dengan grup pemberitahuan Pratinjau Mitra Buletin Keamanan Android NDA (memerlukan penandatanganan perjanjian hukum seperti NDA Pengembang). Buletin harus mencakup:
- Pengumuman
- Ringkasan masalah berdasarkan tingkat patch, termasuk CVE dan tingkat keparahannya
- Detail kerentanan jika diperlukan
Referensi tambahan
Untuk petunjuk tentang praktik pengkodean dan pengembangan perangkat lunak yang aman, lihat yang berikut ini:
- Asosiasi Keandalan Perangkat Lunak Industri Motor (MISRA) .
- Alat & Metode Institut Rekayasa Perangkat Lunak (SEI) .
- Institut Standar dan Teknologi Nasional (NIST).
Praktik produk yang direkomendasikan
Google mendorong penggunaan praktik yang direkomendasikan berikut.
Pedoman peluncuran umum
Secara umum disarankan agar setiap produk yang terhubung diluncurkan dengan versi OS terbaru, dan produsen harus mencoba menggunakan versi OS terbaru sebelum meluncurkan produk. Meskipun mengunci versi diperlukan untuk mendorong stabilitas sebelum pengujian dan validasi, produsen harus menyeimbangkan stabilitas produk yang diperoleh dari versi OS lama dengan versi OS lebih baru yang memiliki lebih sedikit kerentanan keamanan yang diketahui dan perlindungan keamanan yang ditingkatkan.
Pedoman yang direkomendasikan meliputi:
- Karena waktu tunggu pengembangan yang panjang yang melekat pada proses pengembangan kendaraan, produsen mungkin perlu meluncurkan OS versi n-2 atau lebih lama.
- Menjaga kesesuaian dengan Kompatibilitas Android untuk setiap versi OS Android yang dirilis dengan kampanye over-the-air (OTA).
- Menerapkan produk Android Firmware-over-the-air (FOTA) yang mampu melakukan pembaruan dengan cepat dan ramah pelanggan. FOTA harus dilakukan menggunakan praktik terbaik keamanan seperti penandatanganan kode dan koneksi TLS antara produk dan backoffice TI.
- Kirimkan kerentanan keamanan Android yang teridentifikasi secara independen kepada tim Keamanan Android.
Catatan: Google telah mempertimbangkan jenis perangkat atau pemberitahuan khusus industri di Buletin Keamanan Android. Namun, karena Google tidak mengetahui kernel, driver, atau chipset untuk perangkat tertentu (kendaraan, TV, perangkat wearable, ponsel, dll.), Google tidak memiliki cara deterministik untuk memberi label masalah keamanan tertentu berdasarkan jenis perangkat .
Pedoman siklus produk
Pabrikan harus melakukan segala upaya untuk menggunakan versi OS terbaru atau pembaruan keamanan untuk versi yang digunakan selama peningkatan siklus produk. Pembaruan dapat dilakukan selama pembaruan produk berkala yang berulang, atau untuk perbaikan terbaru guna mengatasi masalah kualitas dan/atau masalah lainnya. Praktik yang direkomendasikan meliputi:
- Buat rencana untuk mengatasi pembaruan driver, kernel, dan protokol.
- Memanfaatkan metode yang sesuai dengan industri untuk memberikan pembaruan pada kendaraan yang dikerahkan.
Dokumen Definisi Kompatibilitas (CDD)
Dokumen Definisi Kompatibilitas (CDD) menjelaskan persyaratan agar perangkat dianggap kompatibel dengan Android. CDD bersifat publik dan tersedia untuk semua orang; Anda dapat mengunduh versi CDD dari Android 1.6 hingga versi terbaru dari source.android.com .
Memenuhi persyaratan suatu produk ini melibatkan langkah-langkah dasar berikut:
- Mitra menandatangani Komitmen Kompatibilitas Android (ACC) dengan Google. Konsultan Solusi Teknis (TSC) kemudian ditugaskan sebagai pemandu.
- Mitra menyelesaikan peninjauan CDD untuk versi OS Android produk.
- Mitra menjalankan dan mengirimkan hasil CTS (dijelaskan di bawah) hingga hasilnya dapat diterima untuk Kompatibilitas Android.
Rangkaian Uji Kompatibilitas (CTS)
Alat pengujian Compatibility Test Suite (CTS) memverifikasi implementasi produk kompatibel dengan Android dan patch keamanan terbaru telah disertakan. CTS bersifat publik, open source, dan tersedia untuk semua orang; Anda dapat mengunduh versi CTS dari Android 1.6 hingga versi terbaru dari source.android.com .
Setiap versi perangkat lunak Android yang dirilis ke publik (gambar instalasi pabrik dan pembaruan lapangan) harus membuktikan Kompatibilitas Android melalui hasil CTS. Misalnya, jika perangkat menjalankan Android 7.1, versi terbaru CDD 7.1 dan CTS 7.1 yang sesuai harus dijadikan acuan saat image build tujuan rilis dibuat dan diuji. Produsen sangat dianjurkan untuk menggunakan CTS sejak dini dan sering untuk mengidentifikasi dan mengatasi masalah.
Alur kerja CTS
Alur kerja CTS melibatkan pengaturan lingkungan pengujian, menjalankan pengujian, menafsirkan hasil, dan memahami kode sumber CTS. Pedoman berikut ini dimaksudkan untuk membantu pengguna CTS (misalnya pengembang, produsen) menggunakan CTS secara efektif dan efisien.
- Jalankan tes sesering mungkin . CTS dirancang sebagai alat otomatis yang terintegrasi ke dalam sistem build Anda. Menjalankan CTS secara rutin dapat membantu Anda menemukan kerusakan dengan cepat dan dini ketika terjadi degradasi atau regresi perangkat lunak.
- Unduh dan periksa kode sumber CTS . Kode sumber CTS lengkap adalah perangkat lunak sumber terbuka yang dapat diunduh dan digunakan oleh siapa saja (kode sumber yang diunduh sepenuhnya dapat dibangun dan dijalankan). Ketika pengujian gagal pada perangkat, memeriksa bagian kode sumber yang relevan dapat membantu Anda mengidentifikasi alasannya.
- Dapatkan CTS terbaru . Rilis Android baru dapat memperbarui CTS dengan perbaikan bug, peningkatan, dan pengujian baru. Periksa Unduhan CTS sesering mungkin dan perbarui program CTS Anda jika diperlukan. Produsen dan Google harus menyetujui versi CTS agar dapat lolos peluncuran produk karena produk harus dibekukan pada suatu saat sementara CTS terus disegarkan.
Lulus CTS
Untuk produk yang Kompatibel dengan Android, Google memastikan hasil pengujian laporan CTS dan Verifikator CTS perangkat dapat diterima. Prinsipnya semua ujian harus lulus. Namun, pengujian yang gagal karena alasan selain perangkat tidak mematuhi persyaratan Kompatibilitas Android akan ditinjau oleh Google. Selama proses ini:
- Pabrikan memberi Google usulan patch CTS, validasi patch, dan justifikasi untuk membuktikan argumennya.
- Google memeriksa materi yang dikirimkan, dan jika diterima, memperbarui tes CTS yang relevan sehingga perangkat dapat lulus dalam revisi CTS berikutnya.
Jika pengujian CTS tiba-tiba gagal setelah menerapkan patch keamanan, produsen harus memodifikasi patch tersebut sehingga tidak merusak kompatibilitas ATAU menunjukkan bahwa pengujian tersebut salah dan memberikan perbaikan untuk pengujian tersebut (seperti dijelaskan di atas).
CTS tetap terbuka untuk peninjauan perbaikan pengujian. Misalnya, Android 4.4 terus menerima perbaikan (lihat https://android-review.googlesource.com/#/c/273371/ ).
Pertanyaan yang sering diajukan (FAQ)
T: Siapa yang bertanggung jawab menerapkan update keamanan pada implementasi spesifik Android?
J: Produsen yang menyediakan perangkat secara langsung bertanggung jawab. Entitas ini bukan Google, yang memublikasikan pembaruan keamanan di AOSP dan bukan untuk perangkat tertentu (seperti kendaraan).
T: Bagaimana cara Google menangani masalah keamanan di Android?
J: Google terus menyelidiki masalah dan mengembangkan potensi perbaikan, yang disediakan Google untuk semua level API yang didukung sebagai bagian dari proses pembaruan keamanan rutin. Sejak Agustus 2015, Google terus menerbitkan buletin dan tautan ke pembaruan ke source.android.com secara teratur; Google juga menerbitkan pembaruan keamanan sebagai bagian dari rilis OS utama. Lihat juga kebijakan Backport keamanan .
T: Jika produsen mengintegrasikan semua patch AOSP dari ASB namun tidak mengintegrasikan patch dari vendor BSP yang disebutkan dalam buletin yang sama, apakah produsen tersebut masih dapat meningkatkan tingkat keamanan (misalnya, menerapkan patch yang sesuai ke platform/build)?
J: Untuk mendeklarasikan level patch keamanan (SPL) Android, produsen harus mengatasi semua masalah wajib yang dipublikasikan di Buletin Keamanan Android ( termasuk buletin sebelumnya ) dan dipetakan ke SPL Android tertentu. Misalnya, produsen yang menggunakan Buletin Keamanan Maret 2017 (SPL 01-03-2017) telah mengatasi semua masalah wajib yang didokumentasikan dalam buletin Maret 2017 untuk SPL tersebut dan semua pembaruan sebelumnya termasuk pembaruan khusus perangkat untuk semua Buletin Keamanan Android sebelumnya, termasuk pembaruan khusus perangkat yang terkait dengan SPL 2017-02-05.
T: Apa yang terjadi bila produsen tidak menyetujui pembaruan keamanan yang disediakan oleh vendor BSP ATAU bila pembaruan keamanan yang diamanatkan oleh ASB tidak disediakan oleh vendor?
J: ASB menjelaskan kerentanan keamanan (dihitung berdasarkan daftar CVE) dan sering kali menyediakan pengujian keamanan yang cocok. Tujuannya adalah untuk memastikan kerentanan yang tercantum tidak dapat lagi direproduksi pada perangkat dan perangkat dapat lulus uji keamanan terkait. Dengan demikian, masalahnya bukan mengenai pembaruan keamanan yang disediakan oleh Google atau vendor pihak ketiga, namun tentang produsen yang membuktikan bahwa perangkat tersebut tidak rentan terhadap daftar CVE di ASB. Produsen bebas menggunakan pembaruan keamanan yang disediakan atau, jika mereka memiliki perubahan yang lebih sesuai untuk perangkat mereka, gunakan perubahan tersebut.
Misalnya, pertimbangkan kasus di mana Google mengatasi kerentanan keamanan AOSP menggunakan perubahan kode yang memungkinkan komponen tetap berfungsi penuh dan mematuhi CDD. Jika pabrikan menentukan bahwa komponen tersebut tidak diperlukan pada perangkat atau tidak diwajibkan oleh CDD (atau pengujian sertifikasi terkait), pabrikan dapat menghapus komponen tersebut untuk mengurangi kebutuhan servis di masa mendatang dan mengurangi permukaan serangan. Meskipun produsen tidak menggunakan pembaruan keamanan yang disediakan, produsen memastikan perangkat tidak rentan terhadap CVE yang didokumentasikan dalam buletin keamanan. Namun, jika menyimpang dari pembaruan keamanan yang direkomendasikan, pabrikan mengambil risiko salah menangani masalah, menimbulkan kerentanan keamanan baru, atau mengurangi fungsionalitas versi akhir.
Meskipun kami bekerja sama dengan semua mitra SoC untuk memastikan adanya perbaikan untuk semua masalah di ASB, kami menyarankan agar produsen membuat perjanjian servis dengan vendor SoC mereka untuk siklus hidup perangkat. SoC mungkin berhenti melayani chipset lebih awal dari yang diinginkan, jadi membuat perjanjian sebelum pemilihan chipset perangkat merupakan bagian penting dari proses peluncuran perangkat.
Terakhir, jika tidak mungkin memperoleh atau membuat perbaikan secara mandiri untuk masalah yang didokumentasikan dalam ASB secara langsung, produsen dapat mempertahankan SPL Android sebelumnya dan tetap menambahkan perbaikan baru yang tersedia ke build. Namun, praktik ini pada akhirnya akan menimbulkan masalah pada sertifikasi build (karena Android memastikan tingkat patch keamanan terbaru tersedia pada perangkat yang disertifikasi). Google merekomendasikan untuk bekerja dengan SoC Anda terlebih dahulu untuk menghindari praktik ini.
T: Jika produsen menentukan item ASB tidak berlaku untuk produknya, apakah item tersebut masih perlu diterapkan atau di-patch untuk memenuhi persyaratan Google lainnya atau untuk lulus CTS?
J: Kami tidak mengharuskan pengambilan patch untuk mendeklarasikan level patch keamanan Android (SPL); kami mengharuskan pabrikan membuktikan bahwa bangunan mereka tidak rentan terhadap masalah ini.
Salah satu contohnya adalah ketika komponen yang ditambal tidak ada di sistem pabrikan, atau komponen dihapus dari sistem pabrikan untuk mengatasi masalah. Dalam hal ini sistem mungkin memenuhi persyaratan tanpa mengharuskan produsen melakukan patch.
Hal ini pada dasarnya berbeda dengan keinginan pabrikan, misalnya, hanya memperbaiki patch kritis, namun tidak mengambil patch lain yang dapat diterapkan yang akan menyebabkan kegagalan uji keamanan. Dalam hal ini SPL diasumsikan belum terpenuhi.