arXiv CSopen access

Analysis of Commit Signing on Github

arXiv:2604.14014v1 [cs.SE] 15 Apr 2026

Analysis of Commit Signing on Github Abubakar Sadiq Shittu

John Sadik

University of Tennessee Knoxville, TN, USA [email protected]

University of Tennessee Knoxville, TN, USA [email protected]

Farzin Gholamrezae

Scott Ruoti

University of Tennessee Knoxville, TN, USA [email protected]

University of Tennessee Knoxville, TN, USA [email protected]

Abstract

Keywords

Commit signing is widely promoted as a foundation of software supply-chain security, yet prior work has studied it through the lens of individual repositories or curated project samples, missing the broader picture of how developers behave across an entire platform. Grounded in replicability theory, we vary the sampling unit from repositories to individual developers, following 71,694 active GitHub users, defined as accounts that have authored at least one commit, across all their repositories and their entire commit history, spanning 16 million commits and 874,198 repositories. This platform-wide, user-centric view reveals a fundamental gap that repository sampling cannot detect. The ecosystem’s apparent high signing adoption rate is an illusion. Once platform-generated signatures are excluded, fewer than 6% of developers have ever signed a commit themselves, and the vast majority of apparent signers have never signed outside a web browser. Among the minority who do sign locally, signing rarely persists over time or across repositories, and roughly one in eight developer-managed signatures fails verification because signing keys are never uploaded to GitHub. Examining the key registry, we find that expired keys are almost never revoked and more than a quarter of users carry at least one dead key. Together, these findings reveal that commit signing as practiced today cannot serve as a dependable provenance signal at ecosystem scale, and we offer concrete recommendations for closing that gap.

commit signing, software supply chain security, GitHub, cryptographic provenance, key management, empirical study, developer behavior, verification

CCS Concepts • Security and privacy → Digital signatures; Key management; Usability in security and privacy; • Software and its engineering → Empirical software validation; • General and reference → Empirical studies; Measurement.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. Conference acronym ’XX, Woodstock, NY © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-XXXX-X/2018/06 https://doi.org/XXXXXXX.XXXXXXX

ACM Reference Format: Abubakar Sadiq Shittu, John Sadik, Farzin Gholamrezae, and Scott Ruoti. 2026. Analysis of Commit Signing on Github. In Proceedings of Make sure to enter the correct conference title from your rights confirmation email (Conference acronym ’XX). ACM, New York, NY, USA, 22 pages. https://doi.org/XXXXXXX.XXXXXXX

1

Introduction

Software supply chain attacks are becoming more common and more sophisticated [26]. Attackers slip malicious code into legitimate software by exploiting the trust developers place in build and release processes [11]. While many attacks target package managers, high-profile incidents show that the source repository itself is equally at risk. In the SushiSwap MISO compromise [58], an attacker with legitimate repository access modified a single file and redirected nearly $3 million in user funds [49]. The version control system raised no alarm because the push was made with valid account credentials, with no cryptographic check on who actually authored the change. More recently, attackers compromised hundreds of GitHub accounts to inject malicious Actions workflows, exfiltrating thousands of secrets across multiple ecosystems [15, 41, 52], and later deployed a self-replicating worm that poisoned packages at scale [13]. Together, these incidents show that widely trusted development platforms like GitHub have become prime targets, and that strengthening provenance signals to distinguish account access from authentic authorship is critical. Commit signing is Git’s built-in answer to this problem. A developer signs a commit using a private key stored on their machine, and anyone can later check that signature to confirm the code is genuine and unchanged [27, 42, 57]. This only works if developers sign their commits regularly and manage their keys properly. Yet studies show that fewer than 5–10% of commits carry a signature, even in large projects [27, 50]. Moreover, those studies examine repositories in isolation, making it impossible to tell whether low signing rates reflect a developer’s personal habits or project-specific governance, and whether the pattern holds across the wider platform. To address this, we build on the Tree of Validity (ToV) replicability framework (see §2) and shift the focus from repositories to individual developers, measuring signing

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

behavior across every repository they contribute to and over time. We address the following research questions: RQ1: Which mechanisms and workflows produce signed commits, what cryptographic configurations do they use, and what factors undermine their meaning as a provenance signal? RQ2: To what extent do developers adopt commit signing, and how consistently do they apply it over time and across repositories? RQ3: How well do developers manage signing-relevant keys on GitHub? To answer these questions, we build an ecosystem-scale dataset using a stratified sample of GitHub user accounts by account creation date. For each sampled account, we collect public profile metadata, public keys registered with GitHub, public repositories they contributed to, and the commits they authored in those repositories. We restrict our analyses to active users—accounts with at least one public commit—to focus on developers who actually contribute code. We make the following contributions: (1) We confirm at platform scale that commit signing adoption is low, that unknown_key is the dominant verification failure mode, and that signing frequency degrades as developer activity increases. (2) We reveal that the ecosystem’s apparent 89% signing adoption rate is an illusion driven by GitHub automatically signing commits made through its web interface. Once these platform-generated signatures are excluded, fewer than 6% of developers have ever signed a commit themselves, and 94% of apparent signers have never done so outside a browser. (3) We show that developer-managed signing is not only rare but fragile. Only 12.65% of local signers sign consistently across all their repositories, 42.33% stop signing while remaining active contributors, and adoption is concentrated among long-tenured users, rising from under 1% for accounts under one year old to over 15% for accounts older than ten years. Even experience on the platform does not protect against eventually abandoning the practice. (4) We examine GitHub’s key registry and find that expired keys are almost never revoked, rotation happens after keys lapse rather than before, and the proportion of users carrying at least one stale credential rises from under 5% among new accounts to over 53% among accounts older than ten years. (5) We offer evidence-based recommendations for platforms to bifurcate the verification badge, close the key-binding feedback loop at push time, and treat key lifecycle management as a security feature rather than a passive registry.

2

Background and Related Work

In this section, we review the foundations that motivate and situate our study. We begin with supply-chain provenance frameworks that establish why commit signing matters at the ecosystem level. We then examine how Git signing works and how platforms like GitHub interpret signatures, followed by a focused look at what prior measurement studies found and where their designs fall short. We next address key lifecycle management as a dimension prior

anonymous et al.

work has largely overlooked, and then the behavioral barriers that explain why adoption remains low. We close by describing the Tree of Validity replicability framework that structures our study. Supply-Chain Provenance. Modern software supply-chain security frameworks formalize provenance requirements through cryptographic verification at multiple stages. The SLSA specification [55] establishes maturity levels for build and artifact integrity, with higher levels requiring verifiable source provenance from version control. Defense-oriented architectures such as AStRA [1] identify source provenance non-equivocation as a core security objective. When commits are unsigned, inconsistently signed, or signed only by a platform key, this guarantee breaks before the build pipeline begins, and downstream SLSA attestations cannot independently verify the identity binding they assume. SBOM initiatives extend this logic downstream: Zahan et al. [59] and Stalnaker et al. [53] found that generation quality and adoption remain inconsistent, and Nocera et al. [40] observed that uptake is concentrated in specific ecosystems. Together, these gaps make commit signing a foundational element of the ecosystem, providing the initial cryptographic assertion necessary to establish a root of trust [25]. Git Signing: Mechanics and Platform Interpretation. Git stores history as a graph of immutable objects [35]. Each commit records a project snapshot and includes author and committer identity as plain text [7]. These fields are not verified, so anyone can create commits under any name or email [29], enabling commit masquerading on reputation-dependent platforms [27, 42]. Git addresses this by allowing commits to be cryptographically signed via a header that binds the snapshot, parent commits, and author information to a signature [9]. Three methods are common: OpenPGP, based on a decentralized trust model [8, 57]; SSH signing, added in Git 2.34 [54, 56]; and X.509/CMS signing, typically used in organizations [28, 34]. The security value of a signature, however, depends on how verifiers associate the signing key with a developer identity. Large forges act as interpretation layers over Git (Figure 1), providing “verified” indicators based on a mix of cryptographic checks and platform-side identity binding [27, 50]. A critical distinction follows: in developer-managed signing, the private key remains under the developer’s control and the forge verifies against a registered public key. In platform-mediated signing, the forge creates and signs commits on the user’s behalf in web-based workflows, producing verified commits without any local signing configuration [2]. Zhang et al. [60] found that developers often underestimate impersonation risks and are largely unfamiliar with these mechanisms, pointing to a gap between what signing offers in principle and what developers understand in practice. Prior Measurement Studies. Empirical studies of commit signing have focused on repositories rather than developers. Sharma et al. [50] studied 60 top-ranked repositories and found roughly 10% of commits verified, but their design conflates individual developer behavior with project-level governance. By excluding web-flow commits, it also removes the dominant signing mechanism, making it impossible to determine whether low adoption reflects a capability gap or a reliance on platform workflows. Holtgrave et

Analysis of Commit Signing on Github

Figure 1: Examples of Verified and Unverified Commits in the GitHub UI

al. [27] analyzed critical open-source projects and found 86% vulnerable to contributor spoofing, with 95% of users never signing. Their design, however, remains project-centered and cannot track how a given developer behaves across repositories. Because both studies sample repositories rather than developers, neither can separate project policy from individual practice, nor reveal what happens outside a curated set of prominent projects. Key Management. Signatures inherit their trustworthiness from how keys are managed. NIST SP 800-57 motivates finite cryptoperiods and documented rotation practices [4]; NIST SP 800-131A provides a transition framework for deprecated algorithms [5]; and FIPS 186-5 specifies approved signature primitives [39]. Long-lived keys without rotation or revocation can therefore weaken provenance reliability even when individual signatures verify correctly. Bäumer et al. [6] audit SSH keys on GitHub and document shifts toward stronger algorithms while identifying weak or misconfigured keys. Existing audits, however, focus primarily on key strength and configuration, giving little attention to lifecycle properties such as expiration, revocation, and rotation, which determine whether keys remain dependable provenance anchors over time. We extend this line of work by measuring these lifecycle signals directly in GitHub’s public key registry and introducing dead keys to quantify accumulated hygiene risk. Friction and Adoption Barriers. Even when signing is available, behavioral barriers limit uptake. Klivan et al. [31] found that opensource contributors rely on individualized, ad-hoc security setups rather than standardized practices. Kruzikova et al. [33] showed that even when developers recognize the importance of two-factor authentication, friction undermines sustained adoption. Afzali et al. [2] demonstrated that GitHub’s convenience-focused workflows encourage complacency around author authentication. In the CI/CD context, Delicheh et al. [10, 45] quantified security issues in GitHub Actions workflows, and Fischer et al. [14] found that platform-level nudges alone are insufficient without also reducing friction. We connect this usable-security literature to ecosystem-scale evidence, measuring where and why cryptographic provenance breaks down across GitHub’s full developer population. Replicability and the Tree of Validity. Our study is structured as a replicability experiment in the sense defined by Olszewski et al. [44], whose Tree of Validity (ToV) framework formalizes how intentional variation in experimental design tests the bounds of a hypothesis. The ToV models an experiment as a binary tree whose layers correspond to the problem, domain, method, data, and

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

analysis. A validity study follows a path through this tree by keeping some components the same as prior work and varying others. When two independent studies following different paths converge on the same finding, that convergence is strong evidence the finding reflects a real property of the phenomenon rather than an artifact of any particular dataset or design. When they diverge, the divergence reveals the boundary conditions under which each result holds. We apply this framework by varying the domain and sampling unit: rather than sampling repositories, we follow individual developers across all their repositories and over time.

3

Methodology

In this section, we detail our strategy for collecting representative user profiles, keys, and commit metadata from active contributors in § 3.1. The resulting dataset underpins the security analysis presented in § 4–6, while our analytical framework and limitations are outlined in § 3.5 and § 3.4, respectively.

GitHub Accounts Active Active user Commits by endpoints users repositories active users

Public keys

Figure 2: Dataset construction pipeline. The full list of collected fields is in Table 1

Table 1: Collected data from points (1)–(3) in Figure 2. Dataset

Accounts

Field group

Fields

Identifiers Profile

id, login, graphql_id name, email, location, bio, company, website_url, twitter_username user_type, site_admin, createdAt, updatedAt followers, following, repo_count, repo_contributed_count, issue_count, org_count

Account metadata Activity/graph

Identifiers Key material Public keys Key lifecycle Capabilities Associated identities Identifiers Author fields Commits Committer fields Git metadata Signing/verification

id, user_id key, raw_key, fingerprint, subkeys, key_type, title createdAt, expiresAt, revoked, verified, read_only, source can_sign, can_encrypt_comms, can_encrypt_storage, can_certify emails id, sha, repository author_login, author_name, author_email, author_date committer_login, committer_name, committer_email, committer_date tree_sha, parent_shas, comment_count, total_changes signature, verified, verification_reason, verified_at

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

3.1

Account Enumeration

We began by trying to construct a dataset of all GitHub accounts using the platform’s REST API. Our approach leveraged the GET /users?since=id endpoint, which lists accounts in their order of creation [24]. Starting with the earliest user ID allowed us to capture the population systematically and comprehensively, supporting analyses of platform-wide adoption patterns. For each enumerated account, we retrieved detailed profile attributes via the GitHub GraphQL API, which provides efficient, structured access to userlevel metadata [18, 19], as shown in Figure 2. We supplemented this profile data by collecting all publicly available authentication keys and signing keys via dedicated REST endpoints. To query these endpoints at scale, we used a pool of 10 GitHub Personal Access Tokens provided by distinct researchers in our research group. Using multiple tokens allowed us to distribute requests across independent rate-limit quotas and maintain highvolume data collection while remaining compliant with GitHub’s usage policies [16, 21]. We employed a dynamic rotation algorithm that monitored API header telemetry, specifically remaining quotas and query complexity costs [20], to preemptively cycle credentials before exhaustion. This ensured continuous, policy-compliant data collection. Rate-limit. GitHub’s REST API enforces a hard limit of 5,000 requests per hour per token [21], making full enumeration of GitHub’s ∼150M accounts [23] infeasible at scale (≈34 years at observed collection rates) — likely the reason prior work has restricted scope to specific repositories or public keys [6, 27, 50]. Although GitHub declined a permanent rate-limit increase for our project (Figure 11), engineers reviewed and approved our collection methodology during that engagement. To operate within these constraints while maintaining representativeness, we adopted a stratified sampling approach aligned with established practices for large-scale measurement studies where full enumeration is impractical [3].

3.2

Account Sampling

3.2.1 ID Space and Ceiling Estimation. We first establish an upper bound on the GitHub user-ID space. GitHub user IDs are assigned monotonically based on account creation date [24]. While IDs generally increase over time, they are not strictly sequential due to account deletions or internal administrative gaps. The REST endpoint GET /users?since=id returns a list of up to 100 users with IDs starting immediately after the provided since value. To estimate the current “ceiling” of assigned IDs, we performed a manual threshold search by issuing /users?since={id} queries at increasingly large since values until responses became empty, and then probing nearby values to confirm the boundary. Concretely, we tested values in the [230,000,000, 232,000,000] range: queries at since=232,000,000 (and higher) consistently returned empty responses, whereas queries near 230,000,000 returned valid user objects. We therefore conclude that the highest publicly visible assigned user IDs at the time of measurement lie within [230M, 232M) and use ∼230M as a conservative ceiling for constructing stratified samples. Notably, this ceiling represents the allocated identifier space rather than the number of active GitHub users. IDs are assigned

anonymous et al.

sequentially at account creation [24] but, based on our empirical observations during data collection, are not recycled when accounts are deleted, suspended, or otherwise removed. Consequently, the actual number of active GitHub users is substantially lower, estimated at approximately 150 million [23]. 3.2.2 Stratified Sampling Strategy. Rather than enumerating users sequentially from GitHub’s inception, we sampled uniformly across the entire 230 million user ID range. We targeted a 1% sample based on practical constraints identified in the full user enumeration attempt. Given that full traversal would require approximately 2.3 million API requests (230M IDs at 100 users per call), an equivalent 1% sampling rate would require roughly 23,000 requests. To achieve this, we divided the ID range into 23,000 equal intervals. For each interval, we used the starting ID as a sampling point for the since parameter. Because each API request returns a block (or bucket) of 100 consecutive available users, we capture clusters of users at regular intervals across the entire ID space. This approach mitigates the risk of missing specific account distributions that might occur if we had sampled only individual, isolated IDs. Querying the API at each sampling point (returning up to 100 accounts per request) theoretically yields a maximum of 2.3 million user profiles. However, we ultimately retrieved complete metadata for 1,294,214 accounts. The remaining queries returned “NOT FOUND”. To understand these cases, we manually inspected a subset by visiting the corresponding profile URLs and confirmed that these accounts were inaccessible—likely deleted, suspended, or otherwise removed from public view, or enterprise managed users [17], whose profiles are only visible to authenticated members of the associated organization. 3.2.3 Sample Robustness and Expansion. To assess the representativeness of the collected sample, we examined the distribution of account creation dates and verified that it spans GitHub’s entire operational history (2008–2025) [12]. Because full enumeration is infeasible within standard API limits, we treat the initial 1% collection as an exploratory baseline and expand to 2% to evaluate whether our key population-level proportions remain stable as coverage increases. This approximately doubles the number of collected accounts, providing a practical stress test of sampling sensitivity while keeping the additional API cost and data-processing overhead manageable. We stop at 2% because further increases would substantially raise downstream collection costs (e.g., repository and commit retrieval) with limited expected benefit. This incremental expansion aligns with established practices, where sample sizes are gradually increased to validate distribution stability while controlling computational overhead [46, 47]. Having expanded the collection to 2%, we assessed robustness at both the account and key levels. Table 2 shows that active-user prevalence and signing-key proportions remain stable across both strata. We define active users as any GitHub account that has authored at least one publicly visible commit in a public repository, as determined via the GitHub REST API across sampling levels. While differences are statistically detectable due to large sample sizes, effect sizes are negligible (Cramér’s 𝑉 = 0.0101 for active users; 𝑉 ≈ 0.002 for signing keys), confirming that increasing the

Analysis of Commit Signing on Github

sample beyond 1% does not materially change population-level proportions.

3.3

Commit Metadata Collection.

We restricted commit metadata collection to active users (Table 2), removing dormant accounts and focusing on developers with tangible platform contributions. Collection proceeded via GitHub’s REST API in two phases. First, for each account, we identified all repositories, including personal projects, organization-owned repositories, and external repositories with collaborator status, without filtering by size, popularity, or activity level. This is a deliberate design choice: including small and hobby projects provides a truer picture of a developer’s signing consistency, and small single-maintainer components carry disproportionate supply-chain risk when transitively imported into larger ecosystems [62]. Second, for each identified repository, we isolated commits authored by these active accounts, excluding contributions from other collaborators. This approach aligns with our user-centric design, allowing us to analyze individual behavioral patterns without downloading full repository histories. For every retrieved commit, we extracted detailed metadata (Table 1). Because commit retrieval is substantially more resource-intensive than account enumeration, we structured collection in stages. The 2% cohort was used for account- and key-level stability checks (§3.1); commit retrieval was ongoing at time of writing, with the cohort 87.9% complete (71,694 of 81,540 users; 16,112,439 commits). To confirm this does not threaten validity, we computed headline signing proportions on the partial 2% commit data and compared them against the complete 1% cohort (Table 3). All metrics differ by less than 1 percentage point with negligible effect sizes (Cohen’s ℎ ≤ 0.0218), confirming the 2% cohort is a stable and representative basis for all commit-level analyses in §4–6. Lesson 1: Full enumeration of GitHub is not feasible, so we sampled instead. We validated the sample by doubling it and nothing changed meaningfully. So, our data is representative.

3.4

Limitations

API ratlimit. GitHub’s API rate limits prevented exhaustive enumeration of all users. To address this, we used progressive stratified sampling [46]. Sampling constraints. We acknowledge that bucket based stratified sampling might miss account distributions. While GitHub IDs are assigned monotonically based on account creation date rather than in a strictly gapless sequence, we used the since parameter to retrieve blocks of up to 100 consecutive users per interval. This bucket-based approach captures local account distributions and reduces the risk of missing specific cohorts and the stability observed across all three strata suggests that our results are unlikely to be artifacts of sample size or identifier gaps, supporting generalizability to the broader GitHub population. Scope of visible activity. Our analysis is limited to public repositories because commits in private repositories are not

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

accessible through GitHub’s public APIs. As a result, behaviors in private or enterprise environments remain unobserved. Our dataset also includes projects of all sizes, including very small ones. While this may make it smaller than some previous datasets, it provides a more representative view of the ecosystem rather than focusing only on volume. We also do not capture repository-specific details, such as branch protection policies or signing requirements. Our goal is to understand patterns across the entire ecosystem, not the details of individual repositories. Identity ambiguity. Commits made under different usernames by the same individual were treated as separate entities because GitHub’s API does not provide canonical identity mapping. This may affect interpretations at the individual level, but broad trends are likely reliable.

3.5

Data Analysis

Algorithm 1: Signature parsing and feature extraction Input: Commit metadata record 𝑐 with optional signature field 𝜎 Output: Feature vector 𝑥𝑐 (format, algorithms, hashes, key sizes, verification fields) 𝑥𝑐 ← basic fields from 𝑐 (author/committer, timestamps, repo, GitHub verification flags); if 𝜎 is missing then 𝑥𝑐 .signed ← false; return 𝑥𝑐 ; 𝑥𝑐 .signed ← true; if 𝜎 is ASCII-armored then 𝑓 ← identify format from armor header; if 𝑓 is OpenPGP then parse OpenPGP packets; extract (version, sig type, pubkey alg id, hash alg id, issuer id, creation time); else if 𝑓 is SSHSIG then parse SSHSIG container; extract embedded public key and signature metadata; derive key parameters (RSA modulus bits / ECDSA curve id and size / raw key size); else if 𝑓 is CMS/PKCS#7 then parse CMS structure; extract digest alg(s), signature alg(s), signer count; extract certificate attributes (key type, key size, curve); else mark as unknown-armored format; else mark as non-armored/unsupported signature encoding; return 𝑥𝑐 ;

Table 1 summarizes all data elements collected across the three sources in our pipeline. Account fields are used to filter active users and characterize the sample population. Public key fields support our key lifecycle analysis in § 6, including expiration, revocation, and rotation signals. Commit fields — particularly

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

anonymous et al.

Table 2: Sampling robustness across strata. Left: active-user prevalence (𝜒 2 (1) = 408.38, 𝑝 = 8.24 × 10−91 , Cramér’s 𝑉 = 0.0101). Right: signing-key prevalence (𝜒 2 (1) = 0.74, 𝑝 = 0.39, Cramér’s 𝑉 ≈ 0.002). Effect sizes are negligible across both dimensions. Active-User Prevalence Stratum 1% 2%

Signing-Key Prevalence

𝑁

Active 𝑁

%

1,294,214 2,737,649

33,895 81,540

2.62 2.98

Stratum 1% 2%

Total Keys

Signing Keys

%

98,590 208,546

10,229 21,427

10.38 10.27

Table 3: Commit-level robustness check across cohorts. The 2% cohort is 87.9% complete (71,694 of 81,540 users; 16,112,439 commits). Where significant 𝑝-values appear, they are driven by the enormous sample sizes (millions of commits) rather than meaningful differences — all effect sizes are negligible (Cohen’s ℎ ≤ 0.0218). All results have been computed on both samples and the full comparison is in Appendix (Tables 10 and 11.) Metric

1%

2% Partial

Δ (pp)

z

p

Cohen’s h

7,799,840 33,895 414,151 23.73% 89.19% 24.24%

16,112,439 71,694 874,198 24.05% 89.21% 24.61%

— — — 0.32 0.02 0.37

— — — −17.00 −0.10 −19.47

— — —

— — — 0.0074 0.0007 0.0086

6,207,717 28,894 325,317 5.34% 5.98% 24.73%

12,754,615 61,364 684,456 5.25% 5.94% 25.67%

— — — 0.09 0.04 0.95

— — — 8.45 0.24 −20.48

2.94 × 10−17 8.11 × 10−1 3.25 × 10−93

— — — 0.0041 0.0017 0.0218

20.21%

20.63%

0.42

−23.76

9.69 × 10−125

0.0104

Including UI commits† Total commits Total unique users Total repositories Fraction of commits signed Users who ever signed Signed commits among ever-signers

8.51 × 10−65 9.19 × 10−1 1.89 × 10−84

Excluding UI commits† Total commits Total unique users Total repositories Fraction of commits signed Users who ever signed Signed commits among ever-signers

— — —

Overall UI commit fraction

† UI commits: committer_login = ‘web-flow’; all others treated as developer-managed (non-UI).

signature, verified, and verification_reason — form the basis of our signing mechanism and adoption analyses in § 4–5. From each retrieved commit record, we apply a format-specific parsing pipeline (Algorithm 1) to extract the cryptographic attributes such as signature format, hash algorithm, key type, and verification outcome that operationalize the analysis in subsequent sections.

4

Findings: Signing Mechanisms and Reliability

In this section, we examine how commits are signed. The specific commit signing mechanism as described in §2, fundamentally dictates who controls the signing key material, how reliably signing occurs by default, and what security guarantees downstream consumers can reasonably infer. Platform Dominance. We stratify signing activity by whether commits were created via GitHub’s web UI (the web-flow path) or via non-UI workflows. Because GitHub automatically signs web-interface commits using a platform-controlled key [22], these signatures reflect platform mediation rather than

developer-managed security. This distinction drives the majority of signed activity in the ecosystem. Although UI-generated commits account for only 20.63% of our dataset, they are signed at a rate of 96.41% because GitHub signs most web-interface commits automatically using a platform-controlled key. In stark contrast, the non-UI commits, which represent the bulk of development work, have a signing rate of only 5.24% (𝜒 2 (1) = 12,002,263.50, 𝑝 < 0.001). Consequently, 82.69% of all signed commits originate from the GitHub UI, implying that verifiable provenance is largely a byproduct of the interface used rather than a deliberate developer practice. At the user level, this dominance is even stronger: 94.29% of users who have ever produced a signed commit do so exclusively via the GitHub UI, with no observable evidence of developer-managed signing outside the platform. This platform dominance creates the “consistency paradox” detailed in Figure 3. When we analyze the users who appear to be perfect security practitioners (Always signs), we found they are overwhelmingly dependent on the web interface (97.5%). Conversely, among users who sign intermittently, developer-managed signing is typically absent, with a median

Analysis of Commit Signing on Github

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

UI UI Signing Signing 10,142 10,142 (14.1%) (14.1%) Always Always Signs Signs (Consistent) (Consistent) 10,404 10,404 (14.5%) (14.5%) Ever Ever Signed Signed (Capability) (Capability) 63,961 63,961 (89.2%) (89.2%)

Local Local Signing Signing 77 77 (0.11%) (0.11%)

Total Active Users 71,694 (100%)

Never Never Signed Signed 7,733 7,733 (10.8%) (10.8%)

Mixed Mixed 185 185 (0.26%) (0.26%)

Inconsistent Inconsistent 53,557 53,557 (74.7%) (74.7%)

Ever Ever Signed Signed (Capability) (Capability) 3,654 3,654 (6.0%) (6.0%)

Always Always Signs Signs (Consistent) (Consistent) 265 265 (0.4%) (0.4%)

Never Never Signed Signed 57,757 57,757 (94.0%) (94.0%)

Inconsistent Inconsistent Signing Signing 3,389 3,389 (5.5%) (5.5%)

Active Users who have ever made a non GitHub UI commit 61,411 (100%)

Figure 3: Sankey diagram showing how 71,694 active users flow from signing capability to consistency to signing source (UI vs. local).

Figure 4: Sankey diagram showing signing capability and consistency among the 61,411 users who have made at least one non-GitHub UI commit.

non-UI signing rate of 0%. As the table illustrates, true developer-managed consistency is exceedingly rare; for nearly all users, stepping outside the browser effectively means breaking the chain of trust.

Cryptographic Hygiene. So far, we have treated commit signatures as either present or absent, and either verified or not. We now look inside the signatures themselves to examine the specific cryptographic algorithms and configurations they use. In our dataset, modern hash functions such as SHA-256 and SHA-512 dominate. However, we identified 15,461 commits signed with the legacy SHA-1 hash function. These artifacts are not merely historical; they span from 2012 to as recently as December 2025, with a clear peak in 2016 (4,207 signatures). Notably, 87.34% of these SHA-1 signatures were successfully verified, suggesting that while GitHub’s verification pipeline accepts these legacy artifacts for backward compatibility, they remain less reliably verifiable than modern signatures. Furthermore, the fact that these signatures are verified indicates that GitHub’s verification pipeline prioritizes backward compatibility, provided a matching public key is registered. This preserves interoperability with older toolchains, but it also means the valid label does not necessarily imply use of modern primitives. Similarly, we found 5,594 commits using the obsolete DSA algorithm, appearing as recently as March 2026. Much like the SHA-1 subset, DSA signatures in our dataset are largely accepted, achieving a verification rate of 98.52%. Notably, the DSA peak activity falls in 2024 (1,224 signatures), suggesting this obsolete algorithm is not merely a historical artifact but continues to see active use. Importantly, these legacy tails are not broadly distributed across the population. To quantify whether they reflect broad ecosystem behavior or are driven by a small number of dominant actors/toolchains, we measure concentration by reporting the share of signatures attributable to the single most frequent author (top-1) and to a small set of the most frequent authors (top-𝑘). SHA-1 signatures originate from only 172 distinct authors, with the top author accounting for 12.54% of all SHA-1 signatures and the top 10 authors accounting for 55.36%. DSA remains concentrated: only 46 authors appear, with the top author responsible for 29.76% of DSA signatures and the top 5 accounting for 74.83%. Figure 5 illustrates this concentration. Finally, we found that these legacy tails arise entirely outside the GitHub UI: neither SHA-1 nor DSA

Verification Outcomes and Failure Modes. When a user uploads the public key corresponding to the private key used to sign commits, GitHub can mark those commits as verified as in Figure 1. Overall verification in our dataset is high: 97.77% of signed commits are marked valid. However, verification reliability is strongly workflow-dependent. UI signatures verify almost universally (99.92%), whereas non-UI signatures verify at a substantially lower rate (87.51%; 𝜒 2 (1) = 392,519.44, 𝑝 < 0.001). In absolute terms, this corresponds to 2,563 non-valid signed UI commits versus 83,760 non-valid signed non-UI commits; equivalently, a signed commit produced outside the web UI is about 150 times more likely to fail GitHub verification than a signed UI commit. The 12.41 percentage-point gap is practically meaningful for provenance because non-UI commits are where developer-managed signing is expected to provide end-to-end integrity, yet roughly one in eight such signatures does not surface as a valid trust signal on GitHub. The causes of verification failures also differ across workflows, clarifying what breaks in practice. For non-UI commits, failures are dominated by unknown_key (73.73% of failures), meaning the signing key used for the commit is not registered with any GitHub account. This is consistent with a partially completed signing ceremony in which signing succeeds locally but the corresponding public key is never uploaded to GitHub, uploaded to a different account, or later removed. Most remaining non-UI failures are identity-binding issues rather than broken cryptography, including unverified_email (15.06%) and bad_email (7.14%). In contrast, the UI failures are rare. They are primarily driven by expired_key (71.56%), with a notable share attributed to invalid signatures (24.31%), together indicating that the verification state of platform-signed commits can degrade over time. Finally, automated activity does not explain the observed signing signal in our dataset: bot-authored or bot-committed activity is rare (0.06%, 9,963 commits), and none of these bot commits are signed.

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

anonymous et al.

Cumulative % of signatures

100

Table 4: Local signing adoption by account age. Adoption increases monotonically with account tenure (Spearman 𝜌 = 0.21, 𝑝 < 0.001), confirming that developer-managed signing is concentrated among long-tenured users.

80 60 40 20 0

SHA-1 DSA

25

50

75

100

125

150

Author rank (by signature count)

175

Figure 5: Cumulative share of legacy SHA-1 and DSA signatures by author rank. A small number of developers account for the majority of legacy-signed commits.

signatures occur in UI commits in our dataset. Thus, while platform-mediated signing overwhelmingly drives the volume of signed commits, the residual cryptographic heterogeneity—and legacy configurations in particular—are confined to a small number of developer-managed toolchains. Lesson 2: Most signed commits on GitHub are not the result of developers deliberately choosing to protect their work. They are a byproduct of using GitHub’s website, which signs commits automatically behind the scenes. The developers who appear to sign everything consistently are overwhelmingly just people who never leave the browser. The moment they push from a local machine, signing often stops, because they never set up their own keys. When developers do manage signing themselves, roughly one in eight signatures fails verification, usually because the key was never registered with GitHub in the first place. Legacy cryptographic algorithms like SHA-1 and DSA are still in active use, some as recently as early 2026, though this is concentrated among a small number of developers with outdated toolchains rather than a widespread ecosystem habit. Even the platform’s own signatures are not a permanent guarantee, as a commit that shows as verified today can lose that status later if the underlying key expires. The verified badge, in short, reflects how someone interacted with GitHub more than whether they made a deliberate choice to secure their commits.

5

Findings: Adoption and Sustainment

In §4 we established that web-flow signing drives the volume of signed commits. Therefore, in this section, we analyze adoption by measuring developer-managed (local) signing, explicitly excluding UI-generated commits, and contrasting these results with overall signature counts. This distinction is critical for supply-chain security: platform-mediated signatures attest only to the platform’s actions and require trusting the service operator; in contrast, developer-managed signing provides end-to-end provenance by cryptographically binding the commit to a local key held by the developer.

Account Age

Users

Ever Signed Locally

Signing Rate

<1 year 1–2 years 2–5 years 5–10 years 10+ years

5,183 9,702 19,059 15,445 11,999

44 115 480 1,181 1,827

0.85% 1.19% 2.52% 7.65% 15.23%

Adoption. Aggregating commits from both the UI and the local path, we found that signing is widely adopted in the minimal sense of having been used at least once in their GitHub history: 89% of users authored at least one signed commit in our dataset (63,961 out of 71,694 active users). However, adoption is not only widespread; it is often immediate. Among users who have ever signed, the median time from a user’s first observed commit to their first signed commit is 0 days—that is, most signers produce a signed commit on the same day as their first observed activity. Consistent with same-day uptake, 59% (37,557) sign their very first commit, demonstrating that for many developers, signing is already a fundamental part of their workflow from day one—at least when the platform handles it automatically. However, restricting to non-UI commits, only 5.94% of users ever authored a signed commit (3,643/61,364). Moreover, developermanaged adoption is typically not immediate: among signers, the median time from a user’s first observed commit to their first signed commit is 1,122 days—a statistically significant difference from UI signers (Mann–Whitney 𝑈 = 448,593, 𝑝 = 4.63 × 10−25 )—and the median time from account creation to first signing is 2,128 days. We also found that only 14.53% of local committing signers (526/3,643) sign their very first observed commit, and late adopters accumulate substantial unsigned work before first signing (median 136 unsigned commits; IQR: 34–429), with a median latency of 1,440 days (IQR: 622–2,549) from first commit to first signature (Figure 6 and Figure 7). Table 4 confirms this pattern across account age groups: local signing adoption rises from under 1% among accounts younger than one year to over 15% among accounts older than ten years, suggesting that developer-managed signing is largely a behavior of long-tenured users rather than a practice developers adopt early in their GitHub history. Sustained Practice. Having established that signing is not widespread and immediate across the whole platform among people who commit from outside the GitHub UI, we sought to determine whether the central challenge is whether signing persists as a stable practice across a developer’s subsequent and ongoing work among those who have signed once. We found that even among developers who ever produced a non-UI signature, signing rarely persists as a stable default across their ongoing work. We observe substantial inconsistency both across repositories and over time. At the repository level, only 12.65%

Analysis of Commit Signing on Github

Number of Users

8000

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

Table 5: Lapse rate by account age among local signers. Older developers who sign locally are more likely to subsequently abandon the practice (Spearman 𝜌 = 0.08, 𝑝 < 0.001).

Median: 320 Days

7000 6000 5000

Account Age

Lapse Rate

44 115 480 1,181 1,827

15.91% 12.17% 21.88% 30.23% 30.49%

4000 <1 year 1–2 years 2–5 years 5–10 years 10+ years

3000 2000 1000 0

0

500

1000

1500

2000

2500

Days from First Commit

3000

Figure 6: Distribution of days from a user’s first observed non-UI commit to their first non-UI signed commit, among late adopters (excluding users (526, 14.53%) who signed their very first observed non-UI commit).

Number of Users

Local Signers

2000 1750 1500 1250 1000 750 500 250 0

Median: 15 Commits

10

0

10

1

10

2

10

3

10

4

Unsigned Commits Before First Signature Figure 7: Distribution of the number of unsigned non-UI commits authored before a user’s first non-UI signed commit, among late adopters. (461) of developer-managed signers sign commits in all repositories they contribute to, while the vast majority sign in some repositories but not others (3,181; 87.32%). The difference in repository breadth between consistent and inconsistent signers is statistically significant (Mann–Whitney 𝑈 = 123,836, 𝑝 < 0.001), confirming that local signing is highly context-dependent rather than a uniform behavior across a developer’s contributions. To confirm that this pattern is not an artifact of including small repositories, we compared signing rates across 93,001 user × repository pairs grouped by commit activity (1–5 commits up to 500 or more). Although a statistically significant difference exists (Mann–Whitney 𝑈 = 923,179,714, 𝑝 = 1.68 × 10−82 ), the practical effect is negligible (Cliff’s 𝛿 = −0.062): mean signing rates range from 25.2% in repositories where users made 1–5 commits to 25.4% where users made 500 or more, confirming that signing behavior is uniformly rare regardless of repo size. To understand why signing is so inconsistent across repositories, we looked at each user’s signing behavior within individual repos. Among the 3,456 users who contributed to two or

more repositories, only 3.9% (134) signed consistently across all repos, while 96.1% (3,321) signed in some repositories but not others, with a median signing rate standard deviation of 0.33 across their repos. The relationship between activity breadth and signing consistency is weak regardless of direction: the median signing rate remains 0% even in repositories where a developer is most active, underscoring that signing behavior is decoupled from contribution volume. Signing Lapse. At the commit level, persistence is similarly weak. Among developer-managed signers, Figure 8 and Table 8 show that the median signer signs only 22% of their observed commits. Only 12.76% sign at least 90% of their commits, and just 7.27% (265 users) sign every observed commit, while the remaining 92.73% sign only a subset of their commits. In Figure 8, the visible mass near 1.0 is largely driven by low-activity signers: among users who sign 100% of the time, the median total commits is 11 (vs. 308 for others), and 48.68% have ≤ 10 commits. We also observe widespread lapse among developer-managed signers: 1,542 of 3,643 (42.33%) produce unsigned commits after their last signed commit, with a median of 35 unsigned commits following their final signed one (75th percentile: 162). Even among developers who sign from the outset, the behavior is not reliably sustained. Of the 526 users who signed their very first observed non-UI commit, 135 (25.67%) have an unsigned most recent commit in our snapshot (cutoff: Dec. 31, 2025). This pattern is not explained by inactivity: among these unsigned-last users, the median time since their last observed commit is 140 days (IQR: 32–266), and 79.26% have a last commit within the year preceding the snapshot. Table 5 further shows that lapse rates increase with account age: roughly 30% of local signers with accounts older than five years eventually abandon signing, compared to under 16% among the youngest accounts, suggesting that even experience on the platform does not protect against signing lapse. Friction at Scale. The practical consequence of inconsistent developer-managed signing is that provenance coverage remains limited even among developers who demonstrably know how to sign outside GitHub’s web interface. Restricting to non-UI activity, we observe 2,607,634 commits authored by users who produced at least one developer-managed signature, yet only 669,477 of these commits are signed—an overall signing rate of 25.67%. In other words, even within the subset of developers who have successfully signed at least once in a local/non-UI workflow, roughly one in four of their commits carries a cryptographic signature.

Cumulative fraction of signers

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

anonymous et al.

1.0

Lesson 3: While GitHub’s UI signing creates the appearance of widespread, immediate adoption, developer-managed commit signing is actually uncommon, with only 5.94% of developers ever signing a non-UI commit, and when it does begin, it typically starts years into a developer’s activity. Local signing is concentrated almost entirely among long-tenured users, with accounts older than ten years signing at 18 times the rate of accounts under one year old. Even among those who have signed at least once, signing rarely persists as a stable default: behavior is inconsistent across repositories and over time, most developers sign only a fraction of their commits, and nearly half later lapse into unsigned commits, with lapse rates rising alongside account age. Consistent signing is concentrated almost exclusively among low-activity developers, suggesting that friction increases with scale. Together, these patterns show that developer-controlled signing cannot yet serve as a dependable provenance signal at ecosystem scale.

0.8 0.6 0.4 0.2 0.0 0.0

0.2

0.4

0.6

0.8

fraction of commits signed

1.0

Figure 8: CDF of per-user signing rates, computed over nonUI commits only to show signing consistency.

6

Figure 9: Box plot comparing total commits per user on a log scale between developers who always sign and those who do not always sign, showing always-signers have far fewer commits.

A plausible explanation is that maintaining “perfect” signing is burdensome at scale, and that friction compounds as developers operate across multiple repositories and environments. Consistent with this interpretation, we found that users who always sign are disproportionately low-activity compared to those who sign intermittently (Figure 9). Given the highly skewed distribution of commit counts, we compared the groups using a Mann–Whitney 𝑈 test [36]; the difference is statistically significant (𝑝 = 2.10 × 10−105 ) and the effect size is large (Cliff’s 𝛿 = −0.803) [37], indicating that consistent local signing is concentrated among developers with relatively small observed commit histories. While our analysis does not pinpoint the precise operational causes of this degradation, the pattern suggests that developer-managed signing reliability declines as contributors work in higher-throughput, more heterogeneous settings, such as across multiple machines. We discuss likely mechanisms and implications in §7.

Findings: Key Management

Commit signatures are only as trustworthy as the keys behind them. To understand whether GitHub’s cryptographic provenance can realistically be sustained in the wild, we therefore step away from commits and examine the key registry: the public keys users upload and maintain on GitHub. This shifts the question from whether developers can sign to whether they manage signing-capable credentials as living security artifacts—with expiration, rotation, and cleanup—or as static remnants that accumulate over time. Our key-only dataset (Table 6) contains 208,546 unique public keys across 122,050 users, spanning SSH authentication keys, SSH signing keys, and OpenPGP keys. We evaluate lifecycle state at the most recent snapshot in our collection (Dec 31, 2025), and interpret expiry and revocation relative to that point. This lens is deliberately conservative: we do not infer intent from commits or repository policies, but instead measure what the platform’s registry records about key validity and maintenance. Rarity of Expiration. If expiration functioned as a widely adopted hygiene mechanism, expiry metadata would be expected across all key types. However, only 2.81% of all keys (5,858 out of 208,546) possess an expiry date. Expiry is also unevenly distributed: 35.45% of OpenPGP keys include an expiration timestamp, whereas expiry metadata is essentially absent for SSH authentication and SSH signing keys in this registry snapshot. This indicates that explicit lifecycle configuration is primarily associated with OpenPGP workflows and is not reflected in SSH key material on the platform. This pattern aligns with expectations, as SSH public key material typically does not support expiration timestamps; thus, the absence of expiry metadata reflects the key format and registry semantics rather than a deliberate user decision to avoid expiration. Long Key Lifetimes. Even among the minority of keys that adopt expiration, expiry date does not typically represent short rotation cycles. For expiring keys, the median configured lifetime (created → expires) is 730 days, with an interquartile range of 365 to 1,460 days. The tail is long: the 95th percentile lifetime is 3,650 days (10

Analysis of Commit Signing on Github

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

years). These values are difficult to reconcile with expiration as a routine safeguard; instead, expiration appears to function as an infrequent maintenance boundary.

Table 6: Components of Dead Keys (𝑁 = 208, 546 total keys)

Revocation Failure. The most striking breakdown in hygiene occurs after keys reach their expiration date. Within the small subset of keys that have an expiration configuration (𝑁 = 5, 858), more than half had already expired by our snapshot date (3, 096, or 52.85%). In a managed lifecycle, we would expect these lapsed keys to be formally revoked to prevent future misuse. However, we observe the opposite: 99.81% of expired keys remain unrevoked. This confirms revocation is effectively non-existent in this ecosystem and that even among users who configure expiration, it functions primarily as a passive timestamp rather than a trigger for active credential cleanup.

Expired but not revoked Unrevoked, no expiry (> 2 years old) Unverified signing-relevant keys

Dead Keys and Hygiene Risk. To quantify accumulated hygiene risk, we define dead keys as registered credentials existing in states that undermine best-practice lifecycle management. We operationalize this risk through three non-exclusive conditions that represent an increased attack surface or a lack of identity assurance, summarized in Table 6. The two-year threshold for unrevoked keys serves as a conservative staleness heuristic, aligning with NIST cryptoperiod guidance to flag credentials whose exposure window persists absent formal control mechanisms [4, 48, 51]. The data reveals two primary drivers of key debt. First, a lack of explicit lifecycle boundaries is the most prevalent risk, with over 16% of keys remaining active indefinitely without an expiration date. Second, the 10.27% of unverified signing keys represents a significant identity gap; these credentials possess the technical capability to sign code or data, but lack the platform-level verification required to anchor that capability to a proven user identity. At the user level, the distribution of this debt is widespread but heavily skewed. While nearly 28.39% of users (34, 644; 95% CI: 28.13%–28.64%) possess at least one dead key, the median user has none. Figure 10 illustrates this extreme concentration: while 95% of users hold two or fewer dead keys, a sparse long tail of outliers possesses dozens, with a single user reaching a maximum of 84

Count (𝑛)

% of Total Keys

3,090 34,361 21,414

1.48% 16.48% 10.27%

Table 7: Dead key accumulation by account age. Both mean dead key count and prevalence increase monotonically with account tenure, confirming that credential debt accumulates passively over time

Users

Mean Dead Keys

Users with ≥1 Dead Key

16,781 (13.7%) 17,520 (14.4%) 33,050 (27.1%) 31,526 (25.8%) 23,173 (19.0%)

0.05 0.08 0.35 0.50 0.85

4.37% 6.39% 28.08% 35.29% 53.46%

Account Age <1 year 1–2 years 2–5 years 5–10 years 10+ years

keys. Crucially, this debt is not randomly distributed across the population. Account age is a moderate but consistent predictor of dead key accumulation (Spearman 𝜌 = 0.38, 𝑝 < 0.001), with the pattern holding monotonically across age groups (Table 7). Among accounts under two years old, fewer than 7% carry any dead key. Among accounts older than ten years, that figure rises to 53.5%, with a dead keys per user. This concentration makes the problem tractable: targeted outreach to long-tenured accounts would reach the majority of hygiene risk without requiring platform-wide intervention.

105

Number of users (Log Scale)

Rotation is uncommon and largely reactive. To probe whether expiration triggers replacement, we measure a conservative registry-level replacement signal: whether the key owner adds another key to their GitHub account within 30 days before or after the expiring key’s expiration date. We use a 30-day window to capture actions plausibly prompted by the expiration boundary while minimizing accidental matches to unrelated key uploads. This signal indicates that a new credential was uploaded near its expiration date, but it does not, by itself, establish that the new key was adopted for signing or that the expiring key was retired. Overall, only 8.42% of expiring keys exhibit such a replacement. The timing further suggests reactive maintenance. Among keys that are not expired at snapshot, the replacement signal is essentially absent at 0.14%, whereas among keys already expired it rises to 15.79%. This difference is highly statistically significant (𝜒 2 (1) = 461.82, 𝑝 < 0.001), and indicates that users typically do not rotate keys before expiration; when replacements occur, they are disproportionately associated with keys that have already lapsed.

Risk Component

104 103 102 101 100 0

10

20

30

40

50

Dead keys per user

60

70

80

Figure 10: Distribution of dead keys per user.

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

Lesson 4: Most developers treat cryptographic keys as permanent fixtures rather than credentials requiring active maintenance. Expiration dates are rare, and when they exist, they are almost never followed by revocation or replacement. When developers do replace a key, it is usually because it has already lapsed, not because they planned ahead. This reactive posture means that stale, unmanaged keys quietly accumulate on the platform, creating a growing pool of credentials that nobody is actively controlling.

7

Discussion and Conclusion

In this study, we examine how developers on GitHub sign their commits at a scale and granularity that prior work has not attempted. Rather than focusing on individual projects, we follow developers across all their repositories and track their signing behavior over time. Using a broad sample of GitHub accounts, we measure how signing works in practice, how many developers actually do it, how consistently they sustain it, and how well they manage the keys that signing depends on. In the subsections below, and using the comparison table in the Appendix and the detailed Table 9 in the Appendix, we compare our findings with prior work, identify where we agree, where we diverge, and what this platform-wide view of developer behavior reveals that project-level studies could not.

7.1

Agreement with Prior Work

The most important area of agreement is on the number that matters most: roughly 5 to 6% of developer-managed commits carry a signature, a figure that holds across our platform-wide sample, Holtgrave et al.’s [27] critical project dataset, and Sharma et al.’s [50] cross-domain repositories. Three studies with fundamentally different sampling strategies converging on this range suggests that low local signing adoption is a stable property of developer behavior on GitHub, not an artifact of any particular dataset. Similarly, all three studies identify unknown_key as the dominant verification failure mode. Developers are not failing because cryptography is hard; they are failing because they complete only half the setup, signing commits locally without registering the corresponding public key with GitHub. This is a usability problem, not a cryptographic one, and the convergence across studies makes that diagnosis difficult to dispute. We also agree with Holtgrave et al. [27] that signing frequency declines as developer activity grows. They observe this at the repository level; we see it at the individual level with a large effect size. That alignment across two different units of analysis strengthens the interpretation that signing is genuinely incompatible with high-throughput development workflows as currently designed. On key management, our OpenPGP expiry rate of 35.45% sits almost exactly on Holtgrave et al.’s [27] 36.6%, a tight match given entirely different populations, suggesting that key configuration habits are relatively uniform across the GitHub developer community.

anonymous et al.

7.2

Divergence and New Insights

The most consequential divergence is one prior work could not have detected by design. Both Holtgrave et al. [27] and Sharma et al. [50] measure signing at the repository level, conflating platformgenerated and developer-managed signatures in the same pool. We show this is not a minor accounting issue. When GitHub’s automatic web-interface signing is included, adoption appears at 89%. When it is excluded, adoption falls to under 6%, and 94% of apparent signers have never signed a single commit outside a web browser. This is not a consistency gap where developers sign sometimes but not always. It is a capability gap where the vast majority of apparent signers have never engaged with the underlying cryptographic mechanism at all. A related divergence concerns the always-signs rate. Holtgrave et al. [27] report 2% of committers sign all their commits; we find 0.37% among local signers. Their population includes users who sign everything through the GitHub UI, for whom consistency costs nothing because the platform handles it automatically. Our population is restricted to developers operating outside the browser, where consistency requires deliberate effort. The gap between 2% and 0.37% is precisely the size of the illusion that platform mediation creates. We also surface failure modes invisible to any study that does not follow developers across time. Nearly half of local signers produce unsigned commits after their final signed one, and among developers who signed from their very first local commit, a quarter have already lapsed by our snapshot date, most of them having committed within the past year. This is abandonment despite engagement, not abandonment through inactivity, which is a qualitatively more concerning pattern. On key management, Holtgrave et al. [27] find 20.3% of PGP keys expired; we find 52.85%. This likely reflects population differences, as critical OSS contributors may be more attentive to key hygiene than the broader GitHub population. More importantly, neither prior study examines what happens after expiry. We find 99.81% of expired keys are never revoked and rotation is almost entirely reactive. This moves the finding from a descriptive observation about expiry rates to a mechanistic claim about how developers manage credential lifecycle, which has direct implications for the trustworthiness of the provenance signal over time.

7.3

Implications and the Way Forward

These findings point to a problem that is structural rather than behavioral. Developers who configure local signing and then stop are not becoming less security-conscious. They are encountering a workflow that was not designed to survive the ordinary turbulence of a developer’s life: new machines, new repositories, new collaborators, and context switches that interrupt habits. The fact that consistent signing is concentrated among low-activity developers suggests the workflow is sustainable only at low volume, which is precisely the opposite of where provenance guarantees matter most. Platform design is therefore the lever with the most potential. The verified badge currently signals platform authentication for web-flow commits and cryptographic developer identity for locally signed commits using the same visual indicator. Bifurcating the

Analysis of Commit Signing on Github

badge, as both we and Holtgrave et al. [27] recommend, would at minimum make the distinction legible to downstream consumers. More impactful would be closing the feedback loop at push time. The dominant failure mode, developers who sign locally but never upload their key, is entirely addressable by a push-time warning that detects an unregistered key and prompts completion. This is not a cryptographic challenge. It is a nudge problem. Key lifecycle management points in the same direction. If 99.81% of expired keys go unrevoked, the platform cannot rely on users to initiate cleanup. Pre-expiration notifications, automated rotation prompts, and dead-key indicators in developer dashboards would cost little to implement and could materially reduce stale credentials. None of these interventions require developers to change their fundamental security posture. They require platforms to take responsibility for the friction they have not yet eliminated.

7.4

Open Questions

That said, this study is observational by design, and observation has limits. The patterns we document raise questions we cannot answer from commit metadata alone: what causes a developer who signed consistently for months to simply stop, whether enterprise environments with enforced policies and managed devices produce different outcomes, and whether any of the interventions we propose would actually move behavior at scale. These are empirical questions and they deserve controlled experiments rather than speculation. Until those experiments exist, our recommendations should be read as well-evidenced hypotheses about where to intervene, not as proven solutions.

Ethical Considerations Research procedures and data sources. Our study was conducted in accordance with ethical guidelines and GitHub’s Terms of Service. We collected only publicly available information from public repositories and profiles (e.g., commit metadata, user profile fields, and registered public keys). We did not attempt to access private repositories or otherwise non-public data. All requests used personal access tokens from members of our research group, respected API rate limits, and avoided disruptive behavior. We did not contact users in the dataset, attempt to access accounts, modify repositories, or perform any intervention; our analysis is purely observational. Stakeholder identification and impacts. Direct stakeholders include the research team and the platform provider, GitHub, whose provenance and verification semantics shape how commit-signing signals are presented and interpreted. Indirect stakeholders include GitHub users whose public activity and registered keys contribute to the observable ecosystem; maintainers and organizations whose repositories contribute to the commit graph; downstream consumers such as open-source users, package ecosystems, and auditors who rely on provenance signals; and the broader research community that may build on our methods and results. Positive impacts. This work provides evidence about how reliably commit signing covers development activity in practice and which workflow and key-management factors limit its

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

effectiveness. These results can inform improvements to tooling, platform design, and operational guidance that strengthen software supply-chain defenses and help maintainers, auditors, and downstream consumers understand the limits of provenance signals in risk assessment. Potential harms analysis. Even when individual records are publicly visible in isolation, centralizing and analyzing them at scale can increase privacy and abuse risks. In particular, aggregation can reduce the cost of profiling, targeting, or deanonymizing developers and projects [38, 43, 61, 63]. A second risk is dual use: findings about failure modes, weak cryptographic configurations, or verification gaps could be operationalized by adversaries. The Menlo Report emphasizes minimizing foreseeable harms when disclosing security research results [30, 32]. Mitigations and which stakeholders they protect. We implement mitigations that reduce risk to individual users, maintainers, and organizations while preserving scientific value. First, we do not publish a raw dataset containing user-linkable metadata or key material (Appendix § 7.4), reducing the risk of large-scale profiling or targeting of GitHub users. Second, we report results primarily in aggregate and avoid naming or labeling specific accounts or repositories as insecure, which reduces reputational harm and targeting incentives. Third, we store collected data on a secure institutional server with access controls and auditing, restricting access to the authors to reduce the risk of accidental disclosure. Finally, to limit dual-use risk, we provide threat-model context and coarse failure-mode breakdowns without exposing user-linkable artifacts or step-by-step operationalization details. Respect for Persons. We minimize individual-level exposure by focusing on population-level measurements (e.g., adoption and consistency of commit signing) rather than identifiable per-user timelines. When analyzing concentration (e.g., the top-𝑘 contributors to legacy cryptography), we treat it as an ecosystem-level statistic and do not disclose identities. We avoid quoting profile text and avoid spotlighting individual accounts. Justice. The Menlo Report cautions against convenience sampling that disproportionately burdens particular groups [30]. Our sampling is stratified by account creation date rather than demographic or sensitive attributes. Our analysis emphasizes workflows, verification semantics, and key-lifecycle patterns rather than comparing or ranking populations, and we avoid interventions that could differentially burden specific users or projects. Respect for law and public interest. Our methods comply with GitHub’s Terms of Service and align with norms for responsible security measurement research. By clarifying the reliability and limitations of a widely used provenance signal, this work serves the public interest in improving the security and auditability of open-source software supply chains. Publication impacts and decision to publish. Our results may influence how practitioners interpret commit signing and how platforms prioritize provenance features. To reduce misuse and misinterpretation, we report limitations and context, present findings in aggregate, and avoid user-linkable artifacts. We

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

initiated this study to assess ecosystem-scale breakdowns relevant to software supply-chain defense and, before data collection, evaluated foreseeable harms (including aggregation-related privacy risks and dual-use concerns) to shape our methodology and reporting. We decided to publish after a collective agreement within the research team that the findings are likely to strengthen software supply-chain security and help prioritize practical interventions that benefit the broader GitHub and open-source ecosystem.

Open Science We provide an anonymized artifact bundle that includes code to enumerate and sample GitHub accounts, retrieve user profile fields, collect public keys, gather repositories and commits for active users, and extract commit signing and verification metadata. These artifacts allow others to assess the correctness of our data acquisition process, confirm that our measurements are based on the retrieved fields, and reproduce the pipeline on a new sample within GitHub’s API constraints. The bundle is hosted at: https://anonymous.4open.science/r/github-commit-signingmeasurement. However, we do not release the raw collected dataset; in accordance with the privacy safeguards detailed in §7.4, we withhold user-linked metadata and key material (Table 1) to prevent misuse.

anonymous et al.

Analysis of Commit Signing on Github

References [1] Eman Abu Ishgair, Marcela S Melara, and Santiago Torres-Arias. 2024. SoK: A Defense-Oriented Evaluation of Software Supply Chain Security. arXiv e-prints (2024), arXiv–2405. [2] Hammad Afzali, Santiago Torres-Arias, Reza Curtmola, and Justin Cappos. 2018. le-git-imate: Towards verifiable web-based Git repositories. In Proceedings of the 2018 on Asia Conference on Computer and Communications Security. 469–482. [3] Sebastian Baltes and Paul Ralph. 2022. Sampling in Software Engineering Research: A Critical Review and Guidelines. Empirical Software Engineering 27, 4 (2022), 94. doi:10.1007/s10664-021-10072-8 [4] Elaine Barker. 2020. Recommendation for Key Management: Part 1 – General. NIST Special Publication 800-57 Part 1 Rev. 5. National Institute of Standards and Technology. 54–55 pages. doi:10.6028/NIST.SP.800-57pt1r5 Table 2: Comparable security strengths of symmetric block cipher and asymmetric-key algorithms. [5] Elaine Barker and Allen Roginsky. 2019. Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST Special Publication 800-131A Revision 2. National Institute of Standards and Technology. doi:10.6028/NIST.SP.800-131Ar2 [6] Fabian Bäumer, Marcus Brinkmann, Maximilian Radoy, Jörg Schwenk, and Juraj Somorovsky. 2025. On the Security of SSH Client Signatures. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security. 4619–4633. [7] Christian Bird, Peter C Rigby, Earl T Barr, David J Hamilton, Daniel M German, and Prem Devanbu. 2009. The promises and perils of mining git. In 2009 6th IEEE International Working Conference on Mining Software Repositories. IEEE, 1–10. [8] Jon Callas, Lutz Donnerhacke, Hal Finney, David Shaw, and Rodney Thayer. 2007. RFC 4880: OpenPGP Message Format. RFC Editor. https://www.rf ceditor.org/rfc/rfc4880 [9] Scott Chacon and Ben Straub. 2014. Pro Git (2nd ed.). Apress, USA. https: //progit2.s3.amazonaws.com/en/2014-11-20-8fd4b/progit-en.150.pdf [10] Hassan Onsori Delicheh and Tom Mens. 2024. Mitigating Security Issues in GitHub Actions. In Proceedings of the 2024 ACM/IEEE 4th International Workshop on Engineering and Cybersecurity of Critical Systems (EnCyCriS) and 2024 IEEE/ACM Second International Workshop on Software Vulnerability (Lisbon, Portugal) (EnCyCriS/SVM ’24). Association for Computing Machinery, New York, NY, USA, 6–11. doi:10.1145/3643662.3643961 [11] Peng Deng, Lei Zhang, Yuchuan Meng, Zhemin Yang, and Yuan Zhang. 2025. { ChainFuzz } : Exploiting Upstream Vulnerabilities in { Open-Source } Supply Chains. In 34th USENIX Security Symposium (USENIX Security 25). 6199–6218. [12] Encyclopædia Britannica. 2024. GitHub. https://www.britannica.com/technolog y/GitHub Accessed: 2025-12-02. [13] Charlie Eriksen. 2025. S1ngularity/nx Attackers Strike Again. Aikido Security. https://www.aikido.dev/blog/s1ngularity-nx-attackers-strike-again Accessed: 2025-10-21. [14] Felix Fischer, Jonas Höbenreich, and Jens Grossklags. 2023. The Effectiveness of Security Interventions on GitHub. In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (Copenhagen, Denmark) (CCS ’23). Association for Computing Machinery, New York, NY, USA, 2426–2440. doi:10.1145/3576915.3623174 [15] GitGuardian Security Research. 2025. The GhostAction Campaign: 3,325 Secrets Stolen Through Compromised GitHub Workflows. GitGuardian. https://blog.git guardian.com/ghostaction-campaign-3-325-secrets-stolen Accessed: 2025-10-21. [16] GitHub. 2025. Best practices for using the REST API. https://docs.github.com/en /rest/guides/best-practices-for-using-the-rest-api. Accessed: 2025-10-12. [17] GitHub. 2025. Enterprise Managed Users. https://docs.github.com/en/enterprisecloud@latest/admin/concepts/identity-and-access-management/enterprisemanaged-users Accessed: 2026-03-25. [18] GitHub. 2025. GitHub GraphQL API Documentation. https://docs.github.com/en /graphql. Accessed: 2025-10-12. [19] GitHub. 2025. GitHub REST API Documentation. https://docs.github.com/en/rest. Accessed: 2025-10-12. [20] GitHub. 2025. Rate limits and node limits for the GraphQL API. https://docs.githu b.com/en/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api. Accessed: 2025-10-12. [21] GitHub. 2025. Rate limits for the REST API. https://docs.github.com/en/rest/over view/rate-limits-for-the-rest-api. Accessed: 2025-10-12. [22] GitHub, Inc. [n. d.]. Managing commit signature verification. GitHub Docs. https: //docs.github.com/en/authentication/managing-commit-signature-verification [23] GitHub, Inc. 2025. About GitHub. https://github.com/about. Accessed: 2025-10-12. [24] GitHub, Inc. 2025. REST API Endpoints for Users. https://docs.github.com/en/r est/users/users. Accessed: 2025-10-12. [25] Danielle Gonzalez, Thomas Zimmermann, Patrice Godefroid, and Max Schäfer. 2021. Anomalicious: Automated detection of anomalous and potentially malicious commits on github. In 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). IEEE, 258–267. [26] Hao He, Haoqin Yang, Philipp Burckhardt, Alexandros Kapravelos, Bogdan Vasilescu, and Christian Kästner. 2024. 4.5 Million (Suspected) Fake Stars in

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

GitHub: A Growing Spiral of Popularity Contests, Scams, and Malware. arXiv preprint arXiv:2412.13459 (2024). [27] Jan-Ulrich Holtgrave, Kay Friedrich, Fabian Fischer, Nicolas Huaman, Niklas Busch, Jan H. Klemmer, Marcel Fourné, Oliver Wiese, Dominik Wermke, and Sascha Fahl. 2025. Attributing Open-Source Contributions is Critical but Difficult: A Systematic Analysis of GitHub Practices and Their Impact on Software Supply Chain Security. https://www.ndss-symposium.org/wp-content/uploads/2025613-paper.pdf. In Proceedings of the Network and Distributed System Security Symposium (NDSS). Internet Society. [Accessed: Oct. 2, 2025]. [28] Russ Housley. 2009. RFC 5652: Cryptographic Message Syntax (CMS). RFC Editor. https://www.rfc-editor.org/rfc/rfc5652 [29] Eirini Kalliamvakou, Georgios Gousios, Kelly Blincoe, Leif Singer, Daniel M German, and Daniela Damian. 2014. The promises and perils of mining github. In Proceedings of the 11th working conference on mining software repositories. 92–101. [30] Erin Kenneally and David Dittrich. 2012. The menlo report: Ethical principles guiding information and communication technology research. Available at SSRN 2445102 (2012). [31] Sabrina Klivan, Sandra Höltervennhoff, Rebecca Panskus, Karola Marky, and Sascha Fahl. 2024. Everyone for Themselves? A Qualitative Study about Individual Security Setups of Open Source Software Contributors. In 2024 IEEE Symposium on Security and Privacy (SP). IEEE, 1065–1082. doi:10.1109/SP54263.2024.00214 [32] Tadayoshi Kohno, Yasemin Acar, and Wulf Loh. 2023. Ethical frameworks and computer security trolley problems: Foundations for conversations. In 32nd USENIX Security Symposium (USENIX Security 23). 5145–5162. [33] Agata Kruzikova, Jakub Suchanek, Milan Broz, Martin Ukrop, and Vashek Matyas. 2024. What Johnny thinks about using two-factor authentication on GitHub: A survey among open-source developers. In Proceedings of the 19th International Conference on Availability, Reliability and Security (Vienna, Austria) (ARES ’24). Association for Computing Machinery, New York, NY, USA, Article 185, 11 pages. doi:10.1145/3664476.3670885 [34] Piergiorgio Ladisa, Henrik Plate, Matias Martinez, and Olivier Barais. 2023. SoK: Taxonomy of Attacks on Open-Source Software Supply Chains. In 2023 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, Los Alamitos, CA, USA, 1–18. doi:10.1109/SP46215.2023.10179304 [35] Jon Loeliger and Matthew McCullough. 2012. Version Control with Git: Powerful tools and techniques for collaborative software development. O’Reilly Media, Inc. [36] Patrick E McKnight and Julius Najab. 2010. Mann-whitney U test. The Corsini encyclopedia of psychology (2010), 1–1. [37] Kane Meissel and Esther S Yao. 2024. Using Cliff’s delta as a non-parametric effect size measure: an accessible web app and R tutorial. Practical Assessment, Research, and Evaluation 29, 1 (2024). [38] Arvind Narayanan and Vitaly Shmatikov. 2008. Robust de-anonymization of large sparse datasets. In 2008 IEEE Symposium on Security and Privacy (sp 2008). IEEE, 111–125. [39] National Institute of Standards and Technology. 2023. Digital Signature Standard (DSS). Federal Information Processing Standard FIPS 186-5. National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.1 86-5.pdf [40] Sabato Nocera, Simone Romano, Massimiliano Di Penta, Rita Francese, and Giuseppe Scanniello. 2023. Software bill of materials adoption: A mining study from github. In 2023 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 39–49. doi:10.1109/ICSME58846.2023.00016 [41] Nx. 2025. S1ngularity - What Happened, How We Responded, What We Learned. Nx. https://nx.dev/blog/s1ngularity-postmortem Accessed: 2025-10-21. [42] Marc Ohm, Henrik Plate, Arnold Sykosch, and Michael Meier. 2020. Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks. In Detection of Intrusions and Malware, and Vulnerability Assessment: 17th International Conference, DIMVA 2020, Lisbon, Portugal, June 24–26, 2020, Proceedings (Lisbon, Portugal). Springer-Verlag, Berlin, Heidelberg, 23–43. doi:10 .1007/978-3-030-52683-2_2 [43] Paul Ohm. 2009. Broken promises of privacy: Responding to the surprising failure of anonymization. UCLA l. Rev. 57 (2009), 1701. [44] Daniel Olszewski, Tyler Tucker, Kevin R. B. Butler, and Patrick Traynor. 2025. SoK: towards a unified approach of applied replicability for computer security. In Proceedings of the 34th USENIX Conference on Security Symposium (Seattle, WA, USA) (SEC ’25). USENIX Association, USA, Article 25, 20 pages. [45] Hassan Onsori Delicheh, Alexandre Decan, and Tom Mens. 2024. Quantifying security issues in reusable JavaScript actions in GitHub workflows. In Proceedings of the 21st International Conference on Mining Software Repositories. 692–703. doi:10.1145/3643991.3644899 [46] Foster Provost, David Jensen, and Tim Oates. 1999. Efficient Progressive Sampling. In Proceedings of the Fifth ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (San Diego, California, USA) (KDD ’99). ACM, New York, NY, USA, 23–32. doi:10.1145/312129.312188 [47] Matteo Riondato and Eli Upfal. 2015. Mining frequent itemsets through progressive sampling with Rademacher averages. In Proceedings of the 21st ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. ACM, 1005–1014.

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

[48] Riseup. [n. d.]. OpenPGP Best Practices. https://riseup.net/en/security/messagesecurity/openpgp/gpg-best-practices. Accessed: 2026-01-18. [49] Ax Sharma. 2021. $3 Million Cryptocurrency Heist Stemmed from a Malicious GitHub Commit. Sonatype Blog. https://www.sonatype.com/blog/3-millioncryptocurrency-heist-malicious-github-commit Accessed: 2026-01-23. [50] Anupam Sharma, Sreyashi Karmakar, Gayatri Priyadarsini Kancherla, and Abhishek Bichhawat. 2025. On the Prevalence and Usage of Commit Signing on GitHub: A Longitudinal and Cross-Domain Study. In Proceedings of the 29th International Conference on Evaluation and Assessment in Software Engineering (EASE ’25). Association for Computing Machinery, New York, NY, USA, 360–370. doi:10.1145/3756681.3756959 [51] Sonatype. [n. d.]. Working with PGP Signatures. https://central.sonatype.org/p ublish/requirements/gpg/. Accessed: 2026-01-18. [52] Sonatype Security Research Team. 2025. Ongoing npm Software Supply Chain Attack Exposes New Risks. Sonatype. https://www.sonatype.com/blog/ongoingnpm-software-supply-chain-attack-exposes-new-risks Accessed: 2025-10-21. [53] Trevor Stalnaker, Nathan Wintersgill, Oscar Chaparro, Massimiliano Di Penta, Daniel M German, and Denys Poshyvanyk. 2024. BOMs Away! Inside the Minds of Stakeholders: A Comprehensive Study of Bills of Materials for Software Systems. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (Lisbon, Portugal) (ICSE ’24). Association for Computing Machinery, New York, NY, USA, Article 44, 13 pages. doi:10.1145/3597503.3623347 [54] The Git Project. 2021. Git v2.34.0 Release Notes. https://raw.githubusercontent.co m/git/git/master/Documentation/RelNotes/2.34.0.txt See section ’UI, Workflows & Features’. [55] The Linux Foundation. 2025. SLSA specification (Version 1.2). https://slsa .dev/spec/v1.2/ Supply-chain Levels for Software Artifacts (SLSA). Accessed: 2026-01-02. [56] The OpenSSH Project. 2021. PROTOCOL.sshsig: SSH Signature Format. ht tps://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.sshsig Defines MAGIC_PREAMBLE "SSHSIG". [57] Santiago Torres-Arias, Hammad Afzali, Trishank Karthik Kuppusamy, Reza Curtmola, and Justin Cappos. 2019. in-toto: Providing farm-to-table guarantees for bits and bytes. In 28th USENIX Security Symposium (USENIX Security 19). 1393–1410. https://www.usenix.org/system/files/sec19-torres-arias.pdf [58] Laurie Williams, Giacomo Benedetti, Sivana Hamer, Ranindya Paramitha, Imranur Rahman, Mahzabin Tamanna, Greg Tystahl, Nusrat Zahan, Patrick Morrison, Yasemin Acar, Michel Cukier, Christian Kästner, Alexandros Kapravelos, Dominik Wermke, and William Enck. 2025. Research Directions in Software Supply Chain Security. ACM Trans. Softw. Eng. Methodol. 34, 5, Article 146 (May 2025), 38 pages. doi:10.1145/3714464 [59] Nusrat Zahan, Elizabeth Lin, Mahzabin Tamanna, William Enck, and Laurie Williams. 2023. Software bills of materials are required. are we there yet? IEEE Security & Privacy 21, 2 (2023), 82–88. doi:10.1109/MSEC.2023.3237100 [60] Yueke Zhang, Anda Liang, Xiaohan Wang, Pamela Wisniewski, Fengwei Zhang, Kevin Leach, and Yu Huang. 2025. Who’s Pushing the Code? An Exploration of GitHub Impersonation. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE Computer Society, 602–602. [61] Michael Zimmer. 2020. “But the data is already public”: on the ethics of research in Facebook. In The ethics of information technologies. Routledge, 229–241. [62] Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel. 2019. Smallworld with high risks: a study of security threats in the npm ecosystem. In Proceedings of the 28th USENIX Conference on Security Symposium (Santa Clara, CA, USA) (SEC’19). USENIX Association, USA, 995–1010. [63] Matthew Zook, Solon Barocas, Danah Boyd, Kate Crawford, Emily Keller, Seeta Peña Gangadharan, Alyssa Goodman, Rachelle Hollander, Barbara A Koenig, Jacob Metcalf, et al. 2017. Ten simple rules for responsible big data research. e1005399 pages.

A

Appendix

anonymous et al.

Quantile 𝑞 0.10 0.25 0.50 0.75 0.90 0.95 0.99

Signing rate at 𝑞 0.0049 0.0380 0.2203 0.6588 0.9743 1.0000 1.0000

Table 8: Selected quantiles of per-user signing rate among signers. Each user’s signing rate is the fraction of their observed commits that are signed, restricted to users who signed at least once. The mass at 1.0 indicates a minority of users who sign all observed commits, while lower quantiles reflect intermittent signing.

Figure 11: Communication from GitHub Support declining a permanent rate limit increase, necessitating the use of standard API limits for this study.

Analysis of Commit Signing on Github

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

Table 9: Full comparison of commit signing measurement studies on GitHub. Dimension

Our Work

Holtgrave et al. [27]

Sharma et al. [50]

𝚫

Unit of analysis

User-centric

Repository-centric

Repository-centric

Unique

Accounts sampled

2,737,649; 71,694 active

—

—

Unique

Repositories analyzed

874,198

50,328

60

We have more repos

Commits analyzed

16,112,439

25,889,629

869,437

We have less commits

Includes small / hobby repos

Yes

—

—

Unique

STUDY DESIGN

PLATFORM SEMANTICS — UI VS. DEVELOPER SIGNING Distinguishes UI from developer signing

Yes — core contribution; analyzed separately throughout

Yes — UI identified and excluded from user signing counts

Yes — excluded via [email protected] filter; bots manually identified

All three agree

UI signing share of all signed commits

82.69% of all signed commits originate from GitHub UI

72.9% of signed commits from UI

—

Our results aligns

UI-only signers as share of all “signers”

94.29% of users who ever signed are UI-only; no local signing observed

—

—

Unique — provenance paradox finding

Provenance paradox / badge ambiguity

“Verified” badge conflates platform transport security with developer identity

Recommends splitting badge for GitHub-generated vs. developer signatures

Notes auto-signing exists; no paradox framing

Bot activity

0.06% (9,963 commits); none signed

—

—

Aligns; yours most developed framing

Unique

SIGNING ADOPTION — OVERALL RATES Diverges — UI inflation explains gap

Overall signed commit rate (incl. UI)

89.21% of active users ever signed; 24.05% of commits signed

15.7% of all commits signed

33.27% overall; 9.65% excl. bots and UI

Developer-managed signing rate

5.94% of non-UI committers ever signed locally (3,643/61,364)

5.0% of user commits signed (excl. UI)

9.65% of non-bot, non-UI commits signed

Users / committers who never signed

94% of apparent signers never signed outside UI; 10.79% never signed at all

95.4% of committers never signed a commit

>80% of committers have zero signed commits

Always-signs rate (100% consistency)

0.37% of all active users; 7.27% of local signers always sign

2.0% of committers signed all commits

—

Per-repository signing rate

25.2–26.7% across repo activity groups among signers; uniformly rare (Cliff’s 𝛿 = −0.062)

Average ∼5% in repos with any signing; 72.1% of repos have zero signed commits

∼10% average across 60 repos; 28.35% in securitydomain repos

Aligns

∼5–10% range across all three Strong agreement ∼95% Diverge — we found 5x lower

LONGITUDINAL TRENDS Time from first commit to first local sign

UI adoption immediate (median 0 days); local signing severely delayed (median 1,122 days)

—

—

Unique

Time from account creation to first local sign

Median from account creation: 2,128 days; Mann–Whitney 𝑈 = 448,593, 𝑝 = 4.63 × 10 −25

—

—

Unique

Unsigned commits before first sign

Median 136 unsigned commits before first local sign (IQR: 34–429); 14.53% sign very first commit

—

—

Unique

(continued on next page)

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

anonymous et al.

(continued from previous page) Dimension

Our Paper

Holtgrave et al. [27]

Sharma et al. [50]

Verdict

Account age vs. local signing

Spearman 𝜌 = 0.21, 𝑝 < 0.001; adoption rises from 0.85% (<1 yr) to 15.23% (10+ yr); median local signer account age 3,659 days vs. 1,460 days for nonsigners

—

—

Unique

Account age vs. lapse

Spearman 𝜌 = 0.08, 𝑝 < 0.001; lapse rate rises from 15.91% (<1 yr) to 30.49% (10+ yr) among local signers

—

—

Unique

BEHAVIORAL CONSISTENCY AND SUSTAINABILITY Per-user signing rate distribution

Median local signer signs only 22% of commits; 12.76% sign ≥ 90%; 7.27% sign 100%

—

—

Unique

Cross-repository consistency

Only 12.65% of local signers sign in all repos; 96.1% sign inconsistently across repos; signing behavior is decoupled from contribution volume

—

—

Unique

Signing lapse / abandonment

42.33% of local signers produce unsigned commits after final signed commit; median 35 unsigned commits after last signed; 79.26% of lapsed signers still active within the year

—

—

Unique

Productivity penalty (high activity → less signing)

Cliff’s 𝛿 = −0.803 (𝑝 = 2.10 × 10 −105 ); consistent signers have far fewer commits; large effect; median commits for 100%-signers = 11 vs. 308 for others; 48.68% have ≤ 10 commits total

Signing frequency decreases with more contributors or commits (Figure 9)

—

Align

Directionally similar; ours higher due to UI inclusion

VERIFICATION OUTCOMES AND FAILURE MODES Overall verification rate

97.77% overall; 99.92% UI; 87.51% non-UI; 𝜒 2 (1) = 392,519.44, 𝑝 < 0.001

82% PGP valid; 90% SSH valid (user commits only)

—

Dominant failure mode

unknown_key — 73.73% of nonUI failures

unknown_key dominant — 10% PGP, 7% SSH failures

unknown_key identified as primary cause

Aligns

bad_email failures

7.14% of non-UI failures

2% of PGP failures

10 commits in dataset

We found higher rates

unverified_email failures

15.06% of non-UI failures

2% of PGP failures

646 signed commits flagged as significant attack vector

We found 7x higher rates

UI dominant failure mode

expired_key drives 71.56% of UI failures; invalid accounts for 24.31%

—

—

Unique

Non-UI commits more likely to fail

2,563 invalid UI vs. 83,760 invalid non-UI signed commits; non-UI ∼150 × more likely to fail

—

—

Unique

Failures driven by admin issues, not crypto breaks

Identity-binding issues dominate; cryptographic invalidity <0.1%

Unknown key, bad/unverified email dominate; invalid <0.1%

Same failure taxonomy; same conclusion

Agreement

—

—

Unique

CRYPTOGRAPHIC HYGIENE Legacy SHA-1 signatures

15,461 commits spanning 2012– Dec. 2025; 87.34% verified; 172 authors; top 10 account for 55.36%

(continued on next page)

Analysis of Commit Signing on Github

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

(continued from previous page) Dimension

Our Paper

Holtgrave et al. [27]

Sharma et al. [50]

Verdict

Legacy DSA algorithm

5,594 commits as recently as Mar. 2026; 46 authors; top 5 account for 74.83%; 98.52% still verified; peak activity in 2024

626 DSA-1024 keys present among uploaded signing keys

—

Align

Legacy cryptography is concentrated, not systemic

SHA-1 from only 172 authors; DSA from 46 — localized toolchain hygiene issue, not an ecosystem-wide flaw

—

—

Unique framing and finding

Legacy signatures absent in UI

Neither SHA-1 nor DSA appear in any GitHub UI commits — confined to developer-managed toolchains

—

—

Unique

Signature format distribution

OpenPGP dominant; SSH growing; CMS/PKCS#7 rare

PGP: 98.9% of user sigs; SSH: 1.1%; S/MIME: 538 commits

Format breakdown not deeply analyzed; GPG and SSH noted

Backward compatibility validates legacy

GitHub verifies SHA-1 and DSA if key is registered; “valid” label does not imply modern primitives

GitHub verifies regardless of algorithm age; backward compatibility noted

—

Aligns

PGP dominance confirmed

KEY MANAGEMENT (LIFECYCLE) Expiration rate — PGP keys

35.45% of OpenPGP keys have an expiry date; only 2.81% of all key types combined

36.6% of PGP keys have expiry date; average span 4.8 years

—

∼35%

SSH expiration metadata

Essentially absent — SSH format does not support expiry timestamps; reflects format semantics, not user choice

No expiry for SSH keys (noted)

—

Aligns

Keys already expired at snapshot date

52.85% of expiring keys already expired by Dec. 2025 (3,096/5,858)

20.3% of PGP keys marked expired

—

We found 2x rate

Revocation rate

99.81% of expired keys remain unrevoked — revocation is effectively non-existent

—

—

Unique

Key rotation behavior

Only 8.42% of expiring keys show replacement within 30 days; rotation is reactive (post-expiry); 𝜒 2 (1) = 461.82, 𝑝 < 0.001

—

—

Unique

Dead keys metric

Novel metric: 34,644 users (28.39%; 95% CI: 28.13%– 28.64%) carry ≥ 1 dead key (expired+unrevoked, long-lived without expiry, or unverified)

—

—

Unique

Dead keys concentration

Heavy-tailed: median user has 0 dead keys; 95th percentile = 2; max 84 keys; improvement achievable via targeted intervention

—

—

Unique

Long key lifetimes

Median configured lifetime 730 days; 95th percentile 3,650 days (10 years)

Average 4.8 years between creation and expiration

—

Long-lived keys are the norm

Account age vs. dead key accumulation

Spearman 𝜌 = 0.38, 𝑝 < 0.001; users with ≥ 1 dead key rises from 4.37% (<1 yr) to 53.46% (10+ yr)

—

—

Unique

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

anonymous et al.

Table 10: RQ1 Statistics: 1% vs 2% Sample Metric

1% Sample

2% Sample

Platform Dominance Total commits UI commits (% of total) UI signing rate Non-UI signing rate 𝜒 2 (UI vs non-UI signing) Signed commits from GitHub UI Users who only sign via UI

7,799,840 20.21% 96.37% 5.34% 5,758,439.83 82.06% 94.26%

16,112,439 20.63% 96.41% 5.24% 12,002,263.50 82.69% 94.29%

Consistency Paradox Always signs: total users Always signs: UI-only (%) Always signs: Mixed (%) Always signs: Non-UI-only (%) Inconsistent: total users Inconsistent: UI-only (%) Inconsistent: Mixed (%) Inconsistent: Non-UI-only (%)

5,048 97.2% 1.9% 0.9% 25,184 93.7% 6.1% 0.2%

10,404 97.5% 1.8% 0.7% 53,557 93.7% 6.1% 0.2%

97.78% 99.94% 87.91% 182,260.48 79.95% 7.11% 8.99% 92.59% 5.41% 0.02% 0

97.77% 99.92% 87.51% 392,519.44 73.73% 15.06% 7.14% 71.56% 24.31% 0.06% 0

7,873 81 18.16% 73.14% 80.69% 2016 (2,223 sigs) 1,186 14 58.77% 95.28% 98.06% 2018 0%

15,461 172 12.54% 55.36% 87.34% 2016 (4,207 sigs) 5,594 46 29.76% 74.83% 98.52% 2024 0%

Verification Outcomes Overall valid rate UI valid rate Non-UI valid rate 𝜒 2 (verification UI vs non-UI) Non-UI failure: unknown_key Non-UI failure: unverified_email Non-UI failure: bad_email UI failure: expired_key UI failure: invalid Bot commits (% of total) Bot commits signed Cryptographic Hygiene SHA-1 signatures SHA-1 unique authors SHA-1 top-1 author share SHA-1 top-10 author share SHA-1 verified rate SHA-1 peak year DSA signatures DSA unique authors DSA top-1 author share DSA top-5 author share DSA verified rate DSA peak year SHA-1/DSA from GitHub UI

Analysis of Commit Signing on Github

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

Table 11: RQ2 Statistics: 1% vs 2% Sample Metric

1% Sample

2% Sample

33,895 89.00% 59.00% 0

71,694 89.21% 58.78% 0

Adoption (non-UI only) Non-UI signers (% of users) Non-UI signing users (count) Median days: account to first sign Median days: first commit to first sign Mann-Whitney (UI vs local latency) Sign very first non-UI commit Late adopter median days to first sign Late adopter IQR (days) Median unsigned commits before signing IQR unsigned commits before signing

6.00% 1,734 / 28,924 2,138 1,138 U=1,228,394, p=0.013 15.70% (270/1,734) 327 56–1,189 146 33–495

5.94% 3,643 / 61,364 2,128 1,122 U=448,593, p=4.63×10 −25 14.53% (526/3,643) 1,440 622–2,549 136 34–429

Sustained Practice Sign in ALL repos Sign in SOME repos Mann-Whitney (repo consistency) User × repo pairs analyzed Cliff’s 𝛿 (repo size effect) Users with 2+ repos Signers among 2+ repo users Inconsistent across repos Median signing rate std dev (across repos)

13.30% (231) 86.60% (1,502) U=23,935,230, p<0.001 326,013 -0.029 21,672 7.50% (1,631) 95.80% 0.33

12.65% (461) 87.32% (3,181) U=123,836, p<0.001 93,001 -0.062 3,456 3.90% (134) 96.10% 0.33

Signing Lapse Median per-user signing rate Sign ≥90% of commits Sign 100% of commits Median commits: perfect signers Median commits: imperfect signers Lapse rate Median unsigned after last signed commit 75th pct unsigned after last signed commit Unsigned last commit (signed-first users) Median age of unsigned-last commit (days) Last commit within 365 days

22% 14.40% 8.10% (141 users) 9 315 41.90% (727/1,734) 37 177 23.00% (62/270) 152 77.40%

22.45% 12.76% 7.27% (265 users) 11 308 42.33% (1,542/3,643) 35 162 25.67% (135/526) 140 79.26%

1,351,917 332,037 25.00% -0.819

2,607,634 669,477 25.67% -0.803

Adoption (including UI) Total active users Ever signed (incl. UI) Sign very first commit (incl. UI) Median days to first signed commit

Friction at Scale Total commits from signers Signed commits from signers Overall signing rate among signers Cliff’s 𝛿 (always vs not always)

Conference acronym ’XX, June 03–05, 2026, Woodstock, NY

Received 20 February 2007; revised 12 March 2009; accepted 5 June 2009

anonymous et al.