Scoring a GitHub Profile: Genuine, Gamed, or Borrowed

You have a developer's GitHub profile open. There are green squares going back years, a repo with a few thousand stars, a contributor badge on something well-known. Before any of that becomes evidence in a shortlist, you need to decide whether it is a real footprint or a manufactured one. This guide is the judgement layer that sits before technical reads: it scores a profile for authenticity, separates a real developer's history from a backdated graph, a purchased account, or a borrowed identity, and tells you the one check that confirms authorship. It is written for engineering managers, technical founders, developer-relations leads, and technical sourcers who trust GitHub signal into hiring or partnership decisions.

Why a profile needs an authenticity score before you read it for skill

A contribution graph is an identity claim, not proof of who wrote the code. Every downstream read - technical diligence, star traction, contributor ranking - assumes the profile in front of you is real, and that assumption is cheap to fake.

The mechanism is worth stating plainly, because it is the root of every failure in this guide. Git records two timestamps set by environment variables, GIT_AUTHOR_DATE and GIT_COMMITTER_DATE, and GitHub reads them without verification. Anyone can set any date on any commit and produce a graph that looks like years of experience. The tools to do it are public and named: fake-git-history, GitHub Filler, GitArt, and bash and Python backdating scripts. Empty padding is a single command, git commit --allow-empty. A convincing graph takes about ten minutes.

The deeper problem is at the commit level. By default the author name and email on a commit are just text. Git never checks them, so anyone can set user.name and user.email to any value and produce a commit that claims to be from someone else. A proof-of-concept repo exists that attributes commits to arbitrary real users. So the green density everyone eyeballs is the weakest signal on the page. The load-bearing signals are cryptographic authorship and recall of the code, not the shape of the graph.

This matters at volume. In Refolk's index of professional profiles there are 348,340 people with a current "Software Engineer" title in the United States and 544,914 in India, about 1.56x the US figure. High-volume remote-hiring funnels touch the larger pools, and that is exactly where borrowed-profile pressure concentrates. The identity-first step below is not optional at that scale.

The six dimensions to score, and what each one proves

Score a profile on six dimensions, in order, because a borrowed handle invalidates everything downstream of it. Each dimension proves one thing, and each has a way it lies.

The order is deliberate. Fix identity first: if the handle is borrowed, the graph, the repos, and the stars all belong to someone else, and grading them tells you nothing about the person on the call. Signatures and stars refine a picture that identity and repo substance have already framed.

The confirming check: what the .patch trick and the Verified badge actually prove

Two mechanisms move you from eyeballing to evidence: the .patch email check and cryptographic signatures. Neither is optional folklore; both are documented by GitHub itself.

The .patch check confirms which name and email are attached to a commit. Find any commit by the person on GitHub and append .patch to the URL. GitHub renders the commit as a Git patch email, and the From header shows the committer's name and address. This is how you close step one: you get a real name and email tied to the work, and you can then confirm the person controls that email. Commits appear on the contribution graph only if the commit email is associated with the account, which is also why a mismatched email is a linkage problem, not proof of impersonation.

A signature is stronger. It is made with a private key only the signer holds, and anyone with the matching public key can confirm authorship and integrity: if a single byte changes, verification fails. When GitHub has the public key on file and the signature checks out, it marks the commit "Verified" or "Partially verified." That badge is the closest thing on the page to cryptographic proof that a specific person made a specific commit.

The order of operations is the point. The graph is the weakest signal, the .patch header is stronger, and a verified signature is stronger still. But even a wall of verified commits does not prove the person understands the code well enough to build on it. That is what the live walkthrough is for, covered below.

Reading fake versus organic stars without over-flagging

Stars matter only on repos the person owns or maintains, and the strongest simple heuristic is the fork-to-star ratio. A star costs nothing and conveys no commitment; a fork is a signal someone actually used the code.

Independent verification of 20 repositories found that for some projects 36% to 76% of stars came from zero-follower accounts, and the fork-to-star ratio fell below one-tenth of the baseline observed for organic projects. The visible tell is a vertical cliff: many stars in hours or days, rather than gradual growth. But context is everything. Libraries fork heavily; CLIs, demos, and personal tools rarely do, so a low ratio on a non-forkable tool is not manipulation. Compare against similar-category repos, then sample stargazers, and require multiple signals before you call a ring.

Star inflation is economically rational, which is why it persists. Publicly disclosed venture benchmarks sit at 2,850 stars for seed and 4,980 for Series A, and GitHub-active startups are 15 percentage points more likely to have raised a financing round. Buying toward a number has a direct payoff. AI and LLM repositories alone carry an estimated 177,000 fake stars, the largest non-malicious category.

Enforcement does not clean this up for you. GitHub removed 90.42% of repos flagged by one detection study but only 57.07% of the accounts that executed the starring. The labour force stays live, so a clean repo today can be re-inflated tomorrow. When you score stars, you are scoring a moment, not a permanent state.

The fraud you are actually up against: purchased and borrowed profiles

The signal that matters most for hiring is not fake stars but a purchased or borrowed profile: a real-looking account whose history someone else built. A burst of recent commits on a years-old account is the classic tell, along with whole repos cloned, licenses yanked, and commit dates back-filled to look organic.

The market has tiers, and the price ladder tells you which checks each tier is built to defeat.

The budget tier fails the cheap tells: zero-follower, no-bio, empty accounts. The premium tier is built precisely to pass your first three checks. Eighty to ninety cents buys aged profiles, years old, with their own repositories and contribution graphs, delivered gradually to mimic organic growth. That is why one heuristic is never enough, and why the empty-account tell survives at the bottom while the expensive fraud slips past it. Reused AI profile photos across identities are one more checkable signal - reverse-image the avatar and look for the same face on other handles.

Refolk collapses the identity-first work by letting you ask for the signal you actually trust. Instead of opening profiles one at a time and running .patch checks by hand, you can specify verified signatures and self-owned repositories in the query and get a list already filtered toward the load-bearing layers. Refolk searches the public GitHub graph, public LinkedIn records, and the open web from one plain-English ask, which is where the manual version of this rubric spends most of its time.

The scoring procedure, start to finish

Run these eight steps in order. Steps one through six are reviewer work you can do from the profile alone; step seven is a live check a hiring manager runs; step eight is the verdict. The identity check comes first because a borrowed handle makes everything after it meaningless.

The seventh step is the one the fraud economy cannot beat. Pick a specific commit from about six months ago and ask the candidate to walk through it: why the design decisions were made, what the tradeoffs were, what they would change. A fraudster cannot navigate a codebase they did not write. Ownership of a handle and screen-sharing a repo proves neither authorship nor understanding; only recall of design decisions in old code does. Allow warm-up navigation and judge design-decision recall, not typing speed, so nerves do not read as fraud.

Use this rubric to turn the six dimensions plus the interview into a single verdict.

Identity linkage (.patch email confirmed as theirs): ____
Graph shape (organic vs burst/grid/impossible-age): ____
Repo substance (real code vs padding): ____
Signatures (verified present / all unsigned): ____
Star & fork pattern on owned repos (organic vs inflated): ____
Account ring signals (standalone vs farmed): ____
Authorship walkthrough (recalls design decisions vs cannot): ____

RULING:
- TRUSTED SIGNAL: identity confirmed AND repo substance passes AND walkthrough passes.
- NEEDS VERIFICATION: any flag, or walkthrough not yet run. Route to a live check.
- DISCARD: identity fails (borrowed handle) OR walkthrough fails on own code.

How this goes wrong: false positives that reject real developers

The most expensive mistake in this work is not trusting a fake - it is discarding a strong, real developer over a signal that lies. Every dimension has a benign explanation you must rule out before you flag.

Start with the graph, because most bad calls happen here. A sparse or broken graph is often legitimate. By default the graph shows only public-repo activity, so private and enterprise work is invisible unless the user opts to show private-contribution counts with details anonymized. Only contributions to the default branch are counted. Contributions from forks do not appear unless merged into the parent. Squash-and-merge collapses many commits into one. And a generic or mismatched commit email, such as jane@computer.local, cannot be linked to a GitHub account, so those commits never show on the graph at all. None of these are fraud.

The rest of the false positives follow the same pattern: a real signal read out of context.

Two of these deserve emphasis. Being listed as a contributor could mean the person wrote 80% of the codebase or merged one typo fix three years ago. The contributor badge is a claim of participation, not authorship, so git blame -e on the files or a look at commit volume tells you which. And the interview walkthrough has a real false-negative rate: a genuine author can stumble under pressure. The fix is not to lower the bar but to change what you grade - design-decision recall survives nerves in a way that live typing does not.

What to check before you call it done, and how to keep the read current

Before you attach a verdict to a profile, confirm you have run the load-bearing checks, not just eyeballed the graph. Fraud infrastructure persists because enforcement is reactive, so a call you make today has a shelf life.

Two things move under you. First, the star picture is not stable: one study found GitHub removed 90.42% of flagged repos but only 57.07% of the executing accounts, so the starring workforce stays live and a clean repo can be re-inflated. Re-check star growth shape near a decision, not months before. Second, the fraud market keeps pace with detection. When a public investigation named specific accounts, related fake-star accounts were purged within 48 hours - reactive, not proactive. Assume the premium tier is always a step ahead of the cheap tells.

Keep two habits. Run the identity check and the authorship walkthrough on every profile that reaches a real decision, because those are the two layers the economics cannot beat: you can buy an aged account and a five-year graph, but you cannot buy recall of why a specific commit exists. And when a profile clears the bar, record which signals drove the call, so the next reviewer inherits your reasoning instead of re-running it from the green squares.