The Elevated-Access Grant Standard for Open-Source Contributors

You are responsible for a project, and someone wants commit, maintainer, or release access. This guide is for the person who has to say yes or no: the engineering manager, technical founder, developer-relations lead, or maintainer who owns the repository. It turns access-granting into a definition of done - fixed criteria and a checklist that two reviewers apply identically - so the decision does not hinge on one person's gut under pressure.

Public guidance is candid that no agreed method exists. Open Source Guides says plainly there is "no one right way" to grant commit access, and the OpenSSF and OpenJS foundations, after the xz-utils takeover, issued a social-engineering alert rather than a scoring rubric. This standard converts the scattered lessons of that incident into pass or fail criteria you can adopt as team policy.

What "elevated access" means and why the tier matters

Elevated access is any grant above read-only: the ability to merge, to release, or to change how the project is governed. The tier you grant defines the blast radius if the grant is wrong, so the tier is the first thing to name in writing.

GitHub defines five repository roles, and the capability jump that matters for this standard is between Triage and Write. Triage lets someone manage issues and pull requests without touching content. Write is the first tier that can merge pull requests and create releases. Maintain adds broad administrative access short of destructive actions, and Admin confers full control, including altering security settings and deleting the repository.

Package registries add a second, separate elevation. On npm, publish rights and account ownership are the elevated tiers, and they sit outside the GitHub role model entirely. This split is the single most important structural fact in this guide: repository access and release access are two different grants with two different failure modes.

Here is the tier-to-risk mapping, taken from GitHub's repository-roles documentation. Grant against this table, not against how much you like the person.

Two roles both let someone merge and release without any destructive power, which is why Write and Maintain sit in the same risk band for this standard. Admin is a separate decision: it adds the power to weaken the very controls the rest of this guide depends on. Never bundle Admin into a merge-access request. And note a quiet trap in the model: on GitHub, anyone who holds a deploy key's private key can read from or write to the repository even after being removed from the organization. Revoking a role does not revoke a key.

The four fixed criteria

Grade every request against four criteria: contribution record, verified identity, backing organization, and required technical controls. A request that fails any one of them cannot be granted at the requested tier - it is capped at probation or denied.

These four are chosen because they are the ones two reviewers can score the same way from public evidence, and because each maps to a way the xz-utils takeover succeeded. The taxonomy behind them comes from the ICSE and FSE 2024 study "How to Gain Commit Rights in Modern Top Open Source Communities," which built 26 qualification codes across nine themes and confirmed that in practice, developers who submit high-quality code, engage in code review, and contribute across related projects are the ones granted commit rights.

Contribution record. What it proves: sustained, non-trivial technical judgement the project has already reviewed. What it looks like when it lies: a high pull-request count made of typo fixes and dependency bumps, with little or no code-review participation. Grade non-trivial merges and review engagement, not the raw count, because the raw count is the cheapest thing to fake.

Verified identity. What it proves: a real person you can hold accountable and re-contact out of band. What it looks like when it lies: a plausible profile whose entire footprint originates from the requester - endorsements from unknown accounts, contact addresses that appear nowhere else online. The OpenSSF alert is blunt here: know your committers and maintainers, and ask whether you have seen them in working-group meetings or met them at events.

Backing organization. What it proves: an institution with reputation to lose stands behind the person. What it looks like when it lies: a claimed affiliation you cannot confirm through the organization itself. This criterion is checkable against a short list. In Refolk's index, US senior and director-level supply-chain-security talent with Open Source and Cryptography skills clusters at Red Hat, Google, Bloomberg, and The Linux Foundation - a small enough set that "backed by X" is verifiable rather than assumed.

Required technical controls. What it proves: even a correct grant to a compromised account has a bounded blast radius. What it looks like when it lies: green branch protection sitting next to an unprotected publish token. Controls are a grant condition, not a nice-to-have, and they are covered in their own section below.

Why self-identification is a rare, checkable signal

A claimed maintainer title is verifiable against a small, named population, so treat it as evidence you can check rather than a label you accept. In Refolk's index, only seven US professionals publicly self-title as maintainer, open source maintainer, or core maintainer, and the top employers behind those titles are the Python Software Foundation, Quansight, and vLLM.

That scarcity is the point. When the self-identifying population is tiny, "I maintain X" is a claim you can test against real affiliations rather than a vibe. The table below shows how thin the population is across two large markets.

The backing-organization criterion has the same shape: a short, high-signal list of affiliations rather than an open field. Two adjacent US talent pools illustrate where credible backing concentrates.

When you need to confirm that a requester really holds the role or affiliation they claim, plain-English search across the public GitHub graph and professional profiles is faster than manual cross-referencing. Refolk resolves a claim like "core maintainer of X at The Linux Foundation" against its index so you can confirm or fail the backing criterion in one query instead of ten browser tabs.

The grant procedure, start to finish

Run every elevated-access request through these eight steps in order. The procedure ends in a two-reviewer verdict and a least-privilege grant with review dates already set.

One governance choice this procedure leaves open: whether promotion is self-nominated or sponsor-nominated. Sources disagree, and the ICSE study shows both patterns exist across governance models. Pick one and write it into your policy so two reviewers grade the same way. A self-nomination is not itself a red flag - the OpenSSF alert flags aggressive pursuit of the promotion by unknown people, not the act of asking.

How this goes wrong: the failure modes

Most bad grants come from a small set of repeatable failure modes, and each has a check that catches it. This is the section to read twice, because a standard that misses the failure modes is worse than no standard.

The xz-utils takeover is the reference case, and its timeline is a checklist of these failures firing in sequence. The JiaT75 account was created in 2021 and made 546 commits that year, building tenure fast. The first mailing-list patch landed on October 29, 2021, and the first legitimate repository commit on February 6, 2022. Pressure emails from a persona named "Jigar Kumar" followed, and by mid-2022 the attacker was described as "effectively already a co-maintainer." The first attacker-built release, 5.4.2, shipped on March 18, 2023. The backdoor that resulted, CVE-2024-3094, scored 10 out of 10 on CVSS. Tenure, urgency, sock puppets, and a compromised release path all appear in that record.

Two of these deserve extra weight.

Time-in-project is not a trust proxy. The ICSE study found the probability of gaining commit rights actually decreases as participation time grows, because grants cluster around high-quality code and review engagement rather than tenure. A patient long-tail contributor can satisfy any tenure rule while faking merit, which is exactly what xz's attacker did over roughly two years. If your promotion policy rewards time served, you have built the door the xz attacker walked through.

The attack surface migrated from repo to release. xz's payload lived in the release tarballs, not the public git tree, so branch protection alone would not have caught it. That is why the publish path is a separate grant with separate controls, and why over-investing in repository protections while leaving the release path open is a false sense of security.

Branch protection guards the repository, but the xz payload never touched the public git tree.

The technical controls that must be live before access

Access is not granted until the controls are enabled, because the controls are what bound the damage of a wrong grant. Enforce these as conditions of the grant, taken directly from the OpenSSF and OpenJS guidance.

• Require two-factor or multifactor authentication on every account with elevated access.
• Enable branch protection and signed commits.
• Require a second developer to review before merging, even when the pull request comes from a maintainer.
• Enforce readability so pull requests are not obfuscated and opaque binaries are minimized.
• Limit who holds npm publish rights, and audit deploy keys, which survive org removal.

The release path needs its own hardening. npm's recommended account setting is to require two-factor authentication and disallow tokens, because long-lived tokens are the thing that gets stolen. npm now supports OIDC-based trusted publishing, which reached general availability in July 2025 and lets you publish directly from CI/CD using OpenID Connect, eliminating long-lived tokens. It implements the trusted-publishers standard that OpenSSF specified and that PyPI and RubyGems also adopted. Prefer it.

The reason this is not optional is scale. Token compromise does not fail gracefully.

The funnel figures are illustrative of the shape, not measured counts - the point is that publish rights should be the narrowest gate, granted to the fewest people, under the strongest controls.

The verdict rubric: grant, probation, or deny

Convert the four criteria into three verdicts, and default disagreement downward. This is what makes the standard gradeable: two reviewers who apply it to the same request land on the same verdict.

Score each criterion pass or fail, then read the verdict off these rules:

• Grant at the requested tier: all four criteria pass, no red flags present, and both reviewers agree. Provision the lowest tier that unblocks the work.
• Probation: contribution record and identity pass, but backing is unconfirmed or the tier requested exceeds current need. Grant one tier below the request (for example, Write instead of Maintain, or Triage instead of Write) with a fixed review date. A documented probation-to-revocation policy with fixed criteria is not established in public guidance, so write your own and apply it consistently.
• Deny: any red flag is present, identity cannot be verified out of band, or the contribution record is trivial. Deny in writing with the failed criterion named.

The matrix below is the fast read when a request is ambiguous, plotting contribution strength against identity and backing.

Verify before you call the grant done

Run this checklist before access goes live. If any item is unchecked, the grant is not finished - it is capped at probation.

Keeping the grant current

A grant is a decision with an expiry, not a permanent state, so the standard is not done when access goes live - it is done when the review is scheduled. The OpenSSF alert prescribes recurring review: know your committers and maintainers, do a periodic re-check, and ask whether you have still seen them in working-group meetings or at events.

Set two things at grant time. First, a review cadence - a recurring calendar entry where you re-run the identity and activity check. Second, written revocation triggers everyone can see: a departure from the backing organization, a lapse in activity, a failed control audit, or any red flag surfacing after the fact. Because deploy keys and publish tokens outlive role removal, revocation means rotating keys and tokens, not just clicking "remove."

Because the mechanisms shift, re-check the moving parts rather than trusting a fixed answer. GitHub's role capabilities, npm's recommended account settings, and the availability of OIDC trusted publishing across registries all change over time. When you review a grant, confirm the current control set at its source rather than assuming the control you enabled last year is still the strongest one available. The standard stays evergreen because it grades the request against criteria; the controls it requires are the part you keep current.