Riesgo de terceros en DORA: gobernanza de los SDK móviles
Gestione el riesgo de terceros de DORA en las aplicaciones móviles con inventarios y diferencias de SDK por versión, reglas de aprobación y prohibición, SLA de aplicación de parches y paquetes de evidencias listos para auditoría.
Si ha seguido esta serie, ya dispone de:
- Un alcance que define su superficie de riesgo móvil (Artículo 1: Understanding DORA Compliance for Mobile Teams)
- Controles a nivel de versión que producen un veredicto claro por compilación (Artículo 2: DORA Compliance for Mobile Releases)
- Evidencias de resiliencia vinculadas a modos de fallo móviles reales (Artículo 3: DORA Mobile Resilience Drills)
El área que queda es el riesgo de terceros.
Las aplicaciones móviles se distribuyen con SDK integrados y dependen de proveedores externos en tiempo de ejecución. Con DORA, esa exposición sigue siendo responsabilidad suya y debe gobernarse a nivel de versión. A menudo se pasa por alto en los programas móviles, porque el «riesgo de proveedores» se trata como papeleo en lugar de como algo que aterriza directamente en el binario y en el recorrido del cliente.
1) Por qué es diferente el riesgo de terceros en móvil
Estructuralmente, una aplicación móvil es un artefacto empaquetado, similar a una imagen de Docker o a un WAR de Java. Se agrupa el código propio con bibliotecas de terceros y se distribuye una versión concreta. Esa parte no es exclusiva.
Lo exclusivo es lo que ocurre después de distribuirla. Los equipos de backend suelen poder aplicar parches y volver a desplegar de forma centralizada en una infraestructura que operan. Los equipos móviles distribuyen a través de las tiendas de aplicaciones hacia los dispositivos de los clientes, y la adopción de parches depende del procesamiento de la tienda, de las decisiones de despliegue, de las limitaciones de los dispositivos y de las actualizaciones de los usuarios. Eso significa que las versiones antiguas siguen activas en circulación, a menudo durante semanas o más.
Hay dos tipos de riesgo distintos que debe gobernar.
SDK integrados
Se distribuyen dentro del binario y se ejecutan con los privilegios de la aplicación. Cuando un SDK tiene una vulnerabilidad, un problema de política o un cambio incompatible, la corrección va ligada a una versión. Se corrige distribuyendo una nueva versión de la aplicación y esperando a que se adopte. El resultado práctico es una exposición prolongada a través de varias versiones de la aplicación en ejecución simultánea.
Proveedores en tiempo de ejecución
Servicios externos como identidad, OTP, notificaciones push, antifraude y pagos pueden degradarse, fallar parcialmente o comportarse de forma distinta según el entorno. Esa inestabilidad se manifiesta directamente en recorridos móviles críticos sobre dispositivos y redes reales. Cuando falla, los clientes lo ven de inmediato.
La implicación para la gobernanza es simple y estricta. El riesgo de terceros en móvil debe estar acotado a cada versión, ser relevante en tiempo de ejecución y basarse en evidencias.
2) Modelo de gobernanza de SDK (acotado por versión)
El objetivo es controlar qué código de terceros puede incluirse en cada versión, de una forma que pueda demostrarse más adelante. El modelo empieza con un inventario, luego hace visible el cambio y después adjunta registros de decisión para que el veredicto de la versión sea defendible.
Empiece con un inventario de SDK por versión. Trátelo como una línea base, no como un informe puntual: para cada registro de versión, debería poder mostrar el nombre del SDK, la versión exacta, la fuente u origen, el papel funcional y (cuando disponga de ella) una nota o clasificación de riesgo. Este inventario se convierte en el ancla para las aprobaciones, las prohibiciones, los SLA de parches y la recuperación en auditoría.
A continuación, exija una diferencia por versión. Para cada nueva versión, debería poder decir qué SDK se añadieron, qué versiones cambiaron y qué se eliminó, en comparación con la versión aprobada anterior. Esto es lo que convierte «creemos que no cambió nada» en «podemos mostrar qué cambió».
Una vez que puede ver el cambio, puede controlarlo. Defina reglas de aprobación para que los SDK nuevos y las actualizaciones mayores requieran una decisión de revisión explícita, mientras que las actualizaciones rutinarias de parches puedan seguir un camino más ligero siempre que se mantengan dentro de su política de versiones aprobadas. Además, mantenga una lista de prohibidos para SDK obsoletos, versiones vulnerables o proveedores no conformes, de modo que los riesgos conocidos no puedan volver a entrar en la aplicación por una deriva de dependencias.
Por último, defina SLA de parches alineados con su política de riesgo y mida el tiempo de aplicación de parches por cada vulnerabilidad de SDK. La clave no es la perfección; la clave es que, cuando se retrasa un parche, pueda mostrar una decisión con plazo limitado en lugar de un backlog descontrolado.
| Campo | Descripción |
|---|---|
| Nombre del SDK | Nombre de la biblioteca o del proveedor |
| Versión | Versión exacta incluida en la compilación |
| Fuente | Proveedor, repositorio u origen |
| Función | Analítica, autenticación, pagos, etc. |
| Nota de riesgo | Riesgo conocido, clasificación o justificación |
3) Evidencias de tipo SBOM para móvil
DORA no exige un SBOM perfecto para móvil. Exige una visibilidad de las dependencias que sea específica de cada versión, defendible y vinculada a la gobernanza operativa.
Un SBOM mínimo viable para móvil es el inventario de SDK (nombre + versión) de esa versión, más las referencias de dependencias que pueda proporcionar su herramienta de compilación, más el contexto de vulnerabilidades vinculado a esa versión exacta. El requisito es que esté acotado a la versión y vinculado al registro de la versión, de modo que pueda responder «¿qué dependencias había en la versión X?» sin reconstruirlo a partir del control de código fuente, de registros antiguos de CI o del conocimiento tácito.
4) Controles a nivel de versión
Para hacer operativa la gobernanza de terceros, exprésela como controles de versión que produzcan resultados claros. No se trata de crear más documentación; se trata de producir un veredicto de versión que siga siendo válido ante el escrutinio.
Un mínimo práctico es asegurarse de que cada versión tenga un inventario de SDK, una diferencia de SDK respecto a la versión anterior, una aprobación o excepción explícita para los SDK nuevos y las actualizaciones mayores, y una comprobación de que no hay SDK ni versiones prohibidos. Cada versión debería mostrar también una postura de vulnerabilidades que esté dentro del SLA o cubierta por una excepción con plazo limitado. Del lado del tiempo de ejecución, la versión debería enlazar con un mapa de dependencias de proveedores para los recorridos críticos y hacer referencia a las decisiones de degradación y de alternativa definidas para esos recorridos.
Si ya dispone de un pipeline de veredictos del Artículo 2: DORA Compliance for Mobile Releases, estos se convierten en las entradas de terceros de ese mismo veredicto. El registro de la versión sigue siendo el único lugar donde residen la decisión y los enlaces a las evidencias.
5) Paquetes de evidencias listos para auditoría (por versión)
En este punto, las evidencias convergen a nivel de versión. Un paquete de evidencias no es «todo lo que tiene»; es el conjunto mínimo de artefactos que explican por qué la versión era aceptable cuando se desplegó.
Un paquete de evidencias de versión debería incluir:
- Identidad de la versión (ID de la aplicación, versión, referencia de compilación, huella del artefacto)
- Inventario y diferencia de SDK
- Aprobaciones y excepciones
- Mapa de proveedores por recorrido crítico
- Definiciones de degradación y de alternativa
- Resultados de los controles del Artículo 2: DORA Compliance for Mobile Releases
- Evidencias de resiliencia del Artículo 3: DORA Mobile Resilience Drills
La diferencia entre «tenemos evidencias» y «estamos listos para una auditoría» es la recuperación, así que mantenga un índice sencillo organizado por versión que apunte al contenido del paquete.
Para evitar que las excepciones se conviertan en brechas, estandarice un registro de excepciones. Debe identificar el alcance (SDK o proveedor), la versión o versiones afectadas, la justificación, el responsable de riesgo, los controles compensatorios, una fecha de caducidad o revisión y la marca de tiempo de la aprobación. Esto transforma «no pudimos aplicar el parche» en «tomamos una decisión con plazo limitado, con responsable y con controles».
La retención resulta entonces sencilla: conserve el registro de la versión, el paquete de evidencias y el índice conforme a sus políticas internas y regulatorias. La propiedad importante es que las evidencias permanezcan acotadas a la versión, indexadas y recuperables a demanda.
6) Informes para la dirección (enfoque de tendencias)
A nivel directivo, el objetivo es la visibilidad de las tendencias, no volver a litigar cada versión. Tres métricas suelen funcionar bien. La antigüedad de las excepciones muestra si las decisiones de riesgo se revisan o se vuelven permanentes. El tiempo de aplicación de parches de las vulnerabilidades de SDK muestra si su cadena de suministro móvil responde con agilidad. La tasa de cambio de SDK por versión muestra la rotación de dependencias, que se correlaciona fuertemente con la carga de revisión y con el riesgo sorpresa.
Empiece poco a poco y luego amplíe
Implemente de forma progresiva sin romper el tren de versiones. Empiece con el inventario de SDK y las diferencias por versión, porque la visibilidad genera palanca. Luego añada aprobaciones para los SDK nuevos y las actualizaciones mayores, seguidas de la aplicación de la lista de prohibidos y del seguimiento de los SLA de parches con excepciones de plazo limitado.
Una vez estable la gobernanza de SDK, mapee las dependencias de proveedores por recorrido crítico y documente las decisiones de alternativa. Por último, formalice un índice de paquetes de evidencias y su retención para que la recuperación sea rutinaria en lugar de un proyecto especial.