Guillem Alsina Gonzàlez
Históricamente, el equipo de revisión del conocido gestor de contenidos analizaba exhaustivamente los nuevos plug-ins antes de su inclusión en el directorio público, pero las posteriores actualizaciones se distribuían de manera continua sin una revisión equivalente. Esta falta de control sistemático entre la creación de una actualización y su llegada a millones de sitios web permitía que un complemento legítimo pudiera introducir código malicioso o vulnerabilidades en versiones posteriores.
Para solventar esta situación, el pasado 5 de junio se implementó un periodo de espera obligatorio de seis horas para todos los lanzamientos de complementos y temas visuales antes de su distribución a través de la interfaz de programación de aplicaciones (API) del sistema. Durante esta ventana de tiempo, diversas herramientas basadas en inteligencia artificial y escáneres de seguridad analizan los cambios en el código para detectar posibles amenazas. Dichos sistemas cruzan sus resultados para asignar una puntuación de riesgo global, buscando mantener una alta precisión y minimizar los falsos positivos.
La eficacia de esta ventana de supervisión quedó demostrada el 28 de julio, cuando se introdujo una puerta trasera o acceso no autorizado en la nueva versión de un complemento utilizado por unos veinte mil portales corporativos. El sistema de análisis automatizado detectó el código malicioso durante el periodo de espera, lo que permitió detener la distribución de la versión comprometida antes de que llegara a los servidores de producción. En aquella ocasión, la descarga del programa fue cancelada apenas veintiséis minutos después de que el equipo de seguridad recibiera la alerta.
Aquel incidente evidenció la necesidad de que las calificaciones de alto riesgo detuvieran la distribución del código de manera inmediata, sin depender de la disponibilidad de un supervisor humano. Como resultado de esta experiencia operativa, WordPress ha puesto en marcha un mecanismo que bloquea automáticamente cualquier actualización que obtenga una puntuación de peligro elevada tras el escaneo.
Este protocolo detiene el lanzamiento independientemente de si la vulnerabilidad es fruto de un ataque intencionado o de un simple error de programación, ya que el algoritmo mide el nivel de riesgo técnico y no la intención del desarrollador.
Cuando una versión queda retenida, los responsables de la herramienta reciben un aviso por correo electrónico con los detalles técnicos del problema detectado. La vía más rápida para desbloquear la situación pasa por solucionar los fallos reportados y publicar una nueva iteración que consiga una puntuación por debajo del límite de peligro establecido.
Aunque los programadores tienen la opción de contactar con el equipo de control si consideran que ha habido un error en el diagnóstico, el elevado volumen de peticiones hace que la publicación de un código corregido sea siempre la alternativa más ágil para restablecer el servicio.
La organización encargada de mantener este entorno continuará recopilando métricas para perfeccionar las comprobaciones automatizadas. La colaboración de los creadores de software, documentando los posibles fallos de detección, será una pieza clave para evolucionar y afinar la fiabilidad de todo el ecosistema de protección.
