How do you verify GitHub contributions without trusting self-reported skills?

Alex — Sat, 23 May 2026 13:23:38 +0000

I've been thinking about a problem that doesn't get talked about enough in hiring: the gap between what someone claims about their work on linkedin and what they actually did.

Anyone can list "open source contributor" on their resume. Anyone can paste a GitHub repo URL in a portfolio. But without looking at the actual commit history and contributor data — you have no idea if that person wrote 80% of the codebase or merged one typo fix three years ago.

So I started building a system to verify this properly. Here's what I learned — without giving away the methodology we use, because honestly, the moment you publish your exact algorithm, people optimize for it rather than actually doing the work.

The naive approach fails immediately

The first instinct is to just check if the person's GitHub handle appears in the contributor list. Simple, right?

Not quite. Three problems come up immediately.

People have multiple GitHub accounts. Work account, personal account, old account from college. A developer might have significant contributions spread across two or three handles. Checking one handle misses the full picture.

Contribution depth varies wildly. Being listed as a contributor could mean 2,000 commits or 1 commit. The contributor list alone doesn't tell you which. You need actual commit counts per author to understand the depth of contribution.

Public repos can be submitted by anyone. I can submit any famous open source repo to a portfolio system and imply I contributed to it. Without verifying my actual handle against the contributor data, the system has no way to know if I wrote the core architecture or just starred the repo.

What actually works — the principles

I'm not going to share the exact scoring formula. But I can share the principles that make verification meaningful.

Verify account ownership first

Before you can verify contributions, you need to verify identity. The only reliable way to confirm someone owns a GitHub account is OAuth. When someone authenticates via GitHub OAuth, you get a cryptographic proof of ownership — not a claim.

This is the identity anchor. Every contribution check runs against verified handles only. No claims accepted.

Handle the multi-account reality honestly

Developers legitimately use multiple GitHub accounts. A good verification system needs to support this — each additional account verified through its own OAuth flow.

The critical constraint: one GitHub account should only be linkable to one professional identity. Otherwise the whole system can be gamed by linking someone else's high-signal account to your profile.

This requires exclusive handle claiming. First claim wins. If a handle is already associated with another profile — it's blocked. No exceptions.

Contribution depth matters more than presence

There's a meaningful difference between someone who authored 40% of a codebase and someone who fixed a typo. Both show up in the contributor list. Only one actually shaped the project.

The verification system needs to reflect this distinction. Not all verified contributions are equal. Depth matters. History matters. Consistency over time matters more than a spike of activity.

Unverified doesn't mean worthless — but it means discounted

Not everything can be verified through OAuth. Public repos, old contributions, work done under inaccessible accounts — these are real but can't be fully verified.

The right approach isn't to ignore unverified sources. It's to discount them heavily and label them clearly. A user should always know what's verified and what isn't. A recruiter should always be able to see the difference at a glance.

Transparency about what can and can't be verified is more credible than pretending everything is confirmed.

Gaming prevention is architectural, not cosmetic

If your verification system can be gamed by submitting famous repos you didn't write, it's not a verification system — it's a vanity metric generator.

The aggregation rules matter as much as the scoring rules. How multiple sources combine, how unverified sources interact with verified ones, how the system handles edge cases — these decisions determine whether the final score means anything.

We've spent a lot of time on this. The details stay internal.

What this doesn't solve

No verification system is perfect. Worth being honest about the limitations.

Commit squashing — some teams squash all PRs into single commits before merging. A developer who wrote 40 separate commits might appear as 1 in the contributor list.

Pair programming — code written together often gets committed under one person's handle. The other person's contribution is invisible to the API.

Private repos — everything above works for public repos. Private repos require broader OAuth scope, which is a bigger ask for users.

Old accounts — significant contributions under an account you no longer have access to can't be verified without OAuth on that account.

These are real limitations. A verification badge isn't a guarantee — it's evidence. The weight of that evidence depends on the depth and breadth of verified sources.

Why this matters now

LinkedIn profiles are self-reported claims. AI writes perfect ones in 30 seconds. Endorsements come from people who've never seen your code. The entire professional identity system is built on statements that cost nothing to make and nothing to fabricate.

GitHub commits are different. A three-year commit history with consistent cadence, real collaborators, and downstream ecosystem impact — that can't be generated by a chatbot. That's real signal.

The question is how to surface that signal in a way that's portable, shareable, and resistant to gaming. That's the problem worth solving.

Where this is heading

I've been building this verification logic into a larger system called Warrant — a proof-of-work portfolio that computes verified scores from GitHub signals rather than letting engineers describe their own skills.

The exact methodology stays opaque — intentionally. The moment you publish the formula, people optimize for the formula instead of doing real work. We'd rather be the PageRank of professional identity than the ATS keyword game.

If you're an engineer curious to see what your verified GitHub signals look like, you can try it at warrant-plum.vercel.app. Free, currently in beta, no credit card.

If you've thought hard about contribution verification — I'd genuinely like to hear what edge cases you ran into. The ones I listed above are the ones keeping me up at night.

DEV Community: Alex