Continuous Pentesting for Vercel Applications

Modern teams ship on Vercel dozens of times a day. Every push spins up a live preview deployment: a real URL, real APIs, real auth, real secrets in the environment. Your attack surface changes on every commit.

Your security program doesn’t move at that speed. Most teams still run a pentest once or twice a year and lean on scanners that count CVEs. By the time a report lands, the app it describes has been deployed over a thousand times.

That gap is the whole problem. This post is about closing it — not with another integration, but with a workflow where offensive security runs continuously against every deployment.

1. DevSecOps is stuck in the wrong tempo

The tooling most teams run today was built for a slower world:

• Quarterly pentests — a snapshot of an app that no longer exists a week later.
• Static scanners — a wall of findings ranked by CVSS, not by whether anything is actually exploitable.
• Disconnected tools — SAST here, SCA there, DAST somewhere else, triage in a spreadsheet.
• Manual triage — an engineer deciding, by hand, which of 4,000 “criticals” can actually be reached.

None of this maps to how software is shipped now. Deployment became continuous. Testing didn’t. And AI coding assistants have poured fuel on the fire: more code, generated faster, with security assumptions no human explicitly made.

The fix isn’t more scanning. It’s making the offensive side of security continuous and autonomous — testing what’s exploitable, on every deployment, the way an attacker would.

2. Why Vercel changes the security model

Vercel is a great platform to build on, and precisely because of that it reshapes the attack surface:

• Ephemeral preview environments — every branch gets a live, often publicly reachable URL.
• Public-by-default surfaces — preview deployments are frequently exposed with weak or no auth.
• Serverless & edge functions — new API routes appear and disappear per commit.
• Environment-injected secrets — API keys and tokens live in the runtime, one misconfiguration away from leaking.
• AI-accelerated velocity — generated code ships faster than anyone can review it.

The recurring risks that fall out of this are familiar to any offensive tester, but now they show up on every deployment: exposed preview environments, broken or missing auth, SSRF, IDOR/broken RBAC, leaked secrets, and API abuse — often in code no human deliberately wrote.

You can’t cover that with a scan every six months.

3. Continuous offensive security, not scan-and-forget

The shift Faraday is built around:

The engine behind this is FaradAI — autonomous offensive agents that don’t stop at “here’s a finding.” They try to use it: chain vulnerabilities, reach real data, and prove impact. A finding that can’t be exploited gets deprioritized. A finding that leads to an account takeover gets pushed to the top.

4. The workflow: from git push to exploit validation

This is the core of it. One continuous loop, triggered by the thing developers already do every day:

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 automatically

Wired into what teams already use — GitHub Actions, Vercel deployment webhooks — this runs without anyone remembering to kick off a scan.

An illustrative attack chain

A developer pushes a feature branch. Vercel publishes feature-billing-abc123.vercel.app. Within minutes:

1. Recon — FaradAI enumerates the new preview and finds a fresh API route, /api/invoices/[id], that didn’t exist on main.
2. Auth testing — the route trusts a client-supplied userId and never checks ownership. Classic IDOR.
3. Chaining — one invoice object leaks an internal S3 pre-signed URL. Following it exposes a config file with a third-party API key.
4. Validation — the agent confirms the key is live and read-capable. This is no longer a “possible misconfiguration” — it’s a proven data-exposure path.
5. Triage — Faraday files it as a single, high-priority, exploit-validated finding, with the full chain and reproduction steps, assigned to the branch owner. The 3,000 unreachable static-scanner findings stay out of the way.

The developer fixes the ownership check, redeploys, and FaradAI retests the exact chain to confirm it’s closed — before the branch ever merges.

5. Hands-on: adding FaradAI to a pipeline you already have

Enough theory. Let’s do it on a real app: sandbox-graveyard, an ordinary Next.js app deployed on Vercel at https://sandbox-graveyard.vercel.app/. One ordinary pipeline, and the handful of steps it takes to bolt continuous pentesting on top and pipe everything into one Faraday instance.

The pipeline you have today

A typical GitHub Actions workflow for a Next.js app: build, deploy to Vercel, run the scanners you already license — and push each scanner’s results straight into Faraday with faraday-cli right after it runs, so nothing rots in a 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

      # 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 <<YAML
          auth:
            faraday_url: $FARADAY_URL
            ignore_ssl: false
            token: ${{ secrets.FARADAY_TOKEN }}
          YAML

      # SAST — SonarQube analyses the source, then results go to Faraday
      # (--create-workspace makes the per-PR workspace on first use)
      - 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 to Vercel → live preview URL
      - id: deploy
        run: echo "url=$(vercel deploy --prebuilt --token=$VERCEL_TOKEN)" >> "$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"

Not bad — your SonarQube and Burp findings already converge in one Faraday workspace instead of two separate dashboards. But it’s all scanner output: SonarQube flags source it can’t prove is reachable, Burp probes the surface without chaining anything, and neither runs an autonomous pentest. You have breadth, not proof.

Step 1 — Add the FaradAI Autonomous Pentest (one more agent run)

FaradAI is itself a Faraday agent, so you trigger it with the same faraday-cli — nothing new to install, and the FaradAI Autonomous Pentest already runs inside your Faraday instance. Grab its agent ID and executor name once with faraday-cli agent list, then add one step after the deploy:

 # 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"
            }'

Executor parameters go in a single JSON object via -p (all values as strings). FaradAI discovers the surface, runs an autonomous pentest, and pushes validated findings into the same vercel-pr-… workspace — right next to the SonarQube and Burp results. From the UI it’s the same action: Cloud Agents → FaradAI → Run. It’s scope-aware: it stays on the target you name and logs any interesting off-scope host for you to authorize rather than pivoting to it silently.

Step 2 — Triage & patch the whole workspace

The pentest is only half the loop. Run FaradAI’s triage executor over the same workspace to enrich, deduplicate and prioritize every finding together — SonarQube, Burp, and the FaradAI pentest — and, when you’re ready, drive the fix:

# 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"
            }'

WORKSPACE_NAME is what gets triaged — point it at the workspace the pentest and scanners just filled. Triage is stateless: a re-run simply re-classifies whatever’s currently there, picking up new or changed vulns. PATCHING_MODE defaults to dry-run (plan the fix, change nothing); flip it to apply only when you’ve decided to let FaradAI push fixes — an explicit opt-in, never the default, so a stray run can’t touch production.

Step 3 — One place to configure it all: FaradAI

You configure FaradAI once, in Faraday Personal, and everything above just points at it:

1. Create your tenant at scan.faradaysec.com.
2. Your instance lives at scan.apps.faradaysec.com.
3. In Security Scanner, the FaradAI Autonomous Pentest is where you set targets, scope, rounds, and the destination workspace — then trigger it by hand from the UI, or automatically from CI as in Step 1.

The result: git push still does what it always did — but now every preview URL gets pentested, every scanner report lands in the same triage queue, and you review one ranked list of validated risk instead of three disconnected tools.

6. Why this matters most for AI-native companies

Most security vendors still think in quarterly pentests, static scans, and CVE counts. AI-native companies don’t operate that way:

• They deploy constantly.
• They ship AI-generated code with implicit, unreviewed assumptions.
• They expose new APIs weekly.
• They experiment in production.

If the software is autonomous and continuous, the security has to be too. That’s the whole thesis: the first AI-native offensive DevSecOps workflow for Vercel deployments — one loop that discovers, attacks, validates, prioritizes, and retests, on every push.

Traditional pentests tell you what was exploitable last quarter. This tells you what’s exploitable right now.

Want to run continuous offensive security against your Vercel deployments? Faraday →