Cumplimiento de DORA para equipos móviles: alcance y qué debe hacer

Introducción a la serie sobre cumplimiento de DORA:

El reglamento DORA plantea una pregunta legítima para los equipos móviles: ¿qué significa esto realmente para la entrega de aplicaciones iOS y Android?

Esta es una serie de cuatro partes que responde a esa pregunta en términos prácticos. Sin análisis normativos exhaustivos ni teoría. Solo un enfoque cuyo punto de partida es el entorno móvil para el cumplimiento de DORA, que funciona para los equipos móviles y de AppSec, y para los responsables que los dirigen.

• Artículo 1: Comprender el alcance y lo que realmente debe hacer (usted está aquí)
• Artículo 2: El modelo más sencillo de línea base, veredicto y excepciones para las versiones móviles
• Artículo 3: La biblioteca más sencilla de simulacros de resiliencia para los recorridos móviles BFSI
• Artículo 4: Riesgo de terceros, gobernanza de SDK y paquetes de evidencias listos para auditoría
  
  

---

Si usted desarrolla o protege una aplicación móvil de banca, servicios financieros y seguros (BFSI), ya conoce la parte «divertida» en la que el cumplimiento se encuentra con la ingeniería moderna. Su aplicación es a la vez un producto, un límite de seguridad, un imán de solicitudes de soporte y un acumulador de dependencias.

Entra entonces en escena el reglamento DORA, seguido de cerca por la expresión cumplimiento de DORA, normalmente entregada con una fecha límite y una hoja de cálculo.

Este artículo es una guía centrada en el entorno móvil para mantener las cosas en un plano práctico. Definiremos un alcance móvil estricto, aplicaremos DORA al contexto móvil y llegaremos a un modelo operativo sencillo que sirva tanto a los equipos móviles como a quienes toman las decisiones.

Lo mantendremos todo anclado a aquello a lo que los equipos móviles siempre se remiten: la versión publicada.

Entonces, ¿por qué resulta tan doloroso en primer lugar?

Por qué DORA resulta doloroso para los equipos móviles y de AppSec

DORA suele resultar doloroso porque llega como un problema con forma de cumplimiento, pero el trabajo móvil tiene forma de versión publicada. Los equipos móviles piensan en versiones de la aplicación, números de compilación, planes de despliegue, recorridos críticos y guías de respuesta a incidentes. Las solicitudes de cumplimiento suelen aparecer como «demuestre X», sin aclarar qué significa X para iOS y Android.

También se complica porque el riesgo móvil rara vez reside solo en el código móvil. Un recorrido móvil puede fallar por los servicios de identidad, los retrasos de las OTP, la entrega de notificaciones push, las API de backend, la detección de fraude, los errores de configuración remota o la caída de un proveedor externo. Cuando un requisito dice «garantice la resiliencia», la primera pregunta de los equipos móviles es: «¿Resiliencia de qué, exactamente, y medida cómo?»

La forma más sencilla de reducir el dolor no es luchar contra DORA. Consiste en traducir el reglamento DORA a un alcance móvil del que usted pueda responsabilizarse y, después, producir evidencias repetibles por versión, de modo que el cumplimiento de DORA se vuelva rutina.

Bien, entonces, ¿qué es DORA en términos sencillos, sin convertir esto en un club de lectura normativa?

DORA en lenguaje claro, traducido a la realidad móvil

A grandes rasgos, el reglamento DORA empuja a las organizaciones hacia dos resultados:

1. Mantener los servicios digitales funcionando de forma segura, incluso durante las interrupciones.
2. Demostrar esa capacidad con evidencias repetibles y verificables.

Para los equipos móviles, los «servicios digitales» son la experiencia móvil de extremo a extremo, no solo el binario de la aplicación. Su aplicación depende de la identidad y la autenticación, las API de backend, las OTP y las notificaciones push, los sistemas de fraude y riesgo, los servicios de pagos y los SDK de terceros incluidos en la aplicación.

Una traducción de DORA centrada en el entorno móvil se ve así:

• La gestión del riesgo de TIC define una línea base de controles de publicación móvil, con responsables claros.
• La preparación ante incidentes exige una evaluación de impacto por versión, plazos y un paquete de evidencias que pueda reunirse sin heroicidades.
• Las pruebas de resiliencia operativa ejecutan simulacros para los recorridos móviles críticos, no solo pruebas puntuales.
• El riesgo de terceros en TIC abarca la gobernanza de los SDK integrados y de los proveedores en tiempo de ejecución que pueden romper recorridos críticos.
• La mejora continua crea un ciclo en el que los incidentes y los simulacros actualizan los controles, la monitorización y los runbooks.

Si hace todo esto de forma constante, no se limita a «hacer papeleo». Está construyendo un modelo operativo móvil que respalda el cumplimiento de DORA.

Defina el «alcance móvil de DORA» en una página (qué entra y qué no)

Tener claro el alcance es la forma más rápida de reducir la rotación en el trabajo de cumplimiento. Este es un alcance estricto y práctico para el trabajo de cumplimiento de DORA que corresponde a los equipos móviles.

Dentro del alcance de los equipos móviles

• Artefactos de publicación móvil que usted distribuye
  IPA de iOS y AAB o APK de Android, vinculados a una versión y un número de compilación concretos.
• Evidencias del proceso de publicación
  Procedencia de la compilación, firma, aprobaciones y un registro de las comprobaciones que se ejecutaron para un candidato a versión.
• SDK y bibliotecas de terceros integrados
  Qué contiene la aplicación, qué ha cambiado desde la versión anterior y quién lo aprobó.
• Dependencias en tiempo de ejecución que afectan a los recorridos móviles críticos
  Identidad y autenticación, API de backend, OTP y push, sistemas de fraude y riesgo, pagos, configuración remota y feature flags.
• Recorridos críticos
  Inicio de sesión, autenticación reforzada (step-up), recuperación de cuentas, pagos y transferencias, además del alta de clientes si su aplicación la incluye.

Ahora que el alcance está claro, podemos formular la pregunta que mantiene DORA en un plano práctico para los equipos móviles.

Una única pregunta a nivel de versión para mantener práctico el cumplimiento de DORA

Para responder a la pregunta ¿esta versión de la aplicación móvil cumple con nuestros controles de seguridad y resiliencia de aplicaciones alineados con DORA?, debe ser:

• Específica: se aplica a una versión y compilación concretas de iOS o Android.
• Repetible: se responde en cada versión, no solo cuando lo pide el área de cumplimiento.
• Accionable: se asocia a comprobaciones y responsables.
• Revisable: el área de riesgos y la dirección pueden evaluar cada vez evidencias con la misma estructura.

Esta pregunta no reduce el reglamento DORA a «solo móvil». Simplemente define lo que los equipos móviles pueden asumir con credibilidad: la garantía a nivel de versión para los artefactos y los recorridos móviles.

Para responder a esa pregunta sin convertir el día de la publicación en un ritual, necesita un modelo operativo mínimo.

El modelo operativo mínimo (registro de versión, veredicto, paquete de evidencias)

Para que la pregunta a nivel de versión pueda responderse, necesita tres componentes básicos. Manténgalos ligeros y automatice con el tiempo.

1) Registro de versión

Es la «ficha de índice» de la versión. Conecta el artefacto, las evidencias y la decisión.

Campos mínimos:

• Identificador de la aplicación (bundle id o nombre del paquete)
• Plataforma (iOS o Android)
• Versión y número de compilación
• Identificador o huella del artefacto (hash o ID único de compilación)
• Referencia al código fuente (repositorio y SHA del commit)
• ID de ejecución del pipeline
• Responsable de la versión y fecha

Si no puede vincular las evidencias a un artefacto concreto, más adelante no podrá demostrar nada de forma fiable. Es algo aburrido, pero del buen tipo de aburrido.

2) Veredicto de la versión

Utilice un modelo de veredicto que se ajuste a la vida real y respalde la gobernanza:

• PASS
• FAIL
• PASS_WITH_EXCEPTIONS

PASS_WITH_EXCEPTIONS es válido cuando está controlado. Eso significa un responsable, una fecha de caducidad, controles compensatorios y un plan de corrección. Si las excepciones nunca caducan, se convierten en la verdadera línea base.

3) Paquete de evidencias

El paquete de evidencias es lo que hace defendible su veredicto y creíble su relato de cumplimiento de DORA.

El paquete debe responder:

• ¿Qué se publicó?
• ¿Qué comprobaciones se ejecutaron y qué encontraron?
• Si había riesgo, ¿cómo se gestionó y quién lo aprobó?

Evidencias mínimas que conservar por versión:

• Procedencia de la compilación y prueba de la firma
• Resultados de las pruebas de seguridad vinculados al artefacto exacto
• Lista de hallazgos con severidad y categoría
• Diferencias respecto a la versión aprobada anterior: qué cambió
• Inventario de SDK de la versión, más lo que cambió desde la versión anterior
• Prueba de que los simulacros de resiliencia y los runbooks están al día para los recorridos críticos
• Aprobaciones de excepciones y fechas de caducidad, si las hay

Para los equipos móviles, la ventaja es que esto se vuelve repetible. Para quienes toman las decisiones, la ventaja es que la revisión se vuelve coherente y auditable.

Si está pensando «esto sigue pareciendo trabajo», es razonable. Definamos cómo se ve lo «bueno» en 30 días para que siga siendo alcanzable.

Trampas habituales que generan trabajo innecesario y la alternativa más sencilla

Trampa 1: «Un escaneo dice que cumplimos con DORA».

Un escaneo es una evidencia valiosa, pero el cumplimiento de DORA es más amplio que cualquier resultado individual.

Alternativa más sencilla: mantenga la afirmación acotada a la versión. Use los escaneos como insumos de evidencia para su veredicto de versión y su paquete de evidencias.

Trampa 2: Ampliar el alcance hasta que el equipo móvil se responsabiliza de todo

Cuando la responsabilidad no está clara, los equipos móviles acaban coordinando a la mitad de la organización.

Alternativa más sencilla: mantenga un alcance móvil estricto. Asuma la responsabilidad de las versiones móviles, los recorridos móviles críticos, la gobernanza de los SDK integrados y las evidencias a nivel de versión. Colabore con los responsables de identidad, plataforma y proveedores para los controles previos.

Trampa 3: Controles que no se pueden evidenciar

Si un control no puede vincularse a un artefacto, informe, ticket o registro, se convierte en un debate recurrente.

Alternativa más sencilla: reescriba los controles hasta que la evidencia sea obvia. Si no puede evidenciarlo, todavía no es un control.

Trampa 4: Excepciones que nunca caducan

Las excepciones permanentes se convierten en riesgo permanente.

Alternativa más sencilla: cada excepción necesita un responsable, una fecha de caducidad, controles compensatorios y un plan de corrección. Haga seguimiento del cumplimiento de las caducidades.

Trampa 5: Probar componentes en lugar de recorridos

Las pruebas de componentes son útiles, pero los clientes viven recorridos.

Alternativa más sencilla: defina los recorridos críticos y ensaye los modos de fallo que los rompen, como la degradación de la identidad, la latencia de las OTP, las interrupciones de las notificaciones push y las caídas de proveedores.

Si se lleva una sola idea de este artículo, que sea esta: DORA no tiene por qué convertirse en un «proyecto de cumplimiento» paralelo que vive fuera de su ciclo de publicación móvil. Cuando mantiene el alcance en lo móvil, convierte la versión publicada en la unidad de gobernanza y genera evidencias a medida que publica, los requisitos del reglamento DORA se vuelven manejables y el cumplimiento de DORA se vuelve repetible.

En el próximo artículo lo haremos aún más concreto. Definiremos una línea base de controles de publicación móvil alineada con DORA sencilla, mostraremos cómo convertirla en veredictos claros PASS, FAIL, PASS_WITH_EXCEPTIONS y compartiremos la forma más fácil de gestionar las excepciones sin ralentizar la entrega.

Dónde encaja Ostorlab en este alcance móvil de DORA

Un escaneo es un insumo de evidencia, no un veredicto de DORA (Trampa 1). Estas son las partes del paquete de evidencias que Ostorlab puede producir para sus versiones móviles, lo que necesita de usted y lo que sigue en manos de su equipo.

Lo que obtiene para el paquete de evidencias.

• Resultados de pruebas de seguridad vinculados a la compilación: resultados de escaneo por compilación y por versión publicada en la tienda, con cada hallazgo calificado como crítico, alto, medio o bajo, y con los hallazgos potenciales por separado. Mobile SAST analiza directamente el APK, el AAB o el IPA, sin necesidad de código fuente, y Mobile DAST ejecuta la aplicación y captura el tráfico, los stack traces y las capturas de pantalla.
• Inventario de SDK por versión: los SDK y las bibliotecas nativas de cada versión, con sus versiones y su ubicación dentro del paquete de la aplicación, asociados a vulnerabilidades conocidas y con seguimiento de una versión a otra.
• Pruebas de los recorridos críticos tras el inicio de sesión: Ostorlab inicia sesión con sus cuentas de prueba, completa los códigos de un solo uso por SMS, correo electrónico o TOTP, y prueba el inicio de sesión, la renovación de tokens, la invalidación de sesiones y la aplicación de MFA, incluidos los flujos de autenticación reforzada (step-up). Un pentest de la aplicación y de sus API realizado por agentes de IA añade un exploit funcional que puede reproducir para cada hallazgo de los agentes de IA.
• Prueba de corrección: los hallazgos se gestionan como tickets en la plataforma o en Jira y ServiceNow, y la nueva prueba tras la corrección confirma si el problema está resuelto.

Lo que necesita.

• El artefacto de la versión (APK, AAB o IPA), o la aplicación desde la tienda o TestFlight.
• Escaneos integrados en su pipeline de CI/CD, de modo que cada compilación se escanee; las ejecuciones programadas del pipeline mantienen una cadencia semanal en las semanas sin versión.
• Cuentas de prueba y entrega de códigos de un solo uso, de modo que se prueben el inicio de sesión, los pagos y los cambios en la cuenta, y no solo la pantalla de inicio de sesión.

Lo que sigue en manos de su equipo. Ostorlab cubre las aplicaciones móviles y las API que hay detrás. El veredicto de la versión, las aprobaciones de excepciones, la clasificación de las funciones de negocio y su programa de pruebas siguen siendo suyos. Ostorlab no realiza pruebas de penetración guiadas por inteligencia de amenazas (TLPT) ni las sustituye: le ayuda a afrontar una TLPT con los problemas conocidos de la aplicación y de las API ya corregidos, y a volver a probar después los elementos de aplicación y API del plan de corrección. Los requisitos que van más allá de la capa de aplicación, como la red, la seguridad física, las copias de seguridad y la gestión de incidentes, siguen correspondiendo a otras herramientas y equipos.

Evidencias.

• Pruebas de resiliencia de DORA para aplicaciones de banca móvil asocia cada requisito de pruebas de DORA con lo que hace Ostorlab y lo que sigue en sus manos.
• El caso de éxito de Bumble muestra una barrera de publicación en la práctica: las versiones se bloquean ante hallazgos High y Critical hasta que se confirma la corrección.
• Para su revisión del riesgo de terceros en TIC: Ostorlab cuenta con un informe SOC 2 Type II (criterios de seguridad), del 18 de noviembre de 2024 al 18 de abril de 2025, y la auditoría del período actual está en curso. Con el plan Enterprise puede elegir la residencia de datos en la UE o ejecutar los escaneos en sus propias instalaciones.

Siguiente paso. Establezca una línea base: escanee cada aplicación dirigida a clientes una vez con un escaneo gratuito desde la tienda y luego reserve una demostración para planificar las pruebas a lo largo de sus versiones.

A continuación: Cumplimiento de DORA para versiones móviles: el modelo más sencillo de línea base, veredicto y excepciones Si usted es responsable de la preparación de las versiones móviles, de las barreras de AppSec o de la aprobación del área de riesgos, esta es la pieza que convierte DORA de «deberíamos hacer algo» en «así es exactamente como gestionamos las versiones».