Panduan produsen untuk keamanan Android jangka panjang

Panduan ini menjelaskan praktik terbaik yang direkomendasikan Google untuk menerapkan patch keamanan yang dievaluasi oleh Android Compatibility Test Suite (CTS). Program 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 pernyataan penyangkalan

Panduan ini tidak mengikat Google atau produsen lain secara hukum atau kontraktual dan tidak dimaksudkan sebagai serangkaian persyaratan. Sebaliknya, panduan ini adalah alat bantu pengajaran yang menjelaskan praktik yang direkomendasikan.

Masukan

Panduan ini tidak dimaksudkan untuk menjadi komprehensif; revisi tambahan direncanakan. Kirim masukan ke manufacturers-guide-android@googlegroups.com.

Glosarium

Istilah Definisi
ACC Komitmen Kompatibilitas Android. Sebelumnya dikenal sebagai Perjanjian Anti-Fragmentasi Android (AFA).
AOSP Project Open Source Android
ASB Android Security Bulletin
BSP Board Support Package
CDD Compatibility Definition Document
CTS Compatibility Test Suite (CTS)
FOTA firmware over the air
GPS sistem penentuan posisi global
MISRA Motor Industry Software Reliability Association
NIST National Institute of Standards and Technology
OBD diagnostik on-board (OBD-II adalah peningkatan dari OBD-I dalam kemampuan dan standardisasi)
OEM produsen peralatan asli
OS sistem operasi
SEI Software Engineering Institute
SoC sistem di chip
SOP mulai produksi
SPL Tingkat Patch Keamanan
TPMS sistem pemantauan tekanan ban

Tentang Android OS

Android adalah tumpukan perangkat lunak lengkap berbasis Linux dan open source yang didesain untuk berbagai perangkat dan faktor bentuk. Sejak rilis pertamanya pada tahun 2008, Android telah menjadi Sistem Operasi (OS) terpopuler, yang mendukung lebih dari 1,4 miliar perangkat di seluruh dunia (2016). Sekitar 67% perangkat tersebut menggunakan Android 5.0 (Lollipop) atau yang lebih baru pada Maret 2017 (angka yang lebih baru tersedia di Dasbor Android). Meskipun sebagian besar perangkat adalah ponsel dan tablet, Android berkembang di smartwatch, 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 menentukan 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 yang kompatibel dengan Android yang mendukung fitur yang diperlukan untuk aplikasi.

Google merilis versi OS baru, update keamanan OS, dan informasi tentang kerentanan yang ditemukan secara rutin. Produsen harus meninjau Buletin Keamanan Android untuk mengetahui penerapan update ini pada produk yang didukung Android OS. Untuk meninjau keamanan, kompatibilitas, dan sistem build Android, lihat artikel berikut:

Tentang kendaraan terhubung (produk kanonis yang bertahan lama)

Kendaraan mulai terhubung dengan diperkenalkannya radio AM pada tahun 1920-an. Sejak saat itu, jumlah koneksi fisik dan nirkabel eksternal mulai bertambah seiring dengan beralihnya regulator dan produsen mobil ke elektronik untuk mempermudah diagnostik dan servis (misalnya, port OBD-II), meningkatkan keselamatan (misalnya, TPMS), dan memenuhi target efisiensi bahan bakar. Gelombang konektivitas berikutnya memperkenalkan fitur kenyamanan pengemudi seperti sistem masuk tanpa kunci jarak jauh, sistem telematika, dan fitur infotainment canggih seperti Bluetooth, Wi-Fi, dan proyeksi smartphone. Saat ini, sensor dan konektivitas terintegrasi (misalnya, GPS) mendukung sistem keselamatan dan mengemudi semi-otonom.

Seiring bertambahnya jumlah koneksi kendaraan, area potensi permukaan serangan kendaraan juga bertambah. Koneksi menghadirkan kumpulan masalah keamanan siber yang serupa dengan elektronik konsumen. Namun, meskipun reboot, update patch harian, dan perilaku yang tidak dapat dijelaskan adalah hal yang normal untuk elektronik konsumen, hal tersebut tidak konsisten untuk produk dengan sistem penting untuk 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 menanganinya.

Memastikan keamanan jangka panjang

Kendaraan yang terhubung sering kali memiliki satu atau beberapa unit kontrol elektronik (ECU) yang mencakup beberapa komponen software seperti OS, library, utilitas, dll. Produsen harus melacak komponen tersebut dan mengidentifikasi kerentanan yang dipublikasikan dan diketahui dengan analisis proaktif, termasuk:

  • Mengevaluasi produk secara rutin terhadap database Common Vulnerabilities and Exposures (CVE).
  • Pengumpulan informasi untuk mengetahui kelemahan keamanan terkait produk.
  • Pengujian keamanan.
  • Menganalisis Buletin Keamanan Android secara aktif.

Contoh update patch keamanan dan OS (IVI yang menjalankan Android):

Gambar 1. Contoh peluncuran update keamanan dan OS utama selama masa pakai kendaraan.

# Langkah Aktivitas

①

 Cabang Pengembangan Produsen memilih versi Android (Android X). Dalam contoh ini, "Android X" menjadi dasar dari apa yang akan dikirimkan di kendaraan dua tahun sebelum Awal Produksi (SOP) awal.
② Peluncuran Awal Beberapa bulan sebelum Android X menjadi versi OS pertama yang dikirimkan dalam produk, update keamanan diambil dari Buletin Keamanan Android (ASB) dan berpotensi dari sumber lain yang dianggap berharga oleh produsen. y2 = Buletin Keamanan kedua untuk Android versi X, diterapkan (di-backport) oleh produsen ke Android X. Update ini dikirimkan dalam produk dan timer produksi mulai berjalan pada Tahun Nol dengan Android X.y2.

Dalam contoh ini, produsen memutuskan tidak mengirimkan rilis tahunan Android X+1 yang lebih baru. Alasan untuk mengirimkan rilis terbaru mencakup penambahan fitur baru, mengatasi kerentanan keamanan baru, dan/atau mengirimkan layanan Google atau pihak ketiga yang memerlukan versi Android yang lebih baru. Alasan tidak mengirimkan 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.
③ Update OS Lengkap Setelah SOP, produsen merilis update OS Android X+2, yaitu dua rilis Android setelah versi yang digunakan untuk produk awal (Android X0). Update keamanan ASB tersedia untuk level API (mulai tanggal pengiriman), sehingga update akan dirilis sebagai X+2.y0 sekitar 1,25 tahun setelah SOP. Update OS ini mungkin kompatibel atau tidak kompatibel dengan produk di lapangan. Jika ya, rencana dapat dibuat untuk memperbarui kendaraan yang di-deploy.

Kecuali jika ada perjanjian bisnis lain, keputusan untuk melakukan update OS penuh sepenuhnya atas pertimbangan produsen.
④ Update Keamanan Dua tahun setelah masa produksi kendaraan, produsen melakukan patch pada Android X+2 OS. Keputusan ini didasarkan pada penilaian risiko produsen. Produsen memilih update keamanan ASB ketiga untuk rilis X+2 sebagai dasar update. Produk yang menerima update keamanan kini berada di Level Patch Keamanan Android + OS (X+2.y3).

Meskipun produsen dapat memilih patch keamanan individual dari setiap ASB individual, mereka harus memperbaiki semua masalah yang diperlukan dalam buletin untuk menggunakan tingkat patch keamanan (SPL) Android yang terkait dengan buletin (misalnya, 05-02-2017). Produsen bertanggung jawab untuk melakukan backport dan rilis keamanan untuk produk yang didukung.
⑤ Update OS Lengkap Pengulangan langkah 3 (Update OS Penuh), update OS penuh kedua akan mengupgrade produk ke Android X+4, tiga tahun setelah masa produksi kendaraan. Produsen kini menyeimbangkan persyaratan hardware yang lebih baru dari versi Android terbaru dengan hardware di produk dan manfaat pengguna dari OS Android yang diupdate. Produsen merilis update tanpa update keamanan, sehingga produk kini berada di OS (X+4.y0) + Level Patch Keamanan Android.

Dalam contoh ini, karena batasan hardware, X+4 adalah versi utama Android terakhir yang akan disediakan untuk produk ini, meskipun masa pakai kendaraan yang diharapkan selama 6+ tahun masih memerlukan dukungan keamanan.
⑥ Update Keamanan Pengulangan langkah 4 (Update Keamanan). Produsen memiliki tugas untuk mengambil update keamanan ASB dari Android versi yang jauh lebih baru (X+6) dan mem-porting beberapa atau semua update tersebut kembali ke Android X+4. Produsen bertanggung jawab untuk menggabungkan, mengintegrasikan, dan melakukan update (atau membuat kontrak dengan pihak ketiga). Selain itu, produsen harus menyadari bahwa masalah keamanan dalam versi Android yang tidak lagi didukung tidak tercakup dalam ASB.
⑦ Update Keamanan Delapan tahun setelah siklus proses produksi kendaraan, empat rilis Android sejak update OS terakhir di Langkah 5 (Update OS Penuh), dan sepuluh tahun sejak Android X ditentukan, beban untuk menyeleksi dan mem-backport patch keamanan sepenuhnya berada di produsen untuk versi yang lebih lama dari tiga tahun sejak rilis publik level API.

Praktik keamanan terbaik

Untuk mempersulit terjadinya pelanggaran keamanan, Google merekomendasikan dan menggunakan praktik terbaik yang diterima secara umum untuk keamanan dan rekayasa software, seperti yang dijelaskan dalam Menerapkan Keamanan.

Panduan keamanan

Praktik yang direkomendasikan untuk keamanan meliputi:

  • Gunakan versi terbaru library eksternal dan komponen open source.
  • Jangan menyertakan fungsi debug yang mengganggu dalam versi rilis OS.
  • Hapus fungsi yang tidak digunakan (untuk mengurangi permukaan serangan yang tidak diperlukan).
  • Gunakan prinsip hak istimewa terendah dan praktik terbaik pengembangan aplikasi Android lainnya.

Pedoman pengembangan software

Praktik yang direkomendasikan untuk pengembangan software yang aman selama siklus proses sistem mencakup:

  • Lakukan pemodelan ancaman untuk memberi peringkat dan mengidentifikasi aset, ancaman, dan potensi mitigasi.
  • Lakukan peninjauan arsitektur/desain untuk memastikan desain yang aman dan tepat.
  • Lakukan peninjauan kode secara rutin untuk mengidentifikasi anti-pola dan bug sesegera mungkin.
  • Merancang, menerapkan, dan menjalankan pengujian unit dengan cakupan kode tinggi, termasuk:
    • Pengujian fungsional (termasuk kasus pengujian negatif)
    • Pengujian regresi rutin (untuk memastikan bug yang telah 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, UndefinedBehaviorSanitizer, dan FORTIFY_SOURCE (untuk komponen native) guna mengidentifikasi dan memitigasi potensi masalah selama pengembangan sistem.
  • Memiliki strategi pengelolaan untuk kode sumber software dan konfigurasi/versi rilis.
  • Memiliki strategi pengelolaan patch untuk pembuatan dan deployment patch software.

Kebijakan porting balik keamanan

Saat ini, Google memberikan dukungan aktif untuk backport keamanan kerentanan keamanan yang ditemukan dan dilaporkan selama tiga (3) tahun sejak rilis publik level API. Dukungan aktif terdiri dari hal berikut:

  1. Menerima dan menyelidiki laporan kerentanan.
  2. Membuat, menguji, dan merilis update keamanan.
  3. Menyediakan rilis berulang update keamanan dan detail buletin keamanan.
  4. Lakukan penilaian tingkat keparahan sesuai dengan panduan yang telah ditetapkan.

Setelah tiga tahun sejak tanggal rilis publik level API, Google merekomendasikan panduan berikut:

  • Gunakan pihak ketiga (seperti vendor SoC atau penyedia Kernel) untuk dukungan backport untuk update keamanan OS yang lebih lama dari tiga tahun sejak rilis API.
  • Gunakan pihak ketiga untuk melakukan peninjauan kode menggunakan ASB yang disediakan secara publik. Meskipun ASB mengidentifikasi kerentanan untuk versi yang saat ini didukung, produsen dapat menggunakan informasi yang diberikan untuk membandingkan update yang baru dirilis dengan versi sebelumnya. Data ini dapat digunakan untuk melakukan analisis dampak dan berpotensi membuat patch serupa untuk versi OS yang lebih lama dari tiga tahun sejak rilis API.
  • Jika sesuai, upload update keamanan ke Android Open Source Project (AOSP).
  • Produsen harus mengoordinasikan penanganan update keamanan untuk kode khusus vendor (misalnya, kode khusus perangkat berpemilik).
  • Produsen harus bergabung dengan grup notifikasi Pratinjau Partner Buletin Keamanan Android NDA (memerlukan penandatanganan perjanjian hukum seperti NDA Developer). Buletin harus mencakup:
    • Pengumuman
    • Ringkasan masalah menurut tingkat patch, termasuk CVE dan tingkat keparahan
    • Detail kerentanan jika sesuai

Referensi tambahan

Untuk mengetahui petunjuk tentang praktik coding dan pengembangan software yang aman, lihat artikel berikut:

Google mendorong penggunaan praktik yang direkomendasikan berikut.

Secara umum, sebaiknya 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 lama dengan versi OS baru yang memiliki lebih sedikit kerentanan keamanan yang diketahui dan perlindungan keamanan yang ditingkatkan.

Panduan yang direkomendasikan meliputi:

  • Karena waktu tunggu pengembangan yang lama dan melekat pada proses pengembangan kendaraan, produsen mungkin perlu meluncurkan dengan OS versi n-2 atau yang lebih lama.
  • Mempertahankan kepatuhan dengan Kompatibilitas Android untuk setiap versi OS Android yang dirilis dengan kampanye over-the-air (OTA).
  • Terapkan produk yang kompatibel dengan Firmware-over-the-air (FOTA) Android untuk update yang cepat dan mudah bagi pelanggan. FOTA harus dilakukan menggunakan praktik terbaik keamanan seperti penandatanganan kode dan koneksi TLS antara produk dan back office IT.
  • Kirimkan kerentanan keamanan Android yang diidentifikasi secara independen kepada tim Keamanan Android.

Catatan: Google telah mempertimbangkan notifikasi khusus jenis perangkat atau industri dalam 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 pada masalah keamanan tertentu dengan jenis perangkat.

Produsen harus berupaya menggunakan versi OS terbaru atau update keamanan untuk versi yang digunakan selama peningkatan siklus produk. Pembaruan dapat dilakukan selama pembaruan produk berkala yang berulang, atau untuk perbaikan cepat guna mengatasi masalah kualitas dan/atau masalah lainnya. Praktik yang direkomendasikan meliputi:

  • Buat rencana untuk menangani update driver, kernel, dan protokol.
  • Gunakan metode yang sesuai dengan industri untuk memberikan update pada kendaraan yang telah di-deploy.

Compatibility Definition Document (CDD)

Compatibility Definition Document (CDD) menjelaskan persyaratan agar perangkat dianggap kompatibel dengan Android. CDD bersifat publik dan tersedia untuk semua orang; Anda dapat mendownload versi CDD dari Android 1.6 hingga versi terbaru dari source.android.com.

Untuk memenuhi persyaratan ini, produk harus melalui langkah-langkah dasar berikut:

  1. Partner menandatangani Komitmen Kompatibilitas Android (ACC) dengan Google. Kemudian, Konsultan Solusi Teknis (TSC) akan ditetapkan sebagai pemandu.
  2. Partner menyelesaikan peninjauan CDD untuk versi OS Android produk.
  3. Partner menjalankan dan mengirimkan hasil CTS (dijelaskan di bawah) hingga hasilnya dapat diterima untuk Kompatibilitas Android.

Compatibility Test Suite (CTS)

Alat pengujian Compatibility Test Suite (CTS) memverifikasi bahwa penerapan produk kompatibel dengan Android dan patch keamanan terbaru disertakan. CTS bersifat publik, open source, dan tersedia untuk semua orang; Anda dapat mendownload versi CTS dari Android 1.6 hingga versi terbaru dari source.android.com.

Setiap build software Android yang dirilis ke publik (image penginstalan pabrik dan update di lapangan) harus membuktikan Kompatibilitas Android melalui hasil CTS. Misalnya, jika perangkat menjalankan Android 7.1, versi CDD 7.1 dan CTS 7.1 yang sesuai dan terbaru harus dirujuk saat image build niat rilis dibuat dan diuji. Produsen sangat dianjurkan untuk menggunakan CTS sejak awal dan sering kali untuk mengidentifikasi dan memperbaiki masalah.

CATATAN: Partner yang menandatangani perjanjian lain, seperti Layanan Seluler Google (GMS), mungkin perlu memenuhi persyaratan lain.

Alur kerja CTS

Alur kerja CTS mencakup penyiapan lingkungan pengujian, menjalankan pengujian, menafsirkan hasil, dan memahami kode sumber CTS. Panduan berikut dimaksudkan untuk membantu pengguna CTS (misalnya, developer, produsen) menggunakan CTS secara efektif dan efisien.

  • Jalankan pengujian secara berkala. CTS dirancang sebagai alat otomatis yang terintegrasi ke dalam sistem build Anda. Menjalankan CTS secara berkala dapat membantu Anda menemukan kerusakan dengan cepat dan lebih awal saat terjadi penurunan kualitas atau regresi software.
  • Download dan periksa kode sumber CTS. Kode sumber CTS lengkap adalah software open source yang dapat didownload dan digunakan oleh siapa saja (kode sumber yang didownload dapat sepenuhnya dibangun dan dijalankan). Jika pengujian gagal di perangkat, memeriksa bagian kode sumber yang relevan dapat membantu Anda mengidentifikasi penyebabnya.
  • Dapatkan CTS terbaru. Rilis Android baru dapat mengupdate CTS dengan perbaikan bug, peningkatan, dan pengujian baru. Periksa Download CTS secara berkala dan perbarui program CTS Anda sesuai kebutuhan. Produsen dan Google akan menyetujui versi CTS yang akan lulus untuk peluncuran produk karena produk harus dihentikan pada suatu titik saat CTS terus diperbarui.

Lulus CTS

Untuk produk yang Kompatibel dengan Android, Google memastikan hasil pengujian CTS dan CTS Verifier perangkat dapat diterima. Pada prinsipnya, semua pengujian harus berhasil. Namun, pengujian yang gagal karena alasan selain perangkat tidak mematuhi persyaratan Kompatibilitas Android dapat ditinjau oleh Google. Selama proses ini:

  1. Produsen memberikan patch CTS yang diusulkan, validasi patch, dan justifikasi kepada Google untuk membuktikan argumen tersebut.
  2. Google memeriksa materi yang dikirimkan, dan jika diterima, akan memperbarui tes CTS yang relevan sehingga perangkat akan lulus dalam revisi CTS berikutnya.

Jika pengujian CTS tiba-tiba gagal setelah menerapkan patch keamanan, produsen harus mengubah patch agar tidak merusak kompatibilitas ATAU menunjukkan bahwa pengujian salah dan memberikan perbaikan untuk pengujian tersebut (seperti yang dijelaskan di atas).

CTS tetap terbuka untuk peninjauan perbaikan pengujian. Misalnya, Android 4.4 terus menerima perbaikan (lihat https://android-review.googlesource.com/c/platform/cts/+/273371).

Pertanyaan Umum (FAQ)

T: Siapa yang bertanggung jawab untuk menerapkan update keamanan pada penerapan Android tertentu?

J: Produsen yang menyediakan perangkat secara langsung bertanggung jawab. Entitas ini bukan Google, yang memublikasikan update keamanan di AOSP, 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 update keamanan rutin. Sejak Agustus 2015, Google telah mempertahankan ritme rutin dalam memublikasikan buletin dan link ke update di source.android.com; Google juga memublikasikan update keamanan sebagai bagian dari rilis OS utama. Lihat juga Kebijakan porting balik keamanan.

T: Jika produsen mengintegrasikan semua patch AOSP dari ASB, tetapi tidak mengintegrasikan patch dari vendor BSP yang disebutkan dalam buletin yang sama, apakah produsen tersebut masih dapat meningkatkan level keamanan (misalnya, menerapkan patch yang sesuai ke platform/build)?

J: Untuk menyatakan tingkat patch keamanan Android (SPL), produsen harus mengatasi semua masalah yang diperlukan yang dipublikasikan dalam 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 yang diperlukan yang didokumentasikan dalam buletin Maret 2017 untuk SPL tersebut dan semua update sebelumnya, termasuk update khusus perangkat untuk semua Buletin Keamanan Android sebelumnya, termasuk update khusus perangkat yang terkait dengan SPL 05-02-2017.

T: Apa yang terjadi jika produsen tidak menyetujui update keamanan yang disediakan oleh vendor BSP ATAU jika update keamanan yang diwajibkan oleh ASB tidak disediakan oleh vendor?

J: ASB menjelaskan kerentanan keamanan (yang tercantum dalam daftar CVE) dan sering kali menyediakan pengujian keamanan yang cocok. Tujuannya adalah untuk memastikan kerentanan yang tercantum tidak dapat lagi direproduksi di perangkat dan perangkat dapat lulus uji keamanan terkait. Oleh karena itu, masalahnya bukan tentang menginstal update keamanan yang disediakan oleh Google atau vendor pihak ketiga, tetapi tentang produsen yang menyatakan bahwa perangkat tidak rentan terhadap daftar CVE di ASB. Produsen bebas menggunakan update keamanan yang disediakan atau, jika mereka memiliki perubahan yang lebih sesuai untuk perangkat mereka, menggunakan perubahan tersebut.

Misalnya, pertimbangkan kasus saat Google mengatasi kerentanan keamanan AOSP menggunakan perubahan kode yang memungkinkan komponen tetap berfungsi penuh dan mematuhi CDD. Jika produsen menentukan bahwa komponen tidak diperlukan di perangkat atau tidak diwajibkan oleh CDD (atau pengujian sertifikasi terkait), produsen dapat menghapus komponen untuk mengurangi kebutuhan servis di masa mendatang dan mengurangi permukaan serangan. Meskipun produsen tidak menggunakan update keamanan yang disediakan, produsen memastikan perangkat tidak rentan terhadap CVE yang didokumentasikan dalam buletin keamanan. Namun, dengan menyimpang dari update keamanan yang direkomendasikan, produsen mengambil risiko salah menangani masalah, memperkenalkan kerentanan keamanan baru, atau mengurangi fungsi build akhir.

Meskipun kami bekerja sama dengan semua partner SoC untuk memastikan perbaikan tersedia untuk semua masalah dalam ASB, sebaiknya produsen mendapatkan perjanjian servis dengan vendor SoC mereka untuk siklus proses perangkat. SoC dapat berhenti melayani chipset lebih awal dari yang diinginkan, sehingga membuat perjanjian sebelum pemilihan chipset perangkat adalah bagian penting dari proses peluncuran perangkat.

Terakhir, jika tidak mungkin untuk mendapatkan atau membuat perbaikan secara langsung dan independen 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 pada sertifikasi build (karena Android memastikan tingkat patch keamanan terbaru tersedia di perangkat bersertifikasi). Google merekomendasikan agar Anda bekerja sama dengan SoC Anda terlebih dahulu untuk menghindari praktik ini.

T: Jika produsen menentukan bahwa item ASB tidak berlaku untuk produknya, apakah item tersebut tetap perlu diterapkan atau di-patch agar memenuhi persyaratan Google lainnya atau lulus CTS?

J: Kami tidak mewajibkan patch untuk diterapkan guna menyatakan level patch keamanan Android (SPL); kami mewajibkan produsen menyatakan bahwa build mereka tidak rentan terhadap masalah tersebut.

Salah satu contohnya adalah saat komponen yang di-patch tidak ada di sistem produsen, atau komponen dihapus dari sistem produsen untuk mengatasi masalah. Dalam hal ini, sistem mungkin mematuhi tanpa mengharuskan produsen menerapkan patch.

Hal ini pada dasarnya berbeda dengan produsen yang, misalnya, hanya ingin memperbaiki patch penting, tetapi tidak menerapkan patch lain yang berlaku sehingga menyebabkan pengujian keamanan gagal. Dalam hal ini, SPL diasumsikan belum terpenuhi.