[-] peternovakdev@programming.dev 5 points 2 months ago

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.

[-] peternovakdev@programming.dev 4 points 2 months ago

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.

[-] peternovakdev@programming.dev 3 points 2 months ago

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.

[-] peternovakdev@programming.dev 1 points 2 months ago

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.

89

Live AWS keys in 75 throwaway repos, each made public for one of five windows from 60 seconds to 12 hours, every use logged. The keys were tripwires; the real question was who notices a private repo going public, and what they do once they're in.

The most useful finding is the dull one: re-hiding the repo does nothing. One busy harvester kept re-validating the captured keys for a day after the repos went private again. Only rotating the key stops it.

This came out of building a monitor for exactly these repo-setting changes.

[-] peternovakdev@programming.dev 2 points 3 months ago

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!

[-] peternovakdev@programming.dev 5 points 3 months ago

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.

[-] peternovakdev@programming.dev 2 points 3 months ago

Good distinction. If it's useful, GitHub lets you require checks and still grant a bypass for specific people or teams, so the hard rule and the emergency escape hatch can coexist, and the scan reads that as passing. Could be you've already weighed that, in which case ignore me.

[-] peternovakdev@programming.dev 6 points 3 months ago

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.

106

I scanned the public repos of 128 YC-backed dev tools companies, 6,195 repos in total. I expected the companies building our tooling to enforce the basics on themselves. Only 2 of the 128 require any status check to pass before merging.

peternovakdev

0 post score
0 comment score
joined 3 months ago