Uzun süreli Android güvenliği için üretici kılavuzu

Bu kılavuzda, Android Uyumluluk Test Paketi (CTS) tarafından değerlendirilen güvenlik yamalarını uygulamayla ilgili Google'ın önerdiği en iyi uygulamalar açıklanmaktadır. Araç, TV, set üstü kutu ve ev aletleri gibi üç yıldan uzun süre desteklenecek Android uyumlu OEM ekipmanlarının (üreticiler) üreticileri için tasarlanmıştır. Bu kılavuz, son kullanıcılar (ör. araç sahipleri) için değildir.

Teşekkür ve sorumluluk reddi beyanları

Bu kılavuz, Google'ı veya diğer üreticileri yasal veya sözleşmesel olarak bağlamaz ve bir dizi şart olarak tasarlanmamıştır. Bu kılavuz, önerilen uygulamaları açıklayan bir eğitim yardımcısıdır.

Geri bildirim

Bu kılavuzun kapsamlı olması amaçlanmamıştır. Gelecekte ek düzeltmeler yapılması planlanmaktadır. Geri bildiriminizi manufacturers-guide-android@googlegroups.com adresine gönderin.

Sözlük

Terim Tanım
ACC Android Uyumluluk Taahhüdü. Eski adıyla Android Bölünme Önleme Sözleşmesi (AFA).
AOSP Android Açık Kaynak Projesi
ASB Android Güvenlik Bülteni
BSP Kart Destek Paketi
CDD Uyumluluk Tanımlama Belgesi (CDD)
CTS Compatibility Test Suite
FOTA kablosuz donanım yazılımı
GPS Küresel Konum Belirleme Sistemi
MISRA Motor Industry Software Reliability Association
NIST Ulusal Standartlar ve Teknoloji Enstitüsü
OBD Araç içi teşhis (OBD-II, hem özellik hem de standartlaştırma açısından OBD-I'den daha iyidir)
OEM özgün donanım üreticisi
OS işletim sistemi
SEI Yazılım Mühendisliği Enstitüsü
Çip üzerinde sistem (SoC) çip üzerinde sistem
SOP üretime başlama
SPL Güvenlik Yaması Düzeyi
TPMS lastik basıncı izleme sistemi

Android OS 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'de ilk kez kullanıma sunulan Android, dünya genelinde 1,4 milyardan fazla cihazda (2016) kullanılarak en popüler işletim sistemi (OS) haline geldi. Bu cihazların yaklaşık% 67'sinde Mart 2017 itibarıyla Android 5.0 (Lollipop) veya daha yeni bir sürüm kullanılıyor (daha güncel verileri Android Kontrol Paneli'nde bulabilirsiniz). Cihazların büyük çoğunluğu cep telefonu ve tablet olsa da Android, akıllı saatler, TV'ler ve otomotiv araç içi bilgi-eğlence (IVI) cihazlarında da kullanılıyor.

Google Play Store'da bulunan Android uygulamalarının sayısı 2,2 milyonun üzerine çıktı (2016). Android uygulama geliştirme, Uyumluluk Tanımlama Belgesi (CDD) aracılığıyla bir dizi koşulu tanımlayan ve Uyumluluk Test Paketi (CTS) aracılığıyla test araçları sağlayan Android Uyumluluk Programı tarafından desteklenir. Android uyumluluk programları, tüm Android uygulamalarının uygulama için gerekli özellikleri destekleyen Android uyumlu cihazlarda çalışabilmesini sağlar.

Google, yeni işletim sistemi sürümlerini, işletim sistemi güvenlik güncellemelerini ve keşfedilen güvenlik açıkları hakkında bilgileri düzenli olarak yayınlar. Android Güvenlik Bülteninde, bu güncellemelerin Android OS destekli ürünlere uygulanabilirliği üreticiler tarafından incelenmelidir. Android güvenliği, uyumluluk ve derleme sistemleri hakkında bilgi edinmek için aşağıdakilere göz atın:

Bağlı araçlar (kanonik uzun ömürlü ürünler) hakkında

1920'lerde AM radyonun kullanıma sunulmasıyla araçlar bağlı hale geldi. Bu noktadan itibaren, düzenleyiciler ve otomobil üreticileri teşhis ve servisi kolaylaştırmak (ör. OBD-II bağlantı noktası), güvenliği artırmak (ör. TPMS) ve yakıt ekonomisi hedeflerini karşılamak için elektroniklere yöneldikçe harici fiziksel ve kablosuz bağlantıların sayısı artmaya başladı. Ardından gelen bağlantı dalgası, uzaktan anahtarsız giriş ve telematik sistemler gibi sürücüye kolaylık sağlayan özellikler ile Bluetooth, kablosuz bağlantı ve akıllı telefon yansıtma gibi gelişmiş bilgi-eğlence özellikleri sunmuştur. Günümüzde entegre sensörler ve bağlantı (ör. GPS), güvenlik ve yarı otonom sürüş sistemlerini desteklemektedir.

Araç bağlantılarının sayısı arttıkça potansiyel araç saldırısı yüzeyinin alanı da artar. Bağlantılar, tüketici elektroniğiyle ilgili siber güvenlik sorunlarına benzer bir dizi sorun getirir. Ancak yeniden başlatma, günlük yama güncellemeleri ve açıklanamayan davranışlar tüketici elektroniğinde normal olsa da araçlar gibi güvenlik açısından kritik sistemlere sahip ürünlerde tutarlı değildir.

Üreticiler, sahada bulunan bir ürünün güvenlik ve emniyet durumunun korunmasını sağlamak için proaktif bir yaklaşım benimsemelidir. Özetle, üreticiler üründeki bilinen güvenlik açıklarının farkında olmalı ve bunları gidermek için riske dayalı bir yaklaşım benimsemelidir.

Uzun vadeli güvenlik sağlama

Bağlı bir araçta genellikle işletim sistemi, kitaplıklar, yardımcı programlar gibi birden fazla yazılım bileşeni içeren bir veya daha fazla elektronik kontrol birimi (ECU) bulunur. Üreticiler bu tür bileşenleri izlemeli ve aşağıdakiler dahil olmak üzere proaktif analizlerle bilinen yayınlanmış güvenlik açıklarını belirlemelidir:

  • Ürünü Common Vulnerabilities and Exposures (CVE) veritabanına göre düzenli olarak değerlendirme
  • Ürünle ilgili güvenlik kusurları için bilgi toplama
  • Güvenlik testi.
  • Android Güvenlik Bültenlerini etkin bir şekilde analiz eder.

Örnek işletim sistemi ve güvenlik yaması güncellemeleri (Android çalıştıran IVI'ler):

Şekil 1. Araç kullanım ömrü boyunca önemli işletim sistemi ve güvenlik güncellemelerinin kullanıma sunulması örneği.

# Adım Etkinlikler

①

 Geliştirme Bölümü Üretici, Android'in bir sürümünü (Android X) seçer. Bu örnekte, "Android X", ilk üretime başlama tarihinden (SOP) iki yıl önce araca gönderilecek sürümün temelini oluşturur.
② İlk Lansman Android X, üründe gönderilen ilk işletim sistemi sürümü olmadan birkaç ay önce güvenlik güncellemeleri Android Güvenlik Bültenleri'nden (ASB'ler) ve üretici tarafından değerli kabul edilen diğer kaynaklardan alınır. y2 = Android X sürümüne ait ikinci güvenlik bülteni. Bu bülten, üretici tarafından Android X'e uygulanır (geri bağlanır). Bu güncelleme ürünle birlikte gönderilir ve üretim zamanlayıcısı, Android X.y2 ile sıfır yılında çalışmaya başlar.

Bu örnekte üretici, daha yeni Android X+1 yıllık sürümünü göndermemeye karar vermiştir. En son sürümü gönderme nedenleri arasında yeni özellikler ekleme, yeni güvenlik açıklarını giderme ve/veya daha yeni Android sürümünü gerektiren Google veya üçüncü taraf hizmetlerini gönderme yer alır. En son sürümle birlikte gönderilmemesi için nedenler arasında, tüm yasal ve sertifika şartlarını karşılama 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ği yer alıyor.
③ Tam OS güncellemesi Üretici, SOP'den sonra Android X+2 işletim sistemi güncellemesini yayınlar. Bu güncelleme, ilk üründe kullanılan sürümden (Android X0) iki Android sürümü sonradır. ASB güvenlik güncellemeleri, API düzeyi için (gönderim tarihinden itibaren) kullanılabilir.Bu nedenle güncelleme, SOP'den yaklaşık 1,25 yıl sonra X+2.y0 olarak yayınlanır. Bu işletim sistemi güncellemesi, kullanıma sunulan ürünlerle uyumlu olabilir veya olmayabilir. Bu durumda, dağıtılan araçları güncellemek için bir plan oluşturulabilir.

Başka ticari sözleşmeler yoksa işletim sisteminin tamamını güncelleme kararı tamamen üreticinin takdirine bağlıdır.
④ Güvenlik Güncellemesi Üretici, aracın üretim ömrünün iki yıl sonrasında Android X+2 işletim sisteminde düzeltme yapar. Bu karar, üreticinin risk değerlendirmesine dayanı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 şu anda (X+2.y3) OS + Android Güvenlik Yaması Düzeyi'ndedir.

Üreticiler herhangi bir ASB'den ayrı güvenlik yamaları seçebilir ancak bültenle ilişkili Android güvenlik yaması düzeyini (SPL) (ör. 05.02.2017) kullanmak için bültendeki tüm gerekli sorunları düzeltmelidir. Desteklenen ürün için geri taşıma ve güvenlik sürümünü yayınlama sorumluluğu üreticiye aittir.
⑤ Tam OS güncellemesi 3. adımın (Tam OS Güncellemesi) tekrarı olan ikinci tam OS güncellemesi, ürünü aracın üretim ömrünün üçüncü yılında Android X+4'e yükseltir. Üretici artık yeni bir Android sürümünün yeni donanım gereksinimlerini üründeki donanımla dengeliyor ve kullanıcı güncel bir Android OS'den yararlanıyor. Üretici, güvenlik güncellemeleri içermeyen bir güncelleme yayınlar. Bu nedenle ürün şu anda (X+4.y0) OS + Android Güvenlik Yaması Düzeyi'ndedir.

Bu örnekte, donanım sınırlamaları nedeniyle X+4, bu ürün için sağlanacak son ana Android sürümüdür. Ancak aracın 6 yıldan uzun bir süre boyunca kullanılabilmesi için güvenlik desteğine ihtiyaç vardır.
⑥ Güvenlik Güncellemesi 4. adımın (Güvenlik Güncellemesi) tekrarı. Üretici, Android'in çok daha yeni bir sürümünden (X+6) ASB güvenlik güncellemelerini alıp bu güncellemelerin bir kısmını veya tamamını Android X+4'e taşımakla görevlidir. Güncellemeleri birleştirme, entegre etme ve uygulama (veya üçüncü tarafla sözleşme yapma) üreticinin sorumluluğundadır. Ayrıca üretici, artık desteklenmeyen Android sürümlerindeki güvenlik sorunlarının ASB kapsamında olmadığını bilmelidir.
⑦ Güvenlik Güncellemesi Araç üretim yaşam döngüsünün sekizinci yılında, 5. adımdaki son işletim sistemi güncellemesinden (Tam OS Güncellemesi) bu yana dört Android sürümü ve Android X'in belirtilmesinden bu yana on yıl geçtikten sonra, API düzeyinde herkese açık sürümden üç yıldan eski sürümler için güvenlik yamalarını derleme ve geri taşıma yükü tamamen üreticiye aittir.

Güvenlikle ilgili en iyi uygulamalar

Google, güvenlikle ilgili tavizleri daha zor hale getirmek için Güvenliği Uygulama başlıklı makalede 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 kuralları

Güvenlikle ilgili önerilen uygulamalar şunlardır:

  • 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şlevleri eklemeyin.
  • 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 uygulaması geliştirme en iyi uygulamalarını kullanın.

Yazılım geliştirme yönergeleri

Sistemin yaşam döngüsü için güvenli yazılım geliştirmeyle ilgili önerilen uygulamalar şunlardır:

  • Öğeleri, tehditleri ve olası azaltma yöntemlerini sıralamak ve tanımlamak için tehdit modelleme yapın.
  • Güvenli ve sağlam bir tasarım sağlamak için mimari/tasarım incelemesi yapın.
  • Anti-pattern'leri ve hataları en kısa sürede tespit etmek için düzenli kod incelemeleri yapın.
  • Aşağıdakiler dahil olmak üzere yüksek kod kapsamlı birim testleri tasarlayın, uygulayın ve çalıştırın:
    • İşlevsel test (negatif test durumları dahil)
    • Düzenli geriye dönük test (düzeltilen hataların tekrar ortaya çıkmamasını sağlamak için)
    • Fuzz testi (birim testi paketinin bir parçası olarak)
  • Olası sorunları tespit etmek için statik kaynak kodu analiz araçlarını (tarama oluşturma, lint vb.) kullanın.
  • Sistem geliştirme sırasında olası sorunları tespit etmek ve azaltmak için AddressSanitizer, UndefinedBehaviorSanitizer 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ı/sürümü için bir yönetim stratejiniz olmalıdır.
  • Yazılım yamalarını oluşturma ve dağıtma için bir yama yönetimi stratejiniz olmalıdır.

Güvenlik geri taşıma politikası

Google, şu anda keşfedilen ve bildirilen güvenlik açıklarının API düzeyinin herkese açık sürümünden itibaren üç (3) yıl boyunca güvenlik geri taşımaları için etkin destek sağlamaktadır. Etkin destek aşağıdakilerden oluşur:

  1. Güvenlik açığı raporlarını alıp inceleme
  2. Güvenlik güncellemeleri oluşturun, test edin ve yayınlayın.
  3. Güvenlik güncellemelerini ve güvenlik bülteni ayrıntılarını tekrar tekrar yayınlar.
  4. Belirtilen kurallara göre önem derecesi değerlendirmesi yapın.

API düzeyinin herkese açık sürüm tarihinden üç yıl sonra Google aşağıdaki yönergeleri önerir:

  • API'nin yayınlanmasından üç yıldan eski OS güvenlik güncellemeleri için geriye dönük destek almak üzere bir üçüncü taraf (ör. SoC tedarikçisi veya çekirdek sağlayıcısı) kullanın.
  • Herkese açık olarak sağlanan ASB'leri kullanarak kod incelemeleri yapmak için bir üçüncü taraf kullanın. ASB'ler, şu anda desteklenen sürümdeki güvenlik açıklarını tespit eder. Ancak üreticiler, yeni yayınlanan güncellemeleri önceki sürümlerle karşılaştırmak için sağlanan bilgileri kullanabilir. Bu veriler, etki analizi yapmak ve API'nin yayınlanmasından üç yıldan eski OS sürümleri için benzer yamalar oluşturmak amacıyla kullanılabilir.
  • Uygun olduğunda güvenlik güncellemelerini Android Açık Kaynak Projesi'ne (AOSP) yükleyin.
  • Üretici, tedarikçiye özel kod (ör. cihaza özel tescilli kod) için güvenlik güncellemelerinin işlenmesini koordine etmelidir.
  • Üretici, NDA Android Güvenlik Bülteni İş Ortağı Önizleme bildirim grubuna katılmalıdır (Geliştirici Gizlilik Sözleşmesi gibi yasal sözleşmelerin imzalanması gerekir). Bültenlerde şu bilgiler bulunmalıdır:
    • Duyurular
    • CVE ve önem düzeyi dahil olmak üzere yama düzeyine göre sorunların özeti
    • Uygun durumlarda güvenlik açığı ayrıntıları

Ek referanslar

Güvenli kodlama ve yazılım geliştirme uygulamalarıyla ilgili talimatlar için aşağıdaki kaynaklara bakın:

Google, aşağıdaki önerilen uygulamaların kullanılmasını teşvik eder.

Genellikle bağlı ürünlerin en son işletim sistemi sürümüyle kullanıma sunulması önerilir ve üreticilerin ürünleri kullanıma sunmadan önce en son işletim sistemi sürümünü kullanmaya çalışması gerekir. Test ve doğrulamadan önce kararlılığı sağlamak için sürümü kilitlemek gerekli olsa da üretici, eski işletim sistemi sürümlerinden elde edilen ürün kararlılığını, bilinen güvenlik açıklarının daha az olduğu ve gelişmiş güvenlik korumalarına sahip yeni işletim sistemi sürümleriyle dengelemelidir.

Önerilen kurallar şunlardır:

  • Araç geliştirme sürecine özgü uzun geliştirme süreleri nedeniyle üreticilerin, n-2 veya daha eski bir OS sürümüyle lansman yapması gerekebilir.
  • Her yayınlanan Android OS sürümü için kablosuz (OTA) kampanyayla Android uyumluluğuyla uyumluluğu sürdürün.
  • Hızlı ve müşteri dostu güncellemeler için ürün Android kablosuz donanım yazılımı (FOTA) desteğini uygulayın. FOTA, kod imzalama ve ürün ile BT arka ofisi arasındaki TLS bağlantısı gibi güvenlikle ilgili en iyi uygulamalar kullanılarak yapılmalıdır.
  • Gönder bağımsız olarak tespit edilen Android güvenlik açıklarını Android Güvenlik Ekibi'ne gönderin.

Not: Google, Android Güvenlik Bültenleri'nde cihaz türüne veya sektöre özel bildirimler 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ği için Google, belirli bir güvenlik sorununu cihaz türüyle etiketlemenin kesin bir yoluna sahip değildir.

Üretici, ürün döngüsü iyileştirmeleri sırasında kullanılan 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 dönemsel ürün güncellemeleri sırasında veya kalite ve/veya diğer sorunları gidermek için acil düzeltmeler için yapılabilir. Önerilen uygulamalar şunlardır:

  • Sürücü, çekirdek ve protokol güncellemelerini ele alacak bir plan oluşturun.
  • Kullanıma sunulan araçlara güncelleme sağlamak için sektöre uygun bir yöntem kullanın.

Uyumluluk Tanımlama Belgesi (CDD)

Uyumluluk Tanımlama Belgesi (CDD), bir cihazın Android uyumlu olarak kabul edilmesi için gereken koşulları açıklar. CDD herkese açıktır ve herkes tarafından kullanılabilir. Android 1.6'dan en son sürüme kadar CDD sürümlerini source.android.com adresinden indirebilirsiniz.

Bir ürün için bu şartları karşılamak aşağıdaki temel adımları içerir:

  1. İş ortağı, Google ile Android Uyumluluk Taahhüdü'nü (ACC) imzalar. Ardından, teknik çözüm danışmanı (TSC) rehber olarak atanır.
  2. İş ortağı, ürünün Android OS sürümü için CDD incelemesini tamamlar.
  3. İş ortağı, sonuçlar Android uyumluluğu için kabul edilene kadar CTS sonuçlarını (aşağıda açıklanmıştır) çalıştırıp gönderir.

Compatibility Test Suite (CTS)

Uyumluluk Test Paketi (CTS) test aracı, bir ürün uygulamasının Android ile uyumlu olduğunu ve en son güvenlik yamalarını içerdiğini doğrular. CTS herkese açık, açık kaynak ve kullanılabilir. Android 1.6'tan en son sürüme kadar CTS sürümlerini source.android.com adresinden indirebilirsiniz.

Herkese açık olarak yayınlanan Android yazılımı derlemelerinin (fabrika kurulumu ve saha güncelleme resimleri) Android uyumluluğunu CTS sonuçlarıyla kanıtlaması gerekir. Örneğin, cihazda Android 7.1 yüklüyse sürüm yayınlama amacıyla bir derleme resmi oluşturulup test edilirken CDD 7.1 ve CTS 7.1'in ilgili en son sürümüne referans verilmelidir. Üreticilerden, sorunları tespit edip düzeltmek için CTS'yi erken ve sık kullanması önemle tavsiye edilir.

NOT: Google Mobil Hizmetleri (GMS) gibi başka sözleşmeler imzalayan iş ortaklarının başka koşulları karşılaması gerekebilir.

CTS iş akışı

CTS iş akışı, test ortamını oluşturmayı, testleri çalıştırmayı, sonuçları yorumlamayı ve CTS kaynak kodunu anlamayı içerir. Aşağıdaki yönergeler, CTS kullanıcılarının (ör. geliştiriciler, üreticiler) CTS'yi etkili ve verimli bir şekilde kullanması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 çalıştırmak, yazılım bozulduğunda veya gerileme olduğunda kusurları hızlı ve erken bir şekilde bulmanıza yardımcı olabilir.
  • CTS kaynak kodunu indirip inceleyin. CTS kaynak kodunun tamamı, herkesin indirip kullanabileceği açık kaynak bir yazılımdır (indirilen kaynak kod tamamen derlenebilir ve çalıştırılabilir). Cihazdaki bir test başarısız olduğunda, kaynak kodun ilgili bölümünü inceleyerek nedenini belirleyebilirsiniz.
  • En son CTS'yi edinin. Yeni Android sürümleri, CTS'yi hata düzeltmeleri, iyileştirmeler ve yeni testlerle güncelleyebilir. CTS İndirmeleri'ni sık sık kontrol edin ve gerektiğinde CTS programınızı güncelleyin. CTS yenilenmeye devam ederken ürünün bir noktada dondurulması gerektiğinden, üretici ve Google, ürün lansmanı için geçecek CTS sürümü konusunda anlaşmalıdır.

CTS'yi geçme

Google, Android uyumlu bir üründe cihazın CTS ve CTS Doğrulayıcı raporlarının test sonuçlarının kabul edilebilir olmasını sağlar. Prensip olarak tüm testler başarılı olmalıdır. Ancak cihazın Android uyumluluk şartlarına uymaması dışındaki nedenlerle başarısız olan testler Google tarafından incelenir. Bu işlem sırasında:

  1. Üretici, Google'a önerilen CTS yamalarını, yama doğrulamalarını ve iddiayı kanıtlamak için gerekçeleri sağlar.
  2. Google, gönderilen materyali inceler ve kabul edilirse cihazın CTS'nin bir sonraki revizyonunda geçebilmesi için ilgili CTS testlerini günceller.

Bir CTS testi, güvenlik yaması uygulandıktan sonra aniden başarısız oluyorsa üretici, uyumluluğu bozmayacak şekilde yamayı değiştirmeli VEYA testin yanlış olduğunu göstererek test için bir düzeltme sağlamalıdır (yukarıda açıklandığı gibi).

CTS, test düzeltmelerinin incelenmesi için açık kalır. Örneğin, Android 4.4 için düzeltmeler kabul edilmeye devam etmektedir (https://android-review.googlesource.com/#/c/273371/ adresine bakın).

Sık sorulan sorular (SSS)

S: Android'in belirli bir uygulamasına güvenlik güncellemeleri uygulamaktan kim sorumludur?

C: Doğrudan cihazı sağlayan üretici sorumludur. Bu tüzel kişi, belirli bir cihaz (araç gibi) için değil, AOSP'de güvenlik güncellemeleri yayınlayan Google değildir.

S: Google, Android'deki güvenlik sorunlarını nasıl ele alır?

C: Google, sorunları sürekli olarak araştırır ve olası çözümler geliştirir. Google, bu çözümleri düzenli güvenlik güncelleme süreci kapsamında desteklenen tüm API düzeylerinde kullanıma sunar. Google, Ağustos 2015'ten beri source.android.com adresinde düzenli olarak bülten ve güncelleme bağlantıları yayınlamaktadır. Ayrıca, büyük işletim sistemi sürümlerinin bir parçası olarak güvenlik güncellemeleri de yayınlamaktadır. Güvenlik geri taşıma politikasına da bakın.

S: Bir üretici, bir ASB'deki tüm AOSP yamalarını entegre ettiyse ancak aynı bültende belirtilen BSP tedarikçisinin yamalarını entegre etmediyse güvenlik düzeyini yükseltebilir mi (ör. ilgili yamayı platforma/derlemeye uygulayabilir mi)?

C: Bir üreticinin Android güvenlik yaması düzeyi (SPL) beyan etmesi için Android Güvenlik Bülteninde yayınlanan (önceki bültenler dahil) ve belirli bir Android SPL ile eşlenen tüm gerekli sorunları gidermesi gerekir. Örneğin, Mart 2017 Güvenlik Bültenini (2017-03-01 SPL) kullanan bir üretici, bu SPL için Mart 2017 bülteninde ve önceki tüm Android Güvenlik Bültenleri için cihaza özel güncellemeler de dahil olmak üzere önceki tüm güncellemelerde belirtilen tüm gerekli sorunları gidermiştir. 2017-02-05 SPL ile ilişkili cihaza özel güncellemeler de buna dahildir.

S: Üretici, BSP tedarikçisi tarafından sağlanan güvenlik güncellemelerini kabul etmediğinde VEYA bir ASB tarafından zorunlu kılınan güvenlik güncellemeleri tedarikçiler tarafından sağlanmadığında ne olur?

C: ASB, güvenlik açıklarını (CVE listesi ile numaralandırılır) açıklar ve genellikle eşleşen güvenlik testleri sağlar. Amaç, listelenen güvenlik açıklarının artık cihazda yeniden üretilememesini ve cihazın ilgili güvenlik testlerini geçebilmesini sağlamaktır. Bu nedenle, sorun Google veya üçüncü taraf bir tedarikçi tarafından sağlanan bir güvenlik güncellemesi almakla ilgili değil, üreticinin cihazın ASB'deki CVE listesine karşı savunmasız olmadığını onaylaması ile ilgilidir. Üretici, sağlanan güvenlik güncellemelerini kullanabilir veya cihazına daha uygun bir değişiklik varsa bu değişikliği kullanabilir.

Örneğin, Google'ın bir AOSP güvenlik açığını, bileşenin tam işlevli ve CDD'ye uygun kalmasını sağlayan bir kod değişikliğiyle ele aldığı bir durumu düşünün. Üretici, bileşenin cihazda gerekli olmadığını veya CDD (veya ilgili sertifika testleri) tarafından zorunlu kılınmadığını belirlerse gelecekteki servis ihtiyaçlarını 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 belirtilen CVE'ye karşı savunmasız olmadığından emin olmuştur. Ancak üretici, önerilen güvenlik güncellemesinden saparak sorunu yanlış ele alma, yeni güvenlik açıkları oluşturma veya nihai derlemenin işlevini azaltma riskini alır.

Bir ASB'deki tüm sorunlar için düzeltmelerin bulunduğundan emin olmak üzere tüm SoC iş ortaklarıyla birlikte çalışırız. Ancak üreticilerin, cihazın yaşam döngüsü için SoC tedarikçileriyle servis sözleşmesi yapmalarını öneririz. SoC'ler, bir yonga setine servis vermeyi istenenden daha erken durdurabilir. Bu nedenle, cihaz yonga seti seçiminden önce sözleşmeler yapmak cihaz lansmanı sürecinin önemli bir parçasıdır.

Son olarak, ASB'de belgelenen bir sorun için doğrudan edinmenin veya bağımsız olarak düzeltme oluşturmanın mümkün olmadığı durumlarda üretici, önceki Android SPL'yi koruyabilir ve mevcut yeni düzeltmeleri derlemeye ekleyebilir. Ancak bu uygulama, zaman içinde derleme sertifikasyonuyla ilgili sorunlara yol açar (Android, sertifikalı cihazlarda en son güvenlik yaması düzeyinin kullanılmasını sağlar). Google, bu uygulamayı önlemek için SoC'nizle önceden çalışmanızı önerir.

S: Üretici, bir ASB öğesinin ürünü için geçerli olmadığını belirlerse öğenin diğer Google şartlarını karşılamak veya CTS'yi geçmek için yine de uygulanması veya yaması yapılması gerekir mi?

C: Android güvenlik yaması düzeyi (SPL) beyan etmek için yamaları uygulamanız gerekmez. Bununla birlikte, üreticinin derlemesinin soruna karşı savunmasız olmadığını onaylaması gerekir.

Örneğin, üreticinin sisteminde yamalı bir bileşen yoksa veya bir bileşen, bir sorunu gidermek için üreticinin sisteminden kaldırılmışsa bu durumla karşılaşılabilir. Bu durumda, üreticinin bir yamayı uygulamasını gerektirmeden sistem uyumlu olabilir.

Bu, örneğin yalnızca kritik yamaları düzeltmek isteyen ve güvenlik testinin başarısız olmasına neden olacak diğer geçerli yamaları uygulamayan bir üreticiden temel olarak farklıdır. Bu durumda SPL'nin karşılanmadığından varsayılır.