Bu kılavuzda, Android Uyumluluk Testi Paketi (CTS) tarafından değerlendirilen güvenlik yamalarının uygulanmasına ilişkin Google tarafından önerilen en iyi uygulamalar açıklanmaktadır. Araçlar, TV'ler, set üstü kutular ve ev aletleri gibi üç yıldan daha uzun süre desteklenecek olan Android uyumlu OEM ekipmanı üreticilerine (imalatçılara) yöneliktir. Bu kılavuz son kullanıcılara (örneğin araç sahiplerine) yönelik değildir .
Teşekkür ve sorumluluk reddi beyanları
Bu kılavuz, Google'ı veya diğer üreticileri yasal veya sözleşmeye bağlı olarak bağlamaz ve bir dizi gereksinim olarak tasarlanmamıştır. Bu kılavuz daha ziyade önerilen uygulamaları açıklayan bir eğitimsel yardımdır.
Geri bildirim
Bu kılavuzun kapsamlı olması amaçlanmamıştır; ek revizyonlar planlanmaktadır. makers-guide-android@googlegroups.com adresine geri bildirim gönderin.
Sözlük
| Terim | Tanım |
|---|---|
| ACC | Android Uyumluluk Taahhüdü. Eskiden Android Parçalanmayı Önleme Anlaşması (AFA) olarak biliniyordu. |
| AOSP | Android Açık Kaynak Projesi |
| ASB | Android Güvenlik Bülteni |
| BSP | Pano Destek Paketi |
| CDD | Uyumluluk Tanımı Belgesi |
| CTS | Uyumluluk Test Paketi |
| FOTA | bellenim kablosuz olarak |
| Küresel Konumlama Sistemi | Küresel Konumlandırma Sistemi |
| MİSRA | Motor Endüstrisi Yazılım Güvenilirliği Derneği |
| NIST | Ulusal Standartlar ve Teknoloji Enstitüsü |
| OBD | yerleşik teşhis ( OBD-II, hem yetenek hem de standardizasyon açısından OBD-I'ye göre bir gelişmedir ) |
| OEM | Orijinal Ekipman Üreticisi |
| işletim sistemi | işletim sistemi |
| SEI | Yazılım Mühendisliği Enstitüsü |
| SoC | çip üzerindeki sistem |
| SOP | üretim başlangıcı |
| SPL | Güvenlik Yaması Düzeyi |
| TPMS'ler | Lastik basınç gözetim sistemi |
Android işletim sistemi hakkında
Android, çeşitli cihazlar ve form faktörleri için tasarlanmış, açık kaynaklı, Linux tabanlı bir tam yazılım yığınıdır. 2008'deki ilk çıkışından bu yana Android, dünya çapında 1,4 milyardan fazla cihaza güç vererek (2016) en popüler İşletim Sistemi (OS) haline geldi. Mart 2017 itibarıyla bu cihazların yaklaşık %67'si Android 5.0 (Lollipop) veya daha yenisini kullanıyor (daha güncel rakamlar Android Dashboard'da mevcut). Cihazların büyük çoğunluğu cep telefonları ve tabletlerden oluşsa da Android, akıllı saatlerde, TV'lerde ve otomotiv araç içi bilgi-eğlence (IVI) cihazlarında da büyüyor.
Google Play Store'da bulunan Android uygulamalarının sayısı 2,2+ milyona (2016) ulaştı. Android uygulaması geliştirme, Uyumluluk Tanımlama Belgesi (CDD) aracılığıyla bir dizi gereksinimi tanımlayan ve Uyumluluk Test Paketi (CTS) aracılığıyla test araçları sağlayan Android Uyumluluk programı tarafından desteklenir. Android uyumluluk programları, herhangi bir Android uygulamasının, uygulama için gerekli özellikleri destekleyen herhangi bir Android uyumlu cihazda çalışabilmesini sağlar.
Google düzenli olarak yeni işletim sistemi sürümlerini, işletim sistemi güvenlik güncellemelerini ve keşfedilen güvenlik açıklarına ilişkin bilgileri yayınlar. Bu güncellemelerin Android işletim sistemi destekli ürünlere uygulanabilirliği açısından Android Güvenlik Bülteni'nin üreticiler tarafından incelenmesi gerekmektedir. Android güvenliği, uyumluluğu ve derleme sistemlerine ilişkin bir inceleme için aşağıdakilere bakın:
- Bir Android Cihazın Güvenliğini Sağlayın
- Güvenlik Güncellemeleri ve Kaynaklar
- Uyumluluk Test Paketi
- Kod Adları, Etiketler ve Yapı Numaraları
Bağlantılı araçlar hakkında (standart uzun ömürlü ürünler)
1920'lerde AM radyonun kullanıma sunulmasıyla araçlar birbirine bağlanmaya başladı. Düzenleyiciler ve otomobil üreticileri, teşhis ve servisi kolaylaştırmak (örneğin OBD-II bağlantı noktası), güvenliği artırmak (örneğin TPMS) ve yakıt ekonomisi hedeflerini karşılamak için elektroniğe yöneldikçe, harici fiziksel ve kablosuz bağlantıların sayısı da artmaya başladı. . Sonraki bağlantı dalgası, uzaktan anahtarsız giriş, telematik sistemleri ve Bluetooth, Wi-Fi ve akıllı telefon projeksiyonu gibi gelişmiş bilgi-eğlence özellikleri gibi sürücüye kolaylık sağlayan özellikleri tanıttı. Günümüzde entegre sensörler ve bağlantılar (örneğin GPS) güvenliği ve yarı otonom sürüş sistemlerini desteklemektedir.
Araç bağlantılarının sayısı arttıkça potansiyel araç saldırı yüzeyinin alanı da artar. Bağlantılar, tüketici elektroniğinde olduğu gibi benzer siber güvenlik endişelerini de beraberinde getiriyor. Ancak yeniden başlatmalar, günlük yama güncellemeleri ve açıklanamayan davranışlar tüketici elektroniği için norm olsa da, bunlar araçlar gibi güvenlik açısından kritik sistemlere sahip ürünler için tutarsızdır.
Üreticiler, bir ürünün sahada sürekli güvenlik ve güvenlik duruşuna sahip olmasını sağlamak için proaktif bir yaklaşım benimsemelidir. Kısacası üreticiler, üründeki bilinen güvenlik açıklarının farkında olmalı ve bunları ele alırken risk temelli bir yaklaşım benimsemelidir.
Uzun vadeli güvenliği sağlayın
Bağlantılı bir araçta genellikle işletim sistemi, kütüphaneler, yardımcı programlar vb. gibi birden fazla yazılım bileşeni içeren bir veya daha fazla elektronik kontrol ünitesi (ECU) bulunur. Üreticiler bu tür bileşenleri izlemeli ve aşağıdakiler dahil olmak üzere proaktif analizle bilinen yayınlanmış güvenlik açıklarını belirlemelidir:
- Ürünü Ortak Güvenlik Açıkları ve Etkilenmeler (CVE) veritabanına göre düzenli olarak değerlendirmek.
- Ürünle ilgili güvenlik kusurlarına yönelik istihbarat toplama.
- Güvenlik testi.
- Android Güvenlik Bültenlerini aktif olarak analiz ediyoruz.
Örnek işletim sistemi ve güvenlik düzeltme eki güncellemeleri (Android çalıştıran IVI'ler):
Şekil 1. Aracın ömrü boyunca önemli işletim sistemi ve güvenlik güncelleştirmelerinin kullanıma sunulması örneği.
| # | Adım | Faaliyetler |
|---|---|---|
① | Geliştirme Şubesi | Üretici Android'in bir sürümünü (Android X) seçer. Bu örnekte "Android X", ilk Üretim Başlangıcından (SOP) iki yıl önce araçta gönderilecek olanın temelini oluşturuyor. |
| ② | İlk Lansman | Android X'in üründe gönderilen ilk işletim sistemi sürümü haline gelmesinden birkaç ay önce, güvenlik güncellemeleri Android Güvenlik Bültenlerinden (ASB'ler) ve muhtemelen üretici tarafından değerli görülen diğer kaynaklardan alınır. y2 = üretici tarafından Android X'e uygulanan (desteklenen) Android X sürümüne ilişkin ikinci Güvenlik Bülteni. Bu güncelleme ürünle birlikte gönderilir ve üretim saati Android X.y2 ile Sıfır Yılı'nda işlemeye başlar. Bu örnekte üretici, daha yeni Android X+1 yıllık sürümünü göndermeme kararı aldı. En son sürümün gönderilmesinin nedenleri arasında yeni özelliklerin eklenmesi, yeni güvenlik açıklarının giderilmesi ve/veya daha yeni Android sürümünü gerektiren Google veya üçüncü taraf hizmetlerinin gönderilmesi yer alıyor. En son sürümle gönderim yapılmamasının nedenleri, tüm düzenleme ve sertifika gerekliliklerine uygunluk da dahil olmak üzere değişiklikleri entegre etmek, test etmek ve doğrulamak için gereken araç geliştirme ve lansman sürecine özgü zaman eksikliğidir. |
| ③ | Tam İşletim Sistemi Güncellemesi | SOP sonrası üretici, ilk ürün için kullanılan sürümden (Android X0) sonraki iki Android sürümü olan Android X+2 İşletim Sistemi güncellemesini yayınlar. ASB güvenlik güncellemeleri API düzeyi için mevcuttur (sevk tarihi itibariyle), dolayısıyla güncelleme SOP'tan yaklaşık 1,25 yıl sonra X+2.y0 olarak çıkar. Bu işletim sistemi güncellemesi sahadaki ürünlerle uyumlu olabilir veya olmayabilir. Eğer öyleyse, konuşlandırılan araçları güncellemek için bir plan oluşturulabilir. Başka iş anlaşmaları olmadığı sürece tam işletim sistemi güncellemesi yapma kararı tamamen üreticinin takdirindedir. |
| ④ | Güvenlik Güncellemesi | Aracın üretim ömrünün üzerinden iki yıl geçtikten sonra üretici, Android X+2 işletim sistemini yamalar. Bu karar üreticinin risk değerlendirmesine dayanmaktadır. Üretici, güncellemenin temeli olarak X+2 sürümü için üçüncü ASB güvenlik güncellemesini seçer. Güvenlik güncellemesini alan ürünler artık (X+2.y3) OS + Android Güvenlik Yaması Düzeyindedir. Üreticiler herhangi bir ASB'den ayrı ayrı güvenlik yamaları seçebilse de, bültenle ilişkili Android güvenlik yaması düzeyini (SPL) (örneğin, 2017-02-05) kullanabilmek için bültendeki gerekli tüm sorunları düzeltmeleri gerekir. Desteklenen ürün için destek ve güvenlik sürümünün gerçekleştirilmesi üreticinin sorumluluğundadır. |
| ⑤ | Tam İşletim Sistemi Güncellemesi | 3. adımın (Tam İşletim Sistemi Güncellemesi) tekrarı olan ikinci tam İşletim Sistemi güncellemesi, ürünü, aracın üretim ömrünün üç yılı olan Android X+4 sürümüne getirir. Üretici artık güncel bir Android sürümünün daha yeni donanım gereksinimlerini üründeki donanımla dengeliyor ve kullanıcı, güncellenmiş bir Android işletim sisteminden yararlanıyor. Üretici, güvenlik güncellemeleri olmayan bir güncelleme yayınladı, dolayısıyla ürün artık (X+4.y0) OS + Android Güvenlik Yaması Düzeyinde. Bu örnekte, donanım sınırlamaları nedeniyle X+4, bu ürün için sağlanacak olan Android'in son ana sürümüdür; ancak araç için beklenen 6 yıldan fazla kullanım ömrü hala güvenlik desteği gerektirmektedir. |
| ⑥ | Güvenlik Güncellemesi | 4. adımın tekrarı (Güvenlik Güncellemesi). Üreticinin görevi, ASB güvenlik güncellemelerini Android'in çok daha sonraki bir sürümünden (X+6) almak ve bu güncellemelerin bir kısmını veya tamamını Android X+4'e geri taşımaktır. Güncellemelerin birleştirilmesi, entegre edilmesi ve gerçekleştirilmesi (veya üçüncü bir tarafla sözleşme yapılması) üreticinin sorumluluğundadır. Ayrıca üreticinin, Android'in artık desteklenmeyen sürümlerindeki güvenlik sorunlarının ASB kapsamına girmediğinin farkında olması gerekir. |
| ⑦ | Güvenlik Güncellemesi | Aracın üretim yaşam döngüsünden sekiz yıl sonra, 5. Adımdaki (Tam İşletim Sistemi Güncellemesi) son işletim sistemi güncellemesinden bu yana dört Android sürümü ve Android X'in belirlenmesinden on yıl sonra, güvenlik yamalarını düzenleme ve destekleme yükü tamamen üreticiye aittir. API düzeyindeki genel sürümden itibaren üç yıldan daha eski olan sürümler. |
En iyi güvenlik uygulamaları
Güvenlikten ödün verilmesini daha da zorlaştırmak için Google, Güvenliği Uygulama bölümünde açıklandığı gibi güvenlik ve yazılım mühendisliği için yaygın olarak kabul edilen en iyi uygulamaların kullanılmasını önerir ve kullanır.
Güvenlik yönergeleri
Güvenlik için önerilen uygulamalar şunları içerir:
- Harici kitaplıkların ve açık kaynak bileşenlerinin en son sürümlerini kullanın.
- İşletim sisteminin yayın sürümlerine müdahaleci hata ayıklama işlevini dahil etmeyin.
- Kullanılmayan işlevleri kaldırın (gereksiz saldırı yüzeyini azaltmak için).
- En az ayrıcalık ilkesini ve diğer Android uygulama geliştirme en iyi uygulamalarını kullanın.
Yazılım geliştirme yönergeleri
Sistemin yaşam döngüsü boyunca güvenli yazılım geliştirmeye yönelik önerilen uygulamalar şunları içerir:
- Varlıkları, tehditleri ve potansiyel azaltımları sıralamak ve tanımlamak için tehdit modellemesi gerçekleştirin.
- Güvenli ve sağlam tasarım sağlamak için mimari/tasarım incelemesi yapın.
- Anti-kalıpları ve hataları mümkün olan en kısa sürede belirlemek için düzenli kod incelemeleri yapın.
- Aşağıdakileri içeren yüksek kodlu kapsama birimi testlerini tasarlayın, uygulayın ve çalıştırın:
- Fonksiyonel testler (negatif test durumları dahil)
- Düzenli regresyon testleri (düzeltilen hataların yeniden ortaya çıkmamasını sağlamak için)
- Fuzz testi (birim test paketinin bir parçası olarak)
- Potansiyel sorunları belirlemek için statik kaynak kodu analiz araçlarını (tarama-derleme, tüy bırakma vb.) kullanın.
- Sistem geliştirme sırasında olası sorunları belirlemek ve azaltmak için AdresSanitizer, UnDefinitionBehaviorSanitizer ve FORTIFY_SOURCE (yerel bileşenler için) gibi dinamik kaynak kodu analiz araçlarını kullanın.
- Yazılım kaynak kodu ve sürüm yapılandırması/versiyonu için bir yönetim stratejisine sahip olun.
- Yazılım yamalarının oluşturulması ve dağıtımı için bir yama yönetimi stratejisine sahip olun.
Güvenlik destek politikası
Google şu anda, keşfedilen ve rapor edilen güvenlik açıklarına ilişkin güvenlik destek raporları için, API düzeyinde halka açık sürümden itibaren üç (3) yıl boyunca aktif destek sağlamaktadır. Aktif destek aşağıdakilerden oluşur:
- Güvenlik açığı raporlarını alın ve araştırın.
- Güvenlik güncellemelerini oluşturun, test edin ve yayınlayın.
- Güvenlik güncelleştirmelerinin ve güvenlik bülteni ayrıntılarının yinelenen sürümlerini sağlayın.
- Ciddiyet değerlendirmesini belirlenmiş yönergelere göre gerçekleştirin.
API düzeyinde halka açık yayın tarihinden itibaren üç yıl geçtikten sonra Google, aşağıdaki yönergeleri önerir:
- API sürümünden itibaren üç yıldan daha eski olan işletim sistemi güvenlik güncellemelerine yönelik destek desteği için bir üçüncü taraf (SoC satıcısı veya Çekirdek sağlayıcı gibi) kullanın.
- Kamuya açık ASB'leri kullanarak kod incelemeleri gerçekleştirmek için bir üçüncü taraf kullanın. ASB'ler halihazırda desteklenen sürüm için güvenlik açıklarını belirlerken, üretici sağlanan bilgileri yeni yayımlanan güncellemeleri önceki sürümlerle karşılaştırmak için kullanabilir. Bu veriler, etki analizi gerçekleştirmek ve API sürümünden itibaren üç yıldan daha eski işletim sistemi sürümleri için potansiyel olarak benzer yamalar oluşturmak için kullanılabilir.
- Uygun olduğunda güvenlik güncellemelerini Android Açık Kaynak Projesi'ne (AOSP) yükleyin.
- Üreticinin, satıcıya özel kod (örneğin, cihaza özel özel kod) için güvenlik güncellemelerinin işlenmesini koordine etmesi gerekir.
- Üretici, NDA Android Güvenlik Bülteni İş Ortağı Önizlemesi bildirim grubuna katılmalıdır (Geliştirici NDA gibi yasal anlaşmaların imzalanmasını gerektirir). Bültenler şunları içermelidir:
- Duyurular
- CVE ve önem derecesi de dahil olmak üzere yama düzeyine göre sorunların özeti
- Uygun olduğunda güvenlik açığı ayrıntıları
Ek referanslar
Güvenli kodlama ve yazılım geliştirme uygulamalarına ilişkin talimatlar için aşağıdakilere bakın:
- Motor Endüstrisi Yazılım Güvenilirliği Derneği (MISRA) .
- Yazılım Mühendisliği Enstitüsü (SEI) Araçlar ve Yöntemler .
- Ulusal Standartlar ve Teknoloji Enstitüsü (NIST).
Önerilen ürün uygulamaları
Google, aşağıdaki önerilen uygulamaların kullanılmasını teşvik eder.
Genel başlatma yönergeleri
Genellikle bağlı herhangi bir ürünün en son işletim sistemi sürümüyle başlatılması önerilir ve üreticinin, ürünü piyasaya sürmeden önce en son işletim sistemi sürümünü kullanmaya çalışması gerekir. Test ve doğrulama öncesinde kararlılığı sağlamak için sürümün kilitlenmesi gerekli olsa da, üreticinin eski işletim sistemi sürümlerinden elde edilen ürün kararlılığını, daha az bilinen güvenlik açıklarına ve gelişmiş güvenlik korumalarına sahip daha yeni işletim sistemi sürümleriyle dengelemesi gerekir.
Önerilen yönergeler şunları içerir:
- Araç geliştirme sürecinin doğasında olan uzun geliştirme süreleri nedeniyle, üreticilerin işletim sistemi n-2 veya daha eski bir sürümle piyasaya sürmeleri gerekebilir.
- Kablosuz (OTA) bir kampanyayla, yayımlanan her Android işletim sistemi sürümü için Android Uyumluluğuna uygunluğu koruyun.
- Hızlı, müşteri dostu güncellemeler için kablosuz (FOTA) özellikli Android Firmware ürününü uygulayın. FOTA, kod imzalama ve ürün ile BT arka ofisi arasındaki TLS bağlantısı gibi en iyi güvenlik uygulamaları kullanılarak yapılmalıdır.
- Bağımsız olarak tanımlanan Android güvenlik açıklarını Android Güvenlik ekibine gönderin .
Not: Google, Android Güvenlik Bültenlerinde cihaz türüne veya sektöre özel bildirimleri dikkate almıştır. Ancak Google belirli bir cihazın (araç, TV, giyilebilir cihaz, telefon vb.) çekirdeğini, sürücülerini veya yonga setlerini bilmediğinden, Google'ın herhangi bir güvenlik sorununu cihaz türüyle etiketlemenin belirleyici bir yolu yoktur. .
Ürün döngüsü yönergeleri
Üretici, ürün döngüsü geliştirmeleri sırasında, kullanımda olan sürüm için en son işletim sistemi sürümünü veya güvenlik güncellemelerini kullanmak için her türlü çabayı göstermelidir. Güncellemeler, yinelenen periyodik ürün güncellemeleri sırasında veya kalite ve/veya diğer sorunları ele alan düzeltmeler için gerçekleştirilebilir. Önerilen uygulamalar şunları içerir:
- Sürücü, çekirdek ve protokol güncellemelerini ele alacak bir plan oluşturun.
- Konuşlandırılan araçlara güncellemeler sağlamak için sektöre uygun bir yöntem kullanın.
Uyumluluk Tanımı Belgesi (CDD)
Uyumluluk Tanımı Belgesi (CDD), bir cihazın Android uyumlu olarak değerlendirilmesi için gereklilikleri açıklar. CDD halka açıktır ve herkesin erişimine açıktır; CDD sürümlerini Android 1.6'dan en son sürüme kadar source.android.com adresinden indirebilirsiniz.
Bir ürün için bu gereksinimlerin karşılanması aşağıdaki temel adımları içerir:
- İş Ortağı, Google ile Android Uyumluluk Taahhüdünü (ACC) imzalar. Daha sonra rehber olarak bir Teknik Çözüm Danışmanı (TSC) atanır.
- İş ortağı, ürünün Android işletim sistemi sürümü için CDD incelemesini tamamlar.
- İş ortağı, sonuçlar Android Uyumluluğu için kabul edilebilir hale gelene kadar CTS sonuçlarını (aşağıda açıklanmıştır) çalıştırır ve gönderir.
Uyumluluk Test Paketi (CTS)
Uyumluluk Test Paketi (CTS) test aracı, bir ürün uygulamasının Android uyumlu olduğunu ve en yeni güvenlik yamalarının dahil edildiğini doğrular. CTS herkese açıktır, açık kaynaktır ve herkesin kullanımına açıktır; CTS sürümlerini Android 1.6'dan en son sürüme kadar source.android.com adresinden indirebilirsiniz.
Kamuya sunulan her Android yazılımı derlemesi (fabrika kurulumu ve sahada güncelleme görüntüleri), CTS sonuçları aracılığıyla Android Uyumluluğunu kanıtlamalıdır. Örneğin, cihaz Android 7.1 çalıştırıyorsa, yayın amaçlı bir derleme görüntüsü oluşturulduğunda ve test edildiğinde CDD 7.1 ve CTS 7.1'in karşılık gelen en son sürümüne başvurulmalıdır. Üreticilerin, sorunları belirlemek ve düzeltmek için CTS'yi erken ve sık kullanmaları şiddetle tavsiye edilir.
CTS iş akışı
CTS iş akışı , test ortamının kurulmasını, testlerin yürütülmesini, sonuçların yorumlanmasını ve CTS kaynak kodunun anlaşılmasını içerir. Aşağıdaki yönergeler, CTS kullanıcılarının (örneğin geliştiriciler, üreticiler) CTS'yi etkili ve verimli bir şekilde kullanmalarına yardımcı olmayı amaçlamaktadır.
- Testleri sık sık çalıştırın . CTS, derleme sisteminize entegre olan otomatik bir araç olarak tasarlanmıştır. CTS'yi sık sık çalıştırmak, yazılımda bozulma veya gerileme meydana geldiğinde kusurları hızlı ve erken bulmanıza yardımcı olabilir.
- CTS kaynak kodunu indirin ve inceleyin . Tam CTS kaynak kodu, herkesin indirip kullanabileceği açık kaynaklı bir yazılımdır (indirilen kaynak kodu tamamen oluşturulabilir ve çalıştırılabilir). Cihazda bir test başarısız olduğunda kaynak kodun ilgili bölümünü incelemek nedenini belirlemenize yardımcı olabilir.
- En son CTS'yi edinin . Yeni Android sürümleri CTS'yi hata düzeltmeleri, iyileştirmeler ve yeni testlerle güncelleyebilir. CTS İndirmelerini sık sık kontrol edin ve CTS programınızı gerektiği şekilde güncelleyin. CTS yenilenmeye devam ederken ürünün bir noktada dondurulması gerektiğinden, üretici ve Google, ürün lansmanı için CTS sürümünün geçmesi konusunda anlaşacaktır.
CTS'yi geçmek
Android Uyumlu bir ürün için Google, cihazın CTS'sinin ve CTS Doğrulayıcı raporlarının test sonuçlarının kabul edilebilir olmasını sağlar. Prensip olarak tüm testlerin başarılı olması gerekir. Ancak cihazın Android Uyumluluk gereksinimlerine uymaması dışındaki nedenlerden dolayı başarısız olan bir test, Google tarafından incelemeye tabi tutulur. Bu işlem sırasında:
- Üretici, iddiayı kanıtlamak için Google'a önerilen CTS yamalarını, yama doğrulamalarını ve gerekçelerini sağlar.
- Google, gönderilen materyali inceler ve kabul edilmesi halinde cihazın bir sonraki CTS revizyonunu geçebilmesi için ilgili CTS testlerini günceller.
Bir CTS testi, bir güvenlik yaması uygulandıktan sonra aniden başarısız olursa, üretici yamayı uyumluluğu bozmayacak şekilde değiştirmeli VEYA testin yanlış olduğunu göstermeli ve test için bir düzeltme sağlamalıdır (yukarıda açıklandığı gibi).
CTS, test düzeltmelerinin incelemelerine açık kalır. Örneğin, Android 4.4 düzeltmeleri kabul etmeye devam ediyor (bkz. https://android-review.googlesource.com/#/c/273371/ ).
Sık sorulan sorular (SSS)
S: Güvenlik güncellemelerinin belirli bir Android uygulamasına uygulanmasından kim sorumludur?
C: Cihazı doğrudan sağlayan üretici sorumludur. Bu varlık, AOSP'de güvenlik güncellemeleri yayınlayan ve belirli bir cihaza (araç gibi) yönelik olmayan Google değildir .
S: Google, Android'deki güvenlik sorunlarını nasıl ele alıyor?
C: Google, düzenli güvenlik güncelleme sürecinin bir parçası olarak desteklenen tüm API düzeylerinde kullanıma sunduğu sorunları sürekli olarak araştırıyor ve potansiyel düzeltmeler geliştiriyor. Ağustos 2015'ten bu yana Google, source.android.com adresinde düzenli aralıklarla bültenler ve güncelleme bağlantıları yayınlamayı sürdürüyor; Google ayrıca önemli işletim sistemi sürümlerinin bir parçası olarak güvenlik güncellemeleri de yayınlar. Ayrıca Güvenlik destek politikasına da bakın.
S: Bir üretici, bir ASB'den gelen tüm AOSP yamalarını entegre etmiş ancak aynı bültende bahsedilen BSP satıcısından gelen yamaları entegre etmemişse, yine de güvenlik düzeyini yükseltebilir mi (örneğin, ilgili yamayı platforma/derlemeye uygulayabilir)?
C: Bir Android güvenlik yaması düzeyi (SPL) bildirmek için üreticinin, Android Güvenlik Bülteni'nde ( önceki bültenler dahil ) yayınlanan ve belirli bir Android SPL ile eşlenen tüm gerekli sorunları ele alması gerekir. Örneğin, Mart 2017 Güvenlik Bülteni'ni (2017-03-01 SPL) kullanan bir üretici, söz konusu SPL için Mart 2017 bülteninde belgelenen tüm gerekli sorunları ve önceki tüm Android Güvenlik Bültenleri için cihaza özel güncellemeler de dahil olmak üzere önceki tüm güncellemeleri ele almıştır. 2017-02-05 SPL ile ilişkili cihaza özel güncellemeler.
S: Üretici, BSP satıcısı tarafından sağlanan güvenlik güncellemelerini kabul etmediğinde VEYA ASB tarafından zorunlu kılınan güvenlik güncellemeleri satıcılar tarafından sağlanmadığında ne olur?
C: Bir ASB, güvenlik açıklarını (bir CVE listesiyle numaralandırılmış) tanımlar ve sıklıkla eşleşen güvenlik testleri sağlar. Amaç, listelenen güvenlik açıklarının artık bir cihazda yeniden oluşturulamamasını ve cihazın ilgili güvenlik testlerini geçebilmesini sağlamaktır. Dolayısıyla sorun, Google veya üçüncü taraf bir satıcı tarafından sağlanan bir güvenlik güncellemesinin alınmasıyla ilgili değil, üreticinin, cihazın ASB'deki CVE listesine karşı savunmasız olmadığını doğrulamasıyla ilgili. Üretici, sağlanan güvenlik güncellemelerini kullanmakta veya cihazına daha uygun bir değişiklik varsa onun yerine bu değişikliği kullanmakta özgürdür.
Örneğin, Google'ın, bileşenin tamamen işlevsel ve CDD ile uyumlu kalmasını sağlayan bir kod değişikliği kullanarak bir AOSP güvenlik açığını giderdiği bir durumu düşünün. Üretici, bileşenin cihazda gerekli olmadığına veya CDD (veya ilgili sertifika testi) tarafından zorunlu kılınmadığına karar verirse, gelecekteki servis ihtiyaçlarını azaltmak ve saldırı yüzeyini azaltmak için bileşeni kaldırabilir. Üretici, sağlanan güvenlik güncellemesini kullanmamış olsa da, cihazın güvenlik bülteninde belgelenen CVE'ye karşı savunmasız olmamasını sağlamıştır. Ancak üretici, önerilen güvenlik güncelleştirmesinden saparak sorunu yanlış şekilde ele alma, yeni güvenlik açıkları oluşturma veya son yapının işlevselliğini başka şekilde azaltma riskini alıyor.
Bir ASB'deki tüm sorunlara yönelik düzeltmelerin mevcut olmasını sağlamak için tüm SoC iş ortaklarıyla birlikte çalışırken, üreticilerin bir cihazın yaşam döngüsü için SoC satıcılarıyla bir servis sözleşmesi yapmalarını öneriyoruz. SoC'ler bir yonga setine hizmet vermeyi istenenden daha erken durdurabilir; bu nedenle, cihaz yonga seti seçiminden önce anlaşmaların yapılması, cihazın başlatılması sürecinin önemli bir parçasıdır.
Son olarak, bir ASB'de belgelenen bir soruna yönelik düzeltmeyi doğrudan edinmenin veya bağımsız olarak oluşturmanın mümkün olmadığı durumlarda, üretici önceki Android SPL'yi koruyabilir ve yine de mevcut yeni düzeltmeleri yapıya ekleyebilir. Ancak bu uygulama eninde sonunda derleme sertifikasıyla ilgili sorunlara yol açacaktır (çünkü Android, sertifikalı cihazlarda en son güvenlik yaması düzeyinin mevcut olmasını sağlar). Google, bu uygulamadan kaçınmak için SoC'nizle önceden çalışmanızı önerir.
S: Üretici bir ASB öğesinin kendi ürünü için geçerli olmadığını belirlerse, diğer Google gereksinimlerini karşılamak veya CTS'yi geçmek için öğenin yine de uygulanması veya yama uygulanması gerekiyor mu?
C: Android güvenlik yaması düzeyini (SPL) bildirmek için yamaların alınmasına gerek duymuyoruz; Üreticinin, yapısının bu soruna açık olmadığını doğrulamasını zorunlu tutuyoruz.
Bunun bir örneği, yama uygulanan bir bileşenin üreticinin sisteminde mevcut olmaması veya bir bileşenin, bir sorunu çözmek için üreticinin sisteminden kaldırılmasıdır. Bu durumda sistem, üreticinin yama almasına gerek kalmadan uyumlu olabilir.
Bu, bir üreticinin, örneğin yalnızca kritik yamaları düzeltmek, ancak güvenlik testinin başarısız olmasına neden olabilecek diğer geçerli yamaları almak istememesinden temel olarak farklıdır. Bu durumda SPL'nin karşılanmadığı varsayılır.