Continuous Offensive Security Testing en Vercel

Los equipos modernos despliegan en Vercel decenas de veces por día. Cada push levanta un deployment de preview vivo: una URL real, APIs reales, auth real, secrets reales en el entorno. Tu superficie de ataque cambia en cada commit.

Algunos programas de seguridad no se mueve a esa velocidad. Gran parte de los equipos todavía corre un pentest una o dos veces al año y se apoya 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.

1. DevSecOps está atascado en el tempo equivocado

Las herramientas que la mayoría usa hoy fueron pensadas para un mundo más lento:

• Pentests trimestrales — una foto de una app que ya no existe una semana después.
• Scanners estáticos — una pared de hallazgos ordenados por CVSS, no por si algo es realmente explotable.
• Herramientas desconectadas — SAST por acá, SCA por allá, DAST en otro lado, y el triage en una planilla.
• Triage 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 deployment se volvió continuo. El testing 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 deployment, 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 preview efímeros — cada branch obtiene una URL viva, muchas veces accesible públicamente.
• Superficies públicas por defecto — los deployments de preview suelen quedar expuestos con auth débil o nula.
• Serverless & edge functions — aparecen y desaparecen rutas de API en cada commit.
• Secrets inyectados por entorno — API keys y tokens viven en el runtime, a una mala configuración de filtrarse.
• Velocidad acelerada por IA — el código generado sale más rápido de lo que cualquiera puede revisarlo.

Los riesgos recurrentes que salen de esto le resultan familiares a cualquier tester ofensivo, pero ahora aparecen en cada deployment: entornos de preview expuestos, auth rota o ausente, SSRF, IDOR/RBAC roto, secrets filtrados y abuso de APIs — muchas veces en código que ningún humano escribió deliberadamente.

Eso no lo cubrís con un escaneo cada seis meses.

3. Seguridad ofensiva continua, no “escaneá y olvidate”

El cambio sobre el que está construido Faraday:

El motor detrás de esto es FaradAI — agentes ofensivos autónomos que no se quedan en “acá hay un hallazgo”. Intentan usarlo: encadenan vulnerabilidades, llegan a datos reales y prueban el impacto. Un hallazgo que no se puede explotar se despriorija. Un hallazgo que lleva a un account takeover se manda al tope.

4. El flujo: de git push a la validación del exploit

Este es el corazón. Un único loop continuo, disparado por lo que los desarrolladores ya hacen todos los días:

git push
   ↓
Vercel crea un deployment de preview
   ↓
SAST + SCA + detección de secrets + escaneo de IaC corren en paralelo
   ↓
FaradAI pentest autónomo + auditoría de código fuente: descubre la superficie
(rutas, APIs, params, auth), la ataca (auth, IDOR, SSRF, abuso de API,
secrets expuestos) y valida & encadena exploits reales
   ↓
Todos los hallazgos aterrizan en un único workspace de Faraday (gestión de vulnerabilidades basada en riesgo)
   ↓
El triage & patching de FaradAI corre sobre ese workspace — enriqueciendo, deduplicando y priorizando
cada hallazgo (scanners DevSecOps + SecOps + pentest de FaradAI)
   ↓
Redeploy → re-testeo automático

Enganchado a lo que los equipos ya usan — GitHub Actions, webhooks de deployment de Vercel — esto corre sin que nadie se tenga que acordar de disparar un escaneo.

Una cadena de ataque ilustrativa (reemplazar por una corrida real de FaradAI)

Un desarrollador pushea un branch de feature. Vercel publica feature-billing-abc123.vercel.app. En minutos:

1. Recon — FaradAI enumera el nuevo preview y encuentra una ruta de API nueva, /api/invoices/[id], que no existía en main.
2. Testeo de auth — la ruta confía en un userId provisto por el cliente y nunca chequea ownership. Un IDOR clásico.
3. Encadenamiento — un objeto de factura filtra una URL pre-firmada interna de S3. Siguiéndola se expone un archivo de config con una API key de un tercero.
4. Validación — el agente confirma que la key está viva y permite lectura. Ya no es una “posible mala configuración” — es un camino de exposición de datos probado.
5. Triage — Faraday lo registra como un único hallazgo de alta prioridad, con explotabilidad validada, con la cadena completa y los pasos de reproducción, asignado al dueño del branch. Los 3.000 hallazgos inalcanzables del scanner estático quedan fuera del camino.

El desarrollador arregla el chequeo de ownership, hace redeploy, y FaradAI re-testea la misma cadena para confirmar que quedó cerrada — antes de que el branch siquiera se mergee.

5. Manos a la obra: sumar FaradAI a un pipeline que ya tenés

Basta de teoría. Hagámoslo sobre una app real: sandbox-graveyard, una app Next.js común desplegada en Vercel en https://sandbox-graveyard.vercel.app/. Un pipeline común, y los pocos pasos que hacen falta para atornillarle pentesting continuo encima y mandar todo a una única instancia de Faraday.

El pipeline que ya tenés

Un workflow típico de GitHub Actions para una app Next.js: buildeás, desplegás en Vercel, corrés los scanners que ya tenés licenciados — y mandás los resultados de cada scanner directo a Faraday con faraday-cli apenas termina, así nada se pudre en un dashboard.

# .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"

Nada mal — tus hallazgos de SonarQube y Burp ya convergen en un único workspace de Faraday en vez de en dos dashboards separados. Pero es todo salida de scanner: SonarQube marca código que no puede probar que sea alcanzable, Burp sondea la superficie sin encadenar nada, y ninguno corre un pentest autónomo. Tenés amplitud, no prueba.

Paso 1 — Sumá el pentest autónomo de FaradAI

FaradAI corre como un Cloud Agent de Faraday, así que lo disparás sobre la API REST con un solo curl (los Cloud Agents no se manejan con faraday-cli). Sacá el id del agente desde Cloud Agents en la UI (o con GET /_api/v3/cloud_agents), guardalo como secret, y agregá 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"

BUDGET_USD limita el gasto en LLM y MODE: Dual corre Claude + Codex tomando turnos. FaradAI descubre la superficie, corre un pentest autónomo y empuja los hallazgos validados al mismo workspace vercel-pr-… — al lado de los resultados de SonarQube y Burp. Desde la UI es la misma acción: Cloud Agents → FaradAI → Run. Respeta el scope: se queda en el target que nombrás y registra cualquier host interesante fuera de scope para que vos lo autorices, en vez de pivotear hacia él en silencio.

Nota: la corrida es asíncrona — el curl vuelve enseguida (HTTP 200 con un command_id y un id de runner) mientras el pentest sigue en segundo plano. Como un pentest completo cuesta budget y tiempo reales, disparalo de forma deliberada (un job de workflow_dispatch, un label, o un schedule nocturno) en vez de en cada push.

Paso 2 — Triage & patching sobre todo el workspace

El pentest es solo la mitad del loop. Corré el triage de FaradAI sobre el mismo workspace para enriquecer, deduplicar y priorizar todos los hallazgos juntos — SonarQube, Burp y el pentest de FaradAI — y, cuando estés listo, empujar el fix. El triage es su propio Cloud Agent, se dispara igual:

            # DESPUÉS — triage & patching de FaradAI sobre todo el workspace
      - name: FaradAI triage
        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"

WORKSPACE_NAME es lo que se va a triagear — apuntalo al workspace que el pentest y los scanners recién llenaron. El triage no tiene estado: volver a correrlo simplemente re-clasifica lo que hay en ese momento, tomando vulns nuevas o modificadas. PATCHING_MODE viene en dry-run por defecto (planifica el fix, no cambia nada); pasalo a apply solo cuando decidiste dejar que FaradAI empuje fixes — un opt-in explícito, nunca el default, así una corrida al pasar no toca producción.

Paso 3 — Un solo lugar para configurar todo: FaradAI

Configurás FaradAI una sola vez, en Faraday Personal, y todo lo de arriba simplemente le apunta:

1. Creá tu tenant en scan.faradaysec.com.
2. Tu instancia vive en scan.apps.faradaysec.com.
3. En Security Scanner, el FaradAI Autonomous Pentest es donde definís targets, scope, rounds y el workspace destino — después lo disparás a mano desde la UI, o automáticamente desde CI como en el Paso 1.

El resultado: git push sigue haciendo lo de siempre — pero ahora cada URL de preview se pentestea, cada reporte de scanner cae en la misma cola de triage, y revisás una única lista priorizada de riesgo validado en vez de tres herramientas desconectadas.

6. Por qué esto le importa (sobre todo) a las empresas AI-native

La mayoría de los proveedores de seguridad todavía piensa en pentests trimestrales, escaneos estáticos y conteos de CVE. Las empresas AI-native no operan así:

• Despliegan todo el tiempo.
• Entregan código generado por IA con supuestos implícitos y sin revisar.
• Exponen APIs nuevas cada semana.
• 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 DevSecOps ofensivo AI-native para deployments en Vercel — un loop que descubre, ataca, valida, prioriza y re-testea, en cada push.

Los pentests tradicionales te dicen qué era explotable el trimestre pasado. Este te dice qué es explotable ahora mismo.

¿Querés correr seguridad ofensiva continua contra tus deployments de Vercel? Faraday →