{
 "slug": "synthetic-resume-storm-ai-generated-portfolios-overwhelm",
 "topic_id": "TOPIC-087",
 "cluster": "Remote Workforce & Insider Threat",
 "tier": "Tier B",
 "title": "When every credential a candidate presents can be manufactured",
 "summary": "A CV, a professional profile and a code repository are all self-asserted artefacts. Generating convincing versions of all three is now cheap, which removes the screening signal they carried.",
 "lede": "Technical screening rests on artefacts a candidate controls: what they say they did, a profile they wrote, and a repository they populated. Each was a weak signal that worked because forging it took effort.",
 "date": "2024-11-12",
 "category": "Future of Work",
 "author_id": "whit-calloway",
 "tags": [
  "hiring",
  "screening",
  "synthetic profiles",
  "verification",
  "contribution proof",
  "talent"
 ],
 "image_title": "Every Credential Can Be Manufactured",
 "schema": "Article",
 "key_takeaways": [
  "Every artefact in technical screening is self-asserted, and generating a plausible version of each is now inexpensive.",
  "Repository history is the most trusted and among the easiest to fabricate, because commit dates are attacker-controlled fields.",
  "Verifiable contribution — attested by the party that accepted the work — is a different class of evidence and is achievable incrementally."
 ],
 "body": [
  {
   "type": "h2",
   "text": "What screening actually relies on"
  },
  {
   "type": "diagram",
   "kind": "compare",
   "alt": "Self-asserted versus countersigned",
   "caption": [],
   "nodes": [],
   "left": {
    "title": "What screening uses",
    "items": [
     "CV — written by the candidate",
     "Profile — written by the candidate",
     "Repository — controlled by the candidate",
     "Commit history — dates are arbitrary",
     "Portfolio — unverifiable provenance"
    ]
   },
   "right": {
    "title": "What resists generation",
    "items": [
     "A contribution a maintainer countersigned",
     "An employment record the employer signed",
     "A client attestation bound to a deliverable",
     "A credential from an issuer with a JWKS",
     "Anything requiring a second compromise"
    ]
   }
  },
  {
   "type": "table",
   "head": [
    "Artefact",
    "Who asserts it",
    "Cost to fabricate"
   ],
   "rows": [
    [
     "CV",
     "The candidate",
     "Minimal, and always was"
    ],
    [
     "Professional profile",
     "The candidate",
     "Low — including plausible connections"
    ],
    [
     "Portfolio site",
     "The candidate",
     "Low"
    ],
    [
     "Code repository",
     "The candidate",
     "<strong style=\"font-weight:600\">Low — including backdated history</strong>"
    ],
    [
     "References",
     "The candidate selects them",
     "Moderate — requires a cooperating person"
    ],
    [
     "Technical interview performance",
     "Observed",
     "Moderate — requires ability or a proxy"
    ]
   ]
  },
  {
   "type": "p",
   "html": "The fourth row deserves attention because it is the artefact screeners have come to trust most, on the reasoning that code does not lie."
  },
  {
   "type": "h2",
   "text": "Why repository history is weak"
  },
  {
   "type": "p",
   "html": "Commit timestamps are fields in the commit object, set by the committing client. They can be any value."
  },
  {
   "type": "code",
   "text": "# Commit dates are inputs, not observations\nGIT_AUTHOR_DATE=\"2019-04-11T09:22:00\" \\\nGIT_COMMITTER_DATE=\"2019-04-11T09:22:00\" \\\n  git commit -m \"initial parser implementation\"\n\n# Result: a repository with three years of plausible history,\n# created this afternoon."
  },
  {
   "type": "p",
   "html": "Combined with generated code and generated commit messages, a convincing multi-year project history is an afternoon's work. Contribution graphs on hosting platforms reflect these dates, so the visual signal reproduces the fabrication faithfully."
  },
  {
   "type": "p",
   "html": "What cannot easily be faked is interaction: pull requests reviewed by other people, issues discussed, contributions merged into repositories the candidate does not control."
  },
  {
   "type": "h2",
   "text": "The signal that survives"
  },
  {
   "type": "p",
   "html": "Attestation by a party other than the candidate. Not because those parties are infallible, but because obtaining a false attestation requires a cooperating third party — which is the cost that fabrication removed everywhere else."
  },
  {
   "type": "ul",
   "items": [
    "A contribution merged by a maintainer who is not the candidate",
    "A review performed on someone else's code, with the review visible",
    "An employer confirming the work, bound to a specific project and period",
    "An open source project attesting to a contribution's authorship"
   ]
  },
  {
   "type": "p",
   "html": "None of these is available in the form a screener needs today, which is the gap."
  },
  {
   "type": "h2",
   "text": "What a contribution attestation would look like"
  },
  {
   "type": "code",
   "text": "{\n  \"attestation\": \"code_contribution\",\n  \"contributor\": \"[credential id enrolled to the candidate]\",\n  \"repository\": \"github.com/org/project\",\n  \"commits\": [\"7f3a91c8...\", \"c19e4a77...\"],\n  \"merged_by\": \"[maintainer credential id]\",\n  \"merged_at\": \"2025-08-14T11:02:00Z\",\n  \"role\": \"author\",\n  \"signature\": \"...\"            # by the maintainer, not the author\n}"
  },
  {
   "type": "p",
   "html": "The load-bearing element is who signs. An attestation signed by the contributor is a CV entry with extra steps; one signed by the party who accepted the work is evidence."
  },
  {
   "type": "h2",
   "text": "What employers can do now"
  },
  {
   "type": "p",
   "html": "The ecosystem-wide version does not exist. Two things are available immediately."
  },
  {
   "type": "ol",
   "items": [
    "<strong style=\"font-weight:600\">Weight interaction over volume.</strong> A candidate with twelve merged pull requests into projects they do not own is a stronger signal than one with three years of solo commits, and the distinction is visible today.",
    "<strong style=\"font-weight:600\">Attest your own leavers.</strong> When an employee leaves, issue them a signed attestation of what they worked on, in what role, over what period. It costs almost nothing and it is a genuine benefit to them."
   ]
  },
  {
   "type": "p",
   "html": "The second is how this bootstraps. An attestation is only useful if employers issue them, and an employer that issues them to leavers gets to receive them from candidates."
  },
  {
   "type": "h2",
   "text": "The obvious objection"
  },
  {
   "type": "p",
   "html": "A verification regime in hiring disadvantages people without conventional backgrounds: career changers, self-taught engineers, people from smaller markets, anyone whose work was not in a public repository."
  },
  {
   "type": "p",
   "html": "This is a real cost and it should shape the design. An attestation should be one supporting signal, not a gate. A candidate without one should be assessed on work they do for you — a paid trial, a take-home, a pairing session — which was always the better signal and is unaffected by any of this."
  },
  {
   "type": "p",
   "html": "The purpose is to reduce the weight placed on artefacts that no longer carry information, not to add a barrier in front of the ones that do."
  },
  {
   "type": "h2",
   "text": "A worked example: two candidates, same evidence"
  },
  {
   "type": "table",
   "caption": "What a reviewer can distinguish",
   "head": [
    "Evidence",
    "Candidate A (real)",
    "Candidate B (generated)"
   ],
   "rows": [
    [
     "CV",
     "Consistent, well written",
     "Consistent, well written"
    ],
    [
     "Public profile",
     "Complete, with endorsements",
     "Complete, with endorsements"
    ],
    [
     "Repository",
     "40 commits over 8 months",
     "40 commits over 8 months, backdated"
    ],
    [
     "Code quality",
     "Good",
     "Good — generated code often reads better"
    ],
    [
     "<strong style=\"font-weight:600\">Third-party signature</strong>",
     "<strong style=\"font-weight:600\">Merge countersigned by a maintainer</strong>",
     "<strong style=\"font-weight:600\">None</strong>"
    ]
   ]
  },
  {
   "type": "p",
   "html": "Every row but the last is indistinguishable, and the last row is the only one whose forgery requires compromising an account that is not the candidate's."
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Commit timestamps are checkable.”</strong> They are author-controlled. A repository's history can be written in an afternoon with any dates you like, and the platform's own timestamps only record when it was pushed."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“This disadvantages people without an existing network.”</strong> A genuine cost. It argues for issuers that are easy to obtain from — bootcamps, open-source maintainers, short contracts — not for abandoning countersignature."
  }
 ],
 "faq": [
  {
   "q": "Why is a code repository weak evidence?",
   "a": "Commit timestamps are fields set by the committing client. A convincing multi-year history is an afternoon's work, and contribution graphs reproduce the fabrication."
  },
  {
   "q": "What signal survives?",
   "a": "Interaction with parties other than the candidate — merged contributions, reviews of others' code, employer attestation. Faking those requires a cooperating third party."
  },
  {
   "q": "Who should sign an attestation?",
   "a": "The party who accepted the work. An attestation signed by the contributor is a CV entry with extra steps."
  },
  {
   "q": "Doesn't this disadvantage unconventional candidates?",
   "a": "It would if used as a gate. Treat it as one supporting signal and assess candidates without one on work they do for you, which was always the better measure."
  },
  {
   "q": "Is repository history still useful?",
   "a": "As colour, not evidence. Author dates are attacker-controlled and generated code is often cleaner than the real thing."
  },
  {
   "q": "What makes a countersignature different?",
   "a": "Forging it requires compromising an account that is not the candidate's — a second, independent obstacle."
  },
  {
   "q": "Does this disadvantage newcomers?",
   "a": "It can, which is why the set of acceptable issuers should be broad: bootcamps, maintainers, short contracts, volunteer work."
  }
 ],
 "sources": [
  {
   "t": "Git documentation on commit object fields and date handling."
  },
  {
   "t": "FCC — protecting consumers from SIM swap and port-out fraud",
   "u": "https://www.fcc.gov/sim-swap-port-out-fraud"
  },
  {
   "t": "Research on signalling and credential verification in labour markets."
  },
  {
   "t": "FTC — business guidance on marketplaces and consumer protection",
   "u": "https://www.ftc.gov/business-guidance"
  },
  {
   "t": "NIST — Digital Identity Guidelines (SP 800-63)",
   "u": "https://pages.nist.gov/800-63-3/"
  }
 ],
 "related": [
  {
   "slug": "bait-switch-hire-deepfake-video-interviews-infiltrating",
   "title": "The interview proves someone can interview",
   "category": "Future of Work"
  },
  {
   "slug": "dprk-it-worker-laptop-farm-prevention-guide",
   "title": "Hiring one person and employing another",
   "category": "Future of Work"
  },
  {
   "slug": "creator-binding-offboarding",
   "title": "Creator binding at offboarding",
   "category": "Definitional"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/Every%20Credential%20Can%20Be%20Manufactured/1200_630/blog.jpg",
 "wordcount": 942,
 "url": "/blog/synthetic-resume-storm-ai-generated-portfolios-overwhelm.html",
 "reading_time": "4 min read",
 "meta_description": "A CV, a professional profile and a code repository are all self-asserted. Generating convincing versions of all three is now cheap.",
 "hub": {
  "slug": "topics/remote-workforce-identity",
  "title": "Remote workforce identity"
 },
 "answer": "Almost none of the ones in use. A CV, a profile and a repository are all self-asserted artefacts, and all three are now cheap to manufacture convincingly. What survives is anything a third party signed — an employer, a client, a maintainer — because that requires compromising someone else.",
 "answer_q": "What screening signal survives cheap generation?",
 "glossary": [
  {
   "term": "Self-asserted artefact",
   "def": "Evidence whose content and provenance are controlled entirely by its subject."
  },
  {
   "term": "Contribution attestation",
   "def": "A signed statement from a maintainer or employer that a specific person did specific work."
  },
  {
   "term": "Issuer JWKS",
   "def": "A published key set letting anyone verify a signature offline, without calling the issuer."
  }
 ],
 "checklist": {
  "title": "Screening for what survives",
  "id": "screening",
  "desc": "Five steps.",
  "steps": [
   {
    "name": "Stop treating self-asserted artefacts as evidence.",
    "text": "Treat them as claims to verify."
   },
   {
    "name": "Ask for one countersigned item.",
    "text": "One is enough to change the economics."
   },
   {
    "name": "Verify the issuer's key, not the platform's badge.",
    "text": "Badges are rendered images."
   },
   {
    "name": "Accept a wide range of issuers.",
    "text": "Otherwise you screen for network, not skill."
   },
   {
    "name": "Bind the interview to the hire.",
    "text": "Signature at interview, same credential on day one."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav lets an employer, maintainer or client sign a statement about a named person, verifiable offline by anyone with the issuer's key.",
  "href": "../docs.html",
  "label": "See attestations"
 }
}