Why we do manual pentesting

The first question we get on almost every scoping call is some version of this: "Can't a scanner do most of this?" It's a fair question. Scanners are fast, they are cheap, and the industry has spent fifteen years making them better at what they do. If your goal is to find the CVE-2021-44228 in your fleet, a scanner is the right tool. If your goal is to know whether an attacker can turn a low-privilege account into a data-exfiltration incident by chaining four small logic flaws, a scanner is the wrong tool.

This is the thing we keep bumping into. The vulnerabilities that end up in the news — the ones that make legal counsel call you at 9 p.m. — are almost never a single unpatched service. They are a sequence. Someone signs up for a trial account. The trial account has weaker rate-limiting on password resets. The password reset endpoint enumerates registered emails. From the enumeration they identify a Slack integration bot account. The bot account has a leaked token in a public GitHub repository. The token has scopes it should not have. Fifteen minutes later they are reading your Jira.

No scanner in the world models that chain. Every step is technically defensible in isolation. The vulnerability is the chain.

What manual testing actually looks like

When one of our testers spins up an engagement, the first two days are almost entirely mapping. They enumerate every endpoint your app exposes, every role your permission model supports, every third-party integration, every publicly reachable subdomain, every JS bundle for hidden routes. They walk through the app the way a curious new employee would, but with a notebook. By day three the tester has a mental model of your business logic that is often better than the model held by the engineer who wrote the feature two years ago and moved teams.

Then the actual attacking starts. A tester takes each role in your app and asks, systematically, whether they can access data or perform actions that the design says they should not be able to. They tamper with request bodies. They swap object IDs. They race concurrent requests. They walk state machines backwards. They read your JavaScript for API endpoints your engineers forgot were still live. And when they find something, they exploit it end-to-end — not just prove it exists, but prove it matters.

The finding mix that comes out the other side

You can tell a manual pentest from an automated one by looking at the finding list. Automated tools find the same things every time: missing security headers, outdated jQuery, TLS misconfigurations, weak cookie flags. Every one of those findings is real, and every one of them is worth fixing, but none of them is going to be the reason an attacker walks off with your customer database.

Manual pentests turn up a different mix. Broken object-level authorization. Mass-assignment bugs where a hidden is_admin field made it into the user model. Business-logic bypasses where cancelling an order after payment refunds the customer without releasing the inventory. Race conditions in coupon codes. Server-side request forgery via URL fields that were never designed to be user-controlled. These are the findings that show up in the reports that your engineering leadership actually reads.

Why we won't sell scanner-driven testing

There is a large market for pentests that are, in truth, badly-branded vulnerability scans. A junior consultant runs Burp Scanner, cleans up the output, wraps it in a PDF with a company logo, and ships it. The client gets a document that satisfies an auditor. The auditor stamps the box. Nothing about the actual security posture has changed.

We won't do that work. Not because we think there is anything wrong with clients who need a box checked — sometimes that is genuinely what compliance requires — but because doing it dishonestly damages the whole industry. If a "pentest" is just a scan with better packaging, then the word pentest stops meaning anything. And when someone eventually gets breached through the exact class of finding a real pentest would have caught, everyone loses.

Our engagements cost more than a scanner. They take more time. They require a mutual NDA and grown-up access provisioning. And they produce reports that engineers actually implement, because engineers can tell when they are being talked to by someone who understands their code. That is the tradeoff we sell, and the one we are proud of.