What Security Researchers Find Hiding in Public Git Repos
Most of the Linux/open-source conference talks I've watched for other classes have been fine. This one actually stuck with me.
Marta Rybczynska, a security researcher, gave a talk at the Linux Foundation's Open Source Summit Europe called What have we found in Git repos? — and the short answer is: more than you'd think, and probably more than you'd want.
Git is the version control system Linus Torvalds built (yes, the same Torvalds who started Linux), and it's what powers GitHub's public repository hosting. Virtually every open source project you've ever used — and millions you haven't — lives there, with its full history open for anyone to read.
That history is the problem. Rybczynska's research found that developers routinely leak sensitive information into public repos without realizing it: API keys committed straight into source files, build-machine configs, access hints buried in scripts. Project metadata gives away even more — who the authors and maintainers are, who actually has merge authority, and branch names that announce exactly what they shouldn't, like urgent_security_fix.
The part that stands out isn't that this information exists — it's how easy it is to collect at scale. Her research involved automating the scraping and analysis of this data across huge numbers of repos, and her point was blunt: if a researcher can build that pipeline, threat actors almost certainly already have.
The Traefik example
She illustrated the risk with Traefik, an open source reverse proxy I've actually used myself. Traefik sits in front of a web server and reads incoming request headers to figure out which backend application a request on, say, port 8443 is actually meant for — so one server can quietly host several different sites behind one address. It's useful, and it's also sitting directly in the path of every request that server handles, which makes a vulnerability in it a real problem.
Rybczynska found a case where a Traefik CVE had already been fixed in the codebase before the CVE itself was published — her research points to patches showing up in commit history days to weeks ahead of the official advisory. That gap matters because most vulnerability scanners and automated patch systems work by scraping CVE.org for new entries — they don't watch commit history. For that window, anyone running the vulnerable version had no automated way of knowing they needed to patch, even though the fix already existed in public view.
Her suggestion: push the fix and publish the CVE at the same time, so there's no window where the patch is visible but the advisory isn't. And it's worth sitting with the implication here — if a researcher found this gap just by watching commit history, it's a safe bet threat actors who specialize in exactly this kind of scraping found it first. She also noted a pattern worth remembering: when a stable branch that's been quiet for a while suddenly sees a flurry of commits, that's often a tell that a security fix is in progress, CVE or not.
Takeaway
The uncomfortable lesson here isn't really about Traefik. It's that "public" and "obscure" aren't the same thing, and a lot of projects are leaning on the second one without realizing it. If your security posture depends on nobody noticing a branch name or a commit timestamp, you don't have a security posture — you have a head start, and it's shorter than you think.