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 suite de tests de compatibilité Android (CTS). 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 légalement ni contractuellement Google ni d'autres fabricants, et n'est pas destiné à être un ensemble d'exigences. Ce guide est plutôt une aide pédagogique qui décrit les pratiques recommandées.

Commentaires

Ce guide n'est pas 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é avec Android. Anciennement appelé Android Anti-Fragmentation Agreement (AFA).
AOSP Projet Android Open Source
ASB bulletin sur la sécurité d'Android
BSP Board Support Package
CDD Document de définition de la compatibilité
CTS Compatibility Test Suite
FOTA micrologiciel Over The Air
GPS système de positionnement mondial
MISRA Motor Industry Software Reliability Association
NIST National Institute of Standards and Technology
OBD Diagnostics embarqués (OBD-II est une amélioration par rapport à OBD-I en termes de capacité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 une variété d'appareils et de facteurs de forme. Depuis sa première version en 2008, Android est devenu le système d'exploitation le plus populaire, alimentant plus de 1,4 milliard d'appareils dans le monde (2016). En mars 2017, environ 67% de ces appareils utilisaient Android 5.0 (Lollipop) ou une version ultérieure (des chiffres plus récents sont disponibles sur le tableau de bord Android). Si la grande majorité des appareils sont des téléphones mobiles et des tablettes, Android se développe sur les montres connectées, les téléviseurs et les appareils d'info-divertissement embarqués (IVI) 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 soutenu par le programme de compatibilité Android, qui définit un ensemble d'exigences via le document de définition de compatibilité (CDD) et fournit des outils de test via la Compatibility Test Suite (CTS). Les programmes de compatibilité Android garantissent que toute application Android peut s'exécuter sur n'importe quel appareil compatible avec Android et prenant 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écouvertes. Les fabricants doivent consulter les Bulletins sur la sécurité d'Android pour vérifier si ces mises à jour s'appliquent aux produits compatibles avec l'OS Android. Pour en savoir plus sur la sécurité, la compatibilité et les systèmes de compilation d'Android, consultez les ressources suivantes :

À propos des véhicules connectés (produits canoniques à longue durée de vie)

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 organismes de réglementation et les constructeurs automobiles se sont tournés vers l'électronique pour faciliter les diagnostics et l'entretien (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 de connectivité suivante a introduit des fonctionnalités pratiques pour le conducteur, telles que 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 de smartphone. Aujourd'hui, les capteurs et la connectivité intégrés (par exemple, le GPS) prennent en charge les systèmes de sécurité et de conduite semi-autonome.

À mesure que le nombre de connexions de véhicules augmente, la surface d'attaque potentielle des véhicules augmente également. Les connexions présentent des problèmes de cybersécurité similaires à ceux des appareils électroniques grand public. Toutefois, si les redémarrages, les mises à jour quotidiennes des correctifs et les comportements inexpliqués sont la norme pour l'électronique 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 assurer la sécurité et la sûreté continues d'un produit sur le terrain. En bref, les fabricants doivent être conscients des failles de sécurité connues dans le 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 connues publiées grâce à une analyse proactive, y compris :

  • Évaluation régulière du produit par rapport à la base de données Common Vulnerabilities and Exposures (CVE).
  • Collecte d'informations sur les failles de sécurité liées aux produits.
  • Tests de sécurité.
  • Analyse active des bulletins sur la sécurité d'Android.

Exemples de mises à jour de l'OS et des correctifs de sécurité (SVI fonctionnant sous Android) :

Figure 1. Exemple de déploiement de mises à jour majeures de l'OS et de sécurité pendant 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 de l'OS livrée dans le produit, les mises à jour de sécurité sont tirées des bulletins sur la sécurité d'Android (ASB) et potentiellement d'autres sources jugées utiles par le fabricant. y2 = deuxième bulletin sur la sécurité pour la version X d'Android, appliqué (rétroporté) par le fabricant à Android X. Cette mise à jour est incluse dans le produit et le compte à rebours de la production commence à l'année zéro avec Android X.y2.

Dans cet exemple, le fabricant a décidé de ne pas expédier la version annuelle Android X+1 la plus récente. Les raisons pour lesquelles nous fournissons la version la plus récente incluent l'ajout de nouvelles fonctionnalités, la résolution de nouvelles failles de sécurité et/ou la fourniture de services Google ou tiers qui nécessitent la version la plus récente d'Android. Les raisons contre l'expédition 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 nécessaire 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 SOP, le fabricant publie la mise à jour de l'OS Android X+2, qui correspond à deux versions d'Android après celle 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 envoyée sous la forme X+2.y0 environ 1,25 an après la date de début de production. Il est possible que cette mise à jour de l'OS soit compatible ou non 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 d'effectuer une mise à jour complète de l'OS est entièrement à la discrétion du fabricant.
④ Mise à jour de sécurité Deux ans après le début de la durée de vie de production du véhicule, le fabricant 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é ASB pour la version X+2 comme base de la mise à jour. Les produits ayant reçu la mise à jour de sécurité sont désormais au niveau d'OS (X+2.y3) + niveau du correctif de sécurité Android.

Les fabricants peuvent sélectionner des correctifs de sécurité individuels dans n'importe quel bulletin sur la sécurité d'Android, mais ils doivent résoudre 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 d'effectuer le rétroportage et la version de sécurité pour le produit concerné.
⑤ Mise à jour complète de l'OS La deuxième mise à jour complète de l'OS, qui répète l'étape 3 (mise à jour complète de l'OS), permet au produit d'atteindre Android X+4, trois ans après le début de la durée de vie de production du véhicule. Le fabricant doit désormais trouver un équilibre entre les exigences matérielles plus récentes d'une version récente d'Android et le matériel du produit, ainsi que les avantages pour l'utilisateur d'un OS Android mis à jour. Le fabricant publie une mise à jour sans mises à jour de sécurité. Le produit est désormais à la version (X+4.y0) de l'OS et du 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 (plus de six ans) nécessite toujours une assistance de 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é ASB d'une version beaucoup plus récente d'Android (X+6) et en transférer une partie ou la totalité vers Android X+4. Il incombe au fabricant de fusionner, d'intégrer et d'effectuer les mises à jour (ou de faire appel à un tiers). Le fabricant doit également savoir que les problèmes de sécurité dans les versions d'Android qui ne sont plus prises en charge ne sont pas couverts par le bulletin de sécurité Android.
⑦ 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 après 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 charge de curation et de rétroportage des correctifs de sécurité incombe entièrement au fabricant pour les versions datant de plus de trois ans par rapport à la version publique du niveau d'API.

Bonnes pratiques concernant la sécurité

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

Consignes de sécurité

Voici quelques pratiques recommandées pour assurer la sécurité :

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

Consignes de développement de logiciels

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

  • Effectuez une modélisation des menaces pour classer et identifier les composants, les menaces et les atténuations potentielles.
  • Effectuez un examen de l'architecture/de la conception pour vous assurer que la conception est sécurisée et fiable.
  • Effectuez régulièrement des révisions de code pour identifier les anti-patterns et les bugs le plus tôt possible.
  • Concevez, implémentez et exécutez des tests unitaires à couverture de code élevée, y compris :
    • Tests fonctionnels (y compris les scénarios de tests négatifs)
    • Tests de régression réguliers (pour s'assurer que les bugs corrigés ne réapparaissent pas)
    • Tests fuzzing (dans la suite de tests unitaires)
  • Utilisez des outils d'analyse statique du code source (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), afin d'identifier et d'atténuer les problèmes potentiels lors du développement du système.
  • Disposer d'une stratégie de gestion pour le code source du logiciel et la configuration/version de la version.
  • Disposer d'une stratégie de gestion des correctifs pour la génération et le déploiement des correctifs logiciels.

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

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

  1. Recevoir et examiner les rapports de failles.
  2. Créer, tester et publier des mises à jour de sécurité.
  3. Fournir des versions récurrentes des mises à jour de sécurité et des détails du bulletin de sécurité.
  4. Évaluez la gravité conformément aux consignes établies.

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

  • Faites appel à un tiers (tel qu'un fournisseur de SoC ou de noyau) pour obtenir une assistance de rétroportage pour les mises à jour de sécurité de l'OS datant de plus de trois ans après la sortie de l'API.
  • Faites appel à un tiers pour effectuer des revues de code à l'aide des ASB fournis publiquement. Bien que les ASB identifient les failles pour la version actuellement prise en charge, un fabricant peut utiliser les informations fournies pour comparer les mises à jour récemment publiées 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 sortie 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 "NDA Android Security Bulletin Partner Preview" (nécessite la signature d'accords juridiques tels que le NDA pour les développeurs). Les bulletins doivent inclure :
    • Annonces
    • Résumé des problèmes par niveau de correctif, y compris les CVE et la gravité
    • Détails de la faille, le cas échéant

Références supplémentaires

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

Google vous encourage à suivre les bonnes pratiques recommandées ci-dessous.

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 version la plus récente de l'OS avant de lancer le produit. Bien qu'il soit nécessaire de verrouiller la version pour assurer la stabilité avant les tests et la validation, le fabricant doit trouver un équilibre entre la stabilité du produit obtenue avec les anciennes versions de l'OS et les nouvelles versions de l'OS 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 fabricants peuvent avoir besoin de lancer des véhicules avec la version n-2 de l'OS ou une version antérieure.
  • Assurez la conformité avec la compatibilité Android pour chaque version d'OS Android publiée avec une campagne OTA (Over-The-Air).
  • Implémentez la mise à jour du micrologiciel Android par liaison radio (FOTA) pour des mises à jour rapides et conviviales. La mise à jour FOTA doit être effectuée en suivant les bonnes pratiques de sécurité, telles que la signature du code et la connexion TLS entre le produit et le back-office informatique.
  • Envoyez les failles de sécurité Android que vous avez identifiées à l'équipe Android Security.

Remarque : Google a envisagé d'inclure des notifications spécifiques à un type d'appareil ou à un secteur dans les bulletins sur la sécurité d'Android. Toutefois, comme Google ne connaît pas le noyau, les pilotes ni les chipsets d'un appareil donné (véhicule, téléviseur, wearable, téléphone, etc.), il n'a pas de moyen déterministe d'associer un type d'appareil à un problème de sécurité donné.

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 en cours d'utilisation 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 visant à résoudre des problèmes de qualité et/ou d'autres problèmes. Voici quelques pratiques recommandées :

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

Document de définition de compatibilité

Le document de définition de compatibilité (CDD) décrit les exigences qu'un appareil doit respecter pour être 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, vous devez suivre les étapes de base suivantes :

  1. Le partenaire signe l'engagement de compatibilité Android (ACC) avec Google. Un consultant en solutions techniques (TSC, Technical Solution Consultant) est ensuite attribué pour vous guider.
  2. Le partenaire termine l'examen du CDD pour la version de l'OS Android du produit.
  3. Le partenaire exécute et envoie les résultats du 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 Compatibility Test Suite (CTS) 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 accessible à tous. Vous pouvez télécharger les versions du CTS d'Android 1.6 à la dernière version sur source.android.com.

Chaque version du logiciel Android publiée (images d'installation en usine et de mise à jour sur le terrain) doit prouver la compatibilité Android grâce aux 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 release-intent. Nous encourageons vivement les fabricants à utiliser le CTS de manière précoce et fréquente 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 soumis à 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 CTS. Les consignes suivantes sont destinées à aider les utilisateurs du CTS (par exemple, les développeurs et les fabricants) à utiliser le CTS de manière efficace.

  • Exécutez des tests fréquemment. Le CTS est conçu comme un outil automatisé qui s'intègre à votre système de compilation. L'exécution fréquente du CTS peut vous aider à détecter rapidement les défauts lorsqu'une dégradation ou une régression du logiciel se produit.
  • 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, l'examen de la section correspondante du code source peut vous aider à identifier la raison de l'échec.
  • 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 la page Téléchargements CTS et mettez à jour votre programme CTS si nécessaire. Le fabricant et Google doivent s'accorder sur la version CTS à utiliser pour le lancement du produit, car le produit doit être figé à un moment donné, tandis que le CTS continue d'être actualisé.

Passer le CTS

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

  1. Le fabricant fournit à Google les correctifs CTS proposés, les validations de correctifs et les justifications pour prouver l'argument.
  2. Google examine le matériel envoyé et, s'il est accepté, met à jour les tests CTS concernés afin que l'appareil soit conforme à la prochaine révision 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 rompe pas la compatibilité OU montrer que le test est incorrect et fournir une solution pour le test (comme décrit ci-dessus).

Le CTS reste ouvert pour l'examen des correctifs de tests. Par exemple, Android 4.4 continue d'accepter les correctifs (voir https://android-review.googlesource.com/c/platform/cts/+/273371).

Questions fréquentes

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

R : 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é dans Android ?

R : Google étudie en permanence les problèmes et développe des solutions potentielles, 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 les mises à jour sur source.android.com. Google publie également des mises à jour de sécurité dans le cadre des principales versions de l'OS. Consultez également les Règles concernant le rétroportage de sécurité.

Q : Si un fabricant a intégré tous les correctifs AOSP d'un bulletin ASB, mais pas les correctifs du fournisseur BSP mentionnés 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/compilation) ?

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

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 BSP OU lorsque les fournisseurs ne fournissent pas les mises à jour de sécurité requises par l'ASB ?

R : Un bulletin de sécurité Android 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 passer 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 plutôt l'attestation du fabricant selon laquelle l'appareil n'est pas vulnérable à la liste des CVE figurant dans le bulletin de sécurité Android. Le fabricant est libre d'utiliser les mises à jour de sécurité fournies ou, s'il dispose d'une modification plus appropriée à son appareil, de l'utiliser à la place.

Par exemple, imaginons que Google corrige une faille de sécurité AOSP à l'aide d'une modification du code qui permet au composant de rester pleinement fonctionnel et conforme au CDD. Si le fabricant détermine que le composant n'est pas nécessaire sur l'appareil ou n'est pas obligatoire selon le CDD (ou les tests de certification associés), il peut le supprimer pour réduire les besoins de maintenance futurs et 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 CVE documentée dans le bulletin de sécurité. Toutefois, en s'écartant de la mise à jour de sécurité recommandée, le fabricant prend le risque de résoudre le problème de manière incorrecte, d'introduire de nouvelles failles de sécurité ou de réduire la fonctionnalité de la version finale.

Bien que nous collaborions avec tous les partenaires SoC pour nous assurer que des correctifs existent pour tous les problèmes d'un bulletin ASB, nous recommandons aux fabricants de conclure un contrat de maintenance 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 bulletin de sécurité Android, un fabricant peut conserver le niveau de mise à jour de sécurité Android précédent et ajouter les nouveaux correctifs disponibles à la compilation. Toutefois, cette pratique finira par entraîner 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 contacter votre SoC à l'avance pour éviter cette pratique.

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

R : Nous n'exigeons pas l'application de correctifs pour déclarer un niveau de correctif de sécurité Android (SPL, Android Security Patch Level). Nous demandons toutefois au fabricant d'attester que sa version n'est pas vulnérable au problème.

Par exemple, un composant à corriger n'existe 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 besoin d'appliquer un correctif.

Cette approche est fondamentalement différente de celle d'un fabricant qui souhaite, par exemple, ne corriger que les correctifs critiques, sans appliquer d'autres correctifs applicables qui entraîneraient l'échec d'un test de sécurité. Dans ce cas, nous partons du principe que le SPL n'a pas été respecté.