← FinOpsAid blog

Your dormant GitHub seats are a security problem, not just a cost — FinOpsAid blog

Your dormant GitHub seats are a security problem, not just a cost

An unused GitHub seat shows up on two ledgers — the one finance watches and the one security should. A dormant account with live access is waste and risk at once, and the cheapest thing you'll ever remediate.

The usual story about an idle GitHub seat is a cost story: you're paying for a licence nobody uses, so reclaim it. That's true, and it's worth doing on its own. But it undersells the problem, because a dormant seat is rarely just a dormant licence. It's usually a dormant account — one that still holds access to repositories, still counts toward your permission surface, and still represents a way in. The same account sits on two ledgers at once, and most organizations only ever look at one of them.

Two ledgers, one dormant account

One dormant account on two ledgers A single dormant GitHub account appears simultaneously on the finance ledger, as a licence that renews and counts toward the seat total, and on the security ledger, as live repository access with standing permissions and credentials nobody rotates. Most organizations only review the first. THE SAME ACCOUNT, COUNTED TWICE — REVIEWED ONCE One dormant account FINANCE LEDGER A licence you pay for Renews without a decision Counts toward the seat total Reviewed at renewal, if at all. SECURITY LEDGER Live repository access Standing permissions Credentials nobody rotates Nobody is watching an account that never acts. Reclaiming the seat closes both at once — the cheapest remediation you will ever run.
Dormancy is exactly what makes the security half invisible. Anomaly detection, access review and alerting all key off activity, and this account produces none — right up until someone uses it.

Every seat you assign appears in two places. On the cost ledger, it's a recurring charge — the thing FinOps tracks and finance questions at renewal. On the risk ledger, it's a credential with standing access to code and infrastructure — the thing security cares about. When a seat goes quiet, it doesn't leave either ledger. It becomes a charge nobody defends and an access grant nobody's watching.

Treating those as two separate problems — a cost audit run by one team, an access review run by another, months apart — is how the dangerous cases slip through. The account that's expensive and the account that's risky are frequently the same account. Looked at together, it's obvious. Looked at separately, each team assumes the other is handling it.

Why dormant plus privileged is the dangerous combination

Dormancy and privilege are each manageable on their own. Together they're a problem. An active developer with broad access is watched by definition — their activity is visible, anomalies stand out, colleagues would notice something off. A dormant account with the same access is watched by no one. There's no baseline of normal activity, so there's nothing for misuse to stand out against.

That's the combination worth hunting: an account with no recent activity, broad repository access, and no recent sign of strong authentication hygiene. It's paying rent on your cost ledger and sitting as an unattended entry point on your risk ledger. Nobody would provision that account on purpose. It exists because it was provisioned once and never revisited.

Permission drift: access only ever accrues

Here's the quiet mechanism that manufactures these accounts. In most organizations, access is granted constantly and removed almost never. Someone joins a project and gets added to its repos. They rotate to another team and get added to its repos too — but the old access is rarely cleaned up. Over a year of moves, promotions, and one-off "can you just give me access to this" requests, an account's privileges only grow.

Multiply that across everyone and your org's permission surface expands silently, month over month. No single grant is wrong; the accumulation is. And you can't see accumulation in a snapshot — a point-in-time access list tells you who can touch what today, but not that it's twice what it was six months ago. Seeing drift requires history: the same access map, versioned over time, so the direction is visible. That trend is the governance signal that matters, and it's exactly the signal a one-time review can't give you.

The offboarding gap

The sharpest version of all this is the departed employee. Someone leaves, and offboarding remembers to disable the obvious things — but the GitHub-specific ones lag. The Copilot seat keeps billing. The repository access stays live. The account is now maximally dormant and still privileged: no legitimate activity will ever come from it again, and every day it retains access is pure downside on both ledgers.

This is the exact intersection of the cost problem and the security problem, and it's why offboarding deserves a GitHub-specific checklist that covers seats and access, not just SSO. The seat you forget to reclaim is the access you forgot to revoke.

Audit both ledgers in one pass

The fix is to stop running cost and governance as separate exercises on separate calendars. Look at dormancy, access breadth, and authentication posture together, in one review:

Run that one pass and each finding pays twice: a seat reclaimed is money saved, and access revoked is risk removed. A dormant, over-privileged account is the cheapest thing you will ever remediate, because fixing it costs seconds and the only thing standing between you and the fix is seeing it.

Fusing those two ledgers into one view — dormancy and cost next to access and permission drift, with history retained so the trend is visible — is a thing GitHub's own tooling won't do for you, and it's precisely what FinOpsAid was built to do: Security & Governance and Savings reading from the same nightly-snapshotted warehouse, so the account that's wasting money and the account that's carrying risk are the same row on the same screen.

Frequently asked questions

Why is a dormant GitHub account a security problem?

Because it is an unattended credential with live repository access. Nobody is watching the account, so nobody would notice a compromise — and if the account also holds elevated permissions, a single credential can change access and billing for the whole organization.

What is permission drift?

The one-way accumulation of access. Elevation gets granted to unblock something urgent and is essentially never revoked afterwards, so admin lists and repository collaborator lists only ever grow. It is the most common governance finding, and it is invisible unless something explicitly audits it.

How do I audit GitHub cost and access at the same time?

Pull one list of accounts with their last activity, seat assignment, two-factor state and repository access, then read it twice. Once as a cost question — which of these are we paying for and not using — and once as a risk question. The dormant plus privileged rows are where the two answers overlap.

Want to see your dormant, over-privileged GitHub accounts on one screen? Connect your GitHub org — read-only and free during beta — or explore the demo dashboard first.