Contributor tenure at admin-permissioned PR
A dev identity & insider risk factor in the v1.7.0 rubric. Measured per protocol on a e cadence.
Methodology how we score #
**What this measures** This factor measures the tenure — in days since first contribution — of the author of the most recent admin-permissioned code change. A short-tenured contributor being granted admin-level merge or deploy authority is a structural insider-risk signal, particularly when the contributor's identity is not otherwise verifiable. Measurement is programmatic via GitHub API: the factor queries the merge timestamp of the most recent commit touching admin-role or upgrade-path code and compares it to the author's first contribution date in the repository. Category 7 context: DPRK insider-implant attacks specifically exploit short-tenured developers being granted premature admin access.
**Why it matters** The Drift Protocol incident (April 2026) exemplifies the risk: UNC4736 (DPRK-attributed) infiltrated the team by posing as an external integrator, built real-capital credibility over six months, and was ultimately granted sufficient access to influence the Security Council threshold reduction that preceded the $285M exploit. Short-tenured contributor access is not inherently malicious — legitimate security researchers are onboarded quickly — but it creates a window where the contributor's intent cannot be verified through track record. Protocols with documented insider attribution consistently show short-tenure → admin-access patterns.
**Green / Yellow / Red** Green is scored when the most recent admin-permissioned PR author has a contribution history of at least 180 days in the repository, or is a verified external audit firm contributor. Yellow applies when the author's tenure is 30–180 days with verifiable identity. Red is scored when the most recent admin-permissioned change was authored by a contributor with fewer than 30 days of repository history and no verifiable external identity.
**Common gray cases** Gray is assigned when the repository does not clearly distinguish admin-path code from general code changes, when the repo is private, or when the most recent admin change is more than 12 months old and assessing tenure at that historical point is impractical.
**Notable historical examples** No cross-hacked incidents currently linked in database for this factor.
Measurement what to look for #
Measure the number of days contributing to the repo of the author of the most recent admin-permissioned code change.