Security testing
Testing that produces fixes, not just findings.
A report full of severity ratings nobody acts on is a wasted engagement. The deliverable is a prioritized set of issues an engineering team can actually work through, with reproduction steps that hold up.
Plenty of testing engagements end with a PDF that gets filed and forgotten. Usually that is because the findings were written for the buyer rather than for the person who has to fix them, long on severity language, short on the detail an engineer needs to reproduce the issue and confirm it is gone.
I write findings the other way around. Each one includes what the issue is, how to reproduce it, what an attacker gets from it, and what a fix looks like in context. Severity is there, but it is not the point.
Published disclosures
Vulnerabilities I found, reported, and worked through to a public CVE assignment. Each links to the full write-up.
What I test
Web applications
Authentication and session handling, access control, injection, business-logic flaws: the issues that actually get exploited, not just the ones a scanner reports.
APIs
Authorization at the object and function level, data exposure, rate limiting, and the gap between what the documentation says and what the endpoint does.
Mobile applications
Client-side storage, transport security, hardcoded material, and the backend the app talks to, which is usually where the real finding is.
Cloud environments
Identity and permission boundaries, exposed storage, network segmentation, and configuration drift between what was designed and what is deployed.
Need something tested properly?
Tell me what the system is and what you are worried about, and I will tell you whether a test is the right next step.