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.
I lead the penetration testing practice at CLA (CliftonLarsonAllen), where my team runs offensive security engagements for clients that range from Fortune 100 enterprises to small and mid-sized businesses. That range is the useful part: the same class of finding shows up in a global manufacturer and in a thirty-person firm, and the only real difference is how much of it nobody had looked at yet.
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.
- CVE-2026-12960One Exported Service, Six Free Rides: How I Found CVE-2026-12960 in the ASUS Router AppNVD ↗
- CVE-2021-26837SqlNow: How One Apostrophe in DeliverNow Turned Into CVE-2021-26837NVD ↗
- CVE-2020-5148AuthForce: Single Sign-On, Single Sign-Over, and the curl That Became CVE-2020-5148NVD ↗
- CVE-2021-3262SqlSpark: The Wheels on the Bus Went SELECT * FROM, and That Became CVE-2021-3262NVD ↗
What I test
The practice covers the full attack surface, so these can be scoped as one engagement instead of four. Attackers do not respect the boundary between an app test and a cloud review, and neither should the assessment.
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.
Industries
Sector context changes what matters. A dealership's exposure is not a hospital's, and neither looks like a private equity portfolio company's. These are the industries the practice works in regularly.
- Agribusiness
- Food and Beverage
- Construction
- Dealerships
- Education
- Financial Services
- Franchises
- Government
- Health Care
- Life Sciences
- Logistics
- Manufacturing
- Nonprofits
- Private Equity
- Professional Services
- Real Estate
- Retail and Hospitality
- Technology
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.