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). Fitur ini ditujukan untuk produsen peralatan OEM (produsen) yang kompatibel dengan Android 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).

Pengakuan dan pernyataan penyangkalan

Panduan ini tidak mengikat Google atau produsen lain secara hukum atau kontrak dan tidak dimaksudkan sebagai kumpulan persyaratan. Sebaliknya, panduan ini adalah bantuan instruksional yang menjelaskan praktik yang direkomendasikan.

Masukan

Panduan ini tidak dimaksudkan untuk menjadi panduan yang komprehensif; revisi tambahan akan 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 pemosisi global
MISRA Motor Industry Software Reliability Association
NIST National Institute of Standards and Technology
OBD diagnostik onboard (OBD-II adalah peningkatan dari OBD-I dalam hal kemampuan dan standardisasi)
OEM produsen peralatan asli
OS sistem operasi
SEI Software Engineering Institute
SoC sistem di chip
SOP awal produksi
SPL Tingkat Patch Keamanan
TPMS sistem pemantauan tekanan ban

Tentang Android OS

Android adalah tumpukan software lengkap berbasis Linux dan open source yang dirancang 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 mulai Maret 2017 (angka terbaru tersedia di Dasbor Android). Meskipun sebagian besar perangkat adalah ponsel dan tablet, Android terus berkembang di smartwatch, TV, dan perangkat infotainment dalam kendaraan (IVI) otomotif.

Jumlah aplikasi Android yang tersedia di Google Play Store telah mencapai lebih dari 2,2 juta (2016). Pengembangan aplikasi Android didukung oleh program Kompatibilitas Android, yang menentukan kumpulan persyaratan melalui Compatibility Definition Document (CDD) dan menyediakan alat pengujian melalui Compatibility Test Suite (CTS). Program kompatibilitas Android memastikan aplikasi Android dapat berjalan di perangkat yang kompatibel dengan Android dan mendukung fitur yang diperlukan untuk aplikasi.

Google merilis versi OS baru, update keamanan OS, dan informasi tentang kerentanan yang ditemukan secara rutin. Android Security Bulletin harus ditinjau oleh produsen untuk mengetahui penerapan update ini ke produk yang didukung Android OS. Untuk peninjauan sistem keamanan, kompatibilitas, dan build Android, lihat hal berikut:

Tentang kendaraan terhubung (produk kanonis dengan masa aktif lama)

Kendaraan mulai terhubung dengan diperkenalkannya radio AM pada tahun 1920-an. Dari sini, jumlah koneksi fisik dan nirkabel eksternal mulai berkembang seiring dengan regulator dan produsen mobil beralih ke elektronik untuk memudahkan diagnostik dan layanan (misalnya, port OBD-II), meningkatkan keamanan (misalnya, TPMS), dan memenuhi target penghematan bahan bakar. Gelombang konektivitas berikutnya memperkenalkan fitur kenyamanan pengemudi seperti kunci tanpa kunci jarak jauh, sistem telematika, dan fitur infotainmen lanjutan seperti Bluetooth, Wi-Fi, dan proyeksi smartphone. Saat ini, sensor dan konektivitas terintegrasi (misalnya, GPS) mendukung sistem keamanan dan sistem mengemudi semi-otonom.

Seiring meningkatnya jumlah koneksi kendaraan, area potensi permukaan serangan kendaraan juga meningkat. Koneksi membawa sekumpulan masalah keamanan cyber yang serupa dengan elektronik konsumen. Namun, meskipun memulai ulang, update patch harian, dan perilaku yang tidak dapat dijelaskan adalah hal yang wajar untuk elektronik konsumen, hal tersebut tidak konsisten untuk produk dengan sistem yang sangat penting bagi keselamatan seperti kendaraan.

Produsen harus mengambil pendekatan proaktif untuk memastikan postur keamanan dan keselamatan produk di lapangan tetap terjaga. Singkatnya, produsen harus mengetahui kerentanan keamanan yang diketahui dalam produk dan mengambil pendekatan berbasis risiko untuk mengatasinya.

Memastikan keamanan jangka panjang

Kendaraan 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 berkala berdasarkan database Common Vulnerabilities and Exposures (CVE).
  • Pengumpulan intelijen untuk menemukan celah keamanan terkait produk.
  • Pengujian keamanan.
  • Secara aktif menganalisis Buletin Keamanan Android.

Contoh update OS dan patch keamanan (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 dalam 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 Android Security Bulletin (ASB) dan kemungkinan sumber lain yang dianggap berharga oleh produsen. y2 = Security Bulletin kedua untuk Android versi X, diterapkan (di-backport) oleh produsen ke Android X. Update ini dikirimkan dalam produk dan jam produksi mulai berdetak pada Tahun Nol dengan Android X.y2.

Dalam contoh ini, produsen membuat keputusan tidak untuk mengirimkan rilis tahunan Android X+1 terbaru. 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 melawan 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.
③ Update OS Lengkap Setelah SOP, produsen merilis update OS Android X+2, yang merupakan dua rilis Android setelah versi yang digunakan untuk produk awal (Android X0). Update keamanan ASB tersedia untuk level API (sejak tanggal pengiriman), sehingga update akan dikirim sebagai X+2.y0 sekitar 1,25 tahun setelah SOP. Update OS ini mungkin kompatibel atau tidak kompatibel dengan produk yang diluncurkan. Jika demikian, rencana dapat dibuat untuk memperbarui kendaraan yang di-deploy.

Kecuali jika ada perjanjian bisnis lain, keputusan untuk melakukan update OS penuh sepenuhnya merupakan 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 OS (X+2.y3) + Level Patch Keamanan Android.

Meskipun produsen dapat memilih patch keamanan individual dari setiap ASB, mereka harus memperbaiki semua masalah yang diperlukan dalam buletin untuk menggunakan tingkat patch keamanan Android (SPL) yang terkait dengan buletin (misalnya, 05-02-2017). Produsen bertanggung jawab untuk melakukan backport dan merilis keamanan untuk produk yang didukung.
⑤ Update OS Lengkap Pengulangan langkah 3 (Update OS Lengkap), update OS lengkap 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 dalam produk dan manfaat pengguna dari Android OS yang diupdate. Produsen merilis update tanpa update keamanan, sehingga produk kini berada di Level Patch Keamanan Android + OS (X+4.y0).

Dalam contoh ini, karena batasan hardware, X+4 adalah versi utama Android terakhir yang akan disediakan untuk produk ini, meskipun masa pakai yang diharapkan untuk kendaraan masih memerlukan dukungan keamanan selama lebih dari 6 tahun.
⑥ Update Keamanan Pengulangan langkah 4 (Update Keamanan). Produsen memiliki tugas untuk mengambil update keamanan ASB dari versi Android 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 kontrak dengan pihak ketiga). Selain itu, produsen harus mengetahui bahwa masalah keamanan pada 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 Lengkap), dan sepuluh tahun sejak Android X ditentukan, beban kurasi dan backport patch keamanan sepenuhnya ada pada produsen untuk versi yang lebih lama dari tiga tahun sejak rilis publik API level.

Praktik terbaik keamanan

Untuk mempersulit kompromi keamanan, Google merekomendasikan dan menerapkan penggunaan praktik terbaik yang umum diterima untuk keamanan dan rekayasa software, seperti yang dijelaskan dalam Menerapkan Keamanan.

Panduan keamanan

Praktik yang direkomendasikan untuk keamanan meliputi:

  • Gunakan library eksternal dan komponen open source versi terbaru.
  • Jangan sertakan 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.

Panduan pengembangan software

Praktik yang direkomendasikan untuk pengembangan software yang aman untuk siklus proses sistem meliputi:

  • Lakukan pemodelan ancaman untuk menentukan peringkat dan mengidentifikasi aset, ancaman, dan potensi mitigasi.
  • Lakukan peninjauan arsitektur/desain untuk memastikan desain yang aman dan andal.
  • Lakukan peninjauan kode secara rutin untuk mengidentifikasi anti-pola dan bug sesegera mungkin.
  • Mendesain, menerapkan, dan menjalankan pengujian unit cakupan kode tinggi, termasuk:
    • Pengujian fungsional (termasuk kasus pengujian negatif)
    • Pengujian regresi reguler (untuk memastikan bug yang diperbaiki tidak muncul kembali)
    • Uji kegagalan (fuzz testing) (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) untuk mengidentifikasi dan mengurangi 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 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 level API. Dukungan aktif terdiri dari hal berikut:

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

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

  • Gunakan pihak ketiga (seperti vendor SoC atau penyedia Kernel) untuk dukungan backport bagi 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 menghasilkan patch serupa untuk versi OS yang lebih lama dari tiga tahun sejak rilis API.
  • Jika sesuai, upload update keamanan ke Project Open Source Android (AOSP).
  • Produsen harus mengoordinasikan penanganan update keamanan untuk kode khusus vendor (misalnya, kode khusus perangkat eksklusif).
  • Produsen harus bergabung dengan grup notifikasi Pratinjau Partner Android Security Bulletin NDA (memerlukan penandatanganan perjanjian hukum seperti NDA Developer). Buletin harus menyertakan:
    • Pengumuman
    • Ringkasan masalah menurut level patch, termasuk CVE dan tingkat keparahan
    • Detail kerentanan jika sesuai

Referensi tambahan

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

Google mendorong penggunaan praktik yang direkomendasikan berikut.

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

Panduan yang direkomendasikan mencakup:

  • Karena waktu tunggu pengembangan yang lama yang 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 Android OS 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 backoffice IT.
  • Kirimkan kerentanan keamanan Android yang diidentifikasi secara independen ke 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 melakukan segala upaya untuk menggunakan versi OS terbaru atau update keamanan untuk versi yang digunakan selama peningkatan siklus produk. Update dapat dilakukan selama pembaruan produk berkala berulang, atau untuk hotfix guna mengatasi masalah kualitas dan/atau masalah lainnya. Praktik yang direkomendasikan mencakup:

  • Buat rencana untuk mengatasi update driver, kernel, dan protokol.
  • Gunakan metode yang sesuai dengan industri untuk memberikan update ke kendaraan yang 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.

Memenuhi persyaratan ini untuk suatu produk melibatkan langkah-langkah dasar berikut:

  1. Partner menandatangani Komitmen Kompatibilitas Android (ACC) dengan Google. Konsultan Solusi Teknis (TSC) kemudian ditugaskan sebagai pemandu.
  2. Partner menyelesaikan peninjauan CDD untuk versi Android OS 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 implementasi produk kompatibel dengan Android dan bahwa 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 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 intent rilis dibuat dan diuji. Produsen sangat dianjurkan untuk menggunakan CTS sedini mungkin dan secara rutin 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 rutin. CTS dirancang sebagai alat otomatis yang terintegrasi ke dalam sistem build Anda. Menjalankan CTS secara rutin dapat membantu Anda menemukan cacat dengan cepat dan lebih awal saat degradasi atau regresi software terjadi.
  • 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 di-build dan dijalankan sepenuhnya). 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 rutin dan perbarui program CTS Anda sesuai kebutuhan. Produsen dan Google harus menyetujui versi CTS yang akan lulus untuk peluncuran produk karena produk harus dibekukan pada suatu saat saat CTS terus dimuat ulang.

Lulus CTS

Untuk produk yang Kompatibel dengan Android, Google memastikan hasil pengujian CTS dan laporan CTS Verifier perangkat dapat diterima. Pada prinsipnya, semua pengujian harus lulus. Namun, pengujian yang gagal karena alasan selain perangkat tidak mematuhi persyaratan Kompatibilitas Android akan 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 akan memeriksa materi yang dikirimkan, dan jika diterima, akan memperbarui pengujian 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 (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/273371/).

Pertanyaan Umum (FAQ)

T: Siapa yang bertanggung jawab untuk menerapkan update keamanan ke implementasi Android tertentu?

A: Produsen yang langsung menyediakan perangkat tersebut yang bertanggung jawab. Entitas ini bukan Google, yang memublikasikan update 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 API level yang didukung sebagai bagian dari proses update keamanan rutin. Sejak Agustus 2015, Google telah mempertahankan ritme teratur dalam memublikasikan buletin dan link ke update ke source.android.com; Google juga memublikasikan update 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 patch tersebut masih dapat meningkatkan tingkat keamanan (misalnya, menerapkan patch yang sesuai ke platform/build)?

J: Untuk mendeklarasikan level patch keamanan Android (SPL), produsen harus mengatasi semua masalah yang diperlukan yang dipublikasikan dalam Android Security Bulletin (termasuk buletin sebelumnya) dan dipetakan ke SPL Android tertentu. Misalnya, produsen yang menggunakan Android Security Bulletin 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 Android Security Bulletin sebelumnya, termasuk update khusus perangkat yang terkait dengan SPL 05-02-2017.

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

A: ASB menjelaskan kerentanan keamanan (dihitung berdasarkan daftar CVE) dan sering kali memberikan pengujian keamanan yang cocok. Tujuannya adalah untuk memastikan kerentanan yang tercantum tidak dapat lagi diproduksi di perangkat dan perangkat dapat lulus pengujian keamanan terkait. Dengan demikian, masalahnya bukan tentang melakukan 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 dapat menggunakan update keamanan yang disediakan atau, jika mereka memiliki perubahan yang lebih sesuai dengan perangkat mereka, gunakan perubahan tersebut.

Misalnya, pertimbangkan kasus saat Google mengatasi kerentanan keamanan AOSP menggunakan perubahan kode yang memungkinkan komponen tetap berfungsi sepenuhnya 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 platform 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 untuk menangani masalah secara keliru, memperkenalkan kerentanan keamanan baru, atau mengurangi fungsi build akhir.

Meskipun kami bekerja sama dengan semua partner SoC untuk memastikan perbaikan tersedia untuk semua masalah di ASB, sebaiknya produsen mendapatkan perjanjian servis dengan vendor SoC mereka untuk siklus proses perangkat. SoC mungkin 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 langsung memperoleh atau membuat perbaikan secara 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 dengan sertifikasi build (karena Android memastikan tingkat patch keamanan terbaru tersedia di perangkat yang tersertifikasi). Google merekomendasikan untuk 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 masih perlu diterapkan atau di-patch untuk memenuhi persyaratan Google lainnya atau lulus CTS?

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

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

Hal ini secara mendasar berbeda dengan produsen yang ingin, misalnya, hanya memperbaiki patch kritis, tanpa mengambil patch lain yang berlaku yang akan menyebabkan pengujian keamanan gagal. Dalam hal ini, SPL diasumsikan tidak terpenuhi.