Questa guida descrive le best practice consigliate da Google per l'applicazione delle patch di sicurezza valutate dal 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 destinati agli utenti finali (ad esempio, proprietari di veicoli).
Ringraziamenti e disclaimer
Questa guida non vincola legalmente o contrattualmente Google o altri produttori e non inteso come un insieme di requisiti. Si tratta piuttosto di un aiuto didattico che descrive le pratiche consigliate.
Feedback
Questa guida non intende essere completa; in cui sono previste ulteriori revisioni. Invia feedback all'indirizzo Manufacturer-guide-android@googlegroups.com.
Glossario
| Termine | Definizione |
|---|---|
| ACC | Impegno per la compatibilità Android. Noto in precedenza come anti-frammentazione Android del Contratto (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 degli 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). La maggior parte dei dispositivi è composta da telefoni cellulari e tablet, mentre Android è in crescita in smartwatch, TV e dispositivi di infotainment nel veicolo (IVI).
È stato raggiunto il numero di app Android disponibili nel Google Play Store 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 garantiscono 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 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:
- Proteggere un dispositivo Android
- Risorse e aggiornamenti della sicurezza
- Compatibility Test Suite (CTS)
- Nomi in codice, tag e numeri build
Informazioni sui veicoli connessi (prodotti canonici a lunga durata)
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 i regolatori e i produttori di auto si sono rivolti 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 la proiezione dello smartphone. Oggi, sensori e connettività integrati (ad es. GPS) supportano la sicurezza e la guida semi-autonoma sistemi operativi.
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 un livello di sicurezza costante 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.
- Analisi attiva dei 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 un importante aggiornamento del sistema operativo e della sicurezza nel corso del ciclo di vita del veicolo.
| # | Passaggio | Attività |
|---|---|---|
|
① |
Ramo di Sviluppo | Il produttore seleziona una versione di Android (Android X). In questo esempio, "Android X" diventa la base di ciò che verrà spedito a bordo del veicolo due anni prima dell'inizio Produzione (SOP). |
| ② | Lancio iniziale | Alcuni mesi prima che Android X diventi la prima versione del sistema operativo fornita all'interno del prodotto, la sicurezza
vengono presi dai bollettini sulla sicurezza di Android e potenzialmente da altre fonti ritenute
è importante per il produttore. y2 = il secondo bollettino sulla sicurezza per la versione X di Android,
applicata dal produttore ad Android X (con backporting). 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 recente release annuale di Android X+1. Motivi per la spedizione del più recente includono l'aggiunta di nuove funzionalità, la risoluzione di nuove vulnerabilità di sicurezza e/o la spedizione 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. |
| 3 | 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). Sono disponibili aggiornamenti della sicurezza ASB
per il livello API (alla data di spedizione), quindi l'aggiornamento viene emesso come X+2.y0 circa 1.25
anni dopo SOP. Questo aggiornamento del sistema operativo potrebbe essere compatibile o meno con i prodotti sul campo. In tal 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 è interamente 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 ogni singolo ASB, Devi risolvere tutti i problemi richiesti nel bollettino per utilizzare il livello patch di sicurezza (SPL) di Android associati al bollettino (ad esempio, 2017-02-05). È responsabilità del produttore eseguire il backport e la release di sicurezza per il prodotto supportato. |
| ⑤ | Aggiornamento completo del sistema operativo | Ripetindo il passaggio 3 (Aggiornamento completo del sistema operativo), con il secondo aggiornamento completo del sistema operativo, il prodotto
Android X+4, tre anni di durata della produzione del veicolo. Il produttore ora
bilanciare i nuovi requisiti hardware di una versione recente di Android con l'hardware in
il prodotto e i vantaggi per l'utente da 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 garantire la sicurezza ASB aggiornamenti da una versione molto più recente di Android (X+6) e la portabilità di alcuni o tutti gli aggiornamenti tornando 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 sapere che I problemi di sicurezza nelle versioni di Android non più supportate non sono trattati in ASB. |
| ⑦ | Aggiornamento della sicurezza | Otto anni nel ciclo di vita della produzione del veicolo, quattro release Android dal all'ultimo aggiornamento del sistema operativo nel Passaggio 5 (Aggiornamento completo del sistema operativo) e dieci anni dopo la specifica di Android X, curare e distribuire le patch di sicurezza è interamente a carico del produttore, più vecchie di tre anni dalla release pubblica a livello 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 pratiche consigliate 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 l'area 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
Pratiche consigliate per lo sviluppo sicuro del software 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 revisioni regolari 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 regolari di regressione (per garantire che i bug corretti non si ripresentino)
- Test di fuzz (nell'ambito della suite di test delle unità)
- Utilizza strumenti di analisi del codice sorgente statico (scan-build, lint e così via) per identificare potenziali per risolvere problemi di produzione e facilità d'uso.
- 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 del codice sorgente del software e della configurazione/versione della release.
- Avere una strategia di gestione delle patch per la generazione e il deployment di patch software.
Criterio di backport della sicurezza
Google attualmente fornisce supporto attivo per i backport di sicurezza rilevati e segnalati vulnerabilità di sicurezza per tre (3) anni dal Release pubblica a livello API. L'assistenza attiva è costituita da quanto segue:
- Ricevi e analizza i report sulle vulnerabilità.
- Crea, testa e rilascia aggiornamenti della sicurezza.
- Fornisci versioni ricorrenti degli aggiornamenti della sicurezza e dettagli del bollettino sulla sicurezza.
- 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:
- Usa una terza parte (come un fornitore SoC o Kernel) per il supporto del backport per la sicurezza del sistema operativo più vecchi di tre anni dal rilascio dell'API.
- Utilizza una terza parte per eseguire revisioni del codice utilizzando gli ASB forniti pubblicamente. Sebbene gli ASB 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 eseguire analisi d'impatto e generare potenzialmente patch simili per le versioni del sistema operativo precedenti 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 di 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à ove appropriato
Riferimenti aggiuntivi
Per istruzioni sulla programmazione sicura e sulle pratiche di sviluppo software, consulta quanto segue:
- Software per il settore automobilistico Associazione di affidabilità (MISRA).
- Strumenti e metodi del Software Engineering Institute (SEI).
- National Institute of Standards e Tecnologia (NIST).
Pratiche consigliate per i prodotti
Google incoraggia l'utilizzo delle seguenti best practice consigliate.
Linee guida generali per il lancio
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 favorire la stabilità prima dei test e della convalida, il produttore deve bilanciare la stabilità del prodotto ottenuta dalle versioni meno recenti del sistema operativo con quelle più recenti con meno vulnerabilità note e protezioni di sicurezza avanzate.
Le linee guida consigliate includono:
- A causa dei lunghi tempi di risposta inerenti al processo di sviluppo dei veicoli, i produttori potrebbe essere necessario avviare il sistema operativo n-2 o versioni precedenti.
- Mantieni la conformità con la compatibilità Android per ogni versione rilasciata del sistema operativo Android con un una campagna over-the-air (OTA).
- Implementazione del prodotto con funzionalità firmware over-the-air (FOTA) per Android per un'esperienza rapida e di facile utilizzo aggiornamenti. 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 tipo di dispositivo o per il settore nei bollettini sulla sicurezza di Android. Tuttavia, poiché Google non conosce il kernel, driver o chipset per un determinato dispositivo (veicolo, TV, indossabile, telefono e così via), Google non ha un modo deterministico per associare un determinato problema di sicurezza a un tipo di dispositivo.
Linee guida per il ciclo di vita del prodotto
Il produttore deve fare tutto il possibile per utilizzare la versione più recente del sistema operativo o gli aggiornamenti della sicurezza per la versione in uso durante i miglioramenti del ciclo dei prodotti. Gli aggiornamenti possono essere eseguiti durante i periodi aggiornamenti periodici sui prodotti o per correzioni rapide 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.
- Utilizzare un metodo appropriato nel settore per fornire aggiornamenti ai veicoli di cui è stato eseguito il deployment.
Compatibility Definition Document (CDD)
Il Compatibility Definition Document (CDD) descrive i requisiti necessari affinché un dispositivo sia preso in considerazione. Compatibile con Android. Il CDD è pubblico e disponibile per tutti; puoi scaricare le versioni del CDD da Android 1.6 all'ultima versione da source.android.com.
Per soddisfare questi requisiti per un prodotto sono necessari i seguenti passaggi di base:
- Il partner firma l'impegno per la compatibilità Android (ACC) con Google. Una soluzione tecnica Il consulente (TSC) viene quindi assegnato come guida.
- Il partner completa la revisione CDD per la versione del sistema operativo Android del prodotto.
- 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 disponibili 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 sul dispositivo è installato Android 7.1, quando si deve fare riferimento all’ultima versione corrispondente di CDD 7.1 e CTS 7.1 viene creata e testata l'immagine build con intent di rilascio. I produttori sono vivamente incoraggiati a utilizzare CTS tempestivamente e frequentemente per identificare e risolvere i problemi.
Flusso di lavoro CTS
Il flusso di lavoro 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 CTS (ad esempio sviluppatori, produttori) 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 CTS. Il codice sorgente CTS completo è aperto sorgente software che chiunque può di scaricare e usare (il codice sorgente scaricato è completamente generabile ed eseguibile). Quando un test non riesce sul dispositivo, l'esame la sezione pertinente del codice sorgente può aiutarti a identificarne il motivo.
- Ottieni i CTS più recenti. Le nuove release di Android possono aggiornare il CTS con correzioni di bug, miglioramenti e nuovi test. Controlla spesso la pagina Download CTS e aggiorna il tuo programma CTS in base alle necessità. Il Produttore e Google concorderanno la versione CTS a 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 i report CTS e lo strumento di verifica CTS del dispositivo i risultati del test siano accettabili. In linea di principio, tutti i test devono essere superati. Tuttavia, un test che non riesce Motivi diversi dalla mancata conformità del dispositivo ai requisiti di compatibilità con Android. sono soggetti a revisione da parte di Google. Durante questo processo:
- Il produttore fornisce a Google le patch CTS, le convalide delle patch e giustificative per dimostrare l'argomento.
- 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 riesce improvvisamente dopo l'applicazione di una patch di sicurezza, il produttore deve modificare la patch in modo da non danneggiare la compatibilità OPPURE mostrare che il test è errato e fornire una correzione 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 (visita la pagina 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 è 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 su Android?
R: Google esamina continuamente i problemi e sviluppa potenziali correzioni, cosa che rende disponibile per tutti i livelli API supportati nell'ambito del normale processo di aggiornamento della sicurezza. Da agosto di 2015, Google ha gestito una cadenza regolare di pubblicazione di bollettini e link agli aggiornamenti source.android.com; Google pubblica anche aggiornamenti della sicurezza come parte delle principali release del sistema operativo. Vedi anche Criterio di backport di 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 Bollettino sulla sicurezza di marzo 2017 (SPL 2017-03-01) ha risolto tutti i problemi richiesti documentati nel bollettino di marzo 2017 a riguardo. SPL e tutti gli aggiornamenti precedenti, inclusi gli aggiornamenti specifici del dispositivo per tutte le versioni precedenti di Android Security Bollettini, inclusi gli aggiornamenti specifici del dispositivo associati all'SPL 2017-02-05.
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ù riprodotti su un dispositivo e che quest'ultimo possa superare i test di sicurezza associati. Di conseguenza, il problema è non riguarda gli aggiornamenti per la sicurezza forniti da Google o da un fornitore di terze parti, ma riguarda le che attesta che il dispositivo non è vulnerabile all'elenco di 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, considera un caso in cui Google risolva una vulnerabilità di sicurezza AOSP utilizzando un modifica al codice che consenta al componente di rimanere completamente funzionante 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, in deviazione dall'aggiornamento di sicurezza consigliato, il produttore si assume il rischio di risolvere il problema, introdurre nuove vulnerabilità di sicurezza o ridurre la funzionalità della build finale.
Sebbene collaboriamo con tutti i partner SoC per garantire l'esistenza delle correzioni per tutti i problemi di un ASB, consigliamo che i produttori assicurano un accordo di servizio con i fornitori di SoC per l'intero ciclo di vita dispositivo. I SoC potrebbero interrompere la fornitura di un chipset prima del previsto, quindi stabilire accordi prima la selezione del chipset del dispositivo è una parte importante del processo di avvio 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 l'SPL Android precedente e aggiungere comunque le nuove correzioni disponibili alla build. Tuttavia, questa prassi porterà a problemi di compilazione (poiché Android garantisce che il livello patch di sicurezza più recente sia disponibile sui dispositivi). 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, l'elemento 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.