A penetration test (pentest) is an authorised, simulated attack on a system, carried out the way a real attacker would, to find and confirm weaknesses before someone hostile does. The key word is confirm: a pentest proves that an issue can be exploited instead of only flagging that it might exist.
The key distinction, set out in NIST SP 800-115, is that a penetration test actively exploits a weakness to confirm it exists, rather than only reporting that a vulnerability might be present. That's why a good pentest cuts through scanner false positives: every finding comes with proof. The flip side is that it is a time-boxed exercise at a point in time. It reflects the system as it was tested, in the agreed window.
Most engagements follow a recognised process such as the Penetration Testing Execution Standard (PTES) or the four phases of NIST SP 800-115: planning, discovery, attack and reporting. The attack phase loops back to discovery as new access opens new paths. The work starts with scoping and rules of engagement (at Vexaro, also an NDA before any access) and ends with a prioritised report. With us, it also includes a free re-test of the fixes within the window set in the Statement of Work.
Pentests are scoped to a target: a web application (mapped to the OWASP Web Security Testing Guide), an API (the OWASP API Security Top 10), a mobile app (OWASP MASVS/MASTG), an internal or external network, or cloud configuration. Different targets need different methods (a web checklist applied to an API misses most of the real risk), which is why services are split by target.
The tester can work with no prior knowledge (black-box), partial knowledge such as credentials and a spec (grey-box), or full knowledge including source and architecture (white-box). More information generally means deeper coverage in the same time, so choose by your assurance goal, not by which option sounds toughest. Grey-box is the cost-effective norm for most application and API work.
It's an authorised, simulated attack, carried out the way a real attacker would, that confirms exploitable weaknesses rather than only flagging possible ones. As NIST SP 800-115 puts it, a pentest actively exploits a weakness to prove it exists. It is a time-boxed exercise that reflects the system as tested in the agreed window.
Most engagements follow a recognised process such as PTES or the four phases of NIST SP 800-115: planning, discovery, attack and reporting. The work starts with scoping and rules of engagement (at Vexaro, an NDA before any access) and ends with a prioritised report and, with us, a free re-test of the fixes within the window set in the Statement of Work.
Pentests are scoped to a target (a web app, an API, a mobile app, a network or cloud configuration), since different targets need different methods. The tester can start with no knowledge (black-box), partial knowledge such as credentials and a spec (grey-box), or full source and architecture (white-box). The choice depends on the assurance goal, not on which option sounds toughest.