Blackbox & whitebox

Attack it from the outside, or read the code first

Point the agent at a live app or API and it tests what an attacker can reach. Connect a repository and it reads the source before it attacks. Every pentest runs at full depth, on every plan.

Side by side

Two ways in, the same proof

ComparedBlackboxWhitebox
What it testsA verified domain, an API host or a public IP rangeA connected GitHub repository
What the agent seesOnly what's reachable over the network, like an attackerThe actual source, cloned into the sandbox
Where a finding pointsThe request and response that reproduce itThe exact file and line
Fix pull requestsNot applicable: there's no source to patchYes, for eligible findings
CostOne pentest from your planOne pentest from your plan
PlansEvery plan, Free includedEvery plan, Free included

Blackbox

Everything an attacker can reach

No source and no inside knowledge: the agent maps what your app exposes and attacks it over the network. Every finding carries the request and response that reproduce it.

  • Domains you've verified, API hosts, public IP ranges
  • Test users and custom headers for authenticated areas
  • Full depth on every plan

What blackbox covers

Web apps and APIs

Auth, access control, injection and business logic, tested on the running app the way an outside attacker would.

Public IP ranges

A single IP or a CIDR block is port- and service-scanned: exposed services fingerprinted and checked for known CVEs and misconfigurations.

Verification in a click

Prove the domain with a DNS record, a file or a meta tag, or connect Cloudflare or Vercel and Vulnix adds the record for you.

Whitebox

The source first, then the attack

Connect a GitHub repository and Vulnix clones it into the run's isolated sandbox. The agent reads the code to find where trust breaks, then proves it against the running app.

  • Findings point at the exact file and line
  • A fix pull request for eligible findings, opened when you ask
  • Add a verified domain to test the live app in the same run

What whitebox adds

Findings tied to code

Each finding points at the file and line it lives in, so the fix starts where the bug is.

Context an attacker never has

The agent reads routes, auth checks and data flows in the source, then attacks what it found.

Source and live app, one run

Attach a verified domain to a whitebox scope and the agent tests the running app as well. Still one pentest.

Questions

Which should I run first?
If you have a live app and no repository to connect, start with blackbox: it needs nothing beyond verifying the domain. If you want findings that point at exact code, or fix pull requests, run whitebox. For both, set up a whitebox scope with a verified domain attached: one run, one pentest.
Is whitebox more expensive?
No. A blackbox and a whitebox pentest each use one pentest from your plan.
Can I test an internal network?
No. IP-range testing covers external, internet-facing infrastructure only. Private ranges, loopback and cloud-metadata addresses are refused when you add the target, and Active Directory is out of scope.
How does Vulnix know I own the domain?
You prove it with a DNS TXT record, an uploaded file or a meta tag, or by connecting Cloudflare or Vercel. Signing up with your work email also verifies your company's own domain. A run against an unverified domain cannot start.
Does whitebox need write access to my repository?
It needs the Vulnix GitHub App on the repositories you choose to track; nothing else is visible to Vulnix. The repository is cloned into the run's isolated sandbox. A fix pull request is only ever opened when you ask for one.