Correctifs de sécurité supplémentaires

Avec le passage d'Android à une publication continue et à des bulletins trimestriels dans le cadre des mises à jour de sécurité basées sur les risques, les OEM peuvent souhaiter corriger les failles entre les versions plutôt que d'attendre un trimestre entier. La fonctionnalité XML de correctif de sécurité supplémentaire permet aux OEM de signaler les CVE corrigées au-delà du niveau du correctif de sécurité (SPL) déclaré en fournissant un fichier XML standardisé. Les OEM sont ainsi crédités pour l'application continue de correctifs.

Étapes clés

Diagramme montrant le flux de données XML des correctifs de sécurité supplémentaires des partitions système, fournisseur et produit de l'OEM vers l'API AOSP Framework

Figure 1. Architecture et flux de données des correctifs de sécurité supplémentaires.

Les OEM peuvent placer le fichier XML sur plusieurs partitions d'appareil (/system, /vendor ou /product), ce qui garantit que les correctifs de sécurité des composants spécifiques au framework et au matériel sont pris en compte. Le fichier XML doit être installé dans /etc/security/supplemental_security_patches.xml pour la partition correspondante.

La plate-forme agrège les données CVE sur ces partitions d'appareil et les expose dans les API de plate-forme et les bibliothèques Jetpack. Pour en savoir plus, consultez API de plate-forme Android 17 et versions ultérieures et Rétroportage vers des versions Android antérieures.

L'exemple suivant montre un exemple de fichier XML de correctif de sécurité supplémentaire installé sur un appareil Android :

<?xml version="1.0" encoding="utf-8"?>
<security-patches xmlns="http://schemas.android.com/security/patches/1.0">
    <patch><id>CVE-2026-12345</id></patch>
</security-patches>

API de plate-forme (Android 17 et versions ultérieures)

Pour Android 17 (niveau d'API 37) et versions ultérieures, la plate-forme's SecurityStateManager gère l'analyse des correctifs supplémentaires à partir de tous les emplacements de partition compatibles et les expose dans le bundle renvoyé à partir de getGlobalSecurityState à l'aide des clés KEY_SYSTEM_SUPPLEMENTAL_PATCHES et KEY_VENDOR_SUPPLEMENTAL_PATCHES.

Le service système SecurityStateManagerService agrège les fichiers XML de partition dans ces deux buckets de rapports généraux :

  • KEY_SYSTEM_SUPPLEMENTAL_PATCHES : agrège les correctifs des chemins de partition /system, /system_ext et /product.
  • KEY_VENDOR_SUPPLEMENTAL_PATCHES: agrège les correctifs des chemins de partition /vendor et /odm.

Rétroportage vers des versions Android antérieures

Pour Android 16 et versions antérieures, aucune API de plate-forme n'est disponible. À la place, la bibliothèque Jetpack androidx.security:security-state (SecurityStateManagerCompat) lit manuellement les fichiers XML à l'aide de XmlPullParser. Pour autoriser le domaine untrusted_app à lire les fichiers sur Android 16 et versions antérieures, les OEM doivent implémenter les modifications SELinux suivantes sur tous les chemins de partition où le fichier XML est installé :

file_contexts :

/(system|vendor|product|system_ext|odm)/etc/security/supplemental_security_patches\.xml u:object_r:supplemental_security_patches:s0

supplemental_security_patches.te :

allow untrusted_app supplemental_security_patches:file { getattr open read };

Règles de compilation et validation de schéma

Pour installer le fichier XML de correctif supplémentaire dans /vendor/etc/security/, /system/etc/security/, ou /product/etc/security/, ajoutez une règle prebuilt_etcin Android.bp. Étant donné que SecurityStateManagerService s'attend à ce que le fichier sur l'appareil soit nommé exactement supplemental_security_patches.xml, utilisez la propriété filename lorsque vous utilisez des noms de modules spécifiques à la partition :

// For vendor partition (/vendor/etc/security/supplemental_security_patches.xml)
prebuilt_etc {
    name: "vendor_supplemental_security_patches.xml",
    src: "supplemental_security_patches.xml",
    filename: "supplemental_security_patches.xml",
    sub_dir: "security",
    vendor: true,
}
// For system partition (/system/etc/security/supplemental_security_patches.xml)
prebuilt_etc {
    name: "system_supplemental_security_patches.xml",
    src: "supplemental_security_patches.xml",
    filename: "supplemental_security_patches.xml",
    sub_dir: "security",
}
// For product partition (/product/etc/security/supplemental_security_patches.xml)
prebuilt_etc {
    name: "product_supplemental_security_patches.xml",
    src: "supplemental_security_patches.xml",
    filename: "supplemental_security_patches.xml",
    sub_dir: "security",
    product_specific: true,
}

Le Projet Android Open Source (AOSP) inclut le schéma XSD dans supplemental_security_patches.xsd et valide le format de fichier XML lors du processus de compilation à l'aide de la règle de compilation xsdc dans Android.bp :

xsdc {
    name: "supplemental_security_patches_xsd",
    srcs: ["supplemental_security_patches/supplemental_security_patches.xsd"],
    package_name: "android.security.patches", // Java package name for generated code
}

Vous pouvez également valider votre fichier XML localement par rapport au schéma XSD à l'aide de xmllint :

xmllint --schema frameworks/base/services/core/xsd/supplemental_security_patches/supplemental_security_patches.xsd --noout supplemental_security_patches.xml

Intégration de tests et de suites

La Security Test Suite (STS) et l'analyse du micrologiciel (BTS) utilisent les données du fichier supplemental_security_patches.xml pour étendre l'analyse des correctifs aux failles présentes dans le fichier XML. Ainsi, en plus de refléter l'état de sécurité de l'appareil, l'intégration correcte de ce fichier permet aux OEM d'effectuer une analyse proactive des correctifs sur les failles corrigées au-dessus du SPL de l'appareil au lieu d'attendre la déclaration officielle du SPL trimestriel.