Los equipos modernos envían en Vercel decenas de veces al día. Cada "push" genera una implementación de vista previa en vivo: una URL real, API reales, autenticación real, secretos reales en el entorno. Tu superficie de ataque cambia en cada "commit".
Tu programa de seguridad no se mueve a esa velocidad. La mayoría de los equipos todavía realizan una prueba de penetración una o dos veces al año y se basan en escáneres que cuentan las CVE. Para cuando llega un informe, la aplicación que describe ya ha sido desplegada más de mil veces.
Esa brecha es todo el problema. Esta publicación trata sobre cómo cerrarla, no con otra integración, sino con un flujo de trabajo donde la seguridad ofensiva se ejecuta continuamente contra cada implementación.
DevSecOps está atascado en el tempo equivocado
Las herramientas que la mayoría de los equipos usan hoy en día se crearon para un mundo más lento:
- Pruebas de penetración trimestrales — una instantánea de una aplicación que ya no existe una semana después.
- Escáneres estáticos — una pared de hallazgos clasificados por CVSS, no por si algo es realmente explotable.
- Herramientas desconectadas — SAST aquí, SCA allá, DAST en otro lugar, triaje en una hoja de cálculo.
- Triaje manual — un ingeniero que decide, a mano, cuáles de los 4.000 “críticos” pueden ser alcanzados realmente.
Nada de esto se corresponde con la forma en que se distribuye el software ahora. La implementación se volvió continua. Las pruebas no lo hicieron. Y los asistentes de codificación de IA han echado leña al fuego: más código, generado más rápido, con suposiciones de seguridad que ningún humano hizo explícitamente.
La solución no es más escaneo. Es hacer que el ofensivo lado de seguridad continua y autónoma — probando lo explotable, en cada despliegue, de la forma en que lo haría un atacante.
2. Por qué Vercel cambia el modelo de seguridad
Vercel es una gran plataforma para construir, y precisamente por eso remodela la superficie de ataque:
- Entornos de vista previa efímeros — cada rama obtiene una URL en vivo, a menudo accesible públicamente.
- Superficies públicas por defecto — las implementaciones de vista previa a menudo quedan expuestas con autenticación débil o nula.
- Funciones sin servidor y en el borde — las nuevas rutas de la API aparecen y desaparecen por cada commit.
- Secretos inyectados por el entorno — Las claves y tokens de la API residen en tiempo de ejecución, a una mala configuración de distancia de filtrarse.
- Velocidad acelerada por IA — el código generado se envía más rápido de lo que nadie puede revisarlo.
Los riesgos recurrentes que se derivan de esto son familiares para cualquier probador ofensivo, pero ahora aparecen en cada despliegue: entornos de vista previa expuestos, autenticación rota o faltante, SSRF, IDOR/RBAC roto, secretos expuestos y abuso de API, a menudo en código que ningún humano escribió deliberadamente.
No se puede cubrir eso con un escaneo cada seis meses.
3. Seguridad ofensiva continua, no escanear y olvidar
El cambio Faraday está construido alrededor de:
| AppSec tradicional | Ofensiva Continua DevSecOps |
|---|---|
| Pentest trimestral | Prueba en cada implementación |
| Conteo de CVE / severidad | Explotabilidad validada |
| Herramientas de punto aislado | Una capa de orquestación |
| Triaje manual | Priorización automatizada basada en riesgos |
| Informa, luego olvida | Corregir → volver a implementar → volver a probar |
El motor detrás de esto es FaradAI — agentes ofensivos autónomos que no se detienen en “aquí hay un hallazgo”. Intentan usar es: vulnerabilidades en cadena, alcance de datos reales y prueba de impacto. Un hallazgo que no se puede explotar se prioriza menos. Un hallazgo que conduce a la toma de control de una cuenta se prioriza al máximo.
2. El flujo de trabajo: de git push explotar la validación
Este es el quid de la cuestión. Un bucle continuo, activado por lo que los desarrolladores ya hacen a diario:
git push
↓
Vercel creates a preview deployment
↓
SAST + SCA + secret detection + IaC scanning run in parallel
↓
FaradAI autonomous pentest + source-code audit: discovers the surface
(routes, APIs, params, auth), attacks it (auth, IDOR, SSRF, API abuse,
exposed secrets), and validates & chains real exploits — the rest is deprioritized
↓
All findings land in one Faraday workspace (risk-based vulnerability management)
↓
FaradAI triage & patching runs over that workspace — enriching, deduping and prioritizing
every finding (DevSecOps scanners + SecOps + FaradAI pentest)
↓
Redeploy → retest automaticallyIntegrado con lo que los equipos ya usan — GitHub Actions, webhooks de despliegue de Vercel — esto se ejecuta sin que nadie tenga que recordar iniciar un escaneo.
Una cadena de ataque ilustrativa
Un desarrollador sube una rama de características. Vercel publica feature-billing-abc123.vercel.app. En cuestión de minutos:
- Recon — FaradAI analiza la nueva versión preliminar y encuentra una nueva ruta de la API,
/api/facturas/[id], que no existía enprincipal. - Pruebas de autenticación — la ruta confía en un cliente proporcionado
ID de usuarioy nunca verifica la propiedad. Clásico IDOR. - Encadenamiento — Un objeto de factura filtra una URL interna de S3 prefirmada. Al acceder a ella, queda expuesto un archivo de configuración que contiene una clave de API de un tercero.
- Validación — El agente confirma que la clave está activa y que permite la lectura. Ya no se trata de una “posible configuración errónea”, sino de una vía de exposición de datos demostrada.
- Triaje — Faraday lo archiva como una única solicitud de alta prioridad, validado contra vulnerabilidades hallazgo, con la cadena completa y los pasos de reproducción, asignado al propietario de la rama. Los 3.000 hallazgos inalcanzables del escáner estático no interfieren.
El desarrollador corrige la comprobación de propiedad, vuelve a desplegar y FaradAI vuelve a probar la cadena exacta para confirmar que está cerrada, antes de que la rama se fusione.
5. Práctica: cómo integrar FaradAI en un proceso que ya tienes
Basta ya de teoría. Vamos a ponerlo en práctica con una aplicación real: caja de arena-cementerio, una aplicación Next.js normal y corriente desplegada en Vercel en https://sandbox-graveyard.vercel.app/. Una tubería ordinaria, y los pocos pasos que se necesitan para atornillar pruebas de penetración continuas encima y canalizar. todo en una instancia de Faraday.
La tubería que tienes hoy
Un flujo de trabajo típico de GitHub Actions para una aplicación Next.js: compilar, desplegar en Vercel, ejecutar los escáneres que ya tiene licenciados — y enviar los resultados de cada escáner directamente a Faraday con faraday-cli justo después de que se haya ejecutado, para que nada se pudra en el salpicadero.
# .github/workflows/deploy.yml
name: deploy
on: [push]
jobs:
ship:
runs-on: ubuntu-latest
env:
FARADAY_URL: https://scan.apps.faradaysec.com
WS: vercel-pr-${{ github.event.number }}
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 22 }
- run: npm ci && npm run build
# Connect faraday-cli once. It reads a token from its config file
# (there is no --token flag on `auth`), so seed it from a CI secret.
- run: |
pip install faraday-cli
cat > ~/.faraday-cli.yml <> "$GITHUB_OUTPUT"
# DAST — Burp's CLI (Dastardly) scans the live URL, then results go to Faraday
- run: |
docker run --rm -v "$PWD:/out" \
-e BURP_START_URL=https://sandbox-graveyard.vercel.app/ \
-e BURP_REPORT_FILE_PATH=/out/burp.xml \
public.ecr.aws/portswigger/dastardly:latest
faraday-cli tool report burp.xml -w "$WS"No está mal: tus hallazgos de SonarQube y Burp ya convergen en un espacio de trabajo de Faraday en lugar de dos paneles separados. Pero todo está escáner SonarQube marca código fuente que no puede demostrar que es accesible, Burp explora la superficie sin encadenar nada, y ninguno ejecuta una prueba de penetración autónoma. Tienes amplitud, no prueba.
Paso 1: Agregue la prueba de pentest autónoma de FaradAI (una ejecución de agente más)
FaradAI es en sí mismo un agente de Faraday, por lo que se activa de la misma manera faraday-cli — nada nuevo que instalar, y el Prueba de penetración autónoma de FaradAI ya se está ejecutando en tu instancia de Faraday. Obtén su ID de agente y el nombre del ejecutor una vez con lista de agentes faraday-cli, luego agrega un paso después de la implementación:
# AFTER — run the FaradAI Autonomous Pentest against the live preview
- run: |
faraday-cli agent run \
-a "${{ secrets.FARADAI_AGENT_ID }}" \
-e aipentest \
-w "$WS" \
-p '{
"TARGET": "https://sandbox-graveyard.vercel.app/",
"INSTRUCTION": "Test auth, IDOR, SSRF, API abuse, exposed secrets",
"MODE": "dual",
"ROUNDS": "5"
}'Los parámetros del ejecutor se introducen en un único objeto JSON mediante -p (todos los valores como cadenas). FaradAI descubre la superficie, ejecuta una prueba de penetración autónoma y empuja validado hallazgos en lo mismo vercel-pr-… espacio de trabajo — justo al lado de los resultados de SonarQube y Burp. Desde la interfaz de usuario, es la misma acción: Agentes en la nube → FaradAI → Ejecutar. Es consciente del ámbito: se mantiene en el objetivo que usted nombra y registra cualquier host interesante fuera del ámbito para que usted lo autorice en lugar de pivotar hacia él silenciosamente.
Paso 2: Triaje y parcheo de todo el espacio de trabajo
La prueba de penetración es solo la mitad del ciclo. Ejecuta FaradAI's triaje ejecutor sobre mismo espacio de trabajo para enriquecer, desduplicar y priorizar todos los hallazgos juntos — SonarQube, Burp y la prueba de penetración de FaradAI — y, cuando esté listo, impulse la corrección:
# THEN — FaradAI triage & patching over the whole workspace
- run: |
faraday-cli agent run \
-a "${{ secrets.FARADAI_AGENT_ID }}" \
-e triage \
-w "$WS" \
-p '{
"WORKSPACE_NAME": "vercel-pr-${{ github.event.number }}",
"MODE": "dual",
"PATCHING_MODE": "dry-run"
}'NOMBRE_ESPACIO_DE_TRABAJO es lo que se clasifica; apúntalo al espacio de trabajo que los pentesters y escáneres acaban de llenar. La clasificación no tiene estado: una nueva ejecución simplemente reclasifica lo que está presente actualmente, detectando vulnerabilidades nuevas o modificadas. MODO_APLICACION_PARCHES por defecto simulación en seco (planificar la solución, no cambiar nada); cambiar a aplicar solo cuando hayas decidido permitir que FaradAI aplique correcciones — una opción explícita, nunca el valor predeterminado, por lo que una ejecución accidental no puede afectar la producción.
Paso 3 — Un solo lugar para configurarlo todo: FaradAI
Configuras FaradAI una vez, en Faraday Personal, y todo lo anterior solo apunta a ello:
- Crea tu inquilino en scan.faradaysec.com.
- Su instancia vive en scan.apps.faradaysec.com.
- En Escáner de Seguridad, el Prueba de penetración autónoma de FaradAI es donde estableces objetivos, alcance, rondas y el espacio de trabajo de destino; luego lo activas manualmente desde la interfaz de usuario o automáticamente desde CI como en el Paso 1.
El resultado: git push todavía hace lo que siempre hizo, pero ahora cada URL de vista previa se somete a pentesting, cada informe de escáner llega a la misma cola de triaje y revisas una lista clasificada de validado riesgo en lugar de tres herramientas desconectadas.
6. Por qué esto es lo más importante para las empresas nativas de IA
La mayoría de los proveedores de seguridad todavía piensan en pruebas de penetración trimestrales, escaneos estáticos y recuentos de CVE. Las empresas nativas de IA no operan de esa manera:
- Se despliegan constantemente.
- Envían código generado por IA con suposiciones implícitas y no revisadas.
- Exponen nuevas API semanalmente.
- Experimentan en producción.
Si el software es autónomo y continuo, la seguridad también tiene que serlo. Esa es toda la tesis: el primer flujo de trabajo DevSecOps ofensivo nativo de IA para implementaciones de Vercel — un bucle que descubre, ataca, valida, prioriza y vuelve a probar, en cada envío.
Las pruebas de penetración tradicionales te dicen qué era explotable el último trimestre. Esta te dice qué es explotable ahora mismo.
¿Quieres ejecutar seguridad ofensiva continua contra tus despliegues de Vercel? Insights y Blog →
