Qué exige la ISO 27001 sobre el desarrollo seguro

La empresa desarrollaba software de conciliación para instituciones financieras y llegó a su auditoría de certificación con la política de contraseñas, los respaldos, el antivirus y el inventario de activos en orden. El auditor pidió entonces que le explicaran, con un cambio real, cómo llegaba una modificación del código desde la computadora del programador hasta producción. El programador mostró que hacía la prueba en su equipo, con una copia de la base de datos de un cliente, y que él mismo subía el cambio al servidor. No había revisión de código, no había pruebas de seguridad y la copia de datos reales seguía en su laptop.

Qué es el desarrollo seguro

El desarrollo seguro es el conjunto de prácticas que hace que la seguridad se construya dentro del software desde que se definen sus requisitos, y no que se revise al final con un escaneo antes de salir. Parte de una idea simple: casi todas las vulnerabilidades que terminan en un incidente se introdujeron al escribir el código o al diseñar la arquitectura, y corregirlas en producción cuesta mucho más que evitarlas.

La ISO 27001 lo trata en los controles tecnológicos de su Anexo A. En la versión 2022, el bloque que va del control 8.25 al 8.33 cubre el ciclo de vida del desarrollo seguro, los requisitos de seguridad de las aplicaciones, los principios de arquitectura segura, la codificación segura, las pruebas de seguridad, el desarrollo subcontratado, la separación de ambientes, la gestión de cambios y la información que se usa para pruebas. Se complementa con el control 8.4, que pide restringir el acceso al código fuente.

Qué controles aplican

• —Ciclo de vida de desarrollo seguro: reglas definidas para desarrollar software y sistemas, aplicadas en todas las fases.
• —Requisitos de seguridad de la aplicación: identificarlos y aprobarlos al especificar, no descubrirlos después.
• —Arquitectura segura: principios documentados de diseño, como mínimo privilegio, defensa en profundidad o validación de entradas.
• —Codificación segura: prácticas y herramientas para evitar vulnerabilidades conocidas, incluido el control de librerías de terceros.
• —Pruebas de seguridad: pruebas definidas dentro del desarrollo y como criterio de aceptación antes de liberar.
• —Desarrollo subcontratado: dirigir, supervisar y revisar lo que hace un tercero con los mismos criterios.
• —Separación de ambientes: desarrollo, pruebas y producción separados y protegidos.
• —Gestión de cambios: los cambios a sistemas y aplicaciones siguen un procedimiento controlado.
• —Información de prueba: los datos para probar se seleccionan, protegen y controlan; los datos reales se enmascaran o se autorizan.

La declaración de aplicabilidad decide cuáles de estos controles aplican. Una empresa que no desarrolla software y solo configura aplicaciones comerciales puede justificar la exclusión de varios. Una empresa cuyo producto es el software difícilmente puede excluir alguno, y el auditor lo va a revisar con evidencia de proyectos reales, no con la política.

Qué evidencia busca el auditor

La evidencia del desarrollo seguro vive en las herramientas de desarrollo, no en carpetas. El auditor suele pedir un cambio reciente y seguirlo de punta a punta: el requerimiento con sus criterios de seguridad, la rama del repositorio, la revisión de código hecha por alguien distinto al autor, los resultados del análisis estático o de dependencias, las pruebas ejecutadas, la aprobación para pasar a producción y quién hizo el despliegue. Si el proceso está automatizado en una línea de integración y despliegue continuos, esa misma línea es la mejor evidencia, siempre que no se pueda saltar.

Revisa también quién tiene acceso de escritura al repositorio y a producción, cómo se manejan los secretos como llaves y contraseñas de bases de datos, qué pasa con las librerías de código abierto que tienen vulnerabilidades publicadas y cómo se controla lo que entrega un proveedor externo de desarrollo. El control de código de terceros se volvió central: una buena parte del código de cualquier aplicación moderna no lo escribió el equipo, y la vulnerabilidad de una dependencia es una vulnerabilidad del producto.

Errores frecuentes

• —Probar con copias de datos reales de clientes sin enmascarar ni autorizar.
• —Permitir que el mismo programador escriba, apruebe y despliegue su propio cambio.
• —Guardar contraseñas y llaves de acceso dentro del código fuente.
• —No tener inventario de librerías de terceros ni revisar sus vulnerabilidades.
• —Hacer una prueba de penetración al año y considerarla el único control de seguridad del desarrollo.
• —Contratar desarrollo externo sin requisitos de seguridad en el contrato ni revisión de lo entregado.
• —Dar a los desarrolladores acceso permanente a producción para resolver incidentes.
• —Escribir una política de desarrollo seguro que no coincide con cómo trabaja el equipo.

Dónde se rompe en la operación

El desarrollo seguro se rompe cuando la presión de entrega le gana al proceso. Una corrección urgente se sube directo a producción, un proveedor externo entrega un módulo que nadie revisa, un desarrollador nuevo se incorpora sin conocer las reglas y la política queda como un documento que solo lee el auditor. En la Ciudad de México, donde se concentran empresas de software, fintech, servicios financieros y proveedores de tecnología para corporativos y gobierno, los clientes piden cada vez más evidencia de cómo se construye lo que compran, no solo un certificado. Integrar el ciclo de desarrollo con el control de cambios, la gestión de proveedores y el tratamiento de no conformidades es parte de lo que se estructura en la Consultoría ISO 9001 en Ciudad de México, donde el sistema de gestión se monta sobre las herramientas que el equipo ya usa y no en paralelo a ellas.

En resumen

La ISO 27001 trata el desarrollo seguro en los controles 8.25 a 8.33 de su Anexo A, más el control 8.4 sobre el acceso al código fuente. Pide reglas para todo el ciclo de desarrollo, requisitos de seguridad desde la especificación, arquitectura y codificación seguras, pruebas de seguridad como criterio de aceptación, control del desarrollo subcontratado, ambientes separados, gestión de cambios y protección de los datos de prueba. La evidencia está en el repositorio, en las revisiones de código y en la línea de despliegue, y el auditor la busca siguiendo un cambio real.