Más allá de la Prohibición: Implementación Segura de CMS y Cumplimiento con la LFPDPPP.

El comunicado de la Secretaria Anticorrupción y Buen Gobierno respecto al uso de plantillas de código abierto el día 12 de Enero de 2026, abre un espacio de análisis sobre las prácticas de desarrollo y despliegue seguro que realizan  las empresas, instituciones y personas físicas que procesan datos personales en sistemas con estas facilidades.

El comunicado se centró técnicamente en las plataformas CMS (Content Management System) en especial las que son de código abierto, pero es importante entender a qué plataformas se refiere. De primera instancia los CMS son sistemas de cómputo que sirven como herramienta para crear, modificar, organizar contenido digital para que puedan ser publicadas en páginas web, ejemplo de estos sistemas son WordPress, Drupal, Wifi, Shopify, entre otros.

Ahora, lo que respecta a código abierto no es lo mismo que licenciamiento, ni gratuitas, ni de bajo costo (esto lo mencionó porque ya vi artículos con esta comparación) el código abierto puede estar Licenciado y también hay código abierto de paga y de varios precios, a lo que se refiere específicamente el código abierto es a que se tiene disponible el código para que se puede modificar siempre que se cumplan con las reglas de licenciamiento como puede ser GPL o cualquier otro al que el software esté adherido.

Ya con la claridad de a qué software se refiere el comunicado es de suma importancia aclarar que el comunicado está orientado a un concepto completo que es las “complementos y plantillas genéricas”, en este sentido es necesario entender que muchas de las aplicaciones CMS crean un espacio para el desarrollo de productos o servicios para integrar, ya sea por el mismo fabricante del CMS o por terceras personas herramientas que cumplen con objetivos específicos, como por ejemplo, formularios de contacto, plantillas de venta en línea, promociones de cursos, entre muchas otras actividades.

Estos componentes o plantillas se desarrollan a través de un marco de trabajo (Framework) del CMS que establece un conjunto de librerías y/o códigos que de alguna forma han sido probadas y aseguradas por la comunidad que mantiene el CMS, lo que ayuda a que en términos de seguridad y riesgo tengan una mejor perspectiva de seguridad si son adquiridas a través de canales oficiales del fabricante del CMS, lo que apoya a las empresas que no tienen recursos humanos suficientes para acoplar este tipo de desarrollo robustos.

Si bien, también los CMS históricamente han tenido algunas vulnerabilidades críticas, el hecho de que haya grandes comunidades de desarrolladores y usuarios de estas plataformas, ayuda a que estas vulnerabilidades se puedan superar de forma relativamente rápida, lo que abre una contrapostura, los CMS de forma general no son totalmente inseguros y estos al integrar componentes y plantillas comúnmente tienen un marco normativo para seguridad en el desarrollo de los mismos para evitar perder credibilidad ante la comunidad consumidora de este tipo de software.

Con este planteamiento, la perspectiva de la ciudadanía no debería estar enfocada en dejar de utilizar los CMS con sus componentes y plantillas sino que se debe enfocar la estrategia de uso en una perspectiva de reducción de riesgo en el uso, ya que el despliegue y uso de estas herramientas en materia de seguridad dependen de múltiples factores más allá del fabricante, como puede ser la infraestructura tecnológica, el método de despliegue y publicación, la seguridad del desarrollo en la implementación, la confiabilidad de las fuentes de descarga, entre muchos otros aspectos.

Es por ello que antes de implementar CMS o un componente o plantilla y antes de publicar contenido a través de estos elementos se tengan en consideración los siguientes puntos:

  1. Enfoque en el control no en la Prohibición: El uso de un CMS no es inseguro por definición. La estrategia debe centrarse en gestionar el riesgo mediante controles técnicos y administrativos, en lugar de prohibir su adopción
  2. Privilegiar Canales Oficiales: Al adquirir plantillas o complementos (plugins), se deben utilizar exclusivamente los repositorios oficiales del fabricante. Estos componentes han sido probados y asegurados por la comunidad, reduciendo la probabilidad de código malicioso o vulnerabilidades conocidas.
  3. Claridad en el Licenciamiento: Es vital distinguir que «Código Abierto» no significa gratuito. Desde una óptica legal, se debe verificar que el software cumpla con licencias como GPL para evitar infracciones de propiedad intelectual o riesgos de cumplimiento
  4. Verificación de Frameworks Seguros: Se debe asegurar que los complementos estén desarrollados sobre el marco de trabajo estándar del CMS. Esto garantiza que utilicen librerías de seguridad ya validadas por expertos.
  5. Seguridad de la Infraestructura Subyacente: La protección de los datos personales no depende solo del CMS, sino de la infraestructura donde se hospeda. Se debe exigir el endurecimiento (hardening) del servidor y la base de datos.
  6. Debida Diligencia de Fuentes: Antes de la descarga, se debe auditar la reputación del desarrollador tercero y la frecuencia de sus actualizaciones. Un componente sin soporte activo es una negligencia de seguridad
  7. Protección de Datos Personales por Diseño: Dado que el CMS procesa datos personales y personales  sensibles, su configuración debe cumplir con la Ley Federal de Protección de Datos Personales (LFPDPPP), incluyendo cifrado y avisos de privacidad claros.
  8. Protocolos de Despliegue Seguro: La publicación del CMS debe seguir métodos que eviten la exposición de archivos de configuración críticos (como .php o bases de datos) a usuarios no autorizados.
  9. Mantenimiento y Parcheado Proactivo: Se debe establecer normativamente un calendario de actualizaciones. La rapidez de la comunidad para corregir fallos es una ventaja sólo si el administrador aplica los parches de inmediato.
  10. Trazabilidad y Evidencia Digital: El sistema debe registrar quién accede y qué cambios realiza. En caso de una investigación por vulneración de datos, estos registros son la prueba principal de que la empresa actuó con la debida diligencia
  11. Ciclo de Vida de Desarrollo Seguro (S-SDLC) Universal: (Recomendación Clave) El hecho de que el código sea abierto no exime de cumplir con estándares de desarrollo seguro. Cualquier personalización o integración de un CMS debe pasar por las mismas fases de análisis de vulnerabilidades y pruebas que un desarrollo hecho desde cero (in-house).
  12. Prohibición de Software Nulled: El uso de versiones piratas de componentes premium anula cualquier defensa legal ante una brecha. Estos archivos suelen contener malware diseñado para exfiltrar datos de forma silenciosa.

En conclusión, el comunicado debería servir como punto de partida de  revisión de las prácticas de uso de las tecnologías en la infraestructura que procesan datos personales y con ello generar una mayor inclusión segura de los Responsables de procesamiento de datos.

  • Imagen generada con IA