One-time vulnerability assessment

What makes it different from a scan?

The phrase vulnerability assessment often means an automated scan with a long, unverified list attached. This is not that. Brexa attacks your in-scope systems the way an adversary would and reports only what a person has reproduced. You get fewer findings, and every one of them is real. If you are weighing the two, read vulnerability assessment vs penetration test.

• Prioritized by real impact. Severity reflects what an attacker could actually do in your environment, not a generic score alone.
• Every finding proven, with evidence. Sanitized requests and responses, preconditions, root cause and reproduction steps.
• Fixes retested before close. The original attack is re-run against the fix. Partial fixes are caught here.

How does an assessment run?

1. Scoping call. What you run, what matters most, who owns fixes. We agree targets, timing, limits and contacts.
2. Signed scope and rules of engagement. Nothing is tested until this is signed. It names exactly what is in and out of bounds.
3. Discover and challenge. Map what an attacker can see, then attack it, chaining small weaknesses into real attack paths.
4. Prove. A human operator reproduces every path and captures evidence. Unproven issues are not reported.
5. Resolve. Findings reach your engineers or security provider as they are confirmed, with exact fix steps.
6. Verify. We re-run the original attack after each fix ships. The finding closes only when the attack fails.

The full method, including how evidence is captured and how severity is decided, is on how Brexa works.

What can be in scope?

Web applications, APIs, your external attack surface, cloud environments, identity systems and internal networks. Most first assessments focus on the one or two surfaces that hold customer data.

When is a one-time assessment the right call?

• Before a launch, an enterprise deal or a security questionnaire that asks for a recent independent test.
• Ahead of a SOC 2, ISO 27001 or PCI DSS audit. See penetration testing for compliance.
• After a major change: a new product, an acquisition, a cloud migration or a rebuilt authentication flow.
• When you have never been tested and want a clear baseline before deciding on anything ongoing.

If you ship weekly and need that baseline kept current, look at continuous testing.

What should you prepare?

A list of what you run, test accounts for each role you want tested, a technical contact during testing window, and anyone who must be told (such as a hosting provider). Our checklist on how to prepare for a penetration test covers the rest.