Ce guide décrit les meilleures pratiques recommandées par Google pour l'application des correctifs de sécurité évalués par la suite de tests de compatibilité Android (CTS). Il est destiné aux fabricants d'équipements OEM compatibles Android (fabricants) qui seront pris en charge pendant plus de trois ans, tels que les véhicules, les téléviseurs, les 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 avertissements
Ce guide n'engage pas juridiquement ou contractuellement Google ou d'autres fabricants et n'est pas destiné à constituer un ensemble d'exigences. Ce guide est plutôt une aide pédagogique qui décrit les pratiques recommandées.
Retour
Ce guide n'est pas destiné à être exhaustif ; des révisions supplémentaires sont prévues. Envoyez vos commentaires à Manufacturers-guide-android@googlegroups.com.
Glossaire
| Terme | Définition |
|---|---|
| ACC | Engagement de compatibilité Android. Anciennement connu sous le nom d’accord anti-fragmentation Android (AFA). |
| AOSP | Projet Open Source Android |
| ASB | Bulletin de sécurité Android |
| BSP | Forfait de soutien au conseil d’administration |
| CDD | Document de définition de compatibilité |
| CTS | Suite de tests de compatibilité |
| FOTA | firmware par liaison radio |
| GPS | Système de positionnement global |
| MISRA | Association pour la fiabilité des logiciels de l'industrie automobile |
| NIST | Institut national des normes et de la technologie |
| OBD | diagnostics embarqués ( OBD-II est une amélioration par rapport à l'OBD-I en termes de capacité et de standardisation ) |
| OEM | fabricant d'équipement d'origine |
| Système d'exploitation | système opérateur |
| SEI | Institut de génie logiciel |
| SoC | système sur puce |
| AMADOUER | début de production |
| SPL | Niveau du correctif de sécurité |
| TPMS | Système de surveillance de la pression des pneus |
À propos du système d'exploitation 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 (OS) le plus populaire, équipant plus de 1,4 milliard d'appareils dans le monde (2016). Environ 67 % de ces appareils utilisent Android 5.0 (Lollipop) ou une version plus récente en mars 2017 (des chiffres plus récents sont disponibles sur le tableau de bord Android ). Alors que la grande majorité des appareils sont des téléphones mobiles et des tablettes, Android se développe dans les montres intelligentes, les téléviseurs et les appareils d'infodivertissement embarqués (IVI) automobiles.
Le nombre d'applications Android disponibles sur 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 suite de tests de compatibilité (CTS) . Les programmes de compatibilité Android garantissent que toute application Android peut s'exécuter sur n'importe quel appareil compatible Android prenant en charge les fonctionnalités requises pour l'application.
Google publie régulièrement de nouvelles versions du système d'exploitation, des mises à jour de sécurité du système d'exploitation et des informations sur les vulnérabilités découvertes. Le bulletin de sécurité Android doit être examiné par les fabricants pour vérifier l'applicabilité de ces mises à jour aux produits pris en charge par le système d'exploitation Android. Pour un examen de la sécurité, de la compatibilité et des systèmes de build Android, consultez ce qui suit :
- Sécurisez un appareil Android
- Mises à jour et ressources de sécurité
- Suite de tests de compatibilité
- Noms de code, balises et numéros de build
À 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 régulateurs et les constructeurs automobiles se tournaient vers l'électronique pour faciliter les diagnostics et les services (par exemple, le port OBD-II), améliorer la sécurité (par exemple, 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'entrée sans clé à distance, les systèmes télématiques et des fonctionnalités d'infodivertissement avancées telles que Bluetooth, Wi-Fi et projection sur smartphone. Aujourd'hui, les capteurs intégrés et la connectivité (par exemple, le GPS) soutiennent 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 des véhicules augmente également. Les connexions entraînent un ensemble de problèmes de cybersécurité similaires à ceux de l’électronique grand public. Cependant, si les redémarrages, les mises à jour quotidiennes des correctifs et les comportements inexpliqués constituent 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 garantir le maintien de la sécurité et de la sûreté d'un produit sur le terrain. En bref, les fabricants doivent être conscients des vulnérabilités de sécurité connues du produit et adopter une approche basée sur les risques pour y remédier.
Assurer la sécurité à long terme
Un véhicule connecté dispose souvent d'une ou plusieurs unités de contrôle électronique (ECU) qui incluent plusieurs composants logiciels tels que le système d'exploitation, les bibliothèques, les utilitaires, etc. Les fabricants doivent suivre ces composants et identifier les vulnérabilités publiées connues avec une analyse proactive, notamment :
- Évaluer régulièrement le produit par rapport à la base de données Common Vulnerabilities and Exposures (CVE).
- Collecte de renseignements sur les failles de sécurité liées aux produits.
- Tests de sécurité.
- Analyser activement les bulletins de sécurité Android.
Exemples de mises à jour du système d'exploitation et des correctifs de sécurité (IVI exécutant Android) :
Figure 1. Exemple de déploiement de mises à jour majeures du système d'exploitation et de sécurité au cours de la durée de vie du véhicule.
| # | Étape | Activités |
|---|---|---|
① | Direction du développement | Le constructeur 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) initial. |
| ② | Lancement initial | Quelques mois avant qu'Android X ne devienne la première version du système d'exploitation livrée avec le produit, les mises à jour de sécurité proviennent des bulletins de sécurité Android (ASB) et potentiellement d'autres sources jugées utiles par le fabricant. y2 = le deuxième bulletin de sécurité pour la version X d'Android, appliqué (rétroporté) par le fabricant à Android X. Cette mise à jour est livrée avec le produit et l'horloge de production commence à l'année zéro avec Android X.y2. Dans cet exemple, le fabricant a pris la décision de ne pas livrer la version annuelle la plus récente d'Android X+1. Les raisons de la livraison de la version la plus récente incluent l'ajout de nouvelles fonctionnalités, la résolution de nouvelles vulnérabilités de sécurité et/ou la livraison de services Google ou tiers qui nécessitent la version la plus récente d'Android. Les raisons qui s'opposent à l'expédition de 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 le respect de toutes les exigences réglementaires et de certification. |
| ③ | Mise à jour complète du système d'exploitation | Après la SOP, le fabricant publie la mise à jour du système d'exploitation 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 API (à compter de la date d'expédition), donc la mise à jour est publiée en X+2.y0 environ 1,25 an après SOP. Cette mise à jour du système d'exploitation peut être compatible ou non avec les produits mis en service. Si tel est le cas, un plan pourrait ê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 du système d'exploitation est entièrement à la discrétion du fabricant. |
| ④ | Mise à jour de sécurité | Deux ans après le début de la production du véhicule, le constructeur corrige le système d'exploitation 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 mise à jour. Les produits recevant la mise à jour de sécurité sont désormais au niveau (X+2.y3) du correctif de sécurité OS + Android. Bien que les fabricants puissent sélectionner des correctifs de sécurité individuels à partir de n'importe quel ASB individuel, 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 est de la responsabilité du fabricant d'effectuer le rétroportage et la version de sécurité du produit pris en charge. |
| ⑤ | Mise à jour complète du système d'exploitation | Répétition de l'étape 3 (Mise à jour complète du système d'exploitation), la deuxième mise à jour complète du système d'exploitation amène le produit à 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 par rapport au 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 mises à jour de sécurité, le produit est donc désormais au niveau (X+4.y0) du correctif de sécurité OS + 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, même si une durée de vie prévue de plus de 6 ans pour le véhicule nécessite toujours un support de sécurité. |
| ⑥ | Mise à jour de sécurité | Une répétition de l'étape 4 (Mise à jour de sécurité). Le fabricant a pour tâche de prendre les mises à jour de sécurité ASB d'une version beaucoup plus récente d'Android (X+6) et de porter tout ou partie de ces mises à jour sur Android X+4. Il est de la responsabilité du fabricant de fusionner, d'intégrer et d'effectuer les mises à jour (ou de passer un contrat avec un tiers). En outre, le fabricant doit être conscient que les problèmes de sécurité dans les 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 du système d'exploitation à l'étape 5 (mise à jour complète du système d'exploitation) et dix ans depuis la spécification d'Android X, la charge de la conservation et du rétroportage des correctifs de sécurité incombe entièrement au fabricant. les versions datant de plus de trois ans à compter de la version publique au niveau de l'API. |
Bonnes pratiques de sécurité
Pour rendre les compromissions de sécurité plus difficiles, Google recommande et utilise l'utilisation des meilleures pratiques communément acceptées en matière de sécurité et d'ingénierie logicielle, comme décrit dans Mise en œuvre de la sécurité .
Consignes de sécurité
Les pratiques recommandées en matière de sécurité incluent :
- Utilisez les dernières versions de bibliothèques externes et de composants open source.
- N'incluez pas de fonctionnalités de débogage intrusives dans les versions finales du système d'exploitation.
- 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 .
Directives de développement de logiciels
Les pratiques recommandées pour le développement de logiciels sécurisés pendant le cycle de vie du système comprennent :
- Effectuez une modélisation des menaces pour classer et identifier les actifs, les menaces et les atténuations potentielles.
- Effectuer un examen de l'architecture/de la conception pour garantir une conception sécurisée et solide.
- Effectuez des révisions régulières du code pour identifier les anti-modèles et les bogues dès que possible.
- Concevoir, mettre en œuvre et exécuter des tests unitaires à couverture de code élevée, notamment :
- Tests fonctionnels (y compris les cas de tests négatifs)
- Tests de régression réguliers (pour garantir que les bugs corrigés ne réapparaissent pas)
- Tests de 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 du logiciel et de la configuration/version des versions.
- Avoir une stratégie de gestion des correctifs pour la génération et le déploiement des correctifs logiciels.
Politique de rétroportage de sécurité
Google fournit actuellement une prise en charge active des rétroportages de sécurité des vulnérabilités de sécurité découvertes et signalées pendant trois (3) ans à compter de la version publique au niveau de l'API . Le support actif comprend les éléments suivants :
- Recevez et étudiez les rapports de vulnérabilité.
- Créez, testez et publiez des mises à jour de sécurité.
- Fournissez des versions récurrentes de mises à jour de sécurité et des détails sur les bulletins de sécurité.
- Effectuer une évaluation de la gravité conformément aux directives établies.
Trois ans après la date de publication publique du niveau API, Google recommande les directives suivantes :
- Utilisez un tiers (tel qu'un fournisseur de SoC ou un fournisseur de noyau) pour la prise en charge du rétroportage des mises à jour de sécurité du système d'exploitation datant de plus de trois ans à compter de la version de l'API.
- Faites appel à un tiers pour effectuer des révisions de code à l’aide des ASB fournis publiquement. Bien que les ASB identifient les vulnérabilités de la version actuellement prise en charge, un fabricant peut utiliser les informations fournies pour comparer les mises à jour récemment publiées avec les 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 du système d'exploitation datant de plus de trois ans après la sortie de l'API.
- Le cas échéant, téléchargez les mises à jour de sécurité sur le projet Android Open Source (AOSP).
- Le fabricant doit coordonner le traitement 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 Developer NDA). Les bulletins doivent inclure :
- Annonces
- Résumé des problèmes par niveau de correctif, y compris CVE et gravité
- Détails de la vulnérabilité, le cas échéant
Références supplémentaires
Pour obtenir des instructions sur les pratiques de codage sécurisé et de développement de logiciels, reportez-vous à ce qui suit :
- Association pour la fiabilité des logiciels de l'industrie automobile (MISRA) .
- Outils et méthodes du Software Engineering Institute (SEI) .
- Institut national des normes et de la technologie (NIST).
Pratiques de produit recommandées
Google encourage l'utilisation des pratiques recommandées suivantes.
Directives générales de lancement
Il est généralement recommandé que tout produit connecté soit lancé avec la dernière version du système d'exploitation, et le fabricant doit tenter d'utiliser la version la plus récente du système d'exploitation 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 à partir des anciennes versions du système d'exploitation avec des versions plus récentes du système d'exploitation qui présentent moins de vulnérabilités de sécurité connues et des protections de sécurité améliorées.
Les lignes directrices recommandées comprennent :
- En raison des longs délais de développement inhérents au processus de développement des véhicules, les constructeurs peuvent avoir besoin de lancer le système d'exploitation avec la version n-2 ou une version antérieure.
- Maintenez la conformité avec la compatibilité Android pour chaque version publiée du système d'exploitation Android grâce à une campagne en direct (OTA).
- Implémentez le produit Android Firmware-over-the-air (FOTA) pour des mises à jour rapides et conviviales. FOTA doit être effectué en utilisant les meilleures pratiques de sécurité telles que la signature de code et la connexion TLS entre le produit et le back-office informatique.
- Soumettez les vulnérabilités de sécurité Android identifiées de manière indépendante à l’équipe de sécurité Android.
Remarque : Google a envisagé des notifications spécifiques au type d'appareil ou à un secteur d'activité dans les bulletins de sécurité Android. Cependant, comme Google ne connaît pas le noyau, les pilotes ou les chipsets d'un appareil donné (véhicule, téléviseur, portable, téléphone, etc.), Google ne dispose pas d'un moyen déterministe pour étiqueter un problème de sécurité donné avec un type d'appareil. .
Directives relatives au cycle de produit
Le fabricant doit s'efforcer d'utiliser la dernière version du système d'exploitation ou les mises à jour de sécurité pour la version utilisée lors des améliorations du cycle de produit. Les mises à jour peuvent être effectuées lors de mises à jour périodiques récurrentes du produit ou pour des correctifs destinés à résoudre des problèmes de qualité et/ou d'autres problèmes. Les pratiques recommandées comprennent :
- Créez un plan pour gérer les mises à jour des pilotes, du noyau et du protocole.
- Utiliser une méthode appropriée au secteur pour fournir des mises à jour aux véhicules déployés.
Document de définition de compatibilité (CDD)
Le document de définition de compatibilité (CDD) décrit les exigences 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 CDD d'Android 1.6 vers la dernière version depuis source.android.com .
Satisfaire à ces exigences pour un produit implique les étapes de base suivantes :
- Le partenaire signe l'engagement de compatibilité Android (ACC) avec Google. Un consultant en solutions techniques (TSC) est ensuite désigné comme guide.
- Le partenaire termine l'examen CDD pour la version du système d'exploitation Android du produit.
- Le partenaire exécute et soumet les résultats CTS (décrits ci-dessous) jusqu'à ce que les résultats soient acceptables pour la compatibilité Android.
Suite de tests de compatibilité (CTS)
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. CTS est public, open source et accessible à tous ; vous pouvez télécharger les versions CTS d'Android 1.6 vers la dernière version depuis source.android.com .
Chaque version de logiciel Android rendue publique (images d'installation en 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 lorsqu'une image de build d'intention de publication est créée et testée. Les fabricants sont fortement encouragés à utiliser CTS tôt et fréquemment pour identifier et résoudre les problèmes.
Flux de travail CTS
Le flux de travail CTS implique la configuration de l'environnement de test, l'exécution de tests, l'interprétation des résultats et la compréhension du code source CTS. Les directives suivantes sont destinées à aider les utilisateurs du CTS (par exemple, les développeurs, les fabricants) à utiliser le CTS de manière efficace et efficiente.
- Exécutez des tests fréquemment . CTS est conçu comme un outil automatisé qui s'intègre à votre système de build. L’exécution fréquente de CTS peut vous aider à détecter rapidement et précocement 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 de 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 constructible et exécutable). Lorsqu'un test échoue sur l'appareil, l'examen de la section pertinente du code source peut vous aider à identifier pourquoi.
- Obtenez le dernier CTS . Les nouvelles versions d'Android peuvent mettre à jour le CTS avec des corrections de bugs, des améliorations et de nouveaux tests. Vérifiez fréquemment les téléchargements CTS et mettez à jour votre programme CTS si nécessaire. Le fabricant et Google doivent se mettre d'accord sur la version CTS à adopter pour le lancement du produit, car le produit doit être gelé à un moment donné pendant que le CTS continue d'être actualisé.
Passer le CTS
Pour un produit compatible Android, Google garantit que les résultats des tests des rapports CTS et CTS Verifier de l'appareil sont acceptables. En principe, tous les tests doivent réussir. Toutefois, un test qui échoue pour des raisons autres que le fait que l'appareil n'est pas conforme aux exigences de compatibilité Android est soumis à un examen par Google. Au cours de ce processus :
- Le fabricant fournit à Google les correctifs CTS proposés, les validations des correctifs et les justifications pour prouver son argument.
- Google examine le matériel soumis et, s'il est accepté, met à jour les tests CTS pertinents afin que l'appareil réussisse lors de la prochaine révision du 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 erroné et fournir un correctif pour le test (comme décrit ci-dessus).
Le CTS reste ouvert aux examens des correctifs de test. Par exemple, Android 4.4 continue d'accepter les correctifs (voir https://android-review.googlesource.com/#/c/273371/ ).
Foire aux questions (FAQ)
Q : Qui est responsable de l'application des mises à jour de sécurité à une implémentation spécifique d'Android ?
R : Le fabricant fournissant 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 (comme un véhicule).
Q : Comment Google gère-t-il les problèmes de sécurité sous Android ?
R : Google étudie en permanence les problèmes et développe des correctifs potentiels, qu'il met à la disposition de tous les niveaux d'API pris en charge dans le cadre du processus régulier de mise à jour de sécurité. Depuis août 2015, Google a maintenu une cadence régulière de publication de bulletins et de liens vers des mises à jour vers source.android.com ; Google publie également des mises à jour de sécurité dans le cadre des versions majeures du système d'exploitation. Voir également la politique de rétroportage de sécurité .
Q : Si un fabricant a intégré tous les correctifs AOSP d'un ASB mais n'a pas intégré les correctifs du fournisseur 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/build) ?
R : 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 utilisant le bulletin de sécurité de mars 2017 (2017-03-01 SPL) a résolu tous les problèmes requis documentés dans le bulletin de mars 2017 pour ce SPL et toutes les mises à jour antérieures, y compris les mises à jour spécifiques aux appareils pour tous les bulletins de sécurité Android précédents, y compris les mises à jour spécifiques à l'appareil associées au SPL 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 mises à jour de sécurité exigées par un ASB ne sont pas fournies par les fournisseurs ?
R : Un ASB décrit les vulnérabilités de sécurité (énumérées par une liste de CVE) et fournit souvent des tests de sécurité correspondants. L'objectif est de garantir que les vulnérabilités répertoriées ne peuvent plus être reproduites sur un appareil et que l'appareil peut réussir les tests de sécurité associés. En tant que tel, le problème n'est pas de prendre une mise à jour de sécurité fournie par Google ou un fournisseur tiers, mais de savoir si le fabricant atteste que l'appareil n'est pas vulnérable à la liste des CVE de l'ASB. Le fabricant est libre d'utiliser les mises à jour de sécurité fournies ou, s'il propose une modification plus appropriée à son appareil, d'utiliser cette modification à la place.
Par exemple, considérons un cas dans lequel Google corrige une vulnérabilité de sécurité AOSP en utilisant une modification 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 n'est pas mandaté par le CDD (ou les tests de certification associés), il peut supprimer le composant 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 au CVE documenté dans le bulletin de sécurité. Cependant, 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 vulnérabilités de sécurité ou de réduire d'une autre manière les fonctionnalités de la version finale.
Bien que nous travaillions avec tous les partenaires SoC pour garantir l'existence de correctifs pour tous les problèmes d'un ASB, nous recommandons aux fabricants de conclure un accord de maintenance avec leurs fournisseurs de SoC pour le cycle de vie d'un appareil. Les SoC peuvent cesser de gérer un chipset plus tôt que souhaité. L'établissement d'accords avant la sélection du chipset de l'appareil constitue donc une partie importante du processus de lancement 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 le SPL Android précédent tout en ajoutant les nouveaux correctifs disponibles à la version. Cependant, cette pratique finira par entraîner des problèmes de certification de build (car Android garantit que le dernier niveau de correctif de sécurité est disponible sur les appareils certifiés). Google recommande de travailler avec 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é afin de répondre aux autres exigences de Google ou de réussir le CTS ?
R : Nous n'exigeons pas l'utilisation de correctifs pour déclarer un niveau de correctif de sécurité Android (SPL) ; nous exigeons que le fabricant atteste que sa construction n'est pas vulnérable au problème.
Par exemple, un composant en cours de patch 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'un correctif.
Ceci est fondamentalement différent d’un fabricant souhaitant, par exemple, corriger uniquement les correctifs critiques, sans prendre d’autres correctifs applicables qui entraîneraient l’échec d’un test de sécurité. Dans ce cas, le SPL est supposé ne pas avoir été respecté.