Method
How Brexa works
Five stages, two rules. If it cannot be proven, it is not reported. If the original attack still works, it is not fixed.
The short answer
A Brexa engagement maps what an attacker can see, attacks it by chaining weaknesses into real attack paths, has a person reproduce every path with evidence, hands each proven finding to whoever owns the fix, and re-runs the original attack once the fix ships. Nothing starts before a signed scope.
Before anything: scope and authorization
Every engagement starts with a scoping call and a signed scope and rules of engagement. That document names the systems in bounds, the ones that are not, the testing windows, the limits on techniques that could affect availability, the stop conditions and the contacts on both sides. No system is touched before it is signed. Our guide to rules of engagement explains each part.
Stage 1
Discover
Map everything an attacker can see: domains, exposed services, apps, APIs, cloud assets and identities.
This is the attacker's first hour, done thoroughly: subdomains and forgotten hosts, exposed services, application routes, API endpoints, cloud resources and identity entry points within scope. It often surfaces assets the team did not know were public.
Stage 2
Challenge
Attack it like an adversary would, chaining small weaknesses into real routes to impact.
Single findings rarely tell the story. A verbose error, a weak permission check and a reused token can be harmless alone and serious together. Brexa tests how far each weakness can be taken, staying inside the agreed limits.
Stage 3
Prove
A human operator reproduces every path. If it can't be proven, it isn't reported.
A human operator reproduces each attack path and records evidence. Anything that cannot be shown is either dropped or reported as an observation, never as a finding. This is what keeps the result free of scanner noise.
Stage 4
Resolve
The finding goes to whoever owns the fix, your engineers or your security provider, with exact steps.
Serious findings are shared as soon as they are confirmed, not held for a final report. Each one names the affected system, the impact in plain language, and exact steps for the fix.
Stage 5
Verify
Brexa re-runs the exact attack after the fix ships. It only closes when the attack fails.
After the fix ships, Brexa re-runs the original attack and nearby variants. Partial fixes and regressions are caught here. Closure is recorded with the retest evidence, which is what auditors ask for.
How is severity decided?
By what an attacker could actually do with the issue in your environment. Standard references such as CVSS, CWE and the OWASP Top 10 are attached to each finding so engineers and auditors can map it, but the rating also weighs reachability and business impact. A low-scored weakness that unlocks customer data outranks a high-scored one that leads nowhere.
What evidence comes with a finding?
- What was observed, stated plainly, kept separate from potential impact and from anything not shown.
- Sanitized requests and responses, screenshots or logs that let your engineers reproduce it.
- Preconditions, root cause, and the recommended fix with validation criteria agreed up front.
- Retest history: when the fix was checked and whether the original attack failed.
You can see how this looks for leadership and for engineers in the client portal demo.
Who fixes what?
Brexa finds and proves. Your engineers or your existing security provider fix. Brexa verifies. Keeping those roles separate means nobody grades their own work. With continuous testing the blue agent can also draft fixes for your engineers to review.
Find out what an attacker could do with your systems.
Book a short scoping call. Nothing is tested until scope and rules of engagement are signed, and every finding comes with proof.