Cumplimiento de DORA en las versiones móviles: el modelo más sencillo de línea base, veredicto y excepciones

Si ha leído el primer artículo de esta serie: DORA Compliance for Mobile Teams: Understanding scope and what you need to do, ya tiene los cimientos.

1/ Conoce su alcance móvil y entiende por qué la versión es la unidad natural de gobernanza,

2/ Tiene la pregunta que mantiene práctico el cumplimiento de DORA: ¿Es esta versión de la aplicación móvil conforme con nuestros controles de seguridad y resiliencia de aplicaciones alineados con DORA?

Ahora llega la parte en la que hacemos que esa pregunta pueda responderse de forma repetible y auditable.

Este artículo trata sobre la mecánica del cumplimiento de DORA en las versiones móviles. Definiremos una línea base mínima de controles para móvil, presentaremos un modelo de veredicto sencillo y veremos cómo gestionar las excepciones sin convertir cada versión en una negociación de gobernanza.

Empecemos por el motivo por el que este es un trabajo propio de cada versión y no un trabajo genérico de cumplimiento normativo.

Por qué la versión es la unidad más práctica para el cumplimiento de DORA en móvil

El cumplimiento normativo en móvil es difícil cuando se intenta hacer una afirmación global como «nuestra aplicación cumple DORA». Esa afirmación mezcla en una sola declaración la gobernanza organizativa, la supervisión de terceros, los procesos de incidentes y los controles técnicos, algo casi imposible de demostrar con evidencias de forma limpia desde la perspectiva de un equipo móvil.

La versión es una unidad mejor porque así es como ya se trabaja en móvil. Cada versión de iOS y de Android representa un cambio concreto. El riesgo cambia con ella. Las evidencias pueden recopilarse en el momento de la versión, y no reconstruirse más tarde cuando alguien envía una solicitud de auditoría.

Cuando se trata la versión como la unidad del cumplimiento de DORA, ocurren tres cosas:

• Las evidencias se recopilan de forma natural, como parte de la publicación.
• Las decisiones de riesgo se toman de forma explícita, no se dan por supuestas.
• El relato de cumplimiento es coherente, versión tras versión.

A continuación definiremos una línea base lo bastante pequeña para mantenerla y lo bastante sólida para ser útil.

La línea base de cumplimiento de DORA para las versiones móviles

La forma más sencilla de hacer realidad el cumplimiento de DORA en un equipo móvil es definir una línea base. Una línea base es simplemente una lista de controles que toda versión debe cumplir antes de publicarse. Limítela a un máximo de 10 a 20 controles. Más allá de eso, se convierte en una carga de mantenimiento en lugar de una herramienta de gobernanza.

Un buen control tiene tres propiedades. Es binario o casi binario, es decir, se puede decir que se cumple o no. Está vinculado a una evidencia, es decir, se puede señalar un artefacto, un informe o un ticket. Y tiene un responsable, es decir, alguien que responde cuando falla.

Un recordatorio antes de profundizar. Esta parte puede complicarse si se lo permite. Manténgala sencilla. Si el control no puede demostrarse con evidencias, todavía no es un control.

A continuación se presentan cinco categorías que cubren la mayor parte del terreno del cumplimiento de DORA en un alcance móvil.

1) Integridad y trazabilidad de la versión

Esta categoría responde si usted sabe exactamente qué se publicó y puede demostrarlo más tarde. En la práctica, significa que cada artefacto de la versión está identificado de forma única con una versión, un número de compilación y una huella, y que está firmado y producido por un pipeline aprobado. También significa que sus comprobaciones de seguridad se ejecutan sobre el artefacto exacto del candidato a versión, y no sobre una compilación de desarrollo o una aproximación del entorno de staging, y que existe un registro de procedencia que vincula el artefacto con un commit, un repositorio y una ejecución del pipeline. Por último, se conservan las evidencias de respaldo para poder revisarlas más tarde sin depender de la memoria de nadie.

Esta es la categoría aburrida pero crítica, porque si no se puede identificar el artefacto, nada más es atribuible.

2) Umbrales de vulnerabilidad y exposición

Esta categoría responde a la pregunta: ¿está esta versión dentro de nuestra tolerancia al riesgo definida?

Controles que mantienen a los equipos fuera de problemas:

• Ningún hallazgo crítico en la versión.
• Ningún hallazgo de severidad alta en categorías críticas para móvil, normalmente autenticación y gestión de sesiones, criptografía, almacenamiento de datos sensibles, seguridad del transporte y configuración insegura.
• Ninguna regresión nueva de severidad crítica o alta respecto a la última versión aprobada.
• Existen expectativas de corrección para los hallazgos no bloqueantes, de modo que el riesgo no se acumule en silencio.

La clave aquí es definir los umbrales antes de aplicarlos. «Lo sabremos cuando lo veamos» no es un control.

3) Gobernanza de SDK de terceros

Esta categoría responde a la pregunta: ¿sabemos qué hay en el binario y controlamos cómo cambia?

Controles que hacen manejable el riesgo de los SDK:

• Existe un inventario de SDK para esta versión, con todos los SDK y bibliotecas integrados.
• Existe una comparación (diff) que muestra qué ha cambiado desde la última versión aprobada.
• Los SDK nuevos o las actualizaciones de versión mayor requieren aprobación explícita y un responsable asignado.
• Se bloquea la publicación de clases de SDK prohibidas o de versiones de SDK con vulnerabilidades conocidas.
• Existe un proceso para responder con rapidez a los avisos críticos sobre SDK, con una expectativa definida de aplicación de parches.

El móvil tiene un perfil de riesgo de terceros particular, porque las dependencias se distribuyen dentro de la aplicación. Un SDK puede recopilar datos inesperados, romper un flujo de usuario o introducir una vulnerabilidad sin que cambie nada de su propio código. En esta categoría el cumplimiento de DORA se vuelve muy específico del móvil.

4) Preparación de la resiliencia para los flujos críticos

Esta categoría responde a la pregunta: ¿hemos probado los modos de fallo que más importan a los clientes?

Controles que evitan que la «resiliencia» se quede en vaguedades:

• Se declaran los flujos críticos de la aplicación, como el inicio de sesión, la autenticación reforzada (step-up), la recuperación de cuentas y los pagos.
• Existen mapas de dependencias para cada flujo, que abarcan identidad, OTP y notificaciones push, API, fraude, pagos y configuración remota.
• Existen planes de reversión, kill switches y salvaguardas de feature flags para las funcionalidades de alto riesgo, y se han probado.
• Las evidencias de los simulacros de resiliencia se adjuntan y se vinculan en el registro de la versión.

Esta es la categoría que separa «somos seguros» de «somos resilientes». La seguridad y la resiliencia están relacionadas, pero no son lo mismo.

5) Preparación ante incidentes

Esta categoría responde a si, en caso de que algo vaya mal con esta versión, usted puede responder de forma rápida y limpia. En la práctica, significa que su telemetría admite el análisis por versión, de modo que pueda identificar qué versiones de la aplicación están afectadas y cómo cambia el impacto a medida que se aplican mitigaciones. También significa que dispone de criterios claros de severidad de incidentes para los eventos de seguridad móvil, incluidas las señales de fraude y de apropiación de cuentas, además de una plantilla de paquete de evidencias que pueda completarse rápidamente sin análisis forense manual. Por último, necesita un proceso de registro de decisiones que documente qué se decidió, quién lo decidió y con qué fundamento, de modo que el relato del incidente sea coherente y revisable. La preparación ante incidentes suele ser la última categoría que construyen los equipos, pero es la que más importa cuando algo realmente sale mal.

Una vez que tiene una línea base, también necesita una forma coherente de expresar el resultado de cada revisión de versión.

El modelo de veredicto de versión para el cumplimiento de DORA

Una vez que tiene una línea base, cada candidato a versión debería producir uno de tres resultados.

PASS

Se cumplen todos los controles. Las evidencias están completas y vinculadas al registro de la versión. La versión puede continuar.

FAIL

No se cumplen uno o más controles bloqueantes. La versión no se publica hasta que se resuelvan los bloqueos o se gestionen formalmente mediante una excepción.

PASS_WITH_EXCEPTIONS

La versión cumple la línea base solo porque uno o más controles se eximen mediante una excepción aprobada formalmente. Es un resultado gobernado, no un atajo.

Un modelo de tres estados es más honesto que uno binario. En el móvil de BFSI, a veces hay que publicar para abordar un riesgo de mayor prioridad, y una excepción formal con controles compensatorios es más responsable que fingir que todo está bien.

Las excepciones son el punto en el que los programas o se mantienen disciplinados o se deslizan poco a poco hacia el terreno del «lo corregiremos más adelante».

Cómo gestionar las excepciones sin ralentizarlo todo

Las excepciones tienen mala fama porque suelen ser informales y permanentes. Una excepción bien gobernada es en realidad una herramienta útil. Permite hacer una concesión controlada de forma explícita, en lugar de dejar que el riesgo se acumule en silencio.

Una buena excepción necesita cinco elementos:

• Un ID para poder seguirla a lo largo de las revisiones.
• Un responsable encargado de resolverla.
• Una declaración de riesgo en lenguaje claro que explique cuál es el riesgo y por qué es aceptable por ahora.
• Controles compensatorios que reduzcan el impacto práctico mientras la excepción esté activa.
• Una fecha de caducidad que obligue a un seguimiento. Si no caduca, no es una excepción. Es un cambio de política.

La regla de gobernanza es sencilla. PASS_WITH_EXCEPTIONS solo es válido cuando los cinco elementos están presentes y aprobados por las personas adecuadas, normalmente Seguridad y Riesgos conjuntamente.

Haga seguimiento de las excepciones como una métrica. Si el número de excepciones crece y el cumplimiento de las fechas de caducidad es bajo, su línea base no se está aplicando. Se está eludiendo.

Ahora conectamos esto de nuevo con el registro de la versión, porque eso es lo que hace que las auditorías y las revisiones sean mucho menos penosas.

Los campos mínimos del registro de la versión (para que las auditorías sean fáciles)

El registro de la versión conecta el veredicto con las evidencias y hace que todo el modelo sea auditable. Estos son los campos mínimos que debería incluir todo registro de versión.

Identidad de la versión

• Identificador de la aplicación (bundle id o nombre del paquete)
• Plataforma (iOS o Android)
• Versión y número de compilación
• Huella del artefacto o ID único de compilación
• Referencia de origen (repositorio, SHA del commit, ID de ejecución del pipeline)
• Responsable de la versión

Veredicto

• PASS, FAIL o PASS_WITH_EXCEPTIONS
• Resumen de controles, cuáles se cumplieron y cuáles no
• Lista de bloqueos si es FAIL, ID del hallazgo o de la incidencia, responsable y objetivo de corrección
• Lista de excepciones si es PASS_WITH_EXCEPTIONS, ID de la excepción, control eximido, caducidad y aprobador

Enlaces a las evidencias

• Informe de pruebas de seguridad vinculado al artefacto
• Exportación de hallazgos con severidades y categorías
• Inventario de SDK y su diff
• Evidencias de simulacros y enlaces a runbooks de los flujos críticos
• Registro de aprobaciones y entradas del registro de excepciones

Si dispone de estos campos, un auditor puede revisar más tarde una decisión sobre una versión sin pedir al equipo que reconstruya todo desde cero. Ese es el valor práctico.

Última pieza: el despliegue. El objetivo es que esto se perciba como una publicación normal, no como una nueva ceremonia.

Cómo desplegarlo sin romper el tren de versiones

El mayor error de los equipos es intentar aplicarlo todo a la vez. Eso crea bloqueos, ralentiza las versiones y hace que la línea base se perciba como un obstáculo en lugar de una herramienta.

Un mejor enfoque es empezar con un alcance reducido y ampliarlo.

Empiece con una única barrera estricta

Elija el control más importante y aplíquelo como bloqueante. Una buena primera opción es «ningún hallazgo crítico». Todo lo demás puede medirse, pero sin ser bloqueante durante las primeras versiones.

Añada controles gradualmente

A medida que los equipos se sientan cómodos con el modelo, añada controles de uno en uno o de dos en dos. El objetivo es que la línea base se perciba como una parte normal de la publicación, no como un ejercicio de cumplimiento aparte.

Automatice pronto la recopilación de evidencias

Cuanto antes automatice la generación de evidencias, menos penoso resulta el modelo. Empiece con informes de escaneo vinculados a artefactos, después añada los diffs de SDK y, más adelante, las comprobaciones de simulacros y runbooks.

Haga visibles las excepciones desde el primer día

Aunque al principio use las excepciones rara vez, haga que sean rastreables y tengan un plazo desde el comienzo. Es mucho más difícil añadir gobernanza a las excepciones después de que hayan sido informales durante meses.

Epílogo

Una línea base de controles no necesita ser perfecta para ser útil. Necesita ser coherente, estar respaldada por evidencias y aplicarse. Cuando cada versión de iOS, Android o HarmonyOS produce un veredicto y un paquete de evidencias vinculado, el cumplimiento de DORA deja de ser una carrera trimestral. Pasa a ser un resultado natural de cómo se publica en móvil.

En el próximo artículo pasaremos de los controles de versión a la resiliencia operativa. Veremos la biblioteca de simulacros más sencilla para los flujos móviles de BFSI, qué evidencias debería producir cada simulacro y cómo cerrar el círculo entre los resultados de los simulacros y los controles de las versiones.

Próximamente: Mobile Operational Resilience Under DORA: The simplest drill library for BFSI journeys