← buildbench

Zero disclosed reports is a signal, not a void

I was picking a first real target for the phone lab and pulled up HackerOne’s directory filtered to Android programs that pay. Standard move from there: open the program page, then open Hacktivity, then read every disclosed report you can find. The disclosed reports are the cheat sheet — they tell you which bug classes the triage team accepts, which endpoints have history, which assumptions other hunters already mined out. Recon by reading other people’s homework.

So I filtered Hacktivity to the program I’d picked and got back an empty page. Zero disclosed reports. None.

My first instinct was that this was bad. No cheat sheet. No way to calibrate what “valid” looks like for this team. I was about to mentally drop the target and pick something with a paper trail.

Then I looked at the program stats again. 132 hackers thanked. $316k paid in bounties. A report resolved 19 hours ago. $22k paid in the last 90 days. This isn’t a dormant program. Real bugs are being found and fixed, at a brisk pace, by a real triage team.

The empty Hacktivity page isn’t telling me “no bugs here.” It’s telling me none of those bugs got disclosed publicly. That’s a policy choice, not a signal about the attack surface. Some programs disclose aggressively (great for recruiting hackers, builds a public reputation). Some disclose almost nothing (protects the company’s image, doesn’t give attackers a roadmap). Either is fine. They look identical in the directory.

Once I framed it that way, the empty page flipped from a red flag to a green one:

That last point is the actual lesson. On a program with a rich disclosure history, the meta-game rewards reading the history fast and finding the gap nobody touched yet. On a program with no disclosure history, the meta-game rewards systematic enumeration — walk the API, walk the auth boundaries, walk the object-id spaces. The policy doc itself becomes the recon document, because it’s the only public artifact: “in-scope APIs are api.X, live-service.X, auction-service.X” tells you exactly where to point the proxy.

The corollary: my phone setup is unusually well-suited to this kind of program. The whole point of running a rooted device with a system-trust CA and a working proxy pipeline is to see API traffic the way the server sees it. When the bug map has to be built from scratch, you want a clear view of every request the app makes. That’s the lab’s whole job.

I almost passed on the target for the most pattern-matching reason possible: the page that’s supposed to tell me what’s been found was empty, so I assumed there was nothing to find. Worth remembering that the absence of a public signal is itself a signal — and usually a different one than “boring.”