Your GitHub Is a Vault, Not a Graveyard
Your GitHub is not just where your code lives. It is where your keys live, your build pipeline lives, and your path to production lives. It is a vault. Most people run it like a junk drawer.
Open your organization’s settings right now and look at three lists almost nobody reopens after the day they set them up.
The installed GitHub Apps and authorized integrations. The personal access tokens and deploy keys. The list of people with access, and what each one can do.
If you are like most teams, those lists have grown for years and shrunk never. An integration you approved once to try a tool, still connected. A token you made for a script in 2022, never expired. A contractor from a project that ended two summers ago, still a collaborator. And now a row of bots and AI coding agents, opening pull requests faster than anyone can read them. Every one of those is a door into the vault. You have lost count of the doors. That is the graveyard.
Why the graveyard is new, and worse
Two things changed recently.
First, connecting something to your GitHub now takes one click and a broad permission grant you skim past. “Authorize.” Done. The tool you were curious about for one afternoon now has read access to every private repository you own, and six months later you do not remember it exists.
Second, the agents. AI tools and bots open a flood of pull requests, bump dependencies, and touch your repositories on their own. Useful, genuinely. But a flood trains a reflex: approve, approve, approve, without really looking, because looking closely at all of them is impossible. The danger is not any single bot. It is that blind approval becomes the house habit, and a habit is exactly what an attacker builds a plan around. The $6.3 billion Binance theft I wrote about started the same way: trust that had quietly become automatic, on a path nobody was watching closely.
The attacker rarely breaks your code
They walk in through something you connected and forgot.
In 2022, attackers stole OAuth tokens that companies had granted to two popular continuous-integration tools, and used those tokens to clone private repositories from dozens of organizations. The code was not hacked. The key to it, handed to a third party and trusted, was.
A year earlier, a widely used testing tool was quietly altered so that for two months it copied the secrets out of its customers’ build pipelines, the very keys and tokens that unlock everything downstream. Many companies, one compromised integration.
That is the pattern, and it sits under every essay I write: the danger is rarely one weak wall. It is too much trust handed from one part of a system to the next, with too few checks at the handoff. Your forgotten integrations are that trust, still live, long after anyone is watching.
It is not only machines
When you hand repository or DevOps access to an outside team, you are handing over the same vault, to people this time. Where they sit, what law reaches them, whether anyone can be held to account if a key walks out the door, all of that is part of what you are giving, not a detail to sort out later. I made the full case in The Hidden Risks of Offshoring Cybersecurity. The short version: cheap access is only cheap until the first incident.
The machine half of the fix
Hygiene, and it is boring on purpose:
- Least privilege for every token, key and app. The narrowest scope that does the job, and an expiry date on all of it. A token with no expiry is a key you will still be handing out long after you forgot you cut it.
- Prune on a schedule. Once a quarter, open those three lists and remove what you cannot explain. If you do not know why an integration or a person still has access, that is your answer. Revoke it.
- Do not auto-merge what no human read. An agent can open the pull request. A person owns the decision to let it into the code that ships.
- Treat the pipeline like production. Because it is. Whoever controls your build controls what reaches your customers.
The human half, and the real rule
Here is the part the settings page cannot do for you.
A key to your GitHub is a key to your business. The settings page will let you grant it to anyone on earth in two seconds, and that speed is the problem, not the feature. Speed is what builds the graveyard.
So before you hand someone the keys, slow all the way down. Invite the person. Pour a cup of jasmine tea. Sit across from them and look them in the eye. Talk long enough to know who you are actually trusting, because that is what access is: trust, made real and handed over. A grant you click in a hurry tells you nothing about the person on the other end of it. A conversation does.
That is not old-fashioned. It is the one control that scales down to the thing that actually matters, a single judgment about a single person, which no permission screen will ever make for you.
The point
Your GitHub is a vault. Stop running it like a graveyard where access goes to be forgotten. Know every key you have handed out, to every person and every machine, and be able to say, out loud, why each one still holds it. The keys you cannot explain are not saving you time. They are the ones that get used against you, and you will not see it coming, because you stopped looking a long time ago.