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

Chez Android, nous mettons tout en œuvre pour fournir aux développeurs et aux partenaires professionnels 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 Providerversion 1.0.0. Elles fournissent un mécanisme centralisé conçu pour rendre plus transparents l'état de sécurité complet et les mises à jour en attente dans l'écosystème Android.

Que vous développiez des applications critiques pour la sécurité et en contact avec les clients (comme des applications bancaires, fintech 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 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 mesures correctives sont en attente à l'aide de la bibliothèque androidx.security.state. Pour les OEM et les développeurs de clients Over-The-Air (OTA), la bibliothèque androidx.security.state.provider associée vous permet d'exposer la disponibilité des mises à jour via des mécanismes standardisés.

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

Android a évolué pour fournir des mises à jour de composants rapides et indépendants grâce à des systèmes modulaires tels que les mises à jour du système Google Play. S'appuyer sur une seule propriété de compilation SPL n'est donc plus la meilleure façon de déterminer la véritable posture de sécurité d'un appareil. Pour fournir une visibilité au niveau des composants, les bibliothèques Security State 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 en cours d'exécution sur l'appareil pour des composants système spécifiques, récupéré à partir des propriétés et des configurations de l'appareil sans appels réseau.
• Niveau du correctif de sécurité publié (PSPL) : dernier niveau du correctif officiellement publié dans le bulletin sur la sécurité d'Android pour ces composants.
• SPL (ASPL) disponible : 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 Security State suivent ces niveaux de correctifs dans les composants suivants :

• Système  : système d'exploitation Android de base, mis à jour via les mises à jour OTA standard/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 relie le matériel et le logiciel de l'appareil. Il est évalué à l'aide des versions LTS (Long-Term Support), telles que 5.15.159 ou 6.1.91, plutôt qu'à l'aide des dates mensuelles du calendrier.

En affichant ces trois niveaux de correctifs 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. Vous trouverez ci-dessous un exemple de cette méthode.

Plutôt que d'adopter une approche tout ou rien pour l'accès aux appareils, les développeurs et les entreprises peuvent combiner les niveaux 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 exiger de l'utilisateur qu'il 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 posture 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 répond à la référence de sécurité 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 ASPL pour vérifier si une mise à jour du système ou une mise à jour du système Google Play en attente est préparée et prête à être installée. Si c'est le cas, les applications peuvent afficher des conseils personnalisés dans l'application, qui redirigent l'utilisateur vers les paramètres système pour terminer l'installation.
• Audit au niveau des failles (CVE) : pour les cas d'utilisation à haute fiabilité, la bibliothèque permet de télécharger des rapports sur les failles spécifiques aux appareils à partir d'OSV (Open Source Vulnerabilities) afin de vérifier par programmation 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 androidx.security.state.provider associée é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 affichaient la disponibilité des mises à jour, ces informations étaient cloisonnées et ne pouvaient pas être interrogées par des applications tierces. À l'avenir, les applications pourront accéder aux détails ASPL via une API unique et 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é. 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 Security State 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 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é des appareils sans avoir à attendre une augmentation complète et monolithique du niveau de correctif de sécurité. Les efforts de correction continue sont ainsi correctement crédités. Les bibliothèques Security State fournissent ces informations détaillées aux applications et aux services, ce qui permet de reconnaître les efforts de correction continue dès qu'ils sont mis en œuvre.

Commencer

Les bibliothèques Security State 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 sur la compréhension de l'état de sécurité des appareils.
• OEM et clients de mise à jour : intégrez vos clients de mise à jour pour exposer ASPL à l'aide de la bibliothèque AndroidX Security State Provider. Pour bénéficier immédiatement du crédit des correctifs rétroportés, publiez 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 pour obtenir les journaux des modifications et les signatures d'API complets.

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