La Junta General Ejecutiva del Instituto Nacional Electoral (INE) aprobó el 14 de septiembre de 2026, en una sesión extraordinaria urgente realizada en modalidad virtual desde la Ciudad de México, los lineamientos para integrar desarrollo, seguridad y operaciones —DevSecOps— en sus sistemas y servicios tecnológicos. En la misma agenda se incluyó la primera modificación del proyecto G090310, destinado a fortalecer la resiliencia tecnológica y operativa del instituto. La agenda oficial del INE identifica ambos asuntos como puntos 5.1 y 5.2.
La decisión importa porque cambia el momento en que la seguridad debe entrar al desarrollo tecnológico. En lugar de dejar las revisiones para el final, el marco aprobado plantea que los controles acompañen la planeación, la programación, las pruebas, el despliegue y la operación. Para una autoridad electoral, esa lógica no sólo busca evitar ataques: también pretende reducir fallas, conservar evidencia de cada cambio y sostener servicios institucionales cuando exista una contingencia.
Qué sistemas quedan dentro del marco DevSecOps
Los lineamientos no describen una lista cerrada de plataformas, pero sí fijan criterios para determinar cuáles deben incorporarse. El alcance incluye proyectos, plataformas, componentes y entornos de desarrollo gestionados por el INE que, por su nivel de riesgo o madurez tecnológica, requieran prácticas DevSecOps. La obligación alcanza tanto a desarrollos internos como a soluciones elaboradas en colaboración con terceros.
El documento señala cinco señales de prioridad: 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; y soluciones que ya utilicen integración o despliegue continuos.
El Grupo de Gobierno de Tecnologías de la Información y Comunicaciones deberá mantener actualizado el catálogo de sistemas vinculados. La incorporación será gradual y proporcional al riesgo, la exposición, la criticidad, las capacidades técnicas y el presupuesto disponible. Esto significa que la primera pregunta de seguimiento será qué sistemas aparecen en ese catálogo y con qué criterios se ordena su atención.
Controles obligatorios: del código a la infraestructura
El marco establece controles técnicos mínimos que van más allá de una revisión documental. El flujo de desarrollo deberá incluir análisis estático del código, pruebas dinámicas de seguridad, revisión de dependencias y componentes de terceros, detección de secretos, escaneo de contenedores y análisis de infraestructura como código.
Las vulnerabilidades críticas, altas y medias deberán corregirse antes de que un sistema avance a ambientes de integración o producción, salvo que exista una excepción autorizada y documentada. El flujo deberá bloquear el despliegue cuando encuentre riesgos de esas categorías sin remediar. Las vulnerabilidades bajas no bloquearán automáticamente la liberación, pero tendrán que registrarse como deuda técnica y contar con una ruta de atención.
La política también prohíbe guardar contraseñas, tokens o claves privadas en texto plano. Exige firmar digitalmente artefactos de software, emplear imágenes base confiables, elaborar un inventario de componentes y dependencias mediante un SBOM, aplicar controles de acceso por roles y utilizar el principio de mínimo privilegio. Cuando se procesen datos personales, deberán cifrarse o enmascararse para evitar su exposición innecesaria.
En los despliegues, la regla es que los cambios hacia pruebas, capacitación y producción pasen por pipelines que permitan saber quién autorizó la modificación, qué versión se liberó, cuándo ocurrió y en qué ambiente. Ningún despliegue podrá aprobarse sin un mecanismo probado de reversión inmediata. Para la infraestructura, el INE prevé el uso de herramientas de infraestructura como código y limita los cambios manuales en ambientes productivos a casos excepcionales, documentados y autorizados.
Cómo se medirá el cumplimiento
La Unidad Técnica de Servicios de Informática será responsable de coordinar la verificación. La medición deberá apoyarse en la información generada por la herramienta institucional autorizada para gestionar el ciclo de vida del software, con evidencias disponibles para seguimiento y auditoría.
Entre los indicadores posibles aparecen métricas DORA, como frecuencia de despliegue, tiempo de entrega, tasa de fallos y tiempo medio de recuperación. También podrán utilizarse cobertura de pruebas, número de defectos, vulnerabilidades detectadas, cumplimiento de niveles de servicio y otros indicadores de calidad, seguridad y operación.
La revisión ordinaria deberá realizarse al menos una vez al año. Habrá revisiones extraordinarias después de incidentes relevantes, cambios tecnológicos o normativos significativos, o cuando las solicite el Grupo de Gobierno de TIC. Para acreditar el cumplimiento, las áreas deberán conservar reportes de escaneos, bitácoras de integración y despliegue, métricas, excepciones autorizadas y acciones de remediación.
El plazo de adopción también quedó definido: las unidades responsables tendrán tres meses, contados a partir del día siguiente de la aprobación, para realizar las acciones necesarias hacia la implementación gradual y la adopción plena. La UTSI deberá acompañar técnicamente ese proceso.
Proveedores, presupuesto y resiliencia: los pendientes
Los lineamientos abarcan desarrollos realizados con terceros, pero el documento no presenta por sí mismo una matriz pública de evaluación para proveedores ni detalla cómo se traducirán todos los controles a contratos, licitaciones o acuerdos de nivel de servicio. Esa será una de las áreas que convendrá observar en futuras convocatorias y modificaciones contractuales: si las empresas deberán entregar SBOM, someter su código a pruebas, corregir vulnerabilidades dentro de plazos específicos o conservar evidencia accesible para auditorías.
El segundo punto relacionado con la sesión fue la primera modificación del proyecto G090310, denominado Servicios para fortalecer la resiliencia tecnológica y operativa del INE. En las bases presupuestales de 2026, el proyecto se describe como un modelo con protección perimetral, monitoreo permanente, respuesta a incidentes, gobierno, cumplimiento normativo, análisis especializados y atención técnica bajo demanda. La documentación presupuestal del instituto también señala que su objetivo es prevenir, detectar, contener y recuperar oportunamente ante eventos que afecten la infraestructura.
La documentación jurídica de la modificación indica que la Dirección Ejecutiva de Administración deberá actualizar la Cartera Institucional de Proyectos y realizar las adecuaciones presupuestales derivadas del acuerdo. Sin embargo, la agenda pública consultada no muestra en su página principal el monto final reasignado. Un antecedente de la revisión jurídica incluso identifica una discrepancia entre dos formatos sobre un ahorro de 4 mil 347 pesos y 4 mil 346.71 pesos, lo que vuelve necesario consultar los anexos financieros definitivos antes de afirmar cuánto dinero adicional o reasignado tendrá el proyecto.
El antecedente contractual sí permite dimensionar que no se trata de una iniciativa aislada. La licitación nacional LP-INE-030/2025 para estos servicios fue publicada en octubre de 2025 y contempló protección perimetral, monitoreo, respuesta a incidentes y soporte especializado. En ese proceso, el INE publicó ofertas económicas con diferencias amplias entre participantes, por lo que el seguimiento periodístico deberá distinguir entre presupuesto autorizado, monto contratado, gasto ejercido y recursos modificados durante 2026.
Por qué esto toca la confianza pública
La ciberseguridad electoral no se limita a proteger el día de la votación. También involucra sistemas de registro, fiscalización, comunicación, cómputos, publicación de información, gestión interna y servicios dirigidos a la ciudadanía. Una falla puede afectar la disponibilidad de una plataforma; una alteración no detectada puede comprometer la integridad de datos; y una respuesta sin trazabilidad puede dificultar explicar qué ocurrió.
El valor del modelo DevSecOps estará, por tanto, en su ejecución verificable. La publicación de lineamientos no demuestra por sí sola que un sistema sea invulnerable. Sí crea, en cambio, una base para preguntar si los controles se aplicaron, quién autorizó excepciones, cuánto tardó la corrección de una vulnerabilidad, cuántos despliegues fueron revertidos y si los servicios cumplieron sus niveles de disponibilidad.
Para la audiencia mexicana, esas métricas pueden ser más útiles que una declaración general de blindaje. La confianza en los resultados electorales también depende de que la autoridad pueda explicar cómo protege sus sistemas, cómo mantiene la continuidad operativa y qué evidencia conserva cuando se presenta una falla o un intento de intrusión.
En breve
- El INE aprobó el 14 de septiembre de 2026 lineamientos DevSecOps para integrar desarrollo, seguridad y operación durante todo el ciclo de vida de sus sistemas.
- El marco contempla escaneos automáticos, bloqueo de despliegues con vulnerabilidades críticas, altas o medias, firma de artefactos, SBOM, cifrado, mínimo privilegio y trazabilidad.
- La implementación gradual deberá iniciar con un plazo de tres meses, mientras que la revisión del cumplimiento será anual y podrá adelantarse ante incidentes relevantes.
Fuentes consultadas
- Instituto Nacional Electoral, agenda de la sesión extraordinaria de la Junta General Ejecutiva del 14 de septiembre de 2026.
- Instituto Nacional Electoral, Lineamientos para la gestión integrada de desarrollo, seguridad y operaciones (DevSecOps).
- Instituto Nacional Electoral, Bases Generales del Presupuesto 2026 y descripción del proyecto G090310.
- Canal del Congreso, información sobre la revisión presupuestal y la operación del INE.
- Diario Oficial de la Federación, convocatoria de la licitación para servicios de resiliencia tecnológica y operativa del INE.