Oxidación en Android: avanzar rápido y solucionar problemas

Publicado por Jeff Vander Stoep, Android. El año pasado, escribimos sobre por qué una estrategia de seguridad de memoria que se centra en la prevención de vulnerabilidades en el nuevo código produce ganancias duraderas y acumulativas. Este año, analizamos cómo este enfoque no solo arregla las cosas, sino que también nos ayuda a avanzar más rápido. Los datos de 2025 siguen validando el enfoque, y las vulnerabilidades de seguridad de memoria caen por debajo del 20% de todas las vulnerabilidades por primera vez. Datos actualizados para 2025. Estos datos cubren cambios en el código de primera y tercera parte (open source) en la plataforma Android en C, C++, Java, Kotlin y Rust. Esta publicación se publica unos meses antes del final de 2025, pero la ventana de parches estándar de la industria de Android de 90 días significa que estos resultados probablemente serán casi finales. Podemos y debemos acelerar la reparación cuando sea necesario. Adoptamos Rust por su seguridad y observamos una reducción de 1000 veces en la densidad de vulnerabilidades de seguridad de memoria en comparación con el código C y C++ de Android. Pero el mayor impacto fue en la entrega de software. Con cambios de Rust que tienen una tasa de reversión 4 veces menor y pasan un 25% menos de tiempo en la revisión de código, el camino más seguro también es el más rápido. En esta publicación, profundizamos en los datos detrás de este cambio y también cubrimos: Cómo estamos expandiendo nuestro alcance: Estamos trabajando para hacer que el código seguro sea la norma en toda nuestra pila de software. Tenemos actualizaciones sobre la adopción de Rust en aplicaciones de primera parte, el kernel de Linux y firmware. Nuestra primera vulnerabilidad de seguridad de memoria de Rust: casi: Analizaremos un error de seguridad de memoria casi en Rust: cómo ocurrió, cómo se mitigó y los pasos que estamos tomando para prevenir que vuelva a ocurrir. También es una buena oportunidad para responder la pregunta: “¿Si Rust puede tener vulnerabilidades de seguridad de memoria, ¿por qué molestarse?” Desarrollar un sistema operativo requiere el control y la predictibilidad de los lenguajes de programación de sistemas como C, C++ y Rust. Si bien Java y Kotlin son importantes para el desarrollo de la plataforma Android, su papel es complementario a los lenguajes de sistemas, en lugar de ser intercambiables. Introdujimos Rust en Android como una alternativa directa a C y C++, ofreciendo un nivel similar de control, pero sin muchos de sus riesgos. Nos centramos en este análisis en el código nuevo y en desarrollo activo, ya que nuestros datos muestran que este es un enfoque eficaz. Cuando analizamos el desarrollo en lenguajes de sistemas (excluyendo Java y Kotlin), surgen dos tendencias: un aumento en el uso de Rust y una disminución más lenta pero constante en el nuevo C++. Líneas de código añadidas: Rust vs. C++, código de primera parte de Android. Este gráfico se centra en el código de primera parte (desarrollado por Google) (a diferencia del gráfico anterior, que incluía todo el código de primera y tercera parte en Android). Solo incluimos lenguajes de sistemas, C/C++ (que principalmente es C++), y Rust. El gráfico muestra que el volumen de nuevo código de Rust ahora rivaliza con el de C++, lo que permite comparaciones fiables de las métricas de proceso de desarrollo de software. Para medir esto, utilizamos el marco DORA1, un programa de investigación de una década que se ha convertido en el estándar de la industria para evaluar el rendimiento de los equipos de ingeniería de software. Las métricas DORA se centran en: Aumento: la velocidad con la que se entregan los cambios de software. Estabilidad: la calidad de esos cambios. Las comparaciones entre lenguajes pueden ser difíciles. Utilizamos varias técnicas para garantizar que las comparaciones sean fiables. Cambios de tamaño similares: Rust y C++ tienen una densidad de funcionalidad similar, aunque Rust es ligeramente más densa. Esta diferencia favorece a C++, pero la comparación sigue siendo válida. Utilizamos las definiciones de tamaño de cambio de Gerrit. Grupos de desarrolladores similares: Solo consideramos cambios de primera parte del Android. La mayoría son ingenieros de software de Google, y hay una importante superposición entre los grupos, ya que muchos contribuyen tanto. Seguimos las tendencias con el tiempo: A medida que aumenta la adopción de Rust, ¿cambian las métricas de forma constante, acelerando el ritmo o volviendo a la media? Aumento: A medida que aumenta la adopción de Rust, ¿cambian las métricas de forma constante, acelerando el ritmo o volviendo a la media? El proceso de revisión de código es una parte costosa y de alta latencia del proceso de desarrollo. La reescritura del código es una fuente principal de estos retrasos. Los datos muestran que el código de Rust requiere menos revisiones. Esta tendencia ha sido constante desde 2023. Los cambios de Rust de tamaño similar requieren aproximadamente un 20% menos de revisiones que sus contrapartes en C++. Además, los cambios de Rust actualmente pasan aproximadamente un 25% menos de tiempo en la revisión de código en comparación con C++. Especulamos que el cambio significativo en favor de Rust entre 2023 y 2024 se debe a una mayor experiencia de Rust en el equipo de Android. Si bien menos reescrituras y revisiones de código más rápidas ofrecen mejoras modestas de la productividad, las mejoras más significativas son en la estabilidad y la calidad de los cambios. Estabilidad: La estabilidad y la calidad de los cambios son distintivas de Rust. DORA utiliza la tasa de reversión para evaluar la estabilidad del cambio. La tasa de reversión de Rust es muy baja y continúa disminuyendo, incluso a medida que su adopción en Android supera a la de C++. Para los cambios de tamaño medio y grande en Android, la tasa de reversión de los cambios de Rust es ~4 veces menor que la de C++. Esta baja tasa de reversión no solo indica estabilidad, sino que también mejora el rendimiento general del desarrollo. Las reversiones interrumpen mucho la productividad, introduciendo fricción organizacional y movilizando recursos mucho más allá del desarrollador que presentó el cambio defectuoso. Las reversiones requieren reescritura y más revisiones de código, también pueden provocar repeticiones de compilación, postmortems y bloqueo de otros equipos. Los postmortems resultantes a menudo introducen nuevas medidas de seguridad que agregan aún más una sobrecarga de desarrollo. En una encuesta autodeclarada de 2022, los ingenieros de software de Google informaron que Rust es más fácil de revisar y es más probable que sea correcto. Los datos concretos sobre las tasas de reversión y los tiempos de revisión validan estas impresiones. Poniéndolo todo junto Históricamente, nos teníamos que conformar con una compensación: mitigar los riesgos de las vulnerabilidades de seguridad de memoria requería importantes inversiones en análisis estático, mitigaciones de tiempo de ejecución, sandboxing y parches reactivos. Este enfoque intentaba avanzar rápidamente y luego arreglar el desastre. Estas protecciones de capa eran esenciales, pero tenían un alto coste en el rendimiento y la productividad de los desarrolladores, sin ofrecer una garantía adecuada. Si bien C y C++ persistirán, y que las medidas de seguridad tanto del software como del hardware son críticas para la defensa en profundidad, la transición a Rust es un enfoque diferente en el que el camino más seguro también es más eficiente. En lugar de avanzar rápidamente y luego arreglarlo, podemos avanzar más rápido arreglando las cosas. Y, ¿quién sabe, a medida que nuestro código se vuelve cada vez más seguro, ¿podemos comenzar a recuperar aún más de ese rendimiento y productividad que intercambiamos por la seguridad, todo ello al mismo tiempo que mejoramos la seguridad? Reconocimientos: Gracias a las siguientes personas por sus contribuciones a esta publicación: Ivan Lozano por la elaboración del postmortem detallado sobre CVE-2025-48530. Chris Ferris por validar los hallazgos del postmortem y mejorar el manejo de los errores de Scudo como resultado. Dmytro Hrybenko por liderar el esfuerzo para desarrollar la formación para el uso inseguro de Rust y por proporcionar comentarios extensos sobre esta publicación. Alex Rebert y Lars Bergstrom por sus sugerencias valiosas y comentarios extensos sobre esta publicación. Peter Slatala, Matthew Riley y Marshall Pierce por proporcionar información sobre algunos de los lugares donde se está utilizando Rust en las aplicaciones de Google. Finalmente, un gran agradecimiento al Android Rust team y a toda la organización Android por su compromiso implacable con la excelencia de la ingeniería y la mejora continua. Notas: El programa DevOps Research and Assessment (DORA) es publicado por Google Cloud.