Penetration testing
I test the approved target as an attacker would, but within rules that protect the service and its users. The point is to validate exploitable paths and the controls that should stop them — not to produce a long list of scanner output.
Updated
How I run the test
01Rules of engagement
Agree the named targets, user roles, test window, data handling, rate limits, prohibited actions, emergency contact and the conditions for stopping a test. Nothing relies on an assumed permission.
02Map the attack surface
Build a working view of exposed interfaces, authenticated workflows, trust boundaries, integrations and the assets that matter. Architecture and test accounts are used to focus effort, not to replace testing.
03Test and validate
Use manual testing and targeted tooling to validate authentication, authorisation, session handling, input and output handling, business logic, configuration and exposed integration paths. For web applications and APIs, the OWASP Web Security Testing Guide is the baseline reference.
04Report and retest
Document reproducible evidence, realistic impact, remediation guidance and the condition that closes each finding. A focused retest confirms the fix without rerunning the entire engagement.
What the report distinguishes
| Result | What it means | What you get |
|---|---|---|
| Confirmed exploitable finding | A path was demonstrated safely against the approved target. | Reproduction steps, affected scope, evidence, impact and a remediation test. |
| Control gap | A weakness was observed but the end-to-end impact could not or should not be demonstrated safely. | The missing control, the reason for caution and the evidence needed to validate it. |
| Hardening observation | A configuration or design issue is worth fixing but is not presented as an exploit. | Clear prioritisation so it does not compete with confirmed attack paths. |
Frequently asked questions
Do you need source code?
No. The default test validates the running target. Source, architecture and pipeline access can help focus the work, but are agreed as part of the scope rather than assumed.
Will you test production?
Where production is in scope, the rules of engagement set safe accounts, data handling, rate limits and stop conditions. If that cannot be done safely, I use an equivalent environment and state the remaining uncertainty.
Related
Threat modeling
Facilitated STRIDE threat modeling on your real architecture, plus the templates and coaching to keep teams doing it without me.
Cloud security assessment
Configuration and architecture assessment for Azure, GCP and Alibaba Cloud: identity, network, data, logging and CSPM findings with a fix roadmap.
Incident response
IR lifecycle aligned to NIST SP 800-61r3 and CSF 2.0, cloud and identity playbooks, detection coverage and post-incident learning that changes controls.