La brecha de seguridad de GitHub: tus herramientas de mayor confianza ahora son el vector de ataque.

La mañana del 19 de mayo, un ingeniero de GitHub abrió su portátil y una extensión de VS Code que había instalado meses atrás se actualizó automáticamente en segundo plano. En cuestión de minutos, un código malicioso comenzó a leer las credenciales de la memoria y a enviarlas a un atacante. En pocas horas, ese atacante ya estaba dentro de la infraestructura de GitHub, clonando repositorios internos con las credenciales del desarrollador. Al final, aproximadamente 3,800 de esos repositorios se pusieron a la venta en un foro criminal por un grupo que se hacía llamar TeamPCP.

La divulgación de GitHub fue ejemplar: rápida, mesurada y controlada. No se vieron afectados los datos de los clientes ni la producción. Sin embargo, si formas parte de un equipo de GRC, esto debería resultar inquietante. El punto de entrada no fue una vulnerabilidad de día cero ni una campaña de phishing. Se trató, en cambio, de una popular herramienta para desarrolladores, de un proveedor verificado, que hacía exactamente lo que se suponía que debía hacer.

La ventana de once minutos

GitHub es una de las organizaciones de ingeniería con mayor madurez en seguridad del mundo. Por lo tanto, la pregunta no es qué se les escapó, sino qué objetivo tenía el ataque y para qué no estaban diseñados sus controles.

En el centro se encontraba una extensión: Nx Console. Contaba con 2.2 millones de instalaciones, una insignia de editor verificado y un largo historial de mantenimiento. Por lo tanto, el atacante no logró vulnerar el Marketplace. En cambio, robó las credenciales de un mantenedor tras una vulneración previa en la rama principal, las utilizó para publicar una versión maliciosa bajo el nombre del editor legítimo y esperó a que se actualizara automáticamente.

La versión infectada estuvo disponible entre once y dieciocho minutos antes de que los responsables de Nx detectaran la publicación anómala y la retiraran. Microsoft informó inicialmente de 28 instalaciones. Sin embargo, la telemetría de Nx reveló posteriormente que la cifra real superaba las 6,000. Y una de esas instalaciones se produjo en el ordenador de un desarrollador de GitHub.

En el momento en que el desarrollador abría un espacio de trabajo, el código malicioso recopilaba las credenciales de sesión, las claves SSH y los secretos de la nube, y luego los extraía.

¿Por qué los marcos de trabajo estándar no detectaron esto?

Todos los marcos de control convencionales ya exigen lo que GitHub tenía. SOC 2 exige controles de acceso y protección de endpoints. ISO 27001 abarca el desarrollo seguro y la gestión de proveedores. Y NIST 800-53 cubre la gestión de la configuración y el riesgo de la cadena de suministro. Por lo tanto, es casi seguro que GitHub tenía informes limpios en todos ellos.

Por lo tanto, el problema no radica en que los marcos de trabajo sean erróneos, sino en que se basaron en un modelo de confianza que los atacantes han aprendido a invertir. Y la primera suposición que se rompe es que los dispositivos de los desarrolladores son equipos corporativos comunes. No lo son.

El ordenador de un desarrollador almacena sesiones activas en la nube, claves SSH, credenciales de Git, secretos de variables de entorno, tokens de CI/CD y claves API para asistentes de codificación de IA. Por lo tanto, un solo portátil comprometido se convierte en un llavero para todo lo que se encuentra en la cadena de suministro. Sin embargo, la mayoría de los esquemas de clasificación de activos aún sitúan estos puntos finales en el mismo nivel que el Outlook de un gerente financiero. Esta discrepancia es donde reside la brecha de gobernanza, y solucionarla es un problema de GRC antes que un problema de seguridad.

Un nuevo extremo de la cadena de confianza está bajo ataque.

GitHub no destaca en esta historia. Más bien, existe una tendencia más amplia, y GitHub es simplemente la organización más visible en este momento.

La cadena de suministro de software siempre ha estado marcada por una cadena de confianza. En otras palabras, un desarrollador confía en una extensión, la extensión confía en un mantenedor, el mantenedor confía en un registro, y el registro confía en una credencial de editor almacenada en una variable de entorno en el ordenador de otra persona. Por lo tanto, cada eslabón presupone que el que está detrás está intacto.

En los últimos meses, TeamPCP ha lanzado ataques a gran escala contra la confianza de los desarrolladores, ocultando malware en más de 500 paquetes de código abierto a lo largo de aproximadamente 20 oleadas. OpenAI, Mercor y Mistral AI son víctimas confirmadas. Pero la lista de filtraciones no reveladas es mucho mayor.

Por lo tanto, el modus operandi de TeamPCP consiste en atacar la cadena completa en lugar de un enlace individual. La vulnerabilidad de Nx Console comenzó con un token de mantenedor obtenido de una vulnerabilidad anterior de TanStack. Y ahí radica toda la estrategia. La extensión Nx Console ya estaba aprobada, instalada y presente en el entorno de desarrollo integrado (IDE) del programador con permiso para ejecutarse.

Así pues, el atacante no tuvo que superar nada de eso. Simplemente tuvo que vulnerar aquello en lo que el desarrollador ya confiaba, y esa confianza hizo el resto del trabajo por él.

¿Qué significa esto para la próxima revisión de proveedores?

Si lo que está en juego es la cadena de confianza, entonces la pregunta práctica es qué eslabones de su propia cadena se encuentran actualmente fuera de su perímetro de gobernanza.

Empiece por el registro de riesgos de terceros, la lista de proveedores externos que su organización gestiona formalmente. La mayoría incluye a Salesforce, AWS y a cualquier empresa con la que tengan un contrato. Sin embargo, no incluyen las pequeñas herramientas de desarrollo que sus ingenieros instalan, las bibliotecas de código público de las que dependen dichas herramientas ni a los responsables de su mantenimiento. Ninguna pasa por un proceso de adquisición. Y, sin embargo, todas ejecutan código en máquinas que contienen claves de producción. Por lo tanto, deben ser gestionadas como proveedores, al menos en lo que respecta a credenciales o procesos de compilación. El responsable del mantenimiento de Nx cuyo token fue robado no tenía contrato con GitHub. Pero, en la práctica, era un proveedor para todas las empresas que utilizaban su extensión.

A continuación, el punto final del desarrollador controla las reglas sobre lo que se le permite hacer al portátil de un desarrollador. ¿Pueden los ingenieros instalar cualquier extensión que deseen o solo un conjunto aprobado? ¿Se instala una nueva versión de forma silenciosa? Y cuando ocurre algo sospechoso en ese portátil, ¿lo monitorizan las herramientas de seguridad con la misma rigurosidad que a un servidor de producción? En la mayoría de las empresas, la respuesta a las tres preguntas es no. Por lo tanto, los portátiles que contienen las credenciales más poderosas están sujetos a una gestión menos estricta que los servidores a los que esas credenciales dan acceso.

Luego están las credenciales, las claves y los tokens que demuestran que un sistema está autorizado a actuar. La mayoría tienen una vida útil demasiado larga y circulan con demasiada facilidad. Un token emitido para una computadora portátil puede permanecer allí durante meses, y si la computadora se ve comprometida, el atacante hereda todo lo que puede hacer. Por lo tanto, la solución es acortar la vida útil y limitar el alcance: tokens que caduquen en horas, sistemas que obtengan credenciales nuevas en cada ejecución y claves almacenadas en hardware seguro en el dispositivo. Nada de esto es novedoso. Pero todo esto requiere que alguien lidere la migración, y ahí es donde la conversación se estanca.

GitHub es una de las organizaciones de ingeniería con mayor madurez en seguridad del mundo, y aun así el atacante logró infiltrarse. Por lo tanto, el siguiente en la lista no contará con la capacidad de detección, la velocidad de respuesta ni la disciplina de comunicación de GitHub. La superficie de confianza que TeamPCP está industrializando se sitúa casi por completo fuera del alcance de la gobernanza convencional. Esa es la brecha, y se está reduciendo.