Asume que te van a comprometer: lo que la brecha de GitHub enseña a cualquiera que desarrolle software

En mayo de 2026, GitHub reveló que un atacante había copiado unos 3.800 de sus repositorios internos. La vía de entrada no fue un exploit sofisticado contra la plataforma de GitHub. Fue el portátil de un solo empleado y, en él, una versión manipulada de una extensión popular para el editor Visual Studio Code. La versión envenenada estuvo disponible en el marketplace solo unos minutos antes de ser retirada, y bastó. GitHub no encontró indicios de que los repositorios de clientes se hubieran visto afectados.

La lección es una que muchos equipos preferirían no oír: si desarrollas software, en algún momento formarás parte de una brecha. No por descuido, sino porque la ingeniería moderna funciona sobre capas de herramientas, extensiones y dependencias que nadie controla por completo.

Asume que te van a comprometer, minimiza el impacto

La prevención sigue importando, y en ella invertimos. Pero un diseño que solo funciona mientras nada entra es un diseño que falla el peor día. Nosotros partimos de la premisa contraria: alguien va a entrar, así que asegúrate de que se vaya sin nada de valor estratégico. En la práctica, eso se reduce a cuatro hábitos.

• Lógica central detrás de interfaces. Las reglas y los algoritmos propios no están en un repositorio como código fuente legible. Viven detrás de servicios, interfaces o módulos privados, de modo que un repositorio copiado muestra cómo se conectan las cosas, no cómo funcionan.
• Nada sensible en el código. Ni secretos, ni endpoints internos, ni configuración que dibuje el mapa de la infraestructura. Los secretos viven en un almacén de claves y los recupera una identidad en tiempo de ejecución; nunca se pegan en un archivo.
• Abstracción deliberada. El código se escribe para que sea claro para quienes trabajan en él y revele lo menos posible a quien no debería estar leyéndolo.
• Público por defecto. Cada repositorio se escribe como si pudiera quedar expuesto mañana. Si un archivo sería un problema en la portada de un medio de comunicación, no pertenece al repositorio.

El puesto de trabajo es el perímetro

El caso de GitHub también muestra dónde está hoy el verdadero perímetro: en la máquina del desarrollador. El editor, sus extensiones y las herramientas de línea de comandos de esa máquina se ejecutan con los accesos del desarrollador. Eso exige la misma disciplina que cualquier otra parte del entorno: una lista corta de extensiones aprobadas, dispositivos administrados y actualizados, inicios de sesión vinculados a un dispositivo administrado y accesos acotados a la tarea, en lugar de a todo lo que un desarrollador pudiera necesitar algún día.

Resiliencia, no paranoia

La seguridad no consiste solo en mantener fuera a los atacantes. Consiste en asegurarse de que, cuando algo ocurra, el daño sea pequeño, esté contenido y se revierta rápido. La brecha de GitHub no será el último titular de este tipo. Cuánto te cueste a ti se decide decisión de diseño a decisión de diseño, mucho antes del incidente.

Gestionamos así nuestros propios repositorios, y ayudamos a los equipos a adoptar los mismos hábitos: secretos en un almacén de claves, dispositivos de desarrollo administrados, una lista corta de extensiones de editor aprobadas y una revisión en cada cambio.

Descubre lo que ofrecemos en ciberseguridad y cumplimiento normativo y formación de equipos.