31% Interviewed a Fake: Why GitHub Archaeology Beats "Verified"

Checkr's 2025 Hiring Hoax Survey of 3,000 managers landed with a stat that should have reorganized every sourcing team's week: 31% personally interviewed a candidate using a fake identity, and 35% confirmed somebody other than the listed applicant showed up on the call. By the time a candidate is on your Zoom, the identity battle is already lost. The move is to triangulate against artifacts that existed on the open web before the hiring cycle began, and that is a sourcing job, not an HR-tech one.

The 2026 fraud numbers make this a sourcing problem

Pre-interview identity verification is now a sourcing deliverable because the point of failure has moved upstream of HR, background checks, and video platforms. The candidate on the screen can be a face-swap, a proxy, or a GenAI puppet, and the vendors paid to catch that are losing ground fast.

Here is the baseline, pulled straight from the reports:

• 31% of hiring managers interviewed a candidate with a fake identity (Checkr, n=3,000).
• 35% confirmed a proxy, meaning someone other than the listed applicant did the interview (Checkr).
• 59% suspected AI-assisted misrepresentation; 62% believe candidates are now better at faking identities than hiring teams are at catching them (Checkr).
• 41% of enterprises say they have hired and onboarded a fraudulent candidate (GetReal Security).
• +1,300% jump in deepfake fraud attempts across voice and video channels from 2023 to 2024 (Pindrop 2025 Voice Intelligence Report).
• Experian's 2026 Future of Fraud Forecast put deepfake job candidates in its top five fraud threats of the year.
• Gartner projects 1 in 4 candidate profiles worldwide could be fake by 2028, and warns around 30% of enterprises will find standard identity verification tools can no longer reliably tell a real face from a deepfake by end of 2026.

The dollar losses are already here. 23% of hiring managers reported losses exceeding $50,000 in the past year from hiring or identity fraud, and 10% reported losses over $100,000. The FBI has documented more than 300 US companies that unknowingly hired North Korean operatives using stolen identities and AI-generated personas, including the Arizona "laptop farm" case where a single operator enabled infiltration across hundreds of companies.

1,300%

Why open-web artifacts are the only verification layer that still works

Time-anchored open-web artifacts work because they existed before the candidate knew you existed, and GenAI cannot retroactively edit the past. A fake candidate can generate plausible job history in seconds. They cannot generate a 2017 Stack Overflow answer, a 2019 PyCon lightning-talk recording, an npm publish timestamp from 2020, or a commit cadence that bursts around a known 2021 release and goes quiet during the author's documented paternity leave.

Palo Alto Networks found it takes as little as 70 minutes for someone with zero image-manipulation experience to build a fake candidate capable of passing a video interview. Compare that to the five-plus years it takes to retroactively fake a credible GitHub, talks, and blog footprint, and the ROI math on pre-interview artifact triangulation is not close.

The artifacts that resist fabrication share four properties:

1. Timestamped on infrastructure the candidate does not control (GitHub, npm, PyPI, conference org sites, archive.org snapshots).
2. Cross-linked to other identities that themselves have multi-year histories.
3. Technically specific in ways only the actual author can discuss unprompted.
4. Dense enough to show human-shaped irregularity: holidays, outages, release-week bursts, quiet quarters.

Resume content fails all four. LinkedIn profiles fail three of them. This is the gap resume-screening tooling cannot close by looking at the resume, because the resume is where the fraud is designed to live.

The "Verified" checkmark is a trap

GitHub's green Verified badge on a commit does not verify a real-world identity. It verifies that the public key used to sign the commit matches the public key associated with the GitHub account. GPG keys can be generated for any name and email in minutes, so the badge proves key-to-account linkage, never person-to-key.

The real GitHub identity signal is the shape of a multi-year commit history, not any single badge. Look for:

• Holiday-shaped gaps. Real engineers go quiet around Christmas, Diwali, Lunar New Year, and the week of a child's birth. Bots do not.
• Release-correlated bursts. Commits cluster before a tagged release, taper during the stabilization window, and resume on the next milestone.
• Timezone drift. A real developer who moved from Berlin to Toronto in 2022 shows commit-hour drift that matches the move.
• Issue and PR prose. Review comments, bug reports, and PR discussions carry a writing voice that is hard to spoof across years of threads.
• Co-authored commits with people who have their own long-running histories.

The red flag is the inverse: a perfectly uniform contribution graph with green squares every day including weekends and holidays. That is almost always a commit-scripting bot pushing empty commits, whitespace edits, or single-character README changes to simulate activity. A profile that looks too healthy is more suspicious than one with realistic variation.

Cross-reference the same way. A legitimate developer's linked accounts show consistent histories that predate the GitHub profile. A fake profile tends to have linked accounts that were also recently created, or none at all.

Sourcers have the surface area HR does not

Sourcers can run this verification layer and HR cannot, because sourcers go find what the candidate did not submit while HR validates what the candidate did submit. That inverts the fraud-detection surface area entirely.

Here is the number that reframes the problem. In Refolk's index of US software engineers at the SWE, Senior SWE, and Staff SWE levels, there are 27,375 profiles. Of those, only 29 surface any github.com reference in their headline or public profile text. That is roughly 0.11%.

The ratio to internalize: the fraud rate is roughly 280 times higher than the share of engineers who voluntarily hand you a GitHub link. If you are waiting for the candidate to attach their verification artifacts to the application, you are waiting for the 0.1% who do not need the verification in the first place.

This is the work I built Refolk for. You describe the person you want in plain English, and the shortlist comes back stitched across GitHub, LinkedIn, and the open web, with the artifacts attached. The GitHub handle, the npm maintainer page, the conference talk, the Stack Overflow top tags, all tied back to the same human, before anyone opens a calendar invite.

A pre-interview triangulation checklist

Run this before the first recruiter screen, not after the technical loop. It takes about 10 minutes per candidate once you have the artifacts in hand, and it kills proxy and deepfake candidates at the cheapest possible stage.

1. Pull the GitHub profile and look at the contribution graph shape. Flag perfect uniformity. Confirm multi-year span. Note timezone of commit hours.
2. Open three random non-trivial PRs from 2+ years ago. Read the review conversation. Is there a consistent voice? Do co-authors have their own real histories?
3. Check package registries. npm, PyPI, crates.io, Maven Central. Publish timestamps and co-maintainers are hard to fake.
4. Search their name plus "site:youtube.com" and the names of relevant conferences. A 2019 lightning talk is a near-perfect anti-deepfake artifact: it is their actual face and voice from before the fraud economy scaled.
5. Pull archive.org snapshots of their personal site or blog. Registration date on the domain, first snapshot date, writing style over time.
6. Cross-reference the GitHub email to a Keybase, Mastodon, or old Twitter handle. Look for accounts that predate the GitHub profile.
7. Reverse-image search the LinkedIn photo. Not conclusive, but cheap.
8. Save two or three specific technical details (a particular PR, a design decision in a blog post, a bug they fixed in a 2021 release) to drop into the first interview. Only the real person can discuss them unprompted.

Step 8 is the one that solves the proxy-interview problem. A deepfake face-swap defeats visual verification. A stand-in impersonator defeats behavioral questions. Neither can answer an unprompted question about a specific pull request in their own repo from four years ago, because specificity of lived technical context is non-generatable.

A profile that looks too healthy is more suspicious than one with realistic variation.

What the big players are doing instead

Google, McKinsey, and Cisco have quietly reintroduced mandatory in-person interview rounds specifically because remote-only verification stopped being reliable. That is the honest admission: the video-interview identity layer is broken enough that Fortune 100 companies are paying for flights again.

For everyone else without that budget, the alternatives in 2026 look like this:

Open-web triangulation is not a replacement for background checks. It is the layer that runs first, before you spend recruiter and engineer time on someone who cannot pass a 10-minute artifact check. Forward-looking tooling like Sigstore and gitsign will eventually make commit-level identity cryptographically verifiable, but that future depends on broad adoption and is not the 2026 answer.

The 2026 answer is that sourcing verified candidates on GitHub, package registries, and the long-tail open web is the cheapest, highest-ROI fraud defense available, and the sourcing function owns it by default.

FAQ

Does a GitHub "Verified" badge prove the committer is a real person?

No. The green Verified check only proves the GPG or SSH key used to sign the commit matches the key on the GitHub account. Anyone can generate a key for any name and email in a few minutes. The identity signal comes from longitudinal commit history, co-authorship patterns, writing voice in PRs and issues, and cross-references to other long-running accounts, not from the badge itself.

What if the candidate does not have a public GitHub profile?

Most do not. In Refolk's index, roughly 0.1% of US software engineers surface a GitHub URL on their primary profile, so absence of a GitHub is the norm. Fall back to other time-anchored artifacts: conference talk recordings, package authorship on npm or PyPI, blog archives with archive.org snapshots, Stack Overflow history, patent filings, academic papers. The principle is the same: find something timestamped before the hiring cycle, authored on infrastructure the candidate does not control.

How do I detect commit-scripting bots on a fake GitHub profile?

Look at the contribution graph for human-shaped irregularity. Real developers go quiet on holidays, during vacations, and around life events, and burst around releases. Bots push tiny meaningless changes (empty commits, whitespace edits, one-character README edits) to keep the graph green every single day including weekends and holidays. Then open two or three non-trivial PRs and read the review conversation. Fake profiles usually have no substantive technical discussion attached to their commits.

Is open-web verification enough on its own?

No, and it is not supposed to be. It is the pre-interview filter that stops you from spending recruiter and engineering time on candidates who cannot pass a 10-minute artifact check, which is where deepfake interview fraud, proxy interviews, and DPRK-style synthetic identities get caught cheapest. Keep your background check vendor, keep your ID verification, and for sensitive roles, follow Google, McKinsey, and Cisco in requiring at least one in-person round. Artifact triangulation runs before all of that, not instead of it.