Guía para fabricantes sobre la seguridad a largo plazo de Android

En esta guía, se describen las prácticas recomendadas que recomienda Google para aplicar parches de seguridad que se evalúan con el conjunto de pruebas de compatibilidad (CTS) de Android. Está destinado a los fabricantes de equipos OEM compatibles con Android (fabricantes) que recibirán asistencia durante más de tres años, como vehículos, TVs, decodificadores y electrodomésticos. Esta guía no está dirigida a los usuarios finales (por ejemplo, los propietarios de vehículos).

Agradecimientos y renuncias de responsabilidad

Esta guía no vincula legal ni contractualmente a Google ni a otros fabricantes, y no pretende ser un conjunto de requisitos. En cambio, esta guía es una ayuda instructiva que describe las prácticas recomendadas.

Comentarios

Esta guía no pretende ser exhaustiva, y se planean revisiones adicionales. Envía tus comentarios a manufacturers-guide-android@googlegroups.com.

Glosario

Término Definición
ACC Compromiso de compatibilidad con Android. Anteriormente conocido como Acuerdo de Anti-Fragmentación de Android (AFA).
AOSP Proyecto de código abierto de Android
ASB Boletín de seguridad de Android
BSP Paquete de compatibilidad para la placa
CDD Documento de definición de compatibilidad
CTS Conjunto de pruebas de compatibilidad (CTS)
FOTA firmware inalámbrico
GPS sistema de posicionamiento global
MISRA Motor Industry Software Reliability Association
NIST Instituto Nacional de Estándares y Tecnología
OBD Diagnóstico a bordo (OBD-II es una mejora con respecto a OBD-I en cuanto a capacidad y estandarización)
OEM fabricante del equipo original
SO sistema operativo
SEI Software Engineering Institute
SoC sistema en chip
SOP Inicio de la producción
SPL Nivel del parche de seguridad
TPMS Sistema de monitoreo de presión de neumáticos

Acerca del SO Android

Android es una pila de software completa de código abierto basada en Linux diseñada para una variedad de dispositivos y factores de forma. Desde su primer lanzamiento en 2008, Android se convirtió en el sistema operativo (SO) más popular, con más de 1,400 millones de dispositivos en todo el mundo (2016). Aproximadamente el 67% de esos dispositivos usaban Android 5.0 (Lollipop) o versiones posteriores en marzo de 2017 (las cifras más recientes están disponibles en el Panel de Android). Si bien la gran mayoría de los dispositivos son teléfonos celulares y tablets, Android está creciendo en relojes inteligentes, TVs y dispositivos de infoentretenimiento (IVI) para automóviles.

La cantidad de apps para Android disponibles en Google Play Store alcanzó los 2.2 millones (2016). El desarrollo de apps para Android cuenta con el respaldo del programa de compatibilidad de Android, que define un conjunto de requisitos a través del Documento de definición de compatibilidad (CDD) y proporciona herramientas de prueba a través del Conjunto de pruebas de compatibilidad (CTS). Los programas de compatibilidad de Android garantizan que cualquier app para Android se pueda ejecutar en cualquier dispositivo compatible con Android que admita las funciones requeridas para la app.

Google lanza nuevas versiones del SO, actualizaciones de seguridad del SO e información sobre las vulnerabilidades descubiertas de forma periódica. Los fabricantes deben revisar los boletines de seguridad de Android para determinar si estas actualizaciones se aplican a los productos compatibles con el SO Android. Para obtener una revisión de los sistemas de seguridad, compatibilidad y compilación de Android, consulta lo siguiente:

Acerca de los vehículos conectados (productos canónicos duraderos)

Los vehículos comenzaron a estar conectados con la introducción de la radio AM en la década de 1920. A partir de allí, la cantidad de conexiones externas físicas y inalámbricas comenzó a aumentar a medida que los reguladores y los fabricantes de automóviles recurrieron a la electrónica para facilitar el diagnóstico y el servicio (por ejemplo, el puerto OBD-II), mejorar la seguridad (por ejemplo, el TPMS) y cumplir con los objetivos de economía de combustible. La siguiente ola de conectividad introdujo funciones de comodidad para el conductor, como entrada sin llave remota, sistemas telemáticos y funciones avanzadas de infoentretenimiento, como Bluetooth, Wi-Fi y proyección de smartphones. Actualmente, los sensores y la conectividad integrados (por ejemplo, el GPS) son compatibles con los sistemas de seguridad y conducción semiautónoma.

A medida que aumenta la cantidad de conexiones de vehículos, también lo hace el área de la posible superficie de ataque del vehículo. Las conexiones generan una colección similar de inquietudes de seguridad cibernética que las de los dispositivos electrónicos de consumo. Sin embargo, si bien los reinicios, las actualizaciones diarias de parches y los comportamientos inexplicables son la norma para los productos electrónicos de consumo, no son coherentes para los productos con sistemas críticos para la seguridad, como los vehículos.

Los fabricantes deben adoptar un enfoque proactivo para garantizar la seguridad y la protección continuas de un producto en el campo. En resumen, los fabricantes deben conocer las vulnerabilidades de seguridad conocidas del producto y adoptar un enfoque basado en el riesgo para abordarlas.

Garantizar la seguridad a largo plazo

Un vehículo conectado suele tener una o más unidades de control electrónico (ECU) que incluyen varios componentes de software, como SO, bibliotecas, utilidades, etcétera. Los fabricantes deben hacer un seguimiento de estos componentes y, con un análisis proactivo, identificar las vulnerabilidades publicadas conocidas, lo que incluye lo siguiente:

  • Evaluar el producto periódicamente en función de la base de datos de vulnerabilidades y exposiciones comunes (CVE)
  • Recopilación de inteligencia sobre fallas de seguridad relacionadas con el producto
  • Pruebas de seguridad
  • Analizar de forma activa los Boletines de seguridad de Android

Ejemplo de actualizaciones del SO y parches de seguridad (IVI que ejecutan Android):

Figura 1: Ejemplo de lanzamiento de actualizaciones importantes del SO y de seguridad durante la vida útil del vehículo.

# Paso Actividades

①

 Rama de desarrollo El fabricante selecciona una versión de Android (Android X). En este ejemplo, "Android X" se convierte en la base de lo que se incluirá en el vehículo dos años antes del inicio de producción (SOP) inicial.
② Lanzamiento inicial Unos meses antes de que Android X se convierta en la primera versión del SO incluida en el producto, las actualizaciones de seguridad se toman de los Boletines de seguridad de Android (ASB) y, posiblemente, de otras fuentes que el fabricante considere valiosas. y2 = el segundo Boletín de seguridad para la versión X de Android, aplicado (portado a versiones anteriores) por el fabricante a Android X. Esta actualización se incluye en el producto, y el reloj de producción comienza a correr en el año cero con Android X.y2.

En este ejemplo, el fabricante tomó la decisión de no lanzar la versión anual más reciente de Android X+1. Entre los motivos para lanzar la versión más reciente, se incluyen agregar funciones nuevas, abordar nuevas vulnerabilidades de seguridad o lanzar servicios de Google o de terceros que requieren la versión más reciente de Android. Los motivos en contra de lanzar la versión más reciente son la falta de tiempo inherente al proceso de desarrollo y lanzamiento del vehículo necesario para integrar, probar y validar los cambios, incluido el cumplimiento de todos los requisitos reglamentarios y de certificación.
③ Actualización completa del SO Después del SOP, el fabricante lanza la actualización del SO Android X+2, que son dos versiones de Android después de la versión utilizada para el producto inicial (Android X0). Las actualizaciones de seguridad del ASB están disponibles para el nivel de API (a partir de la fecha de lanzamiento), por lo que la actualización se publica como X+2.y0 aproximadamente 1.25 años después del SOP. Es posible que esta actualización del SO sea compatible con los productos en el campo o no. Si es así, se podría crear un plan para actualizar los vehículos implementados.

A menos que existan otros acuerdos comerciales, la decisión de realizar una actualización completa del SO queda totalmente a discreción del fabricante.
④ Actualización de seguridad Dos años después del inicio de la producción del vehículo, el fabricante lanza un parche para el SO Android X+2. Esta decisión se basa en la evaluación de riesgos del fabricante. El fabricante elige la tercera actualización de seguridad del ASB para la versión X+2 como base de la actualización. Los productos que reciben la actualización de seguridad ahora tienen el SO (X+2.y3) y el nivel de parche de seguridad de Android.

Si bien los fabricantes pueden seleccionar parches de seguridad individuales de cualquier ASB, deben corregir todos los problemas requeridos en el boletín para usar el nivel de parche de seguridad (SPL) de Android asociado con el boletín (por ejemplo, 2017-02-05). Es responsabilidad del fabricante realizar el backport y el lanzamiento de seguridad para el producto compatible.
⑤ Actualización completa del SO Repetición del paso 3 (actualización completa del SO): La segunda actualización completa del SO lleva el producto a Android X+4, tres años después del inicio de la vida útil de producción del vehículo. El fabricante ahora equilibra los requisitos de hardware más recientes de una versión reciente de Android con el hardware del producto y los usuarios se benefician de un SO Android actualizado. El fabricante lanza una actualización sin actualizaciones de seguridad, por lo que el producto ahora tiene el SO (X+4.y0) y el nivel de parche de seguridad de Android.

En este ejemplo, debido a limitaciones de hardware, X+4 es la última versión principal de Android que se proporcionará para este producto, aunque los más de 6 años de vida útil esperada del vehículo aún requieren asistencia de seguridad.
⑥ Actualización de seguridad Repetición del paso 4 (actualización de seguridad). El fabricante tiene la tarea de tomar las actualizaciones de seguridad del ASB de una versión mucho más reciente de Android (X+6) y portar algunas o todas esas actualizaciones a Android X+4. Es responsabilidad del fabricante combinar, integrar y realizar las actualizaciones (o contratar a un tercero para que lo haga). Además, el fabricante debe saber que los problemas de seguridad en versiones de Android que ya no se admiten no se cubren en el ASB.
⑦ Actualización de seguridad Ocho años después del inicio del ciclo de vida de producción del vehículo, cuatro versiones de Android después de la última actualización del SO en el paso 5 (actualización completa del SO) y diez años después de que se especificó Android X, la carga de seleccionar y transferir parches de seguridad a versiones anteriores recae por completo en el fabricante para las versiones que tienen más de tres años desde el lanzamiento público del nivel de API.

Prácticas recomendadas en materia de seguridad

Para dificultar las vulneraciones de seguridad, Google recomienda y emplea el uso de prácticas recomendadas comúnmente aceptadas para la seguridad y la ingeniería de software, como se describe en Implementación de la seguridad.

Lineamientos de seguridad

Las prácticas recomendadas para la seguridad incluyen las siguientes:

  • Usa las versiones más recientes de las bibliotecas externas y los componentes de código abierto.
  • No incluya funcionalidades de depuración intrusivas en las versiones de lanzamiento del SO.
  • Quita la funcionalidad sin usar (para reducir la superficie de ataque innecesaria).
  • Usa el principio de privilegio mínimo y otras prácticas recomendadas para el desarrollo de apps para Android.

Lineamientos de desarrollo de software

Las prácticas recomendadas para el desarrollo de software seguro durante el ciclo de vida del sistema incluyen las siguientes:

  • Realiza un modelado de amenazas para clasificar e identificar recursos, amenazas y posibles mitigaciones.
  • Realizar una revisión de la arquitectura o el diseño para garantizar un diseño seguro y sólido
  • Realiza revisiones de código periódicas para identificar antipatrones y errores lo antes posible.
  • Diseñar, implementar y ejecutar pruebas de unidades con alta cobertura de código, incluidas las siguientes:
    • Pruebas funcionales (incluidos los casos de prueba negativos)
    • Pruebas de regresión periódicas (para garantizar que no vuelvan a aparecer los errores corregidos)
    • Pruebas de Fuzz (como parte del paquete de pruebas de unidades)
  • Usa herramientas de análisis de código fuente estático (scan-build, lint, etcétera) para identificar posibles problemas.
  • Usa herramientas de análisis de código fuente dinámico, como AddressSanitizer, UndefinedBehaviorSanitizer y FORTIFY_SOURCE (para componentes nativos) para identificar y mitigar posibles problemas durante el desarrollo del sistema.
  • Tener una estrategia de administración para el código fuente del software y la configuración o versión de la versión
  • Tener una estrategia de administración de parches para la generación y la implementación de parches de software

Política de versiones anteriores de seguridad

Actualmente, Google proporciona asistencia activa para las correcciones de seguridad de las vulnerabilidades de seguridad descubiertas y notificadas durante tres (3) años a partir del lanzamiento público del nivel de API. El soporte activo incluye lo siguiente:

  1. Recibir e investigar informes de vulnerabilidades
  2. Crear, probar y lanzar actualizaciones de seguridad
  3. Proporcionar versiones recurrentes de actualizaciones de seguridad y detalles de boletines de seguridad
  4. Realiza la evaluación de gravedad según los lineamientos establecidos.

Después de tres años desde la fecha de lanzamiento público del nivel de API, Google recomienda los siguientes lineamientos:

  • Usa un tercero (como un proveedor de SoC o un proveedor de kernel) para obtener asistencia con la retroportabilidad de las actualizaciones de seguridad del SO que tengan más de tres años desde el lanzamiento de la API.
  • Usar un tercero para realizar revisiones de código con los ASB proporcionados públicamente Si bien los ASB identifican vulnerabilidades para la versión compatible actual, un fabricante puede usar la información proporcionada para comparar las actualizaciones recién lanzadas con las versiones anteriores. Estos datos se pueden usar para realizar análisis de impacto y, potencialmente, generar parches similares para versiones del SO con más de tres años de antigüedad desde el lanzamiento de la API.
  • Cuando corresponda, sube las actualizaciones de seguridad al Proyecto de código abierto de Android (AOSP).
  • El fabricante debe coordinar el manejo de las actualizaciones de seguridad para el código específico del proveedor (por ejemplo, el código propietario específico del dispositivo).
  • El fabricante debe unirse al grupo de notificaciones de la versión preliminar para socios del Boletín de seguridad de Android del NDA (requiere la firma de acuerdos legales, como el NDA para desarrolladores). Los boletines deben incluir lo siguiente:
    • Anuncios
    • Resumen de los problemas por nivel de parche, incluidos el CVE y la gravedad
    • Detalles de la vulnerabilidad, cuando corresponda

Referencias adicionales:

Para obtener instrucciones sobre prácticas de desarrollo de software y codificación seguras, consulta lo siguiente:

Google recomienda el uso de las siguientes prácticas recomendadas.

En general, se recomienda que cualquier producto conectado se lance con la versión de SO más reciente, y el fabricante debe intentar usar la versión de SO más reciente antes de lanzar el producto. Si bien bloquear la versión es necesario para garantizar la estabilidad antes de las pruebas y la validación, el fabricante debe equilibrar la estabilidad del producto que se obtiene de las versiones de SO anteriores con las versiones de SO más recientes que tienen menos vulnerabilidades de seguridad conocidas y protecciones de seguridad mejoradas.

Entre los lineamientos recomendados, se incluyen los siguientes:

  • Debido a los largos plazos de desarrollo inherentes al proceso de desarrollo de vehículos, es posible que los fabricantes deban lanzar el vehículo con la versión n-2 del SO o una anterior.
  • Mantener la conformidad con la Compatibilidad con Android para cada versión del SO Android lanzada con una campaña inalámbrica (OTA).
  • Implementa el firmware inalámbrico (FOTA) del producto compatible con Android para realizar actualizaciones rápidas y fáciles de usar. La FOTA debe realizarse con las prácticas recomendadas de seguridad, como la firma de código y la conexión TLS entre el producto y el sistema administrativo de TI.
  • Envía de forma independiente las vulnerabilidades de seguridad de Android identificadas al equipo de seguridad de Android.

Nota: Google ha contemplado notificaciones específicas de la industria o el tipo de dispositivo en los Boletines de seguridad de Android. Sin embargo, como Google no conoce el kernel, los controladores ni los chipsets de un dispositivo determinado (vehículo, TV, wearable, teléfono, etc.), no tiene una forma determinística de etiquetar cualquier problema de seguridad determinado con un tipo de dispositivo.

El fabricante debe hacer todo lo posible para usar la versión más reciente del SO o las actualizaciones de seguridad de la versión en uso durante las mejoras del ciclo del producto. Las actualizaciones se pueden realizar durante las actualizaciones periódicas recurrentes de los productos o para las correcciones urgentes que aborden problemas de calidad o de otro tipo. Las prácticas recomendadas incluyen las siguientes:

  • Crea un plan para abordar las actualizaciones de controladores, kernels y protocolos.
  • Utiliza un método adecuado para la industria para proporcionar actualizaciones a los vehículos implementados.

Documento de definición de compatibilidad (CDD)

En el Documento de definición de compatibilidad (CDD), se describen los requisitos que debe cumplir un dispositivo para considerarse compatible con Android. El CDD es público y está disponible para todos. Puedes descargar las versiones del CDD desde Android 1.6 hasta la versión más reciente en source.android.com.

Para cumplir con estos requisitos en un producto, se deben seguir estos pasos básicos:

  1. El socio firma el Compromiso de compatibilidad con Android (ACC) con Google. Luego, se asigna un asesor de soluciones técnicas (TSC) como guía.
  2. El socio completa la revisión del CDD para la versión del SO Android del producto.
  3. El socio ejecuta y envía los resultados del CTS (que se describen a continuación) hasta que los resultados sean aceptables para la compatibilidad con Android.

Conjunto de pruebas de compatibilidad (CTS)

La herramienta de prueba del Conjunto de pruebas de compatibilidad (CTS) verifica que la implementación de un producto sea compatible con Android y que se incluyan los parches de seguridad más recientes. El CTS es público, de código abierto y está disponible para todos. Puedes descargar las versiones del CTS desde Android 1.6 hasta la versión más reciente en source.android.com.

Cada compilación de software de Android que se lanza al público (imágenes de instalación de fábrica y de actualización en el campo) debe demostrar la compatibilidad con Android a través de los resultados del CTS. Por ejemplo, si el dispositivo ejecuta Android 7.1, se debe hacer referencia a la versión correspondiente más reciente de CDD 7.1 y CTS 7.1 cuando se crea y prueba una imagen de compilación de intención de lanzamiento. Se recomienda a los fabricantes que usen las CTS de forma anticipada y frecuente para identificar y corregir problemas.

NOTA: Es posible que los socios que firmen otros acuerdos, como los Servicios para dispositivos móviles de Google (GMS), deban cumplir con otros requisitos.

Flujo de trabajo de CTS

El flujo de trabajo de CTS implica configurar el entorno de pruebas, ejecutar pruebas, interpretar resultados y comprender el código fuente de CTS. Los siguientes lineamientos tienen como objetivo ayudar a los usuarios del CTS (por ejemplo, desarrolladores y fabricantes) a usarlo de manera eficaz y eficiente.

  • Ejecuta pruebas con frecuencia. El CTS está diseñado como una herramienta automatizada que se integra en tu sistema de compilación. Ejecutar el CTS con frecuencia puede ayudarte a encontrar defectos de forma rápida y anticipada cuando se producen regresiones o degradaciones del software.
  • Descarga y examina el código fuente del CTS. El código fuente completo del CTS es software de código abierto que cualquier persona puede descargar y usar (el código fuente descargado se puede compilar y ejecutar por completo). Cuando una prueba falla en el dispositivo, examinar la sección pertinente del código fuente puede ayudarte a identificar el motivo.
  • Obtén el CTS más reciente. Las nuevas versiones de Android pueden actualizar el CTS con correcciones de errores, mejoras y pruebas nuevas. Consulta Descargas de CTS con frecuencia y actualiza tu programa de CTS según sea necesario. El fabricante y Google acordarán la versión de las CTS que se aprobará para el lanzamiento del producto, ya que este debe congelarse en algún momento mientras se siguen actualizando las CTS.

Aprobar el CTS

En el caso de un producto compatible con Android, Google garantiza que los informes del CTS y del CTS Verifier del dispositivo tengan resultados de pruebas aceptables. En principio, todas las pruebas deben aprobarse. Sin embargo, Google revisará las pruebas que fallen por motivos distintos a que el dispositivo no cumpla con los requisitos de compatibilidad con Android. Durante este proceso, sucede lo siguiente:

  1. El fabricante proporciona a Google los parches propuestos del CTS, las validaciones de parches y las justificaciones para demostrar el argumento.
  2. Google examina el material enviado y, si lo acepta, actualiza las pruebas del CTS pertinentes para que el dispositivo apruebe la próxima revisión del CTS.

Si una prueba de CTS falla repentinamente después de aplicar un parche de seguridad, el fabricante debe modificar el parche para que no interrumpa la compatibilidad O mostrar que la prueba es incorrecta y proporcionar una corrección para la prueba (como se describió anteriormente).

El CTS permanece abierto para las revisiones de las correcciones de pruebas. Por ejemplo, Android 4.4 sigue aceptando correcciones (consulta https://android-review.googlesource.com/c/platform/cts/+/273371).

Preguntas frecuentes

P.: ¿Quién es responsable de aplicar las actualizaciones de seguridad a una implementación específica de Android?

R.: El responsable es el fabricante que proporciona el dispositivo directamente. Esta entidad no es Google, que publica actualizaciones de seguridad en AOSP y no para un dispositivo específico (como un vehículo).

P.: ¿Cómo maneja Google los problemas de seguridad en Android?

R.: Google investiga continuamente los problemas y desarrolla posibles soluciones, que pone a disposición de todos los niveles de API compatibles como parte del proceso de actualización de seguridad habitual. Desde agosto de 2015, Google mantiene una cadencia regular de publicación de boletines y vínculos a actualizaciones en source.android.com. Google también publica actualizaciones de seguridad como parte de las versiones principales del SO. Consulta también la Política de versiones anteriores de seguridad.

P.: Si un fabricante integró todos los parches del AOSP de un ASB, pero no integró los parches del proveedor del BSP que se mencionan en el mismo boletín, ¿puede aun así aumentar el nivel de seguridad (por ejemplo, aplicar el parche correspondiente a platform/build)?

R.: Para declarar un nivel de parche de seguridad (SPL) de Android, el fabricante debe abordar todos los problemas obligatorios publicados en el Boletín de seguridad de Android (incluidos los boletines anteriores) y asignados a un SPL de Android en particular. Por ejemplo, un fabricante que usa el Boletín de seguridad de marzo de 2017 (SPL del 2017-03-01) abordó todos los problemas obligatorios documentados en el boletín de marzo de 2017 para ese SPL y todas las actualizaciones anteriores, incluidas las actualizaciones específicas del dispositivo para todos los Boletines de seguridad de Android anteriores, incluidas las actualizaciones específicas del dispositivo asociadas al SPL del 2017-02-05.

P.: ¿Qué sucede cuando el fabricante no está de acuerdo con las actualizaciones de seguridad que proporciona el proveedor del BSP O cuando los proveedores no proporcionan las actualizaciones de seguridad obligatorias de un ASB?

R.: Un ASB describe las vulnerabilidades de seguridad (enumeradas por una lista de CVE) y, a menudo, proporciona pruebas de seguridad coincidentes. El objetivo es garantizar que las vulnerabilidades enumeradas ya no se puedan reproducir en un dispositivo y que este pueda aprobar las pruebas de seguridad asociadas. Por lo tanto, el problema no se relaciona con la aplicación de una actualización de seguridad proporcionada por Google o un proveedor externo, sino con la certificación del fabricante de que el dispositivo no es vulnerable a la lista de CVE del ASB. El fabricante puede usar las actualizaciones de seguridad proporcionadas o, si tiene un cambio más adecuado para su dispositivo, usar ese cambio en su lugar.

Por ejemplo, considera un caso en el que Google aborda una vulnerabilidad de seguridad del AOSP con un cambio de código que permite que el componente siga siendo completamente funcional y cumpla con el CDD. Si el fabricante determina que el componente no es necesario en el dispositivo o que no es obligatorio según el CDD (o las pruebas de certificación relacionadas), puede quitar el componente para reducir las necesidades de servicio futuras y la superficie de ataque. Si bien el fabricante no usó la actualización de seguridad proporcionada, se aseguró de que el dispositivo no sea vulnerable al CVE documentado en el boletín de seguridad. Sin embargo, al desviarse de la actualización de seguridad recomendada, el fabricante corre el riesgo de abordar el problema de forma incorrecta, introducir nuevas vulnerabilidades de seguridad o reducir la funcionalidad de la compilación final.

Si bien trabajamos con todos los socios de SoC para garantizar que existan correcciones para todos los problemas en un ASB, recomendamos que los fabricantes obtengan un acuerdo de servicio con sus proveedores de SoC para el ciclo de vida de un dispositivo. Los SoCs pueden dejar de prestar servicio a un chipset antes de lo deseado, por lo que establecer acuerdos antes de la selección del chipset del dispositivo es una parte importante del proceso de lanzamiento del dispositivo.

Por último, en los casos en los que es imposible adquirir directamente o crear de forma independiente una corrección para un problema documentado en un ASB, un fabricante podría mantener el SPL de Android anterior y, aun así, agregar las nuevas correcciones disponibles a la compilación. Sin embargo, esta práctica eventualmente generará problemas con la certificación de compilación (ya que Android garantiza que el nivel de parche de seguridad más reciente esté disponible en los dispositivos certificados). Google recomienda que trabajes con tu SoC con anticipación para evitar esta práctica.

P.: Si el fabricante determina que un elemento de ASB no es aplicable a su producto, ¿se debe aplicar o corregir el elemento para cumplir con los demás requisitos de Google o aprobar la CTS?

R.: No exigimos que se apliquen parches para declarar un nivel de parche de seguridad (SPL) de Android. Sí exigimos que el fabricante certifique que su compilación no es vulnerable al problema.

Un ejemplo es cuando un componente al que se le aplica un parche no existe en el sistema del fabricante o cuando se quita un componente del sistema del fabricante para solucionar un problema. En ese caso, es posible que el sistema cumpla con los requisitos sin necesidad de que el fabricante aplique un parche.

Esto es fundamentalmente diferente de un fabricante que desea, por ejemplo, solo corregir parches críticos, sin aplicar otros parches aplicables que harían que falle una prueba de seguridad. En este caso, se supone que no se cumplió con el SPL.