La violación de Vercel y por qué no jugamos con secretos «no sensibles»

Nos despertamos con la noticia de que habían atropellado a Vercel. Si estás en el mundo del desarrollo web, es como escuchar que acaban de robar la bóveda principal de un banco. Vercel no es una empresa de aficionados; es la columna vertebral de millones de sitios, incluido el ecosistema Next.js. Pero incluso los gigantes pueden tropezar cuando la comodidad empieza a ganar el tira y afloja contra la seguridad.

La violación no comenzó con un ataque directo a los servidores de Vercel. Comenzó con una herramienta de inteligencia artificial de terceros llamada Context.ai. Un empleado de Vercel la conectó a su Google Workspace mediante OAuth. Los atacantes accedieron a Context.ai, conectaron esa conexión de OAuth a la cuenta de Google del empleado y, desde allí, obtuvieron un mapa del reino interno. Es un pivote clásico de la cadena de suministro y es complicado.

Pero esta es la parte que más nos preocupa en Sweent: los atacantes fueron capaces de leer variables de entorno que no estaban marcadas como «sensibles». Vercel tiene un sistema en el que los desarrolladores pueden elegir si una variable es sensible o no. Si no marcas esa casilla, esos secretos se almacenan de forma que puedan leerse en caso de que un atacante entre en ella. En Sweent, analizamos esa elección de diseño y vemos un riesgo enorme e innecesario. No creemos en dar a los desarrolladores la opción de ser menos seguros por motivos de comodidad.

La falacia del secreto «insensible»

En el panel de control de Vercel, hay una distinción entre variables de entorno sensibles y no sensibles. La idea es que algunas cosas, como una clave de API pública o una cadena de configuración no crítica, no necesiten el cifrado de alto nivel que requiere una contraseña de base de datos. ¿Pero en la práctica? Los desarrolladores están ocupados. El código de envío es a las 2:00 de la mañana. Toman el camino de menor resistencia. Si el valor predeterminado no es «Máxima seguridad», se filtrarán secretos. No se trata de si ocurrirá, sino de cuándo.

Hemos visto que esto ha sucedido en docenas de proyectos antes de que llegaran a nosotros. Un desarrollador cree que un token específico es de «bajo riesgo», por lo que no se preocupa por la capa adicional de protección. Luego se produce una violación y ese token de «bajo riesgo» se convierte en el punto clave para apoderarse por completo del sistema.

En Sweent, nuestro protocolo es sencillo: no existe una variable de entorno que no sea sensible. Si se trata de una variable que se encuentra en un archivo .env o en una canalización de CI/CD, se trata como un secreto crítico. Período. No ofrecemos un botón de «comodidad» que deje las teclas en blanco. Al aplicar una política estricta en la que se cifran y restringen todas las variables, eliminamos el error humano que provocó la filtración de datos en el incidente de Vercel. Si un atacante hubiera conseguido entrar en uno de nuestros entornos durante una violación similar, habría encontrado un muro de datos cifrados que no podría leer, en lugar de una lista de claves «no sensibles» que podría usar para intensificar su ataque.

Combatir con protocolos a los atacantes acelerados por la IA

El director ejecutivo de Vercel mencionó que los atacantes avanzaron con una «velocidad sorprendente» y que probablemente la IA los aceleró. Esta es la nueva realidad. Ya no nos defendemos solo de un tipo con capucha que escribe órdenes manualmente. Nos defendemos de los agentes automatizados que pueden analizar la arquitectura de un sistema, identificar vulnerabilidades y ejecutar una vulnerabilidad en cuestión de segundos.

Cuando el adversario se mueve a la velocidad de una máquina, su defensa no puede depender de que un humano decida en qué casilla marcar. Tiene que estar integrado en la infraestructura. Por eso, hemos creado nuestros flujos de trabajo internos para asumir que siempre es posible que se produzca una infracción. No solo vigilamos las intrusiones, sino que reducimos la superficie de ataque para que la IA no pueda encontrar nada cuando entre por la puerta.

Uno de los mayores problemas relacionados con la violación de Vercel fue la conexión OAuth. OAuth es increíblemente útil, pero supone un enorme agujero de seguridad si no se gestiona con una disciplina extrema. Haces clic en un botón para probar una nueva herramienta de productividad basada en la IA y, de repente, esa herramienta tiene acceso de lectura a todo tu Google Workspace. Si piratean esa herramienta (como lo hizo Context.ai), toda tu organización queda expuesta.

Nuestro equipo de Sweent aplica una política de confianza cero para las integraciones de terceros. No permitimos que las «nuevas y brillantes herramientas» se conecten a nuestros sistemas principales sin una auditoría de seguridad completa. Y aun así, restringimos los alcances al mínimo indispensable. Si una herramienta solo necesita leer un calendario, no tiene acceso a todo el espacio de trabajo. Parece mucho trabajo, y lo es. Pero es la diferencia entre un incidente menor y una petición de rescate de 2 millones de dólares por parte de un grupo como ShinyHunters.

La regla de rotación secreta de 24 horas

Incluso con las mejores defensas, las cosas pueden salir mal. La marca de un equipo profesional no es solo la forma en que previenen una infracción, sino también la forma en que responden ante ella. Vercel recomendó a sus clientes que rotaran sus credenciales de inmediato. Sin embargo, «inmediatamente» es un término vago en el mundo empresarial. Para algunas empresas, eso significa la semana que viene. Para otras, significa después del fin de semana largo.

En Sweent, tenemos una regla estricta: ante cualquier sospecha de compromiso, todos los secretos, claves de API y cadenas de bases de datos se rotan en un plazo de 24 horas. No esperamos a que nos hagan una autopsia completa. No esperamos a ver si los datos fueron «realmente» filtrados. Avanzamos más rápido que el atacante.

Cuando un atacante se da cuenta de que tiene una clave, esa clave ya está muerta. Usamos scripts automatizados e infraestructura como código para gestionar esto. Si hubiéramos estado usando Vercel durante esta violación, las claves de nuestros clientes habrían sido recicladas y aseguradas incluso antes de que las noticias llegaran a los principales blogs de tecnología. La velocidad es la única defensa contra un atacante que se mueve con la velocidad impulsada por la IA.

La seguridad de la cadena de suministro y la regla de los 7 días

La violación de Vercel también generó preocupación por la cadena de suministro de NPM. Dado que Vercel es propietario de Next.js, un atacante con los tokens correctos podría lanzar una versión «envenenada» a millones de desarrolladores. Esta es la opción nuclear de la guerra cibernética. Si actualizas tus dependencias a ciegas cada vez que sale una nueva versión, estás jugando a la ruleta rusa con tu código base.

Protegemos a nuestros clientes mediante la implementación de un retraso obligatorio en todas las actualizaciones de dependencias que no sean críticas. Por lo general, esperamos al menos 7 días antes de incorporar las nuevas versiones de las principales bibliotecas. ¿Por qué? Porque la mayoría de los ataques a la cadena de suministro se identifican y neutralizan en esa primera semana. Al no ser los primeros en adoptar todos los parches menores, nos aseguramos de que nuestros clientes no sean los primeros en ser atacados cuando un paquete es secuestrado.

Puede parecer que estamos siendo demasiado cautelosos, pero busquemos otra alternativa. ShinyHunters supuestamente vende la base de datos interna de Vercel por 2 millones de dólares. Tienen 580 registros de empleados, paneles internos y código fuente. Se trata de una falla catastrófica que podría haberse mitigado con protocolos internos más estrictos y un enfoque menos «conveniente» para la administración de secretos.

¿Por qué no nos saltamos las partes «difíciles»

La seguridad se ve con frecuencia como un punto de fricción. Ralentiza el desarrollo. Hace que sea más difícil probar nuevas herramientas. Añade pasos al proceso de implementación. Y esa es exactamente la razón por la que tantas empresas emergentes se saltan las partes difíciles. Quieren moverse rápido y romper cosas. Pero cuando lo que rompes es la confianza de tus clientes, es posible que no tengas la oportunidad de arreglarlo.

Creamos Sweent partiendo de la idea de que la transformación digital no debería ir en detrimento de la seguridad. Manejamos la fricción para que nuestros clientes no tengan que hacerlo. Somos nosotros quienes realizamos las auditorías de seguridad de las herramientas de inteligencia artificial. Somos los que aplicamos el cifrado obligatorio en todas las variables de entorno. Somos los que nos quedamos despiertos para rotar las claves en 24 horas mientras el resto del sector sigue leyendo los titulares.

Si estás usando Vercel ahora mismo, probablemente deberías revisar tu panel de control. Audita cada una de las variables. Márcalas todas como sensibles. Corta cualquier conexión de OAuth que no necesites en absoluto. Pero si quieres dejar de preocuparte por si tus desarrolladores marcaron la casilla correcta a las 2:00 a.m., necesitas un socio que no trate la seguridad como una función opcional.

Al final del día, es probable que Vercel se recupere de esto. Tienen ingenieros de élite y mucho capital. Pero para una empresa más pequeña, una infracción como esta es una sentencia de muerte. No espere al siguiente gran titular para darse cuenta de que sus variables «no sensibles» son una desventaja. Los atacantes se mueven a la velocidad de una máquina. ¿Lo estás?