Centro de operaciones de ciberseguridad y sistemas electorales del INEEl marco DevSecOps busca que la seguridad se valide durante todo el ciclo de vida de los sistemas del INE.

La Junta General Ejecutiva del Instituto Nacional Electoral (INE) aprobó en su sesión extraordinaria del 14 de septiembre de 2026, en Ciudad de México, los lineamientos para integrar desarrollo, seguridad y operaciones —conocido como DevSecOps— en los sistemas y servicios tecnológicos del organismo. En la misma agenda se incluyó la primera modificación al proyecto G090310, destinado a fortalecer la resiliencia tecnológica y operativa del instituto durante 2026.

La decisión importa porque convierte la ciberseguridad en una obligación transversal del ciclo de vida de los sistemas: desde la planeación y el diseño hasta las pruebas, el despliegue, la operación y la mejora continua. Para el INE, esto alcanza una dimensión institucional y pública: sus plataformas procesan información personal, soportan servicios electorales y deben mantener disponibilidad aun frente a fallas técnicas, intentos de intrusión o interrupciones operativas.

En breve

  • El marco DevSecOps será obligatorio para los proyectos y plataformas que cumplan criterios de criticidad, exposición o manejo de información sensible.
  • Los flujos de desarrollo deberán incorporar análisis automáticos de código, dependencias, aplicaciones, contenedores, secretos e infraestructura.
  • El proyecto de resiliencia G090310 quedó con un presupuesto modificado de 235 millones 90 mil 477 pesos; el ajuste libera recursos de los capítulos 2000 a 6000 para ampliar servicios personales especializados.

Qué sistemas quedan dentro del alcance

Los lineamientos no plantean aplicar exactamente el mismo nivel de control a cada sistema. La incorporación será gradual y proporcional, de acuerdo con el riesgo, la exposición, la criticidad y la capacidad presupuestal del INE. Sin embargo, establecen criterios objetivos para identificar los activos que deberán someterse al marco.

La cobertura incluye sistemas que soporten procesos sustantivos, electorales o misionales; plataformas que almacenen, procesen o transmitan datos personales o información reservada; servicios expuestos a redes públicas o dirigidos a la ciudadanía; nuevos desarrollos y mantenimientos evolutivos mayores; así como soluciones que utilicen integración y despliegue continuos.

El Grupo de Gobierno de Tecnologías de la Información y Comunicaciones deberá mantener actualizado el catálogo de sistemas, proyectos y plataformas vinculados. La Unidad Técnica de Servicios de Informática (UTSI), a través de la Dirección de Operaciones, tendrá la responsabilidad de coordinar la implementación y resolver criterios técnicos de aplicación.

Este punto será relevante para proveedores y áreas internas. El texto alcanza tanto los desarrollos realizados directamente por el instituto como aquellos elaborados en colaboración con terceros. En la práctica, una contratación tecnológica deberá demostrar no sólo funcionalidad y precio, sino también capacidad para entregar código trazable, evidencias de pruebas, inventarios de componentes y controles compatibles con los procesos institucionales.

Controles que deberán pasar antes de producción

El marco fija una condición concreta: ningún cambio debería llegar a producción sin pasar por validaciones de seguridad automáticas y trazables. Entre los controles previstos están el análisis estático de código, las pruebas dinámicas de aplicaciones, el análisis de componentes de terceros, la detección de secretos, el escaneo de contenedores y la revisión de infraestructura como código.

Las vulnerabilidades clasificadas como críticas, altas o medias deberán corregirse antes de promover una aplicación a ambientes de integración o producción, salvo que exista una excepción formalmente autorizada. Las fallas de severidad baja no bloquearán necesariamente el despliegue, pero tendrán que registrarse como deuda técnica y contar con un plan de remediación.

El documento también contempla la firma digital de artefactos, el uso de imágenes base confiables, el control de acceso basado en roles, el principio de mínimo privilegio y, cuando resulte posible, un modelo de confianza cero. Para los componentes de software, cada entrega deberá generar un inventario SBOM en formatos estándar como CycloneDX o SPDX.

En materia de datos, los elementos personales, claves y tokens deberán cifrarse o enmascararse. Los secretos no podrán almacenarse en texto plano dentro de archivos de configuración. Los registros de eventos de seguridad, accesos, errores y despliegues deberán centralizarse: el marco prevé 90 días de almacenamiento en línea y al menos un año en almacenamiento frío para fines de auditoría y respuesta a incidentes.

Cómo se medirá la resiliencia tecnológica

La aprobación de DevSecOps se acompaña de una modificación al proyecto G090310, cuyo objetivo es que el INE pueda anticipar, resistir, responder y recuperarse de incidentes de ciberseguridad y fallas tecnológicas que afecten sus activos o servicios.

El proyecto se organiza en cinco componentes: operación de ciberseguridad; monitoreo y respuesta a amenazas; resiliencia e infraestructura crítica; gobernanza y cumplimiento; y servicios especializados bajo demanda. El acuerdo describe un modelo de servicios administrados con monitoreo permanente, inteligencia de amenazas, gestión proactiva de riesgos y supervisión de proveedores.

El presupuesto aprobado para el proyecto era de 235 millones 94 mil 824 pesos. La modificación reduce 788 mil 823 pesos de los capítulos 2000 a 6000 y amplía en 784 mil 476 pesos el capítulo 1000, con lo que el monto modificado queda en 235 millones 90 mil 477 pesos. El movimiento no eleva el presupuesto total del proyecto: se cubre con ahorros internos.

La reasignación permitirá ampliar hasta el 31 de diciembre de 2026 la vigencia de tres plazas de Ingeniero Especialista en Seguridad Informática A6, originalmente contempladas para actividades del segundo semestre. El acuerdo señala que no se crean nuevas plazas, sino que se restituye el periodo de contratación de personal ya previsto para seguimiento de servicios administrados, revisión de entregables, gestión de vulnerabilidades y supervisión de actividades de resiliencia.

El reto será demostrar que el marco funciona

La norma ofrece una arquitectura de control, pero su valor dependerá de la evidencia que produzca. Los lineamientos establecen que la UTSI deberá coordinar la verificación y reportar resultados al Grupo de Gobierno de TIC. También prevén revisiones al menos anuales, además de evaluaciones extraordinarias después de incidentes relevantes, cambios tecnológicos o modificaciones normativas.

Entre los indicadores posibles aparecen métricas DORA, como frecuencia de despliegue, tiempo de entrega, tasa de fallos y tiempo medio de recuperación. A ellas se suman cobertura de pruebas, número de vulnerabilidades, defectos de software y cumplimiento de niveles de servicio.

Para la confianza pública, la pregunta no será únicamente si el INE cuenta con herramientas de ciberseguridad, sino si puede acreditar que esas herramientas se aplicaron antes de cada liberación, quién autorizó una excepción, cuánto tardó en corregirse una vulnerabilidad y si un incidente alteró la disponibilidad o integridad de un servicio.

El siguiente paso será hacer verificables esas respuestas. El INE deberá precisar el catálogo de sistemas sujetos al marco, los requisitos técnicos que trasladará a sus proveedores, los niveles de servicio exigibles y la forma en que publicará —sin comprometer información sensible— los resultados agregados de sus revisiones. Ahí se definirá si DevSecOps se convierte en una práctica de gobierno tecnológico o queda sólo como un documento administrativo.

Fuentes consultadas

Por Editor

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *