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 de la version stable des bibliothèques AndroidX Security State version 1.1.0 et Security State Provider version 1.0.0. Elles fournissent un mécanisme centralisé conçu pour améliorer la transparence de la stratégie de sécurité globale 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 clients (comme les applications bancaires, de fintech ou de santé) ou des solutions de gestion des appareils mobiles (MDM), ces bibliothèques vous permettent de vérifier de manière programmatique l'état de sécurité de l'appareil par composant. Plutôt que de vous fier à un niveau de correctif de sécurité (SPL) monolithique et approximatif, vous pouvez évaluer la protection réelle au niveau des composants et déterminer si des corrections sont en attente à l'aide de la bibliothèque androidx.security.state. 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 a évolué pour fournir des mises à jour rapides et indépendantes des composants via des systèmes modulaires tels que les mises à jour du système Google Play. Par conséquent, s'appuyer sur une seule propriété de compilation SPL n'est plus le meilleur moyen de déterminer la stratégie de sécurité réelle d'un appareil. Pour assurer une visibilité au niveau des composants, les bibliothèques d'état de sécurité fournissent des API pour trois niveaux de correctifs distincts :

• Niveau du correctif de sécurité de l'appareil (DSPL) : niveau du 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 inter-processus (IPC) avec les clients de mise à jour sur l'appareil.

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

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

En affichant ces trois niveaux de correctifs distincts au niveau des composants, les développeurs et les entreprises peuvent désormais comprendre précisément le niveau de sécurité d'un appareil, identifier les correctifs manquants et prendre des mesures correctives proactives. L'exemple ci-dessous illustre l'une des façons de procéder.

Plutôt que d'adopter une approche de type "tout ou rien" pour l'accès aux appareils, les développeurs et les entreprises peuvent combiner les niveaux de protection 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 niveau de correctif de sécurité actuel d'un appareil (DSPL) aux mises à jour en attente (ASPL) avant de lancer des workflows sensibles, comme 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 exiger que l'utilisateur mette d'abord à jour son appareil. 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, ils peuvent s'assurer que les correctifs critiques pour le NFC ou le Bluetooth sont en place avant d'autoriser le paiement sans contact ou le partage de données de proximité.

Étapes clés

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 de sécurité synchrones (DSPL) : les applications peuvent inspecter immédiatement les niveaux de correctifs installés du système, des modules système et du noyau au lancement de l'application, et les comparer à la PSPL pour vérifier si l'appareil respecte la stratégie de sécurité de base requise par une organisation avant de déverrouiller les ressources d'entreprise sensibles ou l'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 prête à être installée. Si c'est le cas, les applications peuvent afficher des conseils personnalisés dans l'application pour rediriger l'utilisateur vers les paramètres système afin de 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 d'auditer de manière programmatique si des CVE critiques spécifiques 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. Auparavant, même si les clients OTA propriétaires affichaient la disponibilité des mises à jour, ces informations étaient cloisonnées et ne pouvaient pas être interrogées par des applications tierces. Désormais, les applications peuvent accéder aux détails de l'ASPL via une seule API unifiée, que la mise à jour soit fournie par le client OTA dédié d'un OEM ou par 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égrer des données au niveau des bulletins

Au-delà d'une simple chaîne SPL, les bibliothèques d'état de sécurité fournissent des informations claires sur 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 effectuer des recherches plus approfondies 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é "effectif" et précis de l'appareil.

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

• Il arrive qu'une mise à jour de sécurité mensuelle ne contienne aucune nouvelle menace pour un composant spécifique. Dans ce cas, les bibliothèques augmentent automatiquement le niveau de sécurité de ce composant pour refléter son état de sécurité "effectif". 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 mise à jour complète du SPL monolithique. Cela permet de s'assurer que les efforts continus de correction sont correctement pris en compte. Les bibliothèques d'état de sécurité transmettent ces informations précises aux applications et aux services, ce qui permet de s'assurer que les efforts continus d'application de correctifs sont reconnus dès qu'ils sont mis en œuvre.

Commencer

Les bibliothèques d'état de sécurité sont conçues pour 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é de l'appareil.
• 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. Demandez 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 l'Issue Tracker Android public.