Han sido unas semanas muy duras. El portátil de un desarrollador provocó el mayor robo de la historia de las criptomonedas en Binance. LiteLLM volvió a ser víctima de un ataque de «poisoning» en PyPI. PHP2Shell y Node2Shell afectaron a PHP y Node.js, que juntos gestionan una gran parte de la web. Y no nos olvidemos de eMudhra y de las claves privadas que se pudieron recuperar en cuestión de segundos.
Estos incidentes se basaron en técnicas conocidas y con muy poca sofisticación. Sin embargo, los atacantes actuaron con rapidez, y el margen de tiempo entre la divulgación y la explotación se está reduciendo rápidamente. En el caso de algunas vulnerabilidades, ya se ha agotado.
Los equipos deben partir de la premisa de que, en algún momento, un ordenador portátil, un proveedor, un paquete o un ejecutor de CI de su entorno se verá comprometido. Una vez que eso ocurra, el daño dependerá de hasta dónde pueda llegar el atacante a partir de ahí.
A continuación te presentamos seis medidas que te recomendamos para mantenerte a salvo hasta finales de 2026.
Haz que las credenciales robadas no sirvan para nada
Hemos visto el gran daño que pueden causar las credenciales robadas en manos de los atacantes, por lo que es fundamental limitar el alcance del daño una vez que una credencial queda expuesta. La mayoría de los equipos no han previsto el escenario en el que sus credenciales sean realmente robadas. Partir de la hipótesis de que acabarán expuestas facilita la implantación de los controles compensatorios adecuados.
En la práctica, eso significa:
- Utiliza tokens de corta duración o acceso «justo a tiempo» (JIT), de modo que un servicio o una persona solo tenga acceso a un secreto durante el tiempo que requiera la tarea. Si esa credencial se ve comprometida, ya estará a punto de caducar o habrá caducado.
- Mantén los ámbitos de acceso restringidos. Si un servicio solo necesita acceso de lectura, no le concedas también acceso de escritura.
- Establece la autenticación de tres factores como norma en todas las herramientas. Activa la autenticación de dos factores (2FA) siempre que sea posible. Por ejemplo, exige la autenticación de dos factores en GitHub y añade restricciones de IP.
- Revisa tus aplicaciones para detectar cualquier clave API y token que se haya emitido. Evalúa para qué se están utilizando. Asegúrate de comprender su ámbito de aplicación. Revoca aquellos que no sean necesarios o aprovecha la revisión para trazar un plan de rotación de credenciales.
Protege el código que no has escrito tú
PHP2Shell dejó dolorosamente claro el gran riesgo que entraña el código que se hereda. Las imágenes base y las bibliotecas de código abierto vienen con su propio bagaje, al igual que los entornos de ejecución subyacentes. Te conviertes en responsable de todo ello en el momento en que entra a formar parte de tu entorno. No puedes evitar heredar código, pero sí puedes elegir qué heredas y cómo.
En la práctica:
- Empieza con imágenes de contenedor mínimas. Estas incluyen muchos menos paquetes que las imágenes estándar, lo que se traduce, por defecto, en una superficie de ataque más reducida y un menor número de CVE.
- Combina imágenes mínimas con un proveedor de imágenes de contenedores reforzadas, de modo que cualquier CVE que surja se solucione rápidamente.
- Crea bifurcaciones o réplicas de las bibliotecas internamente y utilízalas desde tu propio repositorio.
- Utiliza bibliotecas «hardened» para las dependencias que hayan llegado al final de su ciclo de vida, o siempre que necesites un soporte ampliado durante el ciclo de vida con correcciones de seguridad retroaplicadas.
- Averigua qué productos han dejado de comercializarse revisando tu inventario en busca de versiones que ya no reciban mantenimiento.
- Utiliza análisis de composición de software (SCA) para realizar un seguimiento de todas las dependencias de código abierto, incluidas las transitivas, y para notificar y corregir las vulnerabilidades que detecte.
- Aplica los parches cuando se hagan públicas las vulnerabilidades críticas. Ahora, los ataques aprovechan estas vulnerabilidades a los pocos días de su divulgación.
Elimina los proveedores que no necesites
La proliferación de proveedores es una realidad, y cada proveedor que incorporas a tu organización supone un riesgo si no se gestiona adecuadamente. ¿Ese complemento de GitHub que instalaste el año pasado y que solo has utilizado una vez? Eso es un riesgo. Lo mismo ocurre con la dependencia de npm que instalaste para un proyecto del que ya te has alejado. Se consideran proveedores todos aquellos cuyo código o servicios se ejecutan dentro de tu entorno, desde las empresas a las que pagas hasta los mantenedores de software de código abierto.
En la práctica:
- Crea un inventario bien gestionado de todas las aplicaciones, complementos, integraciones y servicios de tu entorno.
- Elimina a los proveedores externos siempre que sea posible. En el caso de los que mantengas, replica o redirige sus servicios a través de tu propio repositorio de artefactos.
- Limita al mínimo las extensiones y los complementos del IDE.
- Enumera todas las autorizaciones OAuth, aplicaciones de GitHub, tokens de acceso personales e integraciones SaaS conectadas, y revoca aquellas que no utilices.
- Evalúa cada proveedor antes de incorporarlo. Pregunta quién se encarga de su mantenimiento y qué permisos de acceso necesita, y comprueba si alguna de las herramientas que ya utilizas realiza la misma función.
- Excluir a los proveedores externos tan pronto como finalice un proyecto o expire un contrato.
- Incluye en tu plan de respuesta ante incidentes situaciones hipotéticas de violaciones de seguridad de proveedores y ponlas a prueba. Imagina que uno de tus proveedores sufre una violación de seguridad y analiza cómo reaccionaría tu equipo.
Desconecta lo que no necesite estar conectado
PHP2Shell demostró que los equipos deben justificar cada servicio que mantienen en línea y averiguar rápidamente qué servicios se están ejecutando en su entorno.
Ese servidor web olvidado de 2019, el que «solo se suponía que iba a estar en funcionamiento para algunos trabajos de desarrollo internos», es precisamente el tipo de recurso informático sin parches al que apuntan los atacantes. A menudo, los equipos no se enteran de su existencia hasta que ya es demasiado tarde.
En la práctica:
- Revisa tu patrimonio, incluyendo tu superficie de ataque externa, y elabora un inventario de todos los servicios y sistemas en funcionamiento.
- Analiza detenidamente esa lista y prepárate para justificar por qué se incluye cada elemento.
- Haz que los recursos sean responsables asignando a cada uno de ellos un titular y una finalidad. Etiqueta también los entornos y haz que se respete el etiquetado mediante una política.
- Mantén los sistemas fuera de la red pública de Internet, a menos que sea necesario que estén allí. Configura las herramientas internas detrás de una VPN o de un sistema de acceso «zero-trust».
- Ensaya bien el proceso de aplicación de parches para estar preparado cuando se publiquen avisos críticos.
- Utiliza programaciones de apagado automático para que los recursos informáticos solo estén activos cuando sea necesario. Un clúster de Kubernetes de desarrollo que solo utilices los martes puede permanecer apagado el resto de la semana, lo que además te permitirá reducir la factura.
Controlar qué se ejecuta en los equipos de los usuarios
Los ataques de malware contra dispositivos están aumentando, y en una sola semana Aikido bloqueó casi 500 de ellos. Los equipos de los desarrolladores son un objetivo muy atractivo, ya que contienen credenciales y permiten el acceso a sistemas que, en ocasiones, son críticos. En las secciones anteriores se explica cómo limitar lo que pueden hacer esas credenciales, y controlar lo que realmente se ejecuta en los equipos de los desarrolladores reduce aún más la superficie de ataque. La brecha de seguridad de Vercel de este año también nos ha demostrado cómo una sola extensión del navegador puede provocar un incidente.
En la práctica, eso significa:
- Realizar una auditoría de los equipos de los usuarios y elaborar un inventario del software instalado y sus versiones, incluyendo extensiones de navegador, extensiones de IDE, servidores MCP y herramientas de IA.
- Bloquea la instalación de nuevos complementos y extensiones hasta que hayan sido aprobados.
- Mantén una lista de permitidos para que la gente no tenga que esperar a que se aprueben los más habituales.
- Establecer una antigüedad mínima para los paquetes o un periodo de espera. La mayoría de los paquetes maliciosos se detectan en unas pocas horas, por lo que un periodo de espera reduce el riesgo de instalar una versión maliciosa.
- No guardes secretos en el disco. Los programas de robo de información buscan primero tokens en texto plano en los archivos .env y en el historial del shell. Los gestores de secretos y los tokens de corta duración son tus aliados en este caso.
Ataca primero a ti mismo
«Comprueba todo antes de que sea demasiado tarde» es un consejo de seguridad muy acertado. Realiza pruebas de penetración en tu red y automatiza las pruebas de simulación de ataques en todos los servicios que gestionas, para que puedas detectar las vulnerabilidades antes de que lo haga otra persona.
Arreglar una fuga antes de que se convierta en una inundación parece obvio, pero ¿lo haces de verdad? Las herramientas automatizadas lo facilitan. En la práctica:
- Implementa herramientas de gestión de servicios de seguridad ( gestión de la superficie de ataque , ASM) en todo tu entorno para saber qué elementos están expuestos, incluidos aquellos que habías olvidado que tenías.
- Realiza pruebas de penetración en la red externa de forma periódica, no solo una vez.
- Realiza pruebas de forma continua en las aplicaciones que se lanzan con frecuencia, en lugar de considerar las pruebas como una tarea que hay que marcar en una lista una vez al año.
- Simula una intrusión mediante ejercicios de simulación y comprueba a qué podría acceder realmente un atacante desde un equipo comprometido o un ejecutor de CI.
Lista de comprobación completa
Prepara a tu equipo paso a paso.
Esta semana
- Busca en los equipos de los desarrolladores credenciales de la nube, claves SSH, tokens de API y archivos .env.
- Establece una antigüedad mínima de 48 horas para todos los gestores de paquetes que utilices, incluidos npm y PyPI.
- Empieza a bloquear el malware desde el momento de la instalación con Aikido Safe Chain.
- Comprueba qué se puede acceder desde Internet y retira de la red todo aquello que no sea necesario que esté ahí.
Este mes
- Traslada los secretos de producción de los ordenadores portátiles a un gestor de secretos y renueva las credenciales que hayas encontrado en los equipos de los desarrolladores.
- Revisa las dependencias y elimina aquellas que no se utilicen o que no se mantengan.
- Crea un inventario de proveedores que incluya tus aplicaciones, complementos, dependencias y servicios, y asigna un responsable a cada uno de ellos.
- Configurar horarios de apagado automático para los recursos informáticos que no sean de producción.
- Retira los derechos de administrador local en los equipos de los usuarios siempre que sea posible.
- Ejecuta « análisis de código con IA » en el código expuesto a Internet y en el código que gestiona la autenticación o los pagos.
- Almacena el proveedor de identidad, las auditorías en la nube, el control de código fuente y los registros de CI en un lugar donde las credenciales de producción no puedan eliminarlos.
- Establece un plazo para la corrección de las vulnerabilidades críticas expuestas a Internet, medido en horas o días.
Antes de que termine 2026
- Implementa « gestión de la superficie de ataque » en todo tu entorno.
- Realiza una prueba de penetración de la red externa y reserva la siguiente para 2027.
- Realiza simulacros que partan de la hipótesis de una brecha de seguridad provocada por un proveedor comprometido, el ordenador portátil de un desarrollador, un ejecutor de CI o un paquete.
- Realiza una revisión de fin de año de todos tus proveedores y del inventario de servicios, de modo que cada artículo tenga un responsable de cara a 2027.
Para más información, consulta las prácticas recomendadas de «seguridad de la cadena de suministro de software ».
Conclusión
Seguirán apareciendo nuevas vulnerabilidades CVE y paquetes comprometidos hasta finales de año y mucho más allá. Da por hecho que te verás afectado en algún momento y asegúrate de estar en la mejor posición posible cuando eso ocurra. Los equipos que limitan el alcance de un único incidente de seguridad podrán contener el próximo incidente más rápidamente que aquellos que se basan en bloquear todos los puntos de entrada.
Si quieres tener una visión más amplia, lee «PHP2Shell», pasado mañana.
