Guide du fabricant pour la sécurité Android à long terme

Ce guide décrit les bonnes pratiques recommandées par Google pour appliquer les correctifs de sécurité évalués par la Compatibility Test Suite (CTS) Android. Il est destiné aux fabricants d'équipements OEM compatibles avec Android (fabricants) qui seront pris en charge pendant plus de trois ans, tels que les véhicules, les téléviseurs, les boîtiers décodeurs et les appareils électroménagers. Ce guide n'est pas destiné aux utilisateurs finaux (par exemple, les propriétaires de véhicules).

Remerciements et clauses de non-responsabilité

Ce guide n'engage pas Google ni d'autres fabricants sur le plan juridique ni contractuel, et n'a pas vocation à constituer un ensemble d'exigences. Il s'agit plutôt d'un outil pédagogique qui décrit les pratiques recommandées.

Commentaires

Ce guide n'a pas vocation à être exhaustif. D'autres révisions sont prévues. Envoyez vos commentaires à l'adresse manufacturers-guide-android@googlegroups.com.

Glossaire

Terme Définition
ACC Engagement de compatibilité Android Anciennement appelé "Android Anti-Fragmentation Agreement" (AFA).
AOSP Projet Android Open Source
ASB bulletin sur la sécurité d'Android
BSP Formule d'assistance de la carte
CDD Document de définition de la compatibilité
CTS Compatibility Test Suite
FOTA micrologiciel Over The Air
GPS système de positionnement global
MISRA Motor Industry Software Reliability Association
NIST National Institute of Standards and Technology (NIST)
OBD Diagnostic embarqué (OBD-II est une amélioration par rapport à OBD-I en termes de fonctionnalités et de normalisation)
OEM fabricant d'équipement d'origine
OS système d'exploitation
SEI Software Engineering Institute
SoC (System on Chip) système sur une puce
SOP début de la production
SPL Niveau du correctif de sécurité
TPMS système de surveillance de la pression des pneus

À propos de l'OS Android

Android est une pile logicielle complète Open Source basée sur Linux, conçue pour différents appareils et facteurs de forme. Depuis sa première version en 2008, Android est devenu le système d'exploitation (OS) le plus populaire, et équipe plus de 1,4 milliard d'appareils dans le monde (2016). Environ 67% de ces appareils utilisent Android 5.0 (Lollipop) ou une version ultérieure en mars 2017 (des chiffres plus récents sont disponibles sur le tableau de bord Android). Bien que la grande majorité des appareils soient des téléphones mobiles et des tablettes, Android est en plein essor sur les montres connectées, les téléviseurs et les systèmes d'infodivertissement embarqués (IVI) pour les véhicules automobiles.

Le nombre d'applications Android disponibles sur le Google Play Store a atteint plus de 2,2 millions (2016). Le développement d'applications Android est pris en charge par le programme de compatibilité Android, qui définit un ensemble d'exigences via un document de définition de la compatibilité (CDD) et fournit des outils de test via la suite de tests de compatibilité (CTS). Les programmes de compatibilité Android garantissent que n'importe quelle application Android peut s'exécuter sur n'importe quel appareil compatible avec Android qui prend en charge les fonctionnalités requises pour l'application.

Google publie régulièrement de nouvelles versions d'OS, des mises à jour de sécurité de l'OS et des informations sur les failles détectées. Les fabricants doivent examiner le bulletin de sécurité Android pour déterminer si ces mises à jour sont applicables aux produits compatibles avec le système d'exploitation Android. Pour en savoir plus sur la sécurité, la compatibilité et les systèmes de compilation Android, consultez les ressources suivantes:

À propos des véhicules connectés (produits canoniques durables)

Les véhicules ont commencé à être connectés avec l'introduction de la radio AM dans les années 1920. À partir de là, le nombre de connexions physiques et sans fil externes a commencé à augmenter à mesure que les régulateurs et les constructeurs automobiles se sont tournés vers l'électronique pour faciliter les diagnostics et la maintenance (par exemple, le port OBD-II), améliorer la sécurité (par exemple, le TPMS) et atteindre les objectifs d'économie de carburant. La vague suivante de connectivité a introduit des fonctionnalités pratiques pour le conducteur, comme l'accès sans clé à distance, les systèmes télématiques et les fonctionnalités d'infodivertissement avancées telles que le Bluetooth, le Wi-Fi et la projection sur smartphone. Aujourd'hui, les capteurs et la connectivité intégrés (par exemple, le GPS) sont compatibles avec les systèmes de sécurité et de conduite semi-autonome.

À mesure que le nombre de connexions de véhicules augmente, la surface de la surface d'attaque potentielle du véhicule augmente également. Les connexions posent des problèmes de cybersécurité similaires à ceux des appareils électroniques grand public. Toutefois, bien que les redémarrages, les mises à jour quotidiennes des correctifs et les comportements inexpliqués soient la norme pour les produits électroniques grand public, ils sont incohérents pour les produits dotés de systèmes critiques pour la sécurité, tels que les véhicules.

Les fabricants doivent adopter une approche proactive pour garantir la sécurité et la sûreté continues d'un produit sur le terrain. En résumé, les fabricants doivent être conscients des failles de sécurité connues du produit et adopter une approche basée sur les risques pour les résoudre.

Assurer la sécurité à long terme

Un véhicule connecté comporte souvent une ou plusieurs unités de contrôle électronique (ECU) qui incluent plusieurs composants logiciels tels que l'OS, les bibliothèques, les utilitaires, etc. Les fabricants doivent suivre ces composants et identifier les failles publiées connues à l'aide d'une analyse proactive, y compris:

  • Évaluer régulièrement le produit par rapport à la base de données CVE (Common Vulnerabilities and Exposures, ou failles et expositions courantes)
  • Collecte d'informations sur les failles de sécurité liées aux produits
  • Tests de sécurité
  • Analyse active des bulletins de sécurité Android

Exemples de mises à jour de l'OS et de correctifs de sécurité (IVI exécutant Android):

Figure 1 : Exemple de déploiement de mises à jour majeures de l'OS et de sécurité sur la durée de vie du véhicule.

# Étape Activités

①

 Branche de développement Le fabricant sélectionne une version d'Android (Android X). Dans cet exemple, "Android X" devient la base de ce qui sera livré dans le véhicule deux ans avant le début de la production (SOP, Start of Production).
② Lancement initial Quelques mois avant qu'Android X ne devienne la première version du système d'exploitation fournie avec le produit, les mises à jour de sécurité sont extraites des bulletins de sécurité Android (ASB) et d'autres sources jugées utiles par le fabricant. y2 = deuxième bulletin de sécurité pour la version X d'Android, appliqué (porté en arrière) par le fabricant à Android X. Cette mise à jour est fournie avec le produit, et l'horloge de production commence à tourner à l'année 0 avec Android X.y2.

Dans cet exemple, le fabricant a décidé de ne pas expédier la version annuelle la plus récente d'Android X+1. Les raisons pourquoi nous proposons la version la plus récente incluent l'ajout de nouvelles fonctionnalités, la correction de nouvelles failles de sécurité et/ou la diffusion de services Google ou tiers qui nécessitent la version Android la plus récente. Les raisons contre la livraison avec la version la plus récente sont le manque de temps inhérent au processus de développement et de lancement du véhicule requis pour intégrer, tester et valider les modifications, y compris la conformité à toutes les exigences réglementaires et de certification.
③ Mise à jour complète de l'OS Après la mise sur le marché, le fabricant publie la mise à jour de l'OS Android X+2, soit deux versions d'Android après la version utilisée pour le produit initial (Android X0). Les mises à jour de sécurité ASB sont disponibles pour le niveau d'API (à compter de la date d'expédition). La mise à jour est donc publiée sous la forme X+2.y0, soit environ 1,25 an après la SOP. Cette mise à jour de l'OS peut être ou non compatible avec les produits déployés. Si c'est le cas, un plan peut être créé pour mettre à jour les véhicules déployés.

Sauf si d'autres accords commerciaux sont en place, la décision de procéder à une mise à jour complète de l'OS relève entièrement du fabricant.
④ Mise à jour de sécurité Deux ans après le début de la production du véhicule, le constructeur corrige l'OS Android X+2. Cette décision est basée sur l'évaluation des risques du fabricant. Le fabricant choisit la troisième mise à jour de sécurité de l'ASB pour la version X+2 comme base de la mise à jour. Les produits qui reçoivent la mise à jour de sécurité sont désormais à (X+2.y3) OS + niveau du correctif de sécurité Android.

Bien que les fabricants puissent sélectionner des correctifs de sécurité individuels à partir de n'importe quel bulletin de sécurité Android, ils doivent corriger tous les problèmes requis dans le bulletin pour utiliser le niveau de correctif de sécurité Android (SPL) associé au bulletin (par exemple, 2017-02-05). Il incombe au fabricant de procéder au rétroportage et à la publication de la mise à jour de sécurité pour le produit pris en charge.
⑤ Mise à jour complète de l'OS Comme pour l'étape 3 (Mise à jour complète de l'OS), la deuxième mise à jour complète de l'OS met à niveau le produit vers Android X+4, trois ans après le début de la durée de vie de production du véhicule. Le fabricant équilibre désormais les nouvelles exigences matérielles d'une version récente d'Android avec le matériel du produit, et l'utilisateur bénéficie d'un système d'exploitation Android mis à jour. Le fabricant publie une mise à jour sans mise à jour de sécurité. Le produit est donc désormais à (X+4.y0) OS + niveau du correctif de sécurité Android.

Dans cet exemple, en raison de limitations matérielles, X+4 est la dernière version majeure d'Android qui sera fournie pour ce produit, bien que la durée de vie prévue du véhicule soit supérieure à six ans et nécessite toujours une prise en charge de la sécurité.
⑥ Mise à jour de sécurité Répétez l'étape 4 (Mise à jour de sécurité). Le fabricant doit récupérer les mises à jour de sécurité de l'ASB à partir d'une version beaucoup plus récente d'Android (X+6) et les porter en partie ou en totalité vers Android X+4. Il incombe au fabricant de fusionner, d'intégrer et d'effectuer les mises à jour (ou de passer un contrat avec un tiers). Le fabricant doit également savoir que les problèmes de sécurité liés aux versions d'Android qui ne sont plus prises en charge ne sont pas couverts par l'ASB.
⑦ Mise à jour de sécurité Huit ans après le début du cycle de vie de production du véhicule, quatre versions d'Android depuis la dernière mise à jour de l'OS à l'étape 5 (Mise à jour complète de l'OS) et dix ans après la spécification d'Android X, la responsabilité de la sélection et du rétroportage des correctifs de sécurité incombe entièrement au constructeur pour les versions datant de plus de trois ans à compter de la publication publique au niveau de l'API.

Bonnes pratiques relatives à la sécurités

Pour rendre les compromis de sécurité plus difficiles, Google recommande et applique les bonnes pratiques couramment acceptées en matière de sécurité et d'ingénierie logicielle, comme décrit dans la section Implémenter la sécurité.

Consignes de sécurité

Voici quelques bonnes pratiques en matière de sécurité:

  • Utilisez les dernières versions des bibliothèques externes et des composants Open Source.
  • N'incluez pas de fonctionnalité de débogage intrusive dans les versions de l'OS.
  • Supprimez les fonctionnalités inutilisées (pour réduire la surface d'attaque inutile).
  • Appliquez le principe du moindre privilège et d'autres bonnes pratiques de développement d'applications Android.

Consignes de développement logiciel

Voici quelques bonnes pratiques recommandées pour le développement logiciel sécurisé tout au long du cycle de vie du système:

  • Effectuez une modélisation des menaces pour classer et identifier les ressources, les menaces et les mesures d'atténuation potentielles.
  • Effectuez un examen de l'architecture/de la conception pour vous assurer qu'elle est sécurisée et fiable.
  • Effectuez des examens réguliers du code pour identifier les anti-modèles et les bugs dès que possible.
  • Concevoir, implémenter et exécuter des tests unitaires à couverture de code élevée, y compris :
    • Tests fonctionnels (y compris les scénarios de test négatifs)
    • Des tests de régression réguliers (pour s'assurer que les bugs corrigés ne réapparaissent pas)
    • Test fuzz (dans le cadre de la suite de tests unitaires)
  • Utilisez des outils d'analyse de code source statique (scan-build, lint, etc.) pour identifier les problèmes potentiels.
  • Utilisez des outils d'analyse dynamique du code source, tels que AddressSanitizer, UndefinedBehaviorSanitizer et FORTIFY_SOURCE (pour les composants natifs) pour identifier et atténuer les problèmes potentiels lors du développement du système.
  • Avoir une stratégie de gestion du code source logiciel et de la configuration/version de la version
  • Avoir une stratégie de gestion des correctifs pour la génération et le déploiement de correctifs logiciels.

Règle de rétroportage de sécurité

Google fournit actuellement une assistance active pour les rétroports de sécurité des failles de sécurité détectées et signalées pendant trois (3) ans à compter de la publication publique du niveau d'API. L'assistance active comprend les éléments suivants:

  1. Recevoir et examiner les rapports sur les failles
  2. Créer, tester et publier des mises à jour de sécurité
  3. Publier régulièrement des mises à jour de sécurité et des informations sur les bulletins de sécurité
  4. Effectuez une évaluation de la gravité conformément aux consignes établies.

Trois ans après la date de publication publique du niveau d'API, Google recommande les consignes suivantes:

  • Utilisez un tiers (tel qu'un fournisseur de SoC ou de kernel) pour la rétroportabilité des mises à jour de sécurité de l'OS datant de plus de trois ans après la publication de l'API.
  • Faites appel à un tiers pour effectuer des examens du code à l'aide des ASB fournies publiquement. Bien que les avis de sécurité de Google identifient les failles de la version actuellement prise en charge, un fabricant peut utiliser les informations fournies pour comparer les nouvelles mises à jour aux versions précédentes. Ces données peuvent être utilisées pour effectuer une analyse d'impact et potentiellement générer des correctifs similaires pour les versions d'OS datant de plus de trois ans à compter de la publication de l'API.
  • Le cas échéant, importez les mises à jour de sécurité dans le projet Android Open Source (AOSP).
  • Le fabricant doit coordonner la gestion des mises à jour de sécurité pour le code spécifique au fournisseur (par exemple, le code propriétaire spécifique à l'appareil).
  • Le fabricant doit rejoindre le groupe de notification Preview du bulletin de sécurité Android pour les partenaires NDA (nécessite la signature d'accords juridiques tels que l'NDA du développeur). Les bulletins doivent inclure les éléments suivants :
    • Annonces
    • Résumé des problèmes par niveau de correctif, y compris CVE et gravité
    • Détails de la faille, le cas échéant

Autres références

Pour obtenir des instructions sur le codage sécurisé et les pratiques de développement logiciel, consultez les ressources suivantes:

Google encourage l'utilisation des bonnes pratiques suivantes.

Il est généralement recommandé de lancer tout produit connecté avec la dernière version de l'OS. Un fabricant doit essayer d'utiliser la dernière version de l'OS avant de lancer le produit. Bien que le verrouillage de la version soit nécessaire pour assurer la stabilité avant les tests et la validation, le fabricant doit équilibrer la stabilité du produit obtenue grâce aux versions plus anciennes du système d'exploitation avec les versions plus récentes, qui présentent moins de failles de sécurité connues et des protections de sécurité renforcées.

Voici quelques recommandations:

  • En raison des longs délais de développement inhérents au processus de développement des véhicules, les constructeurs peuvent être amenés à lancer leur véhicule avec la version n-2 de l'OS ou une version antérieure.
  • Assurez-vous que chaque version de l'OS Android est compatible avec Android pour une campagne OTA (Over The Air).
  • Implémentez des produits compatibles avec le micrologiciel Android over-the-air (FOTA) pour des mises à jour rapides et conviviales. La mise à jour OTA doit être effectuée en suivant les bonnes pratiques de sécurité, telles que la signature de code et la connexion TLS entre le produit et le back-office IT.
  • Signalez les failles de sécurité Android identifiées indépendamment à l'équipe Android Security.

Remarque:Google a envisagé d'envoyer des notifications spécifiques au type d'appareil ou au secteur dans les bulletins de sécurité Android. Toutefois, Google ne connaît pas le noyau, les pilotes ni les chipsets d'un appareil donné (véhicule, téléviseur, accessoire connecté, téléphone, etc.). Google ne dispose pas d'un moyen déterministe d'étiqueter un problème de sécurité donné avec un type d'appareil.

Le fabricant doit tout mettre en œuvre pour utiliser la dernière version de l'OS ou les mises à jour de sécurité pour la version utilisée lors des améliorations du cycle de vie du produit. Les mises à jour peuvent être effectuées lors de mises à jour périodiques récurrentes des produits ou pour des correctifs afin de résoudre des problèmes de qualité et/ou d'autres problèmes. Voici quelques pratiques recommandées:

  • Élaborez un plan pour gérer les mises à jour du pilote, du noyau et du protocole.
  • Utilisez une méthode adaptée au secteur pour fournir des mises à jour aux véhicules déployés.

Document de définition de la compatibilité (CDD)

Le document de définition de compatibilité (CDD) décrit les exigences requises pour qu'un appareil soit considéré comme compatible avec Android. Le CDD est public et accessible à tous. Vous pouvez télécharger les versions du CDD d'Android 1.6 à la dernière version sur source.android.com.

Pour répondre à ces exigences pour un produit, procédez comme suit:

  1. Le partenaire signe l'engagement de compatibilité Android (ACC) avec Google. Un consultant en solutions techniques (TSC) est ensuite désigné comme guide.
  2. Le partenaire termine l'examen du CDD pour la version du système d'exploitation Android du produit.
  3. Le partenaire exécute et envoie les résultats CTS (décrits ci-dessous) jusqu'à ce qu'ils soient acceptables pour la compatibilité Android.

La suite de tests de compatibilité

L'outil de test CTS (Compatibility Test Suite) vérifie qu'une implémentation de produit est compatible avec Android et que les derniers correctifs de sécurité sont inclus. Le CTS est public, Open Source et disponible pour tous. Vous pouvez télécharger les versions du CTS à partir d'Android 1.6 jusqu'à la dernière version sur source.android.com.

Chaque build du logiciel Android publié auprès du public (images d'installation d'usine et de mise à jour sur le terrain) doit prouver la compatibilité Android via les résultats CTS. Par exemple, si l'appareil exécute Android 7.1, la dernière version correspondante de CDD 7.1 et CTS 7.1 doit être référencée lors de la création et du test d'une image de compilation avec intent de publication. Les fabricants sont vivement encouragés à utiliser le CTS dès le début et fréquemment pour identifier et résoudre les problèmes.

REMARQUE:Les partenaires qui signent d'autres contrats, tels que les services Google Mobile (GMS), peuvent être tenus de respecter d'autres exigences.

Workflow CTS

Le workflow CTS implique de configurer l'environnement de test, d'exécuter des tests, d'interpréter les résultats et de comprendre le code source du CTS. Les consignes suivantes visent à aider les utilisateurs du CTS (développeurs, fabricants, par exemple) à l'utiliser efficacement.

  • Exécutez des tests fréquemment. CTS est conçu comme un outil automatisé qui s'intègre à votre système de compilation. Exécuter fréquemment CTS peut vous aider à détecter rapidement et tôt les défauts en cas de dégradation ou de régression logicielle.
  • Téléchargez et examinez le code source du CTS. Le code source complet du CTS est un logiciel Open Source que tout le monde peut télécharger et utiliser (le code source téléchargé est entièrement compilable et exécutable). Lorsqu'un test échoue sur l'appareil, examiner la section pertinente du code source peut vous aider à identifier la raison.
  • Obtenez la dernière version du CTS. Les nouvelles versions d'Android peuvent mettre à jour le CTS avec des corrections de bugs, des améliorations et de nouveaux tests. Consultez régulièrement les téléchargements CTS et mettez à jour votre programme CTS si nécessaire. Le fabricant et Google doivent s'entendre sur la version du CTS à utiliser pour le lancement du produit, car le produit doit être figé à un moment donné, tandis que le CTS continue d'être actualisé.

Transmettre le CTS

Pour un produit compatible avec Android, Google s'assure que les résultats des tests du CTS et du vérificateur CTS de l'appareil sont acceptables. En principe, tous les tests doivent réussir. Toutefois, un test qui échoue pour d'autres raisons que le non-respect des exigences de compatibilité Android est soumis à un examen par Google. Au cours de ce processus:

  1. Le fabricant fournit à Google les correctifs CTS proposés, les validations des correctifs et les justifications pour étayer son argument.
  2. Google examine le contenu envoyé et, s'il est accepté, met à jour les tests CTS pertinents afin que l'appareil réussisse la prochaine version de CTS.

Si un test CTS échoue soudainement après l'application d'un correctif de sécurité, le fabricant doit modifier le correctif afin qu'il ne brise pas la compatibilité OU indiquer que le test est incorrect et fournir un correctif pour le test (comme décrit ci-dessus).

Le CTS reste ouvert pour examiner les corrections de test. Par exemple, Android 4.4 continue d'accepter les correctifs (voir https://android-review.googlesource.com/#/c/273371/).

Questions fréquentes

Q: Qui est responsable de l'application des mises à jour de sécurité à une implémentation spécifique d'Android ?

A: Le fabricant qui fournit directement l'appareil est responsable. Cette entité n'est pas Google, qui publie des mises à jour de sécurité dans AOSP et non pour un appareil spécifique (tel qu'un véhicule).

Q: Comment Google gère-t-il les problèmes de sécurité sur Android ?

A: Google examine en permanence les problèmes et développe des correctifs potentiels, qu'il met à la disposition de tous les niveaux d'API compatibles dans le cadre du processus de mise à jour de sécurité régulier. Depuis août 2015, Google publie régulièrement des bulletins et des liens vers des mises à jour sur source.android.com. Google publie également des mises à jour de sécurité dans le cadre des versions majeures de l'OS. Consultez également la règle de rétroportage de sécurité.

Q: Si un fabricant a intégré tous les correctifs AOSP d'un bulletin de sécurité Android, mais qu'il n'a pas intégré les correctifs du fournisseur de BSP mentionné dans le même bulletin, peut-il quand même augmenter le niveau de sécurité (par exemple, appliquer le correctif correspondant à la plate-forme/à la version) ?

A: Pour déclarer un niveau de correctif de sécurité Android (SPL), un fabricant doit résoudre tous les problèmes requis publiés dans le bulletin de sécurité Android (y compris les bulletins précédents) et mappés à un SPL Android particulier. Par exemple, un fabricant qui utilise le bulletin de sécurité de mars 2017 (SPL 2017-03-01) a résolu tous les problèmes requis documentés dans le bulletin de mars 2017 pour ce SPL et toutes les mises à jour précédentes, y compris les mises à jour spécifiques à l'appareil pour tous les bulletins de sécurité Android précédents, y compris les mises à jour spécifiques à l'appareil associées au SPL 2017-02-05.

Q: Que se passe-t-il lorsque le fabricant n'est pas d'accord avec les mises à jour de sécurité fournies par le fournisseur de BSP OU lorsque les mises à jour de sécurité imposées par un ASB ne sont pas fournies par les fournisseurs ?

A: Un ASB décrit les failles de sécurité (énumérées par une liste de CVE) et fournit souvent des tests de sécurité correspondants. L'objectif est de s'assurer que les failles listées ne peuvent plus être reproduites sur un appareil et que l'appareil peut réussir les tests de sécurité associés. Par conséquent, le problème ne concerne pas l'application d'une mise à jour de sécurité fournie par Google ou un fournisseur tiers, mais l'attestation du fabricant selon laquelle l'appareil n'est pas vulnérable à la liste des failles CVE de l'ASB. Le fabricant est libre d'utiliser les mises à jour de sécurité fournies ou, s'il dispose d'une modification plus adaptée à son appareil, de l'utiliser à la place.

Par exemple, imaginons que Google corrige une faille de sécurité AOSP à l'aide d'un changement de code qui permet au composant de rester entièrement fonctionnel et conforme au CDD. Si le fabricant détermine que le composant n'est pas nécessaire sur l'appareil ou qu'il n'est pas obligatoire par le CDD (ou les tests de certification associés), il peut le supprimer pour réduire les besoins de maintenance futurs et réduire la surface d'attaque. Bien que le fabricant n'ait pas utilisé la mise à jour de sécurité fournie, il s'est assuré que l'appareil n'était pas vulnérable à la faille CVE documentée dans le bulletin de sécurité. Toutefois, en s'écartant de la mise à jour de sécurité recommandée, le fabricant risque de ne pas résoudre correctement le problème, d'introduire de nouvelles failles de sécurité ou de réduire les fonctionnalités du build final.

Bien que nous collaborions avec tous les partenaires SoC pour nous assurer qu'il existe des correctifs pour tous les problèmes d'une ASB, nous recommandons aux fabricants de conclure un contrat de service avec leurs fournisseurs de SoC pour la durée de vie d'un appareil. Les SoC peuvent cesser de prendre en charge un chipset plus tôt que prévu. Il est donc important d'établir des accords avant de sélectionner le chipset de l'appareil.

Enfin, dans les cas où il est impossible d'acquérir directement ou de créer indépendamment un correctif pour un problème documenté dans un ASB, un fabricant peut conserver l'ancienne SPL Android et ajouter les nouveaux correctifs disponibles au build. Toutefois, cette pratique entraînera à terme des problèmes de certification de compilation (car Android s'assure que le dernier niveau de correctif de sécurité est disponible sur les appareils certifiés). Google vous recommande de travailler avec votre SoC à l'avance pour éviter cette pratique.

Q: Si le fabricant détermine qu'un élément de la liste de compatibilité des appareils n'est pas applicable à son produit, doit-il quand même être appliqué ou corrigé pour respecter les autres exigences de Google ou pour réussir le CTS ?

R: Nous n'exigeons pas de correctifs pour déclarer un niveau de correctif de sécurité Android (SPL). Nous exigeons toutefois que le fabricant atteste que son build n'est pas vulnérable au problème.

Par exemple, un composant mis à jour ne figure pas dans le système du fabricant ou un composant est supprimé du système du fabricant pour résoudre un problème. Dans ce cas, le système peut être conforme sans que le fabricant ait à appliquer un correctif.

Il s'agit d'une approche fondamentalement différente de celle d'un fabricant qui souhaite, par exemple, ne corriger que les correctifs critiques, sans prendre en compte les autres correctifs applicables qui entraîneraient l'échec d'un test de sécurité. Dans ce cas, on suppose que l'objectif de service n'a pas été atteint.