Una oleada de ataques contra sistemas basados en software de codigo abierto ha tenido en vilo a los equipos de ciberseguridad de las empresas. GitHub, adquirida por Microsoft en 2018 , se ha visto involucrada y le cuesta quitarse de encima un sanbenito del que creía estar a salvo. En verdad, siempre ha habido un punto de tensión entre los desarrolladores y la compradora. La promesa de independencia operativa, palabra de Satya Nadella, tuvo como consecuencia un período en el que la mano derecha fingía no saber lo que hacía la izquierda, pero la suma de incidentes recientes dejan poco margen para entornar los ojos o mirar a otro lado. ¿Una crisis? No es para tanto. ¿Un contratiempo? No es para menos.
Esta primera semana de junio, Microsoft ha avisado de la disponibilidad de actualizaciones para 200 agujeros de seguridad identificados en Windows y en software soportado por este sistema operativo, una cifra récord para una compañía que ha instituido hace mucho un cíclico Patch Tuesday como exorcismo. Al menos tres docenas de esos fallos han merecido de la compañía el calificativo de “críticos” y explotan vulnerabilidades que se han conocido sólo gracias al anuncio. Microsoft ha posteado en un blog que sus ingenieros “y nuestra comunidad de seguridad” han utilizado herramientas de inteligencia artificial para localizar ese malware. Algo que cualquiera vería normal tiempo atrás pero, desde que empezó a hablarse del modelo Mythos, de Anthropic , está siendo tratado con especial severidad.
Los paquetes comprometidos, se ha informado, incluyen herramientas que estaban disponibles públicamente con la finalidad de que los desarrolladores los integren en sus proyectos. Pero, ay, los ciberdelincuentes pudieron activar falsas actualizaciones desde cuentas oficiales de Microsoft en GitHub, introduciendo código avanzado para el robo de credenciales. Obviamente, Microsoft actuó con presteza para retirarlos de la plataforma mientras procedía a una investigación interna. Pero queda un malestar.
La particularidad de estas actualizaciones maliciosas, según han publicado estos días los medios especializados en ciberseguridad, es que no se ejecutan al instalar el paquete sino que el código se activa con abrir la carpeta del repositorio en herramientas de desarrollo o en agentes de IA de programación, como Claude Code, Gemini CLI o Cursor. Es una fórmula más difícil de impedir, porque las actualizaciones tienen apariencia legítima a ojos de los sistemas de ciberseguridad convencionales.
Los gestores de paquetes, las plataformas que usan los desarrolladores para descargar y gestionar las bibliotecas de software, como npm para JavaScript o PyPl para Python, no detectaban la ejecución del malware: sus defensas están preparadas para proteger el momento clave de la instalación del software, pero en este caso el ataque se activaba sólo con abrir la carpeta en un editor de código. Así, estos controles quedaban invalidados. Y hay que tener en cuenta que las herramientas de programación de IA, a las que el malware tenía acceso de forma inmediata, contienen una enorme cantidad de información sensible.
El malware, bautizado Miasma [consúltese el DRAE y se entenderá el por qué] tenía otra originalidad perniciosa. Genera una carga útil (la parte activa del código que ejecuta el daño, como el robo de contraseñas) única y cifrada para cada usuario infectado. De esta manera, los métodos tradicionales de indicadores de compromiso (IOC) basados en hash no funcionaban, ya que la firma cambiaba con cada ataque. El regate de los hackers se completa con la burla de la verificación criptográfica y la SLSA (el
marco de trabajo de seguridad pensado para garantizar la integridad del software a lo largo de toda la cadena de suministro), pues se usaron credenciales legítimas de Microsoft para firmar el malware.
El agujero de seguridad afectó a las Azure Functions, herramientas para ejecutar código sin servidor. El gusano Miasma tenía sistemas de recolección de datos específicamente diseñados para identidades en la nube de Google Cloud Platform y Azure. Rastreaba cualquier identidad cloud a la que la máquina del desarrollador o los entornos de ejecución tuvieran acceso.
La gravedad del asunto se impone por un factor acumulativo. El incidente es el segundo en apenas tres semanas que afecta a la cadena de suministro del software de Microsoft, usando una cuenta oficial. A mediados de mayo, la firma especializada en proteger la cadena de suministro de software StepSecurity detectó que el paquete durabletask en PyPl, el SDK de Microsoft para Python, destinado a interactuar con el motor de orquestación de Azure Durable Task Scheduler, había sido comprometido. Este paquete, que consiste en un framework para administrar flujos de trabajo tolerantes a fallos, estaba disponible en la misma cuenta oficial de Microsoft que se utilizó para distribuir el malware mencionado. No hay explicación oficial, lo que ha derivado en acusaciones de la comunidad de desarrolladores, muy revueltas en los últimos tiempos, ya se verá por qué. Señalan que las credenciales de la cuenta oficial no se cambiaron totalmente tras el primer incidente en mayo; o conjeturan que un paquete desconocido se ejecutara en la máquina de un desarrollador de Microsoft y las credenciales volvieran a robarse.
El primer caso significaría una negligencia grave por parte de la compañía, pero la segunda hipótesis tampoco la deja bien parada. El paquete durabletask tenía 400.000 descargas mensuales y el mecanismo servía a los ciberdelincuentes para robar credenciales de AWS, Azure, Google, Cloud, Kubernetes, gestores de contraseñas y más de 90 configuraciones de herramientas de desarrolladores.
Todo esto tiene un problema añadido: las expresiones de mala gestión. Ante un incidente de seguridad, las empresas se han acostumbrado a no admitirlo, no hacerlo en su totalidad o hacerlo tarde. Está mal, pero no deja de ser corriente: si Microsoft quiere asegurarse la confianza de los desarrolladores, desde luego no es una política apropiada. Los paquetes de actualizaciones se etiquetaron como maliciosos cuando los sistemas de GitHub los bloquearon en la plataforma. Pero en lugar de reconocer que lo eran, GitHub comunicó que había inhabilitado los paquetes por una “violación en sus términos de servicio” (sic)
El enfado de los desarrolladores viene de que la propia GitHub ha querido quitar hierro al asunto. Si hubiera dicho a las claras que se trataba de archivos maliciosos y que los desarrolladores que habían usado agentes de IA para trabajar con ellos deberían asumir una infección, los afectados habrían podido reaccionar con tiempo. Por su parte, Microsoft tardó cuatro días, desde la primera voz de alarma de los investigadores de ciberseguridad, en admitir la posibilidad de que los paquetes estuvieran infectados.
El recelo lleva años cociéndose. Dicen, siendo educados, que aún existe una neblina de tensión entre los desarrolladores y Microsoft, desde que esta adquirió GitHub. Fue una de las adquisiciones estrella de Satya Nadella, encumbrado cuatro años antes, orientada a atraerse a la comunidad de programadores. La promesa de independencia operativa tranquilizó a estos, pero nunca abandonaron la cautela –las diferencias culturales son una pobre excusa – y en los últimos tiempos esa actitud se ha tornado en suspicacia; en algún caso, en franci descontento. Los repetidos incidentes de seguridad que en los últimos años ha protagonizado Microsoft han erosionado el ambiente. No sólo porque ocurren, sobre todo por haber sido mal gestionados.
Una queja común es que Microsoft no da crédito cuando la alertan sobre una vulnerabilidad y opta por solucionarla casi en secreto, sin admitir su impacto. El descontento ha llegado hasta un punto en que algunos investigadores publican directamente los fallos en lugar de informar a la compañía sobre ellos. Ante este actuar por libre, Microsoft ha amenazado con consecuencias a aquellos que ofrezcan facilidades a los criminales. Y así se ha ganado un plus de animadversión por parte de la comunidad de seguridad. Es sabido que los medios online sobre ciberseguridad son propensos a criticar a Microsoft.
Resulta triste admitir que GitHub afronta un problema de credibilidad. Desde que fue adquirida por Microsoft, los llamados ‘hubbers’, empleados de la plataforma, han expresado su preocupación muchas veces sin sentirse escuchados. En las últimas semanas, aumentaron las caídas, que impactan en el trabajo diario de los desarrolladores. El punto crítico se remonta al pasado verano, cuando dimitió el entonces CEO de GitHub, Thomas Dohmke, al que siguieron varios colaboradores. A la pérdida de un referente con solera se añadió otra circunstancia: nadie lo ha reemplazado ni parece que el puesto esté disponible. Quienes trabajan en esta línea, ahora reportan directamente al equipo CoreAI.
Aparece una circunstancia que engrosa las suspicacias. El equipo CoreAI lo tutela quien fuera jefe de Ingeniería de Meta, Jay Parikh . Reclutado personalmente por Nadella, no parece que Parikh haya caído simpático entre los empleados de su nuevo empleador. Así las cosas y a primera vista, esta situación mostraría una falta de liderazgo claro en la plataforma para desarrolladores open source. Este no es el único problema: la competencia no se intimida por la marca Microsoft. La partida de Dohmke ha sido un golpe duro para los ‘hubbers’: Llevaba en el cargo desde 2021 y había entrado en Microsoft tras venderle su propia startup, que desarrollaba herramientas para desarrolladores con vocación indie.
Desde su salida ha habido una fuga de talento y parte de este ha recalado, casualmente, en una nueva empresa fundada por Dohmke, de nombre Entire, cuyo indisimulado objetivo es competir con GitHub. Si bien la principal preocupación en este momento, ha declarado Parikh, sería la amenaza de herramientas como Cursor o Claude Code. En los comienzos de la carrera por la IA generativa parecía que GitHub Copilot tenía ventaja en programación, pero durante el último año se habría quedado atrás, en opinión de analistas independientes.
En materia de ciberseguridad, no puede negarse que Nadella lo ha intentado todo o casi todo. La posición de Microsoft es confortable, pero en un contexto complicado. En 2021 fichó a Charlie Bell, entonces aclamado directivo de AWS, con el claro objetivo de mejorar su enfoque y obtener resultados tangibles. En 2024, el CEO de Microsoft incluso hizo circular un memorando a toda la plantilla en el que donde indicaba que la seguridad debía priorizarse por encima de todo. Mientras tanto, Bell se afanaba en proteger identidades, eliminar sistemas heredados y reforzar las operaciones, cuestiones sin duda pendientes.
Sin embargo, la explosión de la IA ha llevado las voluntades corporativas hacia otro ángulo. La pregonada prioridad de Nadella por la seguridad de Nadella se ha inclinado hacia el crecimiento. En su momento había que potenciar Microsoft Teams, luego tocó el turno a Azure y, ahora, la prioridad absoluta es asegurar el negocio de la IA generativa. Es muy posible que esta sea una visión sesgada por los descontentos, pero existe.
La así llamada comunidad de desarrolladores, ajena y desinteresada acerca de los ingresos de la matriz, dice estar preocupada por otra cosa: la cadena de suministro del software. Los incidentes recientes suscitan una inquietud desconocida hasta la fecha, pero si se tratara de fallos que permiten a un malware activarse con insólita facilidad, los equipos de seguridad podrían verse obligados a inspeccionar cada paquete manualmente. Desde luego, nadie desea que esto ocurra.
[informe de Pablo G. Bejerano]