Guida del produttore per la sicurezza a lungo termine di Android

Questa guida descrive le best practice consigliate da Google per l'applicazione di patch di sicurezza valutate dalla Compatibility Test Suite (CTS) di Android. È destinato ai produttori di apparecchiature OEM compatibili con Android (produttori) che verranno supportate per più di tre anni, come veicoli, TV, set-top box e elettrodomestici. Questa guida non è rivolta agli utenti finali (ad esempio i proprietari di veicoli).

Ringraziamenti e disclaimer

Questa guida non vincola legalmente o contrattualmente Google o altri produttori e non è intesa come un insieme di requisiti. Si tratta piuttosto di un aiuto didattico che descrive le pratiche consigliate.

Feedback

Questa guida non è esaustiva; sono previste ulteriori revisioni. Invia il feedback all'indirizzo manufacturers-guide-android@googlegroups.com.

Glossario

Termine Definizione
ACC Impegno di compatibilità Android. Precedentemente noto come Android Anti-Fragmentation Agreement (AFA).
AOSP Android Open Source Project
ASB Bollettino sulla sicurezza di Android
BSP Board Support Package
CDD Compatibility Definition Document
CTS Compatibility Test Suite (CTS)
FOTA firmware over-the-air
GPS sistema di posizionamento globale
MISRA Motor Industry Software Reliability Association
NIST National Institute of Standards and Technology
OBD diagnostica di bordo (OBD-II è un miglioramento rispetto a OBD-I sia in termini di funzionalità che di standardizzazione)
OEM produttore di apparecchiature originali
Sistema operativo sistema operativo
SEI Software Engineering Institute
SoC system on chip
SOP inizio della produzione
SPL Livello patch di sicurezza
TPMS sistema di monitoraggio della pressione dei pneumatici

Informazioni sul sistema operativo Android

Android è uno stack software completo open source basato su Linux progettato per una serie di dispositivi e fattori di forma. Dalla sua prima release nel 2008, Android è diventato il sistema operativo più utilizzato, su più di 1,4 miliardi di dispositivi in tutto il mondo (2016). Circa il 67% di questi dispositivi utilizza Android 5.0 (Lollipop) o versioni successive a partire da marzo 2017 (dati più recenti disponibili nella Dashboard Android). Sebbene la maggior parte dei dispositivi siano smartphone e tablet, Android è in crescita su smartwatch, TV e dispositivi di infotainment in-vehicle (IVI) per auto e motori.

Il numero di app per Android disponibili nel Google Play Store ha raggiunto più di 2,2 milioni (2016). Lo sviluppo di app per Android è supportato dal Programma di compatibilità Android, che definisce un insieme di requisiti tramite il Compatibility Definition Document (CDD) e fornisce strumenti di test tramite la Compatibility Test Suite (CTS). I programmi di compatibilità Android assicurano che qualsiasi app per Android possa essere eseguita su qualsiasi dispositivo compatibile con Android che supporta le funzionalità richieste per l'app.

Google rilascia regolarmente nuove versioni del sistema operativo, aggiornamenti della sicurezza del sistema operativo e informazioni sulle vulnerabilità scoperte. I produttori devono esaminare il bollettino sulla sicurezza di Android per verificare l'applicabilità di questi aggiornamenti ai prodotti supportati dal sistema operativo Android. Per una revisione della sicurezza, della compatibilità e dei sistemi di compilazione di Android, consulta quanto segue:

Informazioni sui veicoli connessi (prodotti canonici a lungo termine)

I veicoli hanno iniziato a essere connessi con l'introduzione della radio AM negli anni '20. Da lì, il numero di connessioni fisiche e wireless esterne ha iniziato a crescere man mano che le autorità di regolamentazione e le case automobilistiche si sono rivolte all'elettronica per semplificare la diagnostica e la manutenzione (ad esempio la porta OBD-II), migliorare la sicurezza (ad esempio il TPMS) e raggiungere gli obiettivi di risparmio di carburante. La successiva ondata di connettività ha introdotto funzionalità di praticità per il conducente come il sistema di accesso senza chiave, i sistemi telematici e funzionalità di infotainment avanzate come Bluetooth, Wi-Fi e proiezione dello smartphone. Oggi, la connettività e i sensori integrati (ad esempio il GPS) supportano i sistemi di sicurezza e di guida semiautonoma.

Con l'aumento del numero di connessioni dei veicoli, aumenta anche l'area della potenziale superficie di attacco del veicolo. Le connessioni comportano una serie di problemi di cybersicurezza simili a quelli per gli elettrodomestici. Tuttavia, sebbene i riavvii, gli aggiornamenti giornalieri delle patch e i comportamenti inspiegabili siano la norma per gli apparecchi elettronici di consumo, non sono coerenti per i prodotti con sistemi di sicurezza critici come i veicoli.

I produttori devono adottare un approccio proattivo per garantire la continuità della sicurezza e della posizione di sicurezza di un prodotto sul campo. In breve, i produttori devono essere a conoscenza delle vulnerabilità di sicurezza note nel prodotto e adottare un approccio basato sul rischio per risolverle.

Garantire la sicurezza a lungo termine

Un veicolo connesso a internet ha spesso una o più unità di controllo elettroniche (ECU) che includono più componenti software come sistema operativo, librerie, utilità e così via. I produttori devono monitorare questi componenti e identificare le vulnerabilità pubblicate note con analisi proattive, tra cui:

  • Valutare regolarmente il prodotto in base al database delle vulnerabilità ed esposizioni comuni (CVE).
  • Raccolta di informazioni per individuare i difetti di sicurezza relativi ai prodotti.
  • Test di sicurezza.
  • Analizzare attivamente i bollettini sulla sicurezza di Android.

Esempi di aggiornamenti del sistema operativo e delle patch di sicurezza (IVI con Android):

Figura 1. Esempio di implementazione di aggiornamenti principali del sistema operativo e della sicurezza durante il ciclo di vita del veicolo.

# Passaggio Attività

①

 Branch di sviluppo Il produttore seleziona una versione di Android (Android X). In questo esempio, "Android X" diventa la base di ciò che verrà spedito nel veicolo due anni prima dell'inizio iniziale della produzione.
② Lancio iniziale Alcuni mesi prima che Android X diventi la prima versione del sistema operativo fornita nel prodotto, gli aggiornamenti di sicurezza vengono ricavati dai bollettini sulla sicurezza di Android e potenzialmente da altre fonti ritenute utili dal produttore. y2 = il secondo bollettino sulla sicurezza per la versione X di Android, applicato (backportato) dal produttore ad Android X. Questo aggiornamento viene fornito con il prodotto e il timer di produzione inizia a ticchettare dall'anno zero con Android X.y2.

In questo esempio, il produttore ha deciso di non spedire la release annuale Android X+1 più recente. I motivi per cui viene rilasciata la release più recente includono l'aggiunta di nuove funzionalità, la risoluzione di nuove vulnerabilità di sicurezza e/o il rilascio di servizi Google o di terze parti che richiedono la versione più recente di Android. I motivi contro la spedizione con la release più recente sono la mancanza di tempo insita nel processo di sviluppo e lancio del veicolo necessaria per integrare, testare e convalidare le modifiche, nonché la conformità a tutti i requisiti normativi e di certificazione.
③ Aggiornamento completo del sistema operativo Dopo la SOP, il produttore rilascia l'aggiornamento del sistema operativo Android X+2, ovvero due release di Android dopo la versione utilizzata per il prodotto iniziale (Android X0). Gli aggiornamenti della sicurezza ASB sono disponibili per il livello API (a partire dalla data di spedizione), pertanto l'aggiornamento viene inviato come X+2.y0 circa 1,25 anni dopo la SOP. Questo aggiornamento del sistema operativo potrebbe essere o meno compatibile con i prodotti implementati. In questo caso, potrebbe essere creato un piano per aggiornare i veicoli di cui è stato eseguito il deployment.

A meno che non siano in vigore altri contratti commerciali, la decisione di eseguire un aggiornamento completo del sistema operativo è esclusivamente a discrezione del produttore.
④ Aggiornamento della sicurezza A due anni dalla fine del ciclo di produzione del veicolo, il produttore applica una patch al sistema operativo Android X+2. Questa decisione si basa sulla valutazione del rischio effettuata dal produttore. Il produttore sceglie il terzo aggiornamento della sicurezza ASB per la release X+2 come base dell'aggiornamento. I prodotti che ricevono l'aggiornamento della sicurezza ora sono al livello (X+2.y3) del sistema operativo + patch di sicurezza Android.

Sebbene i produttori possano selezionare singole patch di sicurezza da qualsiasi singolo ASB, devono risolvere tutti i problemi richiesti nel bollettino per utilizzare il livello della patch di sicurezza Android (SPL) associato al bollettino (ad esempio 05-02-2017). È responsabilità del produttore eseguire il backport e la release di sicurezza per il prodotto supportato.
⑤ Aggiornamento completo del sistema operativo Ripetizione del passaggio 3 (aggiornamento completo del sistema operativo). Il secondo aggiornamento completo del sistema operativo porta il prodotto ad Android X+4, tre anni dopo l'inizio del ciclo di vita produttivo del veicolo. Ora il produttore bilancia i requisiti hardware più recenti di una versione recente di Android con l'hardware del prodotto e l'utente beneficia di un sistema operativo Android aggiornato. Il produttore rilascia un aggiornamento senza aggiornamenti della sicurezza, quindi il prodotto ora è al livello (X+4.y0) OS + Android Security Patch.

In questo esempio, a causa di limitazioni hardware, X+4 è l'ultima versione principale di Android che verrà fornita per questo prodotto, anche se il veicolo ha una durata prevista di oltre 6 anni e richiede ancora il supporto della sicurezza.
⑥ Aggiornamento della sicurezza Ripeti il passaggio 4 (Aggiornamento della sicurezza). Il produttore ha il compito di trasferire gli aggiornamenti di sicurezza ASB da una versione molto più recente di Android (X+6) e di eseguire il porting di alcuni o di tutti questi aggiornamenti ad Android X+4. È responsabilità del produttore unire, integrare ed eseguire gli aggiornamenti (o stipulare un contratto con una terza parte). Inoltre, il produttore deve essere consapevole che i problemi di sicurezza nelle versioni di Android non più supportate non sono coperti dall'ASB.
⑦ Aggiornamento della sicurezza Otto anni dopo l'inizio del ciclo di vita produttivo del veicolo, quattro release di Android dall'ultimo aggiornamento del sistema operativo nel passaggio 5 (aggiornamento completo del sistema operativo) e dieci anni dalla specifica di Android X, il compito di gestire e eseguire il backporting delle patch di sicurezza è interamente a carico del produttore per le versioni precedenti a tre anni dalla release pubblica a livello di API.

Best practice per la sicurezza

Per rendere più difficili i compromessi relativi alla sicurezza, Google consiglia e utilizza le best practice comunemente accettate per la sicurezza e l'ingegneria del software, come descritto in Implementing Security.

Linee guida sulla sicurezza

Le best practice per la sicurezza includono:

  • Utilizza le versioni più recenti delle librerie esterne e dei componenti open source.
  • Non includere funzionalità di debug intrusive nelle versioni release del sistema operativo.
  • Rimuovi le funzionalità inutilizzate (per ridurre la superficie di attacco non necessaria).
  • Utilizza il principio del privilegio minimo e altre best practice per lo sviluppo di app per Android.

Linee guida per lo sviluppo di software

Le pratiche consigliate per lo sviluppo di software sicuro per il ciclo di vita del sistema include:

  • Esegui la modellazione delle minacce per classificare e identificare asset, minacce e potenziali mitigazioni.
  • Esegui la revisione dell'architettura/del design per garantire un design sicuro e affidabile.
  • Esegui regolarmente revisioni del codice per identificare antipattern e bug il prima possibile.
  • Progetta, implementa ed esegui test delle unità con una copertura del codice elevata, tra cui:
    • Test funzionali (inclusi casi di test negativi)
    • Test di regressione regolari (per assicurarti che i bug corretti non riappaiano)
    • Test di fuzz (nell'ambito della suite di test delle unità)
  • Utilizza strumenti di analisi statica del codice sorgente (scan-build, lint e così via) per identificare potenziali problemi.
  • Utilizza strumenti di analisi dinamica del codice sorgente, come AddressSanitizer, UndefinedBehaviorSanitizer e FORTIFY_SOURCE (per i componenti nativi), per identificare e mitigare potenziali problemi durante lo sviluppo del sistema.
  • Avere una strategia di gestione per il codice sorgente del software e la configurazione/versione della release.
  • Avere una strategia di gestione delle patch per la generazione e l'implementazione delle patch software.

Criterio di backporting della sicurezza

Al momento Google fornisce assistenza attiva per i backport di sicurezza delle vulnerabilità di sicurezza scoperte e segnalate per tre (3) anni dalla release pubblica del livello API. L'assistenza attiva è costituita da quanto segue:

  1. Ricevere e esaminare i report sulle vulnerabilità.
  2. Crea, testa e rilascia aggiornamenti della sicurezza.
  3. Fornire rilasci ricorrenti di aggiornamenti della sicurezza e dettagli dei bollettini sulla sicurezza.
  4. Esegui la valutazione della gravità in base alle linee guida stabilite.

Dopo tre anni dalla data di rilascio pubblico a livello di API, Google consiglia le seguenti linee guida:

  • Utilizza una terza parte (ad esempio un fornitore di SoC o di kernel) per il supporto del backport per gli aggiornamenti della sicurezza del sistema operativo risalenti a più di tre anni dalla release dell'API.
  • Utilizza una terza parte per eseguire revisioni del codice utilizzando gli ASB forniti pubblicamente. Sebbene gli annunci di sicurezza per il browser identifichino le vulnerabilità per la versione attualmente supportata, un produttore può utilizzare le informazioni fornite per confrontare gli aggiornamenti appena rilasciati con le versioni precedenti. Questi dati possono essere utilizzati per eseguire analisi di impatto e potenzialmente generare patch simili per le versioni del sistema operativo precedenti a tre anni dal rilascio dell'API.
  • Se opportuno, carica gli aggiornamenti della sicurezza nell'Android Open Source Project (AOSP).
  • Il produttore deve coordinare la gestione degli aggiornamenti della sicurezza per il codice specifico del fornitore (ad esempio, codice proprietario specifico del dispositivo).
  • Il produttore deve aderire al gruppo di notifica di anteprima del partner del bollettino sulla sicurezza di Android (richiede la firma di contratti legali come l'NDA per gli sviluppatori). I bollettini devono includere:
    • Annunci
    • Riepilogo dei problemi per livello di patch, inclusi CVE e gravità
    • Dettagli della vulnerabilità, se opportuno

Riferimenti aggiuntivi

Per istruzioni sulla programmazione sicura e sulle pratiche di sviluppo software, consulta quanto segue:

Google incoraggia l'utilizzo delle seguenti best practice consigliate.

In genere, è consigliabile lanciare qualsiasi prodotto connesso con la versione più recente del sistema operativo e un produttore deve tentare di utilizzare la versione più recente del sistema operativo prima di lanciare il prodotto. Sebbene il blocco della versione sia necessario per garantire la stabilità prima dei test e della convalida, il produttore deve bilanciare la stabilità del prodotto ottenuta dalle versioni precedenti del sistema operativo con le versioni più recenti del sistema operativo che presentano meno vulnerabilità di sicurezza note e protezioni di sicurezza avanzate.

Le linee guida consigliate includono:

  • A causa dei lunghi tempi di sviluppo inerenti al processo di sviluppo dei veicoli, i produttori potrebbero dover lanciare il prodotto con la versione del sistema operativo n-2 o precedente.
  • Mantieni la conformità alla compatibilità con Android per ogni versione del sistema operativo Android rilasciata con una campagna over-the-air (OTA).
  • Implementa il firmware over-the-air (FOTA) Android per aggiornamenti rapidi e intuitivi per i clienti. L'aggiornamento over-the-air (FOTA) deve essere eseguito utilizzando best practice di sicurezza come la firma del codice e la connessione TLS tra il prodotto e il backoffice IT.
  • Invia al team di sicurezza di Android le vulnerabilità di sicurezza di Android identificate in modo indipendente.

Nota:Google ha previsto notifiche specifiche per il settore o per il tipo di dispositivo nei bollettini sulla sicurezza di Android. Tuttavia, poiché Google non conosce il kernel, i driver o i chipset di un determinato dispositivo (veicolo, TV, indossabile, smartphone e così via), Google non ha un modo deterministico per etichettare un determinato problema di sicurezza con un tipo di dispositivo.

Il produttore deve fare ogni sforzo per utilizzare la versione più recente del sistema operativo o gli aggiornamenti della sicurezza per la versione in uso durante i miglioramenti del ciclo di vita del prodotto. Gli aggiornamenti possono essere eseguiti durante aggiornamenti periodici ricorrenti dei prodotti o per hotfix per risolvere problemi di qualità e/o altri problemi. Ecco alcune pratiche consigliate:

  • Crea un piano per gestire gli aggiornamenti di driver, kernel e protocolli.
  • Utilizza un metodo appropriato per il settore per fornire aggiornamenti ai veicoli di cui è stato eseguito il deployment.

Compatibility Definition Document (CDD)

Il Compatibility Definition Document (CDD) descrive i requisiti per un dispositivo affinché sia considerato compatibile con Android. Il CDD è pubblico e disponibile per tutti. Puoi scaricare le versioni del CDD da Android 1.6 alla versione più recente da source.android.com.

Per soddisfare questi requisiti per un prodotto, sono necessari i seguenti passaggi di base:

  1. Il partner firma l'impegno di compatibilità con Android (ACC) con Google. Viene quindi assegnato un consulente per le soluzioni tecniche (TSC) come guida.
  2. Il partner completa la revisione del CDD per la versione del sistema operativo Android del prodotto.
  3. Il partner esegue e invia i risultati del CTS (descritti di seguito) finché non sono accettabili per la compatibilità con Android.

Suite di test di compatibilità (Compatibility Test Suite, CTS)

Lo strumento di test Compatibility Test Suite (CTS) verifica che l'implementazione di un prodotto sia compatibile con Android e che siano incluse le patch di sicurezza più recenti. CTS è pubblico, open source e disponibile per tutti. Puoi scaricare le versioni CTS da Android 1.6 alla versione più recente da source.android.com.

Ogni build del software Android rilasciata al pubblico (immagini di installazione di fabbrica e di aggiornamento sul campo) deve dimostrare la compatibilità con Android tramite i risultati del CTS. Ad esempio, se il dispositivo esegue Android 7.1, quando viene creata e testata un'immagine di build con intent di rilascio, deve essere fatto riferimento alla versione corrispondente più recente di CDD 7.1 e CTS 7.1. I produttori sono vivamente incoraggiati a utilizzare CTS in anticipo e di frequente per identificare e risolvere i problemi.

NOTA: i partner che firmano altri contratti, come quelli relativi a Google Mobile Services (GMS), potrebbero dover soddisfare altri requisiti.

Flusso di lavoro CTS

Il workflow CTS prevede la configurazione dell'ambiente di test, l'esecuzione dei test, l'interpretazione dei risultati e la comprensione del codice sorgente CTS. Le seguenti linee guida hanno lo scopo di aiutare gli utenti del CTS (ad esempio sviluppatori, produttori) a utilizzare il CTS in modo efficace ed efficiente.

  • Esegui i test di frequente. CTS è progettato come uno strumento automatizzato che si integra nel tuo sistema di build. Eseguire frequentemente i CTS può aiutarti a trovare rapidamente e in anticipo i difetti quando si verificano degradi o regressioni del software.
  • Scarica ed esamina il codice sorgente di CTS. Il codice sorgente completo di CTS è un software open source che chiunque può scaricare e utilizzare (il codice sorgente scaricato è completamente compilabile ed eseguibile). Quando un test non va a buon fine sul dispositivo, esaminare la sezione pertinente del codice sorgente può aiutarti a identificare il motivo.
  • Ottieni la versione più recente del CTS. Le nuove release di Android possono aggiornare il CTS con correzioni di bug, miglioramenti e nuovi test. Controlla spesso la sezione Download di CTS e aggiorna il tuo programma CTS in base alle necessità. Il produttore e Google devono concordare la versione del CTS da superare per il lancio del prodotto, in quanto il prodotto deve essere bloccato a un certo punto mentre il CTS continua a essere aggiornato.

Superare il CTS

Per un prodotto compatibile con Android, Google garantisce che i risultati dei test del CTS e dei report del CTS Verifier del dispositivo siano accettabili. In linea di principio, tutti i test devono essere superati. Tuttavia, un test che non supera il test per motivi diversi dalla mancata conformità del dispositivo ai requisiti di compatibilità Android è soggetto a revisione da parte di Google. Durante questo processo:

  1. Il produttore fornisce a Google le patch CTS proposte, le relative convalide e le giustificazioni per dimostrare l'argomento.
  2. Google esamina il materiale inviato e, se accettato, aggiorna i test CTS pertinenti in modo che il dispositivo li superi nella revisione successiva del CTS.

Se un test CTS non va a buon fine all'improvviso dopo l'applicazione di una patch di sicurezza, il produttore deve modificare la patch in modo che non violi la compatibilità OPPURE dimostrare che il test è errato e fornire una correzione per il test (come descritto sopra).

Il CTS rimane aperto per le revisioni delle correzioni dei test. Ad esempio, Android 4.4 continua ad accettare correzioni (vedi https://android-review.googlesource.com/#/c/273371/).

Domande frequenti

D: Chi è responsabile dell'applicazione degli aggiornamenti della sicurezza a un'implementazione specifica di Android?

A: Il produttore che fornisce direttamente il dispositivo è responsabile. Questa entità non appartiene a Google, che pubblica aggiornamenti della sicurezza in AOSP e non per un dispositivo specifico (ad esempio un veicolo).

D: In che modo Google gestisce i problemi di sicurezza in Android?

R: Google esamina continuamente i problemi e sviluppa potenziali correzioni, che rende disponibili per tutti i livelli API supportati nell'ambito della normale procedura di aggiornamento della sicurezza. Da agosto 2015, Google ha mantenuto una cadenza regolare di pubblicazione di bollettini e link agli aggiornamenti su source.android.com. Google pubblica inoltre aggiornamenti della sicurezza nell'ambito delle release principali del sistema operativo. Consulta anche le norme relative al backport della sicurezza.

D: se un produttore ha integrato tutte le patch AOSP di un ASB, ma non ha integrato le patch del fornitore BSP menzionate nello stesso bollettino, può comunque aumentare il livello di sicurezza (ad esempio applicare la patch corrispondente alla piattaforma/alla build)?

R: per dichiarare un livello patch di sicurezza Android (SPL), un produttore deve risolvere tutti i problemi obbligatori pubblicati nel bollettino sulla sicurezza di Android (inclusi i bollettini precedenti) e mappati a un determinato SPL Android. Ad esempio, un produttore che utilizza il Bollettino sulla sicurezza di marzo 2017 (SPL del 01/03/2017) ha risolto tutti i problemi obbligatori documentati nel bollettino di marzo 2017 per quel SPL e tutti gli aggiornamenti precedenti, inclusi gli aggiornamenti specifici del dispositivo per tutti i precedenti bollettino sulla sicurezza di Android, inclusi gli aggiornamenti specifici del dispositivo associati al SPL del 05/02/2017.

D: cosa succede quando il produttore non è d'accordo con gli aggiornamenti della sicurezza forniti dal fornitore BSP OPPURE quando gli aggiornamenti della sicurezza obbligatori da parte di un ASB non sono forniti dai fornitori?

R: un ASB descrive le vulnerabilità di sicurezza (elencate in un elenco di CVE) e spesso fornisce test di sicurezza corrispondenti. L'obiettivo è garantire che le vulnerabilità elencate non possano più essere riprodotte su un dispositivo e che il dispositivo possa superare i test di sicurezza associati. Pertanto, il problema non riguarda l'applicazione di un aggiornamento della sicurezza fornito da Google o da un fornitore di terze parti, ma l'attestazione del produttore che il dispositivo non è vulnerabile all'elenco delle CVE nell'ASB. Il produttore è libero di utilizzare gli aggiornamenti della sicurezza forniti o, se ha una modifica più appropriata per il proprio dispositivo, di utilizzarla.

Ad esempio, prendiamo il caso in cui Google risolva una vulnerabilità di sicurezza di AOSP utilizzando una modifica del codice che consente al componente di rimanere completamente funzionale e conforme al CDD. Se il produttore stabilisce che il componente non è necessario sul dispositivo o non è obbligatorio dal CDD (o dai test di certificazione correlati), il produttore può rimuoverlo per ridurre le future esigenze di assistenza e ridurre la superficie di attacco. Sebbene il produttore non abbia utilizzato l'aggiornamento della sicurezza fornito, ha comunque garantito che il dispositivo non è vulnerabile alla CVE documentata nel bollettino della sicurezza. Tuttavia, se si discosta dall'aggiornamento della sicurezza consigliato, il produttore rischia di risolvere in modo errato il problema, di introdurre nuove vulnerabilità di sicurezza o di ridurre la funzionalità della build finale.

Sebbene collaboriamo con tutti i partner SoC per garantire che esistano correzioni per tutti i problemi in un ASB, consigliamo ai produttori di stipulare un contratto di assistenza con i propri fornitori di SoC per il ciclo di vita di un dispositivo. Gli SoC potrebbero interrompere il servizio di un chipset prima del previsto, pertanto la stipula di contratti prima della selezione del chipset del dispositivo è una parte importante della procedura di lancio del dispositivo.

Infine, nei casi in cui sia impossibile acquisire direttamente o creare in modo indipendente una correzione per un problema documentato in un ASB, un produttore potrebbe mantenere la precedente SPL Android e aggiungere comunque le nuove correzioni disponibili alla build. Tuttavia, questa pratica alla fine causerà problemi con la certificazione della build (poiché Android garantisce che il livello della patch di sicurezza più recente sia disponibile sui dispositivi certificati). Google consiglia di collaborare in anticipo con il tuo SoC per evitare questa pratica.

D: se il produttore stabilisce che un elemento ASB non è applicabile al proprio prodotto, deve comunque essere applicato o sottoposto a patch per soddisfare gli altri requisiti di Google o superare il CTS?

R: Non è necessario applicare patch per dichiarare un livello di patch di sicurezza Android (SPL). È necessario che il produttore attesti che la sua build non è vulnerabile al problema.

Un esempio è quando un componente sottoposto a patch non esiste nel sistema del produttore o un componente viene rimosso dal sistema del produttore per risolvere un problema. In questo caso, il sistema potrebbe essere conforme senza che il produttore debba applicare una patch.

Questo è fondamentalmente diverso dal caso in cui un produttore voglia, ad esempio, correggere solo le patch critiche, senza applicare altre patch applicabili che causerebbero il fallimento di un test di sicurezza. In questo caso, si presume che l'SPL non sia stato raggiunto.