Présentation des bibliothèques d'état de sécurité AndroidX : une vue unifiée de la sécurité des appareils

Chez Android, nous nous efforçons constamment de fournir aux développeurs et aux partenaires d'entreprise les données dont ils ont besoin pour protéger les appareils. Aujourd'hui, nous sommes ravis d'annoncer la sortie stable des bibliothèques AndroidX Security State version 1.1.0 et Security State Provider version 1.0.0, qui fournissent un mécanisme centralisé conçu pour améliorer la transparence de la stratégie de sécurité complète et des mises à jour en attente dans l'écosystème Android.

Que vous développiez des applications critiques pour la sécurité et destinées aux consommateurs (comme les applications bancaires, financières ou de santé) ou des solutions de gestion des appareils mobiles (MDM), ces bibliothèques vous permettent de vérifier par programmation l'état de sécurité de l'appareil par composant. Plutôt que de vous appuyer sur un niveau de correctif de sécurité (SPL) grossier et monolithique, vous pouvez évaluer la protection réelle au niveau des composants et vérifier si des corrections sont en attente activement via la androidx.security.state bibliothèque. Pour les OEM et les développeurs de clients OTA (Over-The-Air), la bibliothèque associée androidx.security.state.provider vous permet d'exposer la disponibilité des mises à jour via des mécanismes standardisés.

Comprendre les niveaux de correctif de sécurité (SPL)

Android ayant évolué pour fournir des mises à jour de composants rapides et indépendantes via des systèmes modulaires tels que les mises à jour du système Google Play, s'appuyer sur une seule propriété de build SPL n'est plus la meilleure façon de déterminer la véritable stratégie de sécurité d'un appareil. Pour fournir une visibilité au niveau des composants, les bibliothèques d'état de sécurité fournissent des API pour trois niveaux de correctif distincts :

• SPL de l'appareil (DSPL) : niveau de correctif de sécurité actuellement installé et exécuté sur l'appareil pour des composants système spécifiques, interrogé à partir des propriétés et des configurations de l'appareil sans appels réseau.
• SPL publié (PSPL) : dernier niveau de correctif officiellement publié dans le Bulletin sur la sécurité d'Android pour ces composants.
• SPL disponible (ASPL) : niveau de correctif prêt à être téléchargé et installé sur l'appareil spécifique, interrogé de manière asynchrone via la communication interprocessus (IPC) avec les clients de mise à jour sur l'appareil.

Les bibliothèques d'état de sécurité suivent ces niveaux de correctif pour les composants suivants :

• Système  : système d'exploitation Android de base, mis à jour via les mises à jour OTA standard/OEM.
• Modules système : sous-systèmes d'OS modulaires mis à jour de manière transparente en arrière-plan via les mises à jour du système Google Play (Project Mainline).
• Noyau : couche de base connectant le matériel et les logiciels de l'appareil, évaluée via les versions de support à long terme (LTS) (telles que 5.15.159 ou 6.1.91) plutôt que les dates de calendrier mensuelles.

En exposant ces trois niveaux de correctif distincts au niveau des composants, les développeurs et les entreprises peuvent désormais comprendre exactement le niveau de sécurité d'un appareil, identifier les correctifs manquants et prendre des mesures correctives proactives. L'exemple ci-dessous illustre cette approche.

Plutôt que d'adopter une approche tout ou rien pour l'accès aux appareils, les développeurs et les entreprises peuvent combiner DSPL, PSPL et ASPL pour prendre des décisions de sécurité intelligentes et contextuelles. Par exemple, une application bancaire ou d'entreprise peut comparer le correctif de sécurité actuel d'un appareil (DSPL) aux mises à jour en attente (ASPL) avant de lancer des workflows sensibles tels que des paiements de valeur élevée ou l'enregistrement d'identifiants. Si une mise à jour est en attente d'installation, les développeurs et les entreprises peuvent demander à l'utilisateur de mettre à jour son appareil en premier. Pour un contrôle encore plus précis, les développeurs et les entreprises peuvent vérifier si des failles spécifiques à haut risque (CVE) ont été corrigées sur l'appareil, par exemple en s'assurant que les correctifs critiques NFC ou Bluetooth sont en place avant d'autoriser le paiement sans contact ou le partage de données de proximité.

Flux de haut niveau

Pour les développeurs d'applications et la gestion d'entreprise

Les applications clientes peuvent utiliser la bibliothèque androidx.security.state pour prendre des décisions éclairées et contextuelles :

• Vérifications de la stratégie synchrones (DSPL) : les applications peuvent inspecter immédiatement les niveaux de correctif installés du système, des modules système et du noyau au lancement de l'application, et les comparer au PSPL pour vérifier si l'appareil répond à la référence de sécurité requise par une organisation avant de déverrouiller des ressources d'entreprise sensibles ou un accès biométrique.
• Invite de mise à jour en attente (ASPL) : au lieu de bloquer immédiatement un employé dont l'appareil est légèrement en retard sur les correctifs, les applications d'entreprise peuvent interroger l'ASPL pour vérifier si une mise à jour du système ou une mise à jour du système Google Play en attente est en cours de préparation et prête à être installée. Si c'est le cas, les applications peuvent afficher des conseils personnalisés dans l'application, invitant l'utilisateur à accéder aux paramètres système pour terminer l'installation.
• Audit au niveau des failles (CVE) : pour les cas d'utilisation à haute assurance, la bibliothèque permet de télécharger des rapports de failles spécifiques à l'appareil à partir d'Open Source Vulnerabilities (OSV) afin de vérifier par programmation si des CVE spécifiques et critiques ont été résolues sur l'appareil.

Pour les OEM et les clients de mise à jour : standardisation de la disponibilité des mises à jour

La bibliothèque associée androidx.security.state.provider établit un mécanisme IPC Android standardisé permettant aux clients de mise à jour de signaler la disponibilité des mises à jour directement sur l'appareil. Historiquement, même si les clients OTA propriétaires exposaient la disponibilité des mises à jour, ces informations étaient isolées et ne pouvaient pas être interrogées par des applications tierces. À l'avenir, les applications pourront accéder aux détails de l'ASPL via une API unique et unifiée, que la mise à jour soit fournie via le client OTA dédié d'un OEM ou Google Play, à condition qu'elle soit fournie par le client de mise à jour.

• Les mises à jour du système Google Play exposent déjà l'ASPL sur les appareils Android GMS.
• Google Over-The-Air (GOTA) a également été intégré, et nous collaborons avec des OEM du monde entier pour intégrer leurs clients OTA à ce framework standardisé.

Intégration des données au niveau du bulletin

Au-delà d'une seule chaîne SPL, les bibliothèques d'état de sécurité indiquent clairement ce que ce niveau de correctif signifie réellement pour l'appareil. En s'intégrant à la base de données Open Source Vulnerabilities (OSV) pour obtenir les données du Bulletin sur la sécurité d'Android, les bibliothèques peuvent aller plus loin que jamais. Au lieu de simplement demander si une menace spécifique, telle qu'une entrée CVE, est bloquée, ces données permettent également aux bibliothèques de fournir l'état de sécurité "efficace" et précis de l'appareil.

Voici deux avantages de cette approche pour les entreprises et les OEM Android :

• Parfois, une mise à jour de sécurité mensuelle ne contient aucune nouvelle menace pour un composant spécifique. Dans ce cas, les bibliothèques incrémentent automatiquement le niveau de sécurité de ce composant pour refléter son état de sécurité "efficace". Cela permet de s'assurer qu'un appareil est correctement crédité pour être entièrement protégé contre toutes les menaces de sécurité connues.
• Une nouvelle fonctionnalité introduite dans Android 17 permet aux OEM de déclarer des correctifs de sécurité spécifiques qui ont été appliqués au-dessus du SPL via un fichier XML de correctifs supplémentaires. Cette fonctionnalité permet aux OEM qui rétroportent des correctifs de sécurité spécifiques de prouver immédiatement la conformité de l'appareil sans avoir à attendre une augmentation complète du SPL monolithique, ce qui garantit que les efforts de correction continus sont correctement crédités. Les bibliothèques d'état de sécurité exposent ces informations précises aux applications et aux services, ce qui garantit que les efforts de correction continus sont reconnus dès leur mise en œuvre.

Commencer

Les bibliothèques d'état de sécurité sont conçues pour renforcer l'ensemble de l'écosystème Android.

• Développeurs d'applications et MDM : pour commencer à protéger vos utilisateurs et à évaluer l'état des correctifs en temps réel, consultez le guide officiel Comprendre l'état de sécurité des appareils.
• OEM et clients de mise à jour : intégrez vos clients de mise à jour pour exposer l'ASPL à l'aide de la bibliothèque AndroidX Security State Provider. Bénéficiez d'un crédit immédiat pour les correctifs rétroportés en publiant des fichiers XML de correctifs supplémentaires.
• Notes de version : consultez les notes de version officielles d'AndroidX pour les bibliothèques Security-State et Security-State-Provider afin d'obtenir les journaux des modifications complets et les signatures d'API.

Vos commentaires nous sont précieux Veuillez essayer les bibliothèques et nous faire part de vos commentaires ou signaler tout problème sur la version publique Android Issue Tracker.