Better models won't secure the apps your users build. They move the risk upward↑.

01THE PROBLEM

export async function GET(req, { params }) {
  // fetch the order by id…
  const { data } = await supabase
    .from('orders')
    .select('*')
    .eq('id', params.id)
  // MISSING: .eq('owner_id', session.user.id)
    .single()

  // returns ANY user's order →
  return Response.json(data)
}

04THE ADVERSARIAL LOOP

One brain, two roles, locked in a duel.

The same intelligence attacks and defends — and the attacker is the judge of the defense.

05THE BET

Security doesn't get solved as models improve. It relocates upward.

And the layer it relocates into gets stronger with every model release — not weaker.

The intuition is that better AI will write secure code and this whole problem evaporates. It won't — for two reasons. First, attackers hold the same models you do, so any capability that helps you defend helps them attack. Second, the bugs that actually matter are intent-dependent: authorization is about your rules — who in your app is allowed to see what — and no smarter model can close that gap, because it doesn't know your rules. So the scarce, durable thing isn't a smarter code generator. It's independent, continuous, machine-speed verification of what AI-written code actually does. Every model release makes the code more abundant and the attackers stronger — which makes that verification layer more valuable, not less.

• Attackers hold the same models. Defensive capability is never a one-sided gain.
• Authorization is intent-dependent. A smarter model doesn't know your access rules.
• So verification — not generation — becomes the scarce thing.
• Every model release strengthens the layer that proves what code really does.

A smarter model still doesn't know who's allowed to see what.

06THE MOAT

The scanner is commodity. These four things aren't.

What compounds, and why a model vendor structurally can't copy it.

Detection alone is a race to the bottom — everyone gets the same models. VulX's defensibility is in what the loop produces and where it sits, not in the act of scanning.

• 01
  Fix-outcome data

  Which fixes were accepted and actually held in production. The model vendors structurally can't get this; we capture it on every cycle.

• 02
  Structural independence

  The platform and the model that wrote the code can't credibly certify that same code. We're the third party that can.

• 03
  Depth on authorization

  We go deep on the classes we actually prove — data leaks and broken access — the bugs that cause real breaches and that a better model can't fix.

• 04
  Cross-codebase network

  An attack learned on one app preemptively patches the others. The network gets safer as it grows.

07COVERAGE + PROOF

Comprehensive coverage on the modern web stack — the serious risks proven.

TypeScript / React / Next, Postgres / Supabase, Node. Breadth you can trust as verified facts — and data leaks / broken access proven end-to-end.

We cover the whole app — exposed keys, a leaked service-role key, public storage buckets, hallucinated package imports, vulnerable dependencies — reported as verified facts with the exact file and line; everything else is clearly flagged for review, never dressed up as proven. For the class that causes real breaches — a stranger or the wrong user reading private data — we don't stop at a warning, we prove it. Today's working proof connects directly to your Supabase database and demonstrates an anonymous, stranger read of private rows. Depth on the serious class, breadth you can trust across the rest.

08WHO IT'S FOR / PRICING POSTURE

The people a breach would kill are who pay.

Victims don't buy prevention. Founders with everything to lose do.

We're honest about who pays: not individual developers (the person who gets breached rarely buys prevention in advance). Our first paying customers are serious indie founders and small startups whose entire business a single data breach would end. They buy comprehensive security they can actually trust — the dangerous findings proven, the rest verified facts or clearly flagged, so nobody chases a false alarm on what matters. Regulated, compliance-driven teams and enterprise CISOs come later, reached through AdaptiveGRC — an enterprise governance, risk and compliance platform that partnered with us to bring proof-based AI-code security to regulated enterprises. It's a partnership and a distribution channel, not a customer logo — we won't pretend otherwise.

Not individual developers — the victim doesn't buy prevention; we don't pretend otherwise.

09HOW WE PROVE THE SERIOUS ONES

Watch the duel that proves a data leak.

A Next.js + Supabase route that returns any order by id — proven, patched, re-attacked, shipped.

This is how we prove the flagship class — data leaks and broken access. Today's working, wired proof connects directly to your Supabase database and demonstrates an anonymous or wrong user reading private rows: safely, always rolled back, marked with a planted canary. The walk-through below is an illustrative example of that same prove → patch → re-attack → ship-gate loop shown at the code layer — a depiction of the mechanism, not a wired self-serve flow, and the numbers depict the flow, not a benchmark. Alongside this proof, the scan reports the breadth as verified facts — exposed keys, vulnerable dependencies, and more — with the exact file and line.

// service-role client bypasses Row Level Security
const supabase = createClient(SUPABASE_URL, SERVICE_ROLE_KEY)

export async function GET(req, { params }) {
  // BUG: fetches by id only — never checks ownership
  const { data, error } = await supabase
    .from('orders')
    .select('*')
    .eq('id', params.id)
    .single()
  if (error) return Response.json({ error: error.message }, { status: 404 })
  return Response.json(data)   // returns ANY user's order
}

$ vulx hack --target ./app --path /api/orders/[id]
[SCAN]   reachable: params.id (untrusted) → orders.eq('id', params.id)  [no ownership predicate]
[LLM]   intended rule: order is private to owner_id; route enforces none → EXPLOITABLE (IDOR)
[SBX]   spinning up sandbox, seeding 2 users: alice (ord_A1), bob (ord_B7)
[SBX]   POST /auth/login  [email protected]           → 200  session=sess_alice
[SBX]   GET  /api/orders/ord_B7   Cookie: sess_alice
        → 200  {"id":"ord_B7","owner_id":"bob","total":"£420.00","card_last4":"4242"}
[PROOF] Alice read Bob's order. Cross-tenant data leak CONFIRMED. Evidence: req+resp captured.
[GATE]  exploitable_before = TRUE

import { createServerClient } from '@/lib/supabase/server'

export async function GET(req, { params }) {
  const supabase = createServerClient()        // session-scoped client
  const { data: { user } } = await supabase.auth.getUser()
  if (!user) return Response.json({ error: 'unauthorized' }, { status: 401 })

  const { data, error } = await supabase
    .from('orders').select('*').eq('id', params.id)
    .eq('owner_id', user.id)   // FIX: scope to the caller — RLS-equivalent
    .single()
  if (error || !data) return Response.json({ error: 'forbidden' }, { status: 403 })
  return Response.json(data)
}

$ vulx fix --finding IDOR-orders-by-id
[FIXER]  patch: derive caller from session, scope to owner_id, 403 on mismatch
[BATTLE] re-attack: GET /api/orders/ord_B7  Cookie: sess_alice
         → 403  {"error":"forbidden"}
[BATTLE] control:   GET /api/orders/ord_A1  Cookie: sess_alice
         → 200  (Alice still reads her own order)
[GATE]  exploitable_after = FALSE  AND  control_ok = TRUE
[TESTS] vitest: 41 passed, 0 failed   |   build: next build OK
[SHIP]  ship-gate PASSED → draft PR #128 opened
[NOTE]  propose-and-approve: awaiting human merge. outcome (accepted? held?) tracked.