Con el cambio de Android hacia la versión continua y los boletines trimestrales como parte de las actualizaciones de seguridad basadas en riesgos, es posible que los OEMs quieran corregir las vulnerabilidades entre las versiones en lugar de esperar un trimestre completo. La función XML de parche de seguridad complementario permite que los OEM informen las CVEs corregidas más allá del nivel de parche de seguridad (SPL) declarado a través de un archivo en formato XML estandarizado, de modo que los OEM reciban crédito por la aplicación de parches continua.
Flujo de alto nivel
Figura 1: Arquitectura y flujo de datos de los parches de seguridad complementarios
Los OEM pueden colocar el archivo en formato XML en varias particiones de dispositivos (/system, /vendor o /product), lo que garantiza que se tengan en cuenta los parches de seguridad del framework y los componentes específicos del hardware. El archivo XML debe instalarse en /etc/security/supplemental_security_patches.xml para la partición respectiva.
La plataforma agrega datos de CVE en estas particiones de dispositivos y los expone en las APIs de la plataforma y las bibliotecas de Jetpack. Para obtener más detalles, consulta API de la plataforma (Android 17 y versiones posteriores) y Retrocompatibilidad con versiones anteriores de Android.
En el siguiente ejemplo, se muestra un archivo XML de parche de seguridad complementario de muestra instalado en un dispositivo con tecnología 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 la plataforma (Android 17 y versiones posteriores)
En el caso de Android 17 (nivel de API 37) y versiones posteriores, el
SecurityStateManager controla el análisis de los parches complementarios de todas las
ubicaciones de partición compatibles y los expone en el paquete que se muestra desde
getGlobalSecurityState con las claves KEY_SYSTEM_SUPPLEMENTAL_PATCHES
y KEY_VENDOR_SUPPLEMENTAL_PATCHES.
El servicio del sistema SecurityStateManagerService agrega archivos XML de partición en estos dos buckets de informes generales:
KEY_SYSTEM_SUPPLEMENTAL_PATCHES: Agrega parches de las rutas de acceso de partición/system,/system_exty/product.KEY_VENDOR_SUPPLEMENTAL_PATCHES: Agrega parches de las rutas de acceso de partición/vendory/odm.
Retrocompatibilidad con versiones anteriores de Android
En el caso de Android 16 y versiones anteriores, no hay compatibilidad con la API de la plataforma. En su lugar, la biblioteca
androidx.security:security-state de Jetpack (SecurityStateManagerCompat)
lee manualmente los archivos XML con XmlPullParser. Para permitir que el dominio untrusted_app lea los archivos en Android 16 y versiones anteriores, los OEMs deben implementar los siguientes cambios de SELinux en todas las rutas de acceso de partición en las que está instalado el archivo XML:
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 };
Reglas de compilación y validación de esquemas
Para instalar el archivo en formato XML de parche complementario en /vendor/etc/security/,
/system/etc/security/, o /product/etc/security/, agrega una regla prebuilt_etc
en Android.bp. Dado que SecurityStateManagerService espera que el archivo del dispositivo se llame exactamente supplemental_security_patches.xml, usa la propiedad filename cuando uses nombres de módulos específicos de la partición:
// 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,
}
El Proyecto de código abierto de Android (AOSP) incluye el esquema XSD en
supplemental_security_patches.xsd
y valida el archivo en formato XML durante el proceso de compilación con la xsdc
regla de compilación en 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
}
También puedes validar tu archivo XML de forma local con el esquema XSD usando xmllint:
xmllint --schema frameworks/base/services/core/xsd/supplemental_security_patches/supplemental_security_patches.xsd --noout supplemental_security_patches.xml
Pruebas e integración de conjuntos
El Security Test Suite (STS) y Firmware Analysis (BTS) usan los datos del archivo supplemental_security_patches.xml para extender el análisis de parches para las vulnerabilidades presentes en el archivo en formato XML. Por lo tanto, además de reflejar el estado de seguridad del dispositivo, la integración correcta de este archivo permite que los OEMs realicen un análisis de parches proactivo en las vulnerabilidades corregidas por encima del SPL del dispositivo en lugar de esperar a que se declare oficialmente el SPL trimestral.