Los equipos modernos desplegan en Vercel decenas de veces al día. Cada "push" levanta un "deployment" de vista previa activo: una URL real, APIs reales, autenticación real, secretos reales en el entorno. Tu superficie de ataque cambia en cada "commit".
Algunos programas de seguridad no se mueven a esa velocidad. Gran parte de los equipos todavía corren un pentest una o dos veces al año y se apoyan en scanners que cuentan CVEs. Para cuando llega el informe, la app que describe ya se desplegó más de mil veces.
Esa brecha es todo el problema. Este post trata de cerrarla — no con otra integración, sino con un flujo donde la seguridad ofensiva corre de forma continua contra cada deployment.
DevSecOps está atascado en el tempo equivocado
Las herramientas que la mayoría usa hoy fueron pensadas para un mundo más lento:
- Pruebas de penetración trimestrales — una foto de una app que ya no existe una semana después.
- Escáneres estáticos — un muro de hallazgos ordenados por CVSS, no por si algo es realmente explotable.
- Herramientas sin conexión — SAST por acá, SCA por allá, DAST en otro lado, y el triage en una hoja de cálculo.
- Triaje manual — un ingeniero decidiendo, a mano, cuál de los 4.000 “críticos” se puede alcanzar de verdad.
Nada de esto se corresponde con cómo se entrega software hoy. El despliegue se volvió continuo. Las pruebas no. Y los asistentes de código con IA le echaron nafta al fuego: más código, generado más rápido, con supuestos de seguridad que ningún humano tomó explícitamente.
La solución no es escanear más. Es hacer que el lado ofensivo de la seguridad sea continuo y autónomo — probando qué es explotable, en cada despliegue, como lo haría un atacante.
2. ¿Por qué Vercel cambia el modelo de seguridad?
Vercel es una gran plataforma para construir, y justamente por eso reconfigura la superficie de ataque:
- Entornos de vista previa efímeros — Cada rama obtiene una URL activa, a menudo accesible públicamente.
- Espacios públicos por defecto — los despliegues de vista previa suelen quedar expuestos con autenticación débil o nula.
- Funciones sin servidor y en el borde — En cada commit aparecen y desaparecen rutas de la API.
- Secretos inyectados por entorno — Las claves API y los tokens viven en tiempo de ejecución, una mala configuración podría filtrarlos.
- Velocidad potenciada por IA — El código generado se genera más rápido de lo que cualquiera puede revisarlo.
Los riesgos recurrentes que surgen de esto le resultan familiares a cualquier tester ofensivo, pero ahora aparecen en cada Implementación: entornos de vista previa expuestos, autenticación defectuosa o inexistente, SSRF, IDOR/RBAC defectuosos, secretos filtrados y uso indebido de las API — a menudo en código que ningún ser humano escribió deliberadamente.
Eso no se soluciona con una revisión cada seis meses.
3. Seguridad ofensiva continua, no “analiza y olvídate”
El cambio en el que se basa Faraday:
| AppSec tradicional | DevSecOps de seguridad ofensiva continua |
|---|---|
| Prueba de penetración trimestral | Testing en cada despliegue |
| Recuento de CVE / gravedad | Operatividad validada |
| Herramientas puntuales aisladas | Una única capa de orquestación |
| Triaje manual | Priorización automática basada en el riesgo |
| Reportar y olvidar | Corregir → volver a implementar → volver a realizar las pruebas |
El motor que impulsa todo esto es FaradAI — agentes ofensivos autónomos que no se limitan a decir “aquí hay un hallazgo”. Intentan utilizarlo: encadenan vulnerabilidades, acceden a datos reales y comprueban el impacto. Un hallazgo que no se puede explotar se descarta. Un hallazgo que conduce a la apropiación de una cuenta se coloca en primer lugar.
4. El flujo: de git push a la validación del exploit
Este es el corazón. Un único ciclo continuo, impulsado por lo que los desarrolladores ya hacen todos los días:
git push
↓
Vercel crea un despliegue de vista previa
↓
SAST + SCA + detección de secretos + escaneo de IaC se ejecutan en paralelo
↓
Prueba de penetración autónoma y auditoría de código fuente de FaradAI: descubre la superficie
(rutas, APIs, parámetros, autenticación), la ataca (autenticación, IDOR, SSRF, abuso de API,
secretos expuestos) y valida y encadena exploits reales
↓
Todos los hallazgos aterrizan en un único espacio de trabajo de Faraday (gestión de vulnerabilidades basada en el riesgo)
↓
La clasificación y el parcheo de FaradAI se ejecutan en ese espacio de trabajo — enriqueciendo, deduplicando y priorizando
cada hallazgo (escáneres DevSecOps + SecOps + pruebas de penetración de FaradAI)
↓
Re-despliegue → re-prueba automáticaIntegrado con las herramientas que ya utilizan los equipos —GitHub Actions, webhooks de implementación de Vercel—, esto funciona sin que nadie tenga que acordarse de iniciar un análisis.
Una cadena de ataque ilustrativa (reemplazar por una corrida real de FaradAI)
Un desarrollador realiza un «push» a una rama de características. Vercel la publica. feature-billing-abc123.vercel.app. En minutos:
- Recon — FaradAI lista la nueva vista previa y encuentra una nueva ruta de API.,
/api/facturas/[id], que no existía enprincipal. - Prueba de autenticación — La ruta se basa en un
ID de usuarioproporcionado por el cliente y nunca comprueba quién es el propietario. Un IDOR clásico. - Encadenamiento — Un objeto de factura contiene una URL interna de S3 pre-firmada. Al acceder a ella, se muestra un archivo de configuración con una clave API de un tercero.
- Validación — el agente confirma que la clave está activa y permite la lectura. Ya no es una “posible mala configuración”, sino una vía probada de exposición de datos.
- Triaje — Faraday lo registra como un hallazgo único de alta prioridad, con explotabilidad validada, 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 quedan descartados.
El desarrollador corrige la comprobación de propiedad, vuelve a implementar el código y FaradAI vuelve a probar la misma cadena para confirmar que se ha cerrado, antes incluso de que la rama se fusione.
5. Manos a la obra: 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 habitual de Next.js alojada en Vercel en https://sandbox-graveyard.vercel.app/. Un proceso estándar, y los pocos pasos que hay que seguir para integrarle pruebas de penetración continuas y enviar tareas pendientes a una única instancia de Faraday.
El proceso que ya tienes
Un flujo de trabajo típico de GitHub Actions para una aplicación de Next.js: compilas, despliegas en Vercel, ejecutas los escáneres para los que ya tienes licencia y envías los resultados de cada escáner directamente a Faraday con faraday-cli en cuanto se acaba, para que nada se eche a perder en el panel de control.
# .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
# Conectá faraday-cli una vez. Lee el token de su archivo de config
# (auth no tiene flag --token), así que sembralo desde un secret de CI.
- run: |
pip install faraday-cli
cat > ~/.faraday-cli.yml <<YAML
auth:
faraday_url: $FARADAY_URL
ignore_ssl: false
token: ${{ secrets.FARADAY_TOKEN }}
YAML
# SAST — SonarQube analiza el código fuente, después los resultados van a Faraday
# (--create-workspace crea el workspace del PR en el primer uso)
- run: |
sonar-scanner -Dsonar.projectKey=sandbox-graveyard
curl -s -u "$SONAR_TOKEN:" \
"$SONAR_URL/api/issues/search?componentKeys=sandbox-graveyard" -o sonarqube.json
faraday-cli tool report sonarqube.json -w "$WS" --create-workspace
# Deploy a Vercel → URL de preview viva
- id: deploy
run: echo "url=$(vercel deploy --prebuilt --token=$VERCEL_TOKEN)" >> "$GITHUB_OUTPUT"
# DAST — la CLI de Burp (Dastardly) escanea la URL viva, después los resultados van a 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á nada mal: tus resultados de SonarQube y Burp ya se agrupan en un único espacio de trabajo de Faraday, en lugar de en dos paneles de control separados. Pero todo eso es solo el principio de escáner: SonarQube marca como «inaccesible» el código que no puede comprobar que sea accesible, Burp explora la superficie sin encadenar nada, y ninguno de ellos ejecuta una prueba de penetración autónoma. Tienes amplitud, pero no pruebas.
Paso 1 — Añade la prueba de penetración autónoma de FaradAI
FaradAI funciona como un Agente en la nube de Faraday, así que lo ejecutas sobre la API REST con un solo rizo (Los Cloud Agents no se gestionan con faraday-cli). Saca el id del agente de Agentes de la nube en la interfaz de usuario (o con GET /_api/v3/cloud_agents), guárdalo como secret, y agrega un paso después del deploy:
# DESPUÉS — dispará el pentest autónomo de FaradAI contra el preview vivo.
# FaradAI es un Cloud Agent de Faraday; se dispara vía /cloud_agents/<id>/run.
# Fire-and-forget: el runner ejecuta de forma asíncrona y empuja
# los hallazgos validados al workspace.
- name: FaradAI scan
env:
FARADAY_TOKEN: ${{ secrets.FARADAY_TOKEN }}
run: |
curl -sS -X POST "$FARADAY_URL/_api/v3/cloud_agents/${{ secrets.FARADAI_AGENT_ID }}/run" \
-H "Authorization: Token $FARADAY_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"args": {
"TARGET": "sandbox-graveyard.vercel.app",
"INSTRUCTION": "Test auth, IDOR, SSRF, API abuse, exposed secrets. Validate and chain real exploits.",
"GOAL": "Find and prove real, exploitable vulnerabilities on the target.",
"MODE": "Dual",
"ROUNDS": 5,
"BUDGET_USD": 20,
"DRY_RUN": false,
"TIME_LIMIT_SECONDS": 86400
},
"workspaces": ["vercel-pr-${{ github.event.number }}"]
}' -w "\nHTTP %{http_code}\n"PRESUPUESTO_USD limita el gasto en LLM y MODO: Dual Claude y Codex se turnan para trabajar. FaradAI explora la superficie, realiza una prueba de penetración autónoma y transmite los resultados. validados al mismo espacio de trabajo vercel-pr-… — 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. Respeta el alcance: se mantiene dentro del objetivo que nombras y registra cualquier host interesante fuera de alcance para que tú lo autorices, en lugar de pivotar hacia él en silencio.
Note: la corrida es asíncrona — el rizo vuelve enseguidaHTTP 200 con un id_comando y un ID de runner) mientras el pentest continúa en segundo plano. Como un pentest completo cuesta presupuesto y tiempo reales, ejecútalo deliberadamente (un trabajo de flujo_de_trabajo_despacho, una etiqueta o un programa nocturno) en lugar de en cada push.
Paso 2: Triaje y aplicación de parches en todo el espacio de trabajo
El pentest es solo la mitad del ciclo. Ejecuta el triaje de FaradAI sobre el mismo espacio de trabajo para enriquecer, deduplicar y priorizar todos los hallazgos a la vez —SonarQube, Burp y la prueba de penetración de FaradAI— y, cuando estés listo, aplicar la corrección. El triage es su propio Cloud Agent, y se activa de la misma manera:
# DESPUÉS — Clasificación y aplicación de parches de FaradAI en todo el espacio de trabajo
- name: Clasificación de FaradAI
env:
FARADAY_TOKEN: ${{ secrets.FARADAY_TOKEN }}
run: |
curl -sS -X POST "$FARADAY_URL/_api/v3/cloud_agents/${{ secrets.FARADAI_TRIAGE_AGENT_ID }}/run" \
-H "Authorization: Token $FARADAY_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"args": {
"WORKSPACE_NAME": "vercel-pr-${{ github.event.number }}",
"MODE": "Dual",
"PATCHING_MODE": "dry-run"
},
"workspaces": ["vercel-pr-${{ github.event.number }}"]
}' -w "\nHTTP %{http_code}\n""
NOMBRE_ESPACIO_DE_TRABAJO esto es lo que se va a triar — apúntalo al espacio de trabajo que el pentest y los escáneres acaban de llenar. El triaje no tiene estado: volver a ejecutarlo simplemente reclasifica lo que hay en ese momento, teniendo en cuenta vulnerabilidades nuevas o modificadas. MODO_APLICACION_PARCHES viene en simulación en seco por defecto (planifica la corrección, no cambia nada); pásalo a aplicar solo cuando decidiste permitir que FaradAI aplicara correcciones — una opción explícita, nunca la predeterminada, de modo que una ejecución en segundo plano no afecte al entorno de producción.
Paso 3 — Un único lugar para configurarlo todo: FaradAI
Configurás FaradAI una sola vez, en Faraday Personal, y todo lo anterior simplemente apunta a ello:
- Crea tu tenant en scan.faradaysec.com.
- Tu instancia vive en scan.apps.faradaysec.com.
- En Escáner de Seguridad, el Prueba de penetración autónoma de FaradAI es donde definís objetivos, alcance, rondas y el espacio de trabajo de destino — después lo disparas manualmente desde la interfaz de usuario, o automáticamente desde CI como en el Paso 1.
El resultado: git push sigue haciendo lo de siempre — pero ahora se somete a pruebas de penetración cada URL de vista previa, cada informe del escáner se añade a la misma cola de clasificación, y revisas una única lista de riesgos ordenada por prioridad validado en lugar de tres herramientas desconectadas.
6. Por qué esto le importa (sobre todo) a las empresas nativas de IA
La mayoría de los proveedores de seguridad siguen pensando en pruebas de penetración trimestrales, análisis estáticos y recuentos de CVE. Las empresas nativas de IA no funcionan así:
- Se despliegan constantemente.
- Entregar código generado por IA con supuestos implícitos y sin revisar.
- Cada semana se publican nuevas API.
- Están realizando pruebas en la 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 DevSecOps ofensivo nativo de IA para implementaciones en Vercel — un bucle que descubre, ataca, valida, prioriza y vuelve a probar, en cada push.
Las pruebas de penetración tradicionales te indican qué vulnerabilidades se podían explotar el trimestre pasado. Esta te indica cuáles se pueden explotar en este mismo momento.
¿Quieres aplicar medidas de seguridad ofensiva continuas en tus implementaciones de Vercel? Insights y Blog →
