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 (Produsen) yang Kompatibel dengan Android yang akan didukung lebih dari tiga (3) tahun seperti kendaraan, TV, dekoder, peralatan rumah tangga, dll. Panduan ini tidak ditujukan untuk pengguna akhir ( misalnya, pemilik kendaraan).
Ucapan Terima Kasih & Penafian
Panduan ini tidak mengikat Google atau Produsen lain secara hukum atau kontraktual dan tidak dimaksudkan sebagai kumpulan persyaratan. Sebaliknya, panduan ini adalah bantuan instruksional yang menjelaskan praktik yang direkomendasikan.
Masukan
Panduan ini tidak dimaksudkan untuk komprehensif; revisi tambahan direncanakan. Kirim umpan balik ke manufacturer-guide-android@googlegroups.com.
Glosarium
| Ketentuan | Definisi |
|---|---|
| ACC | Komitmen Kompatibilitas Android. Sebelumnya dikenal sebagai Android Anti-Fragmentation Agreement (AFA). |
| AOSP | Proyek Sumber Terbuka Android |
| ASB | Buletin Keamanan Android |
| BSP | Paket Dukungan Papan |
| CDD | Dokumen Definisi Kompatibilitas |
| CTS | Suite Uji Kompatibilitas |
| FOTA | Firmware Over The Air |
| GPS | Sistem Pemosisian Global |
| MISRA | Asosiasi Keandalan Perangkat Lunak Industri Motor |
| NIST | Institut Standar dan Teknologi Nasional |
| OBD | Diagnostik On-Board ( OBD-II adalah peningkatan dari OBD-I dalam kemampuan dan standarisasi ) |
| OEM | Produsen Peralatan Asli |
| OS | Sistem operasi |
| SEI | Institut Rekayasa Perangkat Lunak |
| SOC | Sistem pada Chip |
| SOP | Mulai Produksi |
| SPL | Tingkat Patch Keamanan |
| TPMS | Sistem pemantauan tekanan ban |
Tentang Android OS
Android adalah kumpulan perangkat lunak lengkap berbasis Linux open source 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 yang lebih baru pada Maret 2017 (angka terbaru tersedia di Dasbor Android ). Sementara sebagian besar perangkat 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 Compatibility Definition Document (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 teratur. Buletin Keamanan Android harus ditinjau oleh Produsen untuk penerapan pembaruan ini pada produk yang didukung OS Android. Untuk ulasan tentang keamanan, kompatibilitas, dan sistem build Android, lihat yang berikut:
- Amankan Perangkat Android
- Pembaruan dan Sumber Daya Keamanan
- Suite Uji Kompatibilitas
- Nama Kode, Tag, dan Nomor Pembuatan
Tentang Kendaraan Terhubung (Produk Berumur Panjang Canonical)
Kendaraan mulai terhubung dengan pengenalan radio AM pada tahun 1920-an. Dari sana, jumlah koneksi fisik dan nirkabel eksternal mulai bertambah ketika regulator dan pembuat mobil beralih ke elektronik untuk memudahkan diagnostik dan layanan (misalnya, port OBD-II), meningkatkan keselamatan (misalnya, TPMS), dan memenuhi target penghematan bahan bakar. . Gelombang konektivitas berikut memperkenalkan fitur kenyamanan pengemudi seperti remote keyless entry, sistem telematika, dan fitur infotainment canggih seperti Bluetooth, Wi-Fi, dan proyeksi smartphone. Saat ini, sensor dan konektivitas terintegrasi (misalnya, GPS) mendukung keselamatan dan sistem mengemudi semi-otonom.
Seiring dengan bertambahnya jumlah sambungan kendaraan, demikian pula area permukaan serangan kendaraan yang potensial. Koneksi membawa serta kumpulan masalah keamanan siber yang serupa dengan elektronik konsumen. Namun, meskipun reboot, pembaruan tambalan harian, dan perilaku yang tidak dapat dijelaskan adalah norma untuk elektronik konsumen, hal itu tidak konsisten untuk produk dengan sistem kritis keselamatan seperti kendaraan.
Produsen harus mengambil pendekatan proaktif untuk memastikan postur keamanan dan keselamatan produk yang berkelanjutan di lapangan. Singkatnya, Produsen harus menyadari kerentanan keamanan yang diketahui dalam produk dan mengambil pendekatan berbasis risiko untuk mengatasinya.
Memastikan 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 dipublikasikan dengan analisis proaktif, termasuk:
- Secara teratur mengevaluasi produk terhadap 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 pembaruan keamanan dan OS utama selama masa pakai kendaraan.
| # | Melangkah | Kegiatan |
|---|---|---|
| Cabang Pengembangan | Produsen memilih versi Android (Android X). Dalam contoh ini, 'Android X' menjadi dasar dari apa yang akan dikirimkan dalam kendaraan dua tahun sebelum Start of Production (SOP) awal. | |
| Peluncuran Awal | Beberapa bulan sebelum Android X menjadi versi OS pertama yang dikirimkan dalam produk, pembaruan keamanan diambil dari Android Security Bulletins (ASB) dan kemungkinan sumber lain yang dianggap berharga oleh Produsen. y2 = Buletin Keamanan kedua untuk Android versi X, diterapkan (di-backport) oleh Produsen ke Android X. Pembaruan ini dikirimkan dalam produk dan jam produksi mulai berdetak di Tahun Nol dengan Android X.y2. Dalam contoh ini, Produsen membuat 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, yang merupakan dua rilis Android setelah versi yang digunakan untuk produk awal (Android X0). Pembaruan keamanan ASB tersedia untuk level API (sejak tanggal pengiriman), sehingga pembaruan keluar sebagai X+2.y0 sekitar 1,25 tahun setelah SOP. Pembaruan OS ini mungkin kompatibel atau tidak dengan produk yang diterjunkan. Jika ya, 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 sekarang berada di (X+2.y3) OS + Android Security Patch Level. Meskipun Produsen dapat memilih patch keamanan individual dari ASB individu mana pun, mereka harus memperbaiki semua masalah yang diperlukan dalam buletin untuk menggunakan level patch keamanan (SPL) Android yang terkait dengan buletin (misalnya, 02-05-2017). Produsen bertanggung jawab untuk melakukan backport dan rilis keamanan untuk produk yang didukung. | |
| Pembaruan OS Lengkap | Pengulangan langkah 3 (Pembaruan OS Penuh), pembaruan OS lengkap kedua membawa produk ke Android X+4, tiga tahun ke masa produksi kendaraan. Pabrikan sekarang menyeimbangkan persyaratan perangkat keras yang lebih baru dari versi Android terbaru dengan perangkat keras dalam produk dan pengguna mendapat manfaat dari OS Android yang diperbarui. Pabrikan merilis pembaruan tanpa pembaruan keamanan, sehingga produk sekarang berada di (X+4.y0) OS + Android Security Patch Level. Dalam contoh ini, karena keterbatasan perangkat keras, X+4 adalah versi utama Android terakhir yang akan disediakan untuk produk ini, meskipun masa pakai kendaraan yang diharapkan 6+ tahun masih memerlukan dukungan keamanan. | |
| Pembaruan Keamanan | Pengulangan langkah 4 (Pembaruan Keamanan). Pabrikan memiliki 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. Produsen bertanggung jawab untuk menggabungkan, mengintegrasikan, dan melakukan pembaruan (atau membuat kontrak dengan pihak ketiga). Selain itu, produsen harus menyadari bahwa masalah keamanan di versi Android yang tidak lagi didukung tidak akan tercakup dalam ASB. | |
| Pembaruan Keamanan | Delapan tahun dalam siklus produksi kendaraan, empat rilis Android sejak pembaruan OS terakhir di Langkah 5 (Pembaruan OS Penuh), dan sepuluh tahun sejak Android X ditetapkan, beban kurasi dan backport patch keamanan sepenuhnya ada di Produsen untuk versi yang lebih lama dari tiga tahun dari rilis publik tingkat API. |
Praktik Terbaik Keamanan
Untuk mempersulit penyusupan keamanan, Google merekomendasikan dan menerapkan praktik terbaik yang diterima secara umum untuk keamanan dan rekayasa perangkat lunak, seperti yang dijelaskan dalam Menerapkan Keamanan .
Pedoman Keamanan
Praktik yang disarankan untuk keamanan meliputi:
- Gunakan versi terbaru dari library eksternal dan komponen open source.
- Jangan sertakan fungsionalitas debug yang mengganggu dalam versi rilis OS.
- Hapus fungsionalitas yang tidak digunakan (untuk mengurangi permukaan serangan yang tidak dibutuhkan).
- Gunakan prinsip hak istimewa paling rendah 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 tinjauan kode reguler 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 fuzzy (sebagai bagian dari unit test suite)
- Gunakan alat analisis kode sumber statis (scan-build, lint, dll.) untuk mengidentifikasi potensi masalah.
- Gunakan alat analisis kode sumber dinamis, seperti AddressSanitizer, UndefinedBehaviorSanitizer, 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 tambalan untuk pembuatan dan penyebaran tambalan 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:
- Menerima dan menyelidiki laporan kerentanan.
- Buat, uji, dan rilis pembaruan keamanan.
- Berikan rilis berulang pembaruan keamanan dan detail buletin keamanan.
- Lakukan penilaian 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 untuk umum. Sementara ASB mengidentifikasi kerentanan untuk versi yang saat ini didukung, Produsen dapat menggunakan informasi yang disediakan 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, unggah pembaruan keamanan ke Android Open Source Project (AOSP).
- Produsen harus mengoordinasikan penanganan pembaruan keamanan untuk kode khusus vendor (misalnya, kode khusus perangkat berpemilik).
- Produsen harus bergabung dengan grup pemberitahuan Pratinjau Mitra Buletin Keamanan Android NDA (memerlukan penandatanganan perjanjian hukum seperti NDA Pengembang). Buletin harus mencakup:
- Pengumuman
- Ringkasan masalah menurut level patch, termasuk CVE dan tingkat keparahan
- Detail kerentanan jika sesuai
Referensi Tambahan
Untuk instruksi tentang pengkodean aman dan praktik pengembangan perangkat lunak, lihat yang berikut ini:
- Asosiasi Keandalan Perangkat Lunak Industri Motor (MISRA) .
- Perangkat & Metode Software Engineering Institute (SEI) .
- Institut Nasional Standar dan Teknologi (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 penguncian versi diperlukan untuk mendorong stabilitas sebelum pengujian dan validasi, Produsen harus menyeimbangkan stabilitas produk yang diperoleh dari versi OS yang lebih lama dengan versi OS yang lebih baru yang memiliki lebih sedikit kerentanan keamanan yang diketahui dan perlindungan keamanan yang ditingkatkan.
Pedoman yang direkomendasikan meliputi:
- Karena waktu tunggu pengembangan yang lama yang melekat pada proses pengembangan kendaraan, Produsen mungkin perlu meluncurkan dengan OS versi n-2 atau lebih lama.
- Pertahankan kesesuaian dengan Kompatibilitas Android untuk setiap versi OS Android yang dirilis melalui kampanye over-the-air (OTA).
- Menerapkan produk Android Firmware-over-the-air (FOTA)-mampu untuk pembaruan yang cepat dan ramah pelanggan. FOTA harus dilakukan dengan menggunakan praktik terbaik keamanan seperti penandatanganan kode dan koneksi TLS antara produk dan backoffice TI.
- Kirim kerentanan keamanan Android yang diidentifikasi secara independen ke 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 yang dapat dikenakan, telepon, dll.), Google tidak memiliki cara deterministik untuk melabeli masalah keamanan tertentu dengan 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 berulang, atau untuk perbaikan terbaru untuk mengatasi masalah kualitas dan/atau lainnya. Praktik yang direkomendasikan meliputi:
- Buat rencana untuk mengatasi pembaruan driver, kernel, dan protokol.
- Memanfaatkan metode yang sesuai industri untuk menyediakan pembaruan untuk 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 ke versi terbaru dari source.android.com .
Memenuhi persyaratan ini untuk suatu produk melibatkan langkah-langkah dasar berikut:
- Mitra menandatangani Komitmen Kompatibilitas Android (ACC) dengan Google. Konsultan Solusi Teknis (TSC) kemudian ditugaskan sebagai pemandu.
- Mitra menyelesaikan tinjauan CDD untuk versi OS Android produk.
- Mitra menjalankan dan mengirimkan hasil CTS (dijelaskan di bawah) hingga hasilnya dapat diterima untuk Kompatibilitas Android.
Suite Uji Kompatibilitas (CTS)
Alat pengujian Compatibility Test Suite (CTS) memverifikasi implementasi produk kompatibel dengan Android dan patch keamanan terbaru disertakan. CTS bersifat publik, open source, dan tersedia untuk semua orang; Anda dapat mengunduh versi CTS dari Android 1.6 ke versi terbaru dari source.android.com .
Setiap build perangkat lunak Android yang dirilis ke publik (gambar pemasangan 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 direferensikan saat gambar build maksud rilis dibuat dan diuji. Produsen sangat dianjurkan untuk menggunakan CTS lebih awal dan sering untuk mengidentifikasi dan memperbaiki masalah.
Alur Kerja CTS
Alur kerja CTS melibatkan pengaturan lingkungan pengujian, menjalankan pengujian, menafsirkan hasil, dan memahami kode sumber CTS. Panduan berikut dimaksudkan untuk membantu pengguna CTS (misalnya, pengembang, produsen) menggunakan CTS secara efektif dan efisien.
- Jalankan tes sering . CTS dirancang sebagai alat otomatis yang terintegrasi ke dalam sistem pembangunan Anda. Menjalankan CTS dengan sering dapat membantu Anda menemukan cacat dengan cepat dan dini saat 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 siapa saja (kode sumber yang diunduh sepenuhnya dapat dibuat dan dijalankan). Saat 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 seperlunya. Produsen dan Google harus menyetujui versi CTS untuk lolos peluncuran produk karena produk harus dibekukan di beberapa titik sementara CTS terus diperbarui.
Lulus CTS
Untuk produk yang Kompatibel dengan Android, Google memastikan perangkat CTS dan CTS Verifier melaporkan hasil pengujian dapat diterima. Pada prinsipnya, semua tes harus lulus. Namun, pengujian yang gagal karena alasan selain perangkat yang tidak sesuai dengan persyaratan Kompatibilitas Android harus ditinjau oleh Google. Selama proses ini:
- Produsen memberi Google patch CTS yang diusulkan, validasi patch, dan pembenaran untuk membuktikan argumen.
- Google memeriksa materi yang dikirimkan, dan jika diterima, memperbarui tes CTS yang relevan sehingga perangkat akan lulus dalam revisi CTS berikutnya.
Jika tes CTS tiba-tiba gagal setelah menerapkan patch keamanan, Produsen harus memodifikasi patch agar tidak merusak kompatibilitas ATAU menunjukkan bahwa pengujian salah dan memberikan perbaikan untuk pengujian (seperti dijelaskan di atas).
CTS tetap terbuka untuk tinjauan 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 untuk menerapkan pembaruan keamanan ke implementasi Android tertentu?
A: Produsen yang secara langsung menyediakan perangkat bertanggung jawab. Entitas ini bukan Google, yang menerbitkan 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 kemungkinan perbaikan, yang disediakan Google untuk semua level API yang didukung sebagai bagian dari proses pembaruan keamanan reguler. Sejak Agustus 2015, Google telah mempertahankan irama penerbitan buletin dan tautan ke pembaruan ke source.android.com ; 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 tetapi tidak mengintegrasikan patch dari vendor BSP yang disebutkan dalam buletin yang sama, apakah 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 yang diperlukan yang dipublikasikan di Android Security Bulletin ( termasuk buletin sebelumnya ) dan dipetakan ke Android SPL tertentu. Misalnya, Produsen yang menggunakan Buletin Keamanan Maret 2017 (SPL 2017-03-01) telah mengatasi semua masalah yang diperlukan 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 ketika Produsen tidak setuju dengan pembaruan keamanan yang disediakan oleh vendor BSP ATAU ketika pembaruan keamanan yang diamanatkan oleh ASB tidak disediakan oleh vendor?
J: ASB menjelaskan kerentanan keamanan (dihitung dengan daftar CVE) dan sering menyediakan tes keamanan yang cocok. Tujuannya adalah untuk memastikan kerentanan yang terdaftar tidak lagi dapat direproduksi pada perangkat dan perangkat tersebut dapat lulus uji keamanan terkait. Dengan demikian, masalahnya bukan tentang mengambil pembaruan keamanan yang disediakan oleh Google atau vendor pihak ketiga, tetapi tentang Produsen yang membuktikan bahwa perangkat tidak rentan terhadap daftar CVE di ASB. Produsen bebas menggunakan pembaruan keamanan yang disediakan atau, jika mereka memiliki perubahan yang lebih sesuai dengan perangkat mereka, gunakan perubahan itu sebagai gantinya.
Misalnya, pertimbangkan kasus di mana Google mengatasi kerentanan keamanan AOSP menggunakan perubahan kode yang memungkinkan komponen tetap berfungsi penuh dan sesuai dengan CDD. Jika Pabrikan menentukan bahwa komponen tidak diperlukan pada perangkat atau tidak dimandatkan oleh CDD (atau pengujian sertifikasi terkait), Pabrikan dapat menghapus komponen untuk mengurangi kebutuhan servis di masa mendatang dan mengurangi permukaan serangan. Meskipun Produsen tidak menggunakan pembaruan keamanan yang disediakan, itu memastikan perangkat tidak rentan terhadap CVE yang didokumentasikan dalam buletin keamanan. Namun, menyimpang dari pembaruan keamanan yang direkomendasikan, Pabrikan mengambil risiko salah menangani masalah, memperkenalkan kerentanan keamanan baru, atau mengurangi fungsionalitas build final.
Sementara kami bekerja dengan semua mitra SoC untuk memastikan ada perbaikan untuk semua masalah di ASB, kami menyarankan agar Produsen mengamankan perjanjian servis dengan vendor SoC mereka untuk siklus hidup perangkat. SoC mungkin berhenti memperbaiki chipset lebih awal dari yang diinginkan, jadi membuat perjanjian sebelum pemilihan chipset perangkat merupakan bagian penting dari proses peluncuran perangkat.
Terakhir, jika tidak mungkin untuk secara langsung memperoleh atau secara mandiri membuat perbaikan untuk masalah yang didokumentasikan dalam ASB, Produsen dapat mempertahankan SPL Android sebelumnya dan tetap menambahkan perbaikan baru yang tersedia ke build. Namun, praktik ini pada akhirnya akan menyebabkan masalah dengan sertifikasi build (karena Android memastikan level patch keamanan terbaru tersedia di perangkat bersertifikat). Google merekomendasikan untuk bekerja dengan SoC Anda terlebih dahulu untuk menghindari praktik ini.
T: Jika produsen menentukan item ASB tidak berlaku untuk produk mereka, apakah item tersebut masih perlu diterapkan atau ditambal untuk memenuhi persyaratan Google lainnya atau untuk lulus CTS?
J: Kami tidak memerlukan patch untuk menyatakan level patch keamanan (SPL) Android; kami memang mengharuskan Pabrikan membuktikan bahwa build mereka tidak rentan terhadap masalah tersebut.
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 sesuai tanpa mengharuskan Pabrikan untuk mengambil tambalan.
Ini pada dasarnya berbeda dari Produsen yang ingin, misalnya, hanya memperbaiki tambalan kritis, sementara tidak mengambil tambalan lain yang berlaku yang akan menyebabkan uji keamanan gagal. Dalam hal ini SPL diasumsikan belum terpenuhi.