This is what I struggled with myself, whether basing the research on people using the key is even relevant. But to get the key, they first have to be watching repos go public. So the watching is the common step, whatever the motive behind it. That's where the 6 minutes comes from.
Fair to call out. This did come out of me building a product in the space, and I'd rather disclose that than bury it. The method and numbers are real, happy to get into either.
The 6 minutes was the earliest contact, not the typical one. Most first hits came around 8 minutes. I agree there has to be something delaying repos showing up. I was expecting even 60 seconds of exposure to be enough to get caught.
That matches what I saw. One of the actors was a Hetzner host running TruffleHog, and the busiest was a harvester on two OVH IPs doing nothing but GetCallerIdentity checks. So yes, someone is polling the public events feed and scanning whatever shows up. The keys got found the moment the repo was visible to that feed.
Don’t have data to answer that, but it’s a very good question. Weighting it by the number of contributors would make the data more honest, and probably more interesting. Will consider a follow-up based on this angle - thanks!
That's fair, and it's a real limit of measuring GitHub config. If a team runs review or merge gating in a separate tool, or mirrors to GitHub from somewhere that's their actual source of truth, the scan won't see it and they'd look unprotected when they aren't. The finding is really about repos where GitHub is the place the work happens, and even then it's public repos only. Worth saying plainly so the number isn't read as more than it is.
Right? The part that surprised me was that most of them turn branch protection ON and then don't require any check to pass. So the gate is there, it just doesn't gate anything. Makes me wonder if private repos are the same or if the public ones just get less attention.