Pith. sign in

REVIEW 3 major objections 5 minor 86 references

ARMS: A Vision for Actor Reputation Metric Systems in the Open-Source Software Supply Chain

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper proposes ARMS, an Actor Reputation Metric System that would score open-source contributors on seven security signals so maintainers can triage their pull requests.

desk verdict The stress-test is right: five of the seven signals don't actually operate for external contributors, leaving a load-bearing attribution gap, but this is still a serious vision paper worth refereeing. read the letter →

arxiv 2505.18760 v4 pith:7DF6SQL4 submitted 2025-05-24 cs.CR cs.SE

Kelechi G. Kalu , Sofia Okorafor , Betül Durak , Kim Laine , Radames C. Moreno , Santiago Torres-Arias , James C. Davis This is my paper · ORCID
classification cs.CRcs.SE
keywords softwaresupplychainsecurityactorreputationopen-sourcemaintainervettingsignalsmetricscontributortriagedecisionsupport
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Open-source maintainers routinely merge code from strangers, and existing checks examine the artifact rather than the actor behind it. This paper argues that the ecosystem needs an Actor Reputation Metric System (ARMS): a trust engine that turns a contributor's public security-relevant history into a reputation score. The authors identify seven security signals—covering vulnerability handling, dependency hygiene, code scanning, integrity guarantees, branch protection, security policies, and automated workflows—and map each to concrete, measurable metrics derived from industry standards and existing security tooling. If such a system worked, maintainers could triage contributions from unknown actors with higher confidence, routing risky submissions into stricter review while letting trusted contributors move faster. The paper also outlines quasi-experimental studies to test whether these signals actually predict downstream security outcomes.

What carries the argument

The load-bearing object is the seven-signal reputation model (S1–S7) together with weighting factors W1–W3. Signals S1–S2 capture actor behavior (vulnerabilities introduced through commits or pull requests, and use of vulnerable dependencies), while S3–S7 capture repository governance practices (code scanning, integrity guarantees, branch protection, security policies, and automated workflows) and are treated as context unless control can be attributed to the actor. Each signal aggregates one or more measurable metrics, and the trust engine computes a normalized per-signal score, a weighted linear composite, a calibrated score using W1–W3, and an ecosystem-benchmarked score; the final output is triage guidance rather than automatic acceptance or rejection. The design deliberately consumes best-available outputs from existing security tools and treats them as noisy evidence for decision support rather than ground truth.

What would settle it

Compare pre-incident reputation scores for accounts behind known supply-chain backdoors, such as the XZ Utils attacker, with matched benign contributors; if the malicious accounts' scores are indistinguishable from or higher than those of benign contributors, the signals are not predictive of security outcomes.

Watch

Extended reading notes

Core claim

The paper's central claim is that actor reputation can be operationalized for cybersecurity in open-source development. It defines a reference architecture in which the maintainer team is the trustor, the prospective contributor the trustee, and ARMS the missing trust engine. Interaction history is distilled into seven security signals (S1–S7), each aggregated from concrete metrics such as time-to-fix vulnerabilities, the number of projects with vulnerable dependencies, security-alert status, protected branch counts, private vulnerability reporting, and automated workflow presence; three calibration factors (W1–W3) adjust evidence for downstream exposure, community tenure, and network centrality. The trust engine combines per-signal scores into a composite, calibrates and benchmarks that score, and outputs a recommended triage action—faster routing for high scores, stronger safeguards or additional verification for low or sparse histories—while treating missing signals as unknown rather than negative evidence. The paper demonstrates the design on the XZ Utils backdoor, where the attacker's sparse and shallow public history would yield a low reputation score, and on the Dexcom outage, which would depress the responsible engineers' signals; it explicitly leaves impersonation attacks out of scope because they break the stable-identity assumption that any reputation system requires.

Load-bearing premise

A contributor's public, artifact-based history on collaborative development platforms is a stable and honest proxy for their future security behavior, and determined attackers cannot cheaply fabricate good signals.

Editorial extensions

If this is right

  • Maintainers could route unknown contributors' pull requests by risk: high-scoring actors receive normal review, while low-scoring or sparse-history actors are steered into smaller-scoped pull requests, two-person review, or mandatory signing requirements.
  • ARMS-style actor metrics would complement artifact-based checks, closing a vetting gap the paper identifies in current supply-chain security practice.
  • If the proposed retrospective incident prediction study confirms predictive utility, projects could set their own risk thresholds and use benchmarked reputation percentiles before granting contributor or maintainer access.
  • A deployed ARMS would imply a privacy-preserving disclosure model in which contributors opt in, view dashboards of what will be shared, and maintainers receive only aggregated or pseudonymized scores.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same signal architecture could be extended to software agents and bots that increasingly commit code; because agents evolve and are composed as dependencies, their reputation would need to be strongly versioned and lifecycle-aware.
  • A testable extension beyond the paper's retrospective studies is a randomized field experiment in which matched projects receive ARMS-style triage recommendations for new contributors, with merge decisions and downstream vulnerability incidence measured over time.
  • If public artifact history proves to be a weak proxy for security behavior, the framework could be strengthened by adding the social and process signals the paper lists as future work, such as code-review feedback quality and explicit threat-model discussions.
  • The chilling-effect concern implies a deployment boundary: ARMS is most defensible on high-criticality, security-sensitive packages, leaving hobby and low-risk repositories untouched, although the exact criticality threshold remains an open question.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. This vision paper proposes ARMS, an Actor Reputation Metric System intended to help open-source maintainers assess the cybersecurity reputation of prospective contributors. The paper motivates the need for actor-centric measurement as a complement to artifact-centric security checking, presents a threat model distinguishing inexperienced contributors, reputation spoofers, and impersonation (with impersonation out of scope), and proposes seven security signals S1–S7 plus three calibration factors W1–W3. These signals are mapped to concrete metrics in Table 1, drawing on standards such as SLSA, CNCF, NIST SSDF, and OpenSSF Scorecard, and on GitHub-ecosystem tools. The trust-engine section gives candidate formulas for per-signal scoring, composite scoring, calibration, and benchmarking, and the paper closes with study designs for effectiveness evaluation and user behavior, plus discussions of privacy, gameability, and future extensions to agents and process metrics. The central claim is that ARMS can operationalize actor cybersecurity reputation from public GitHub interaction histories in a way that supports maintainer triage decisions.

Significance. If the central claim were fully realized, ARMS would be a useful complement to artifact-centric supply-chain security: the paper provides a clear mapping from high-level security standards to measurable signals, an explicit threat model with a defensible out-of-scope boundary (impersonation), and a set of concrete, falsifiable evaluation designs, including difference-in-differences, retrospective incident prediction, ablation, and vignette studies. The paper is also unusually candid about limitations: it acknowledges false positives/negatives, insider threats, privacy harms, gameability, and chilling effects, and it proposes specific mitigations. The main weakness is that the operationalization is incomplete for the exact population the system targets, external non-maintainer contributors, because signals S3–S7 are repository-level attributes without a stated attribution rule. As a vision paper this is not fatal, but the central 'seven-signal' claim is currently overstated; the paper needs either a concrete attribution mechanism or a narrowed claim that treats S3–S7 as repository context rather than actor behavior.

major comments (3)
  1. [§4.2/Table 1 and §4.3] The central operationalization claim is not delivered for the population ARMS targets. Signals S3–S7 (dependabot status, secret scanning, branch protection, security policy, automated workflows) are repository-configuration metrics. The only attribution rule is the Table 1 note: "S3–S7 reflect repository configuration and are treated as context unless governance control is attributable to the actor (e.g., owner/maintainer)." For a non-maintainer external contributor, no rule is given for attributing these metrics to the actor, and no algorithm is specified for handling Score_S3..S7 when they are undefined or inapplicable. As written, a typical contributor receives only S1–S2, so the claim that ARMS computes "seven security signal scores" is unsupported. Please either specify an attribution rule for contribution events to repository-configuration changes, or explicitly redefine S3–S7 as repository-level context that modulates the actor-level signals, and describe how missing or undefined signal scores enter the composite R0(a) in §4.3.
  2. [§4.3 composite equation] The reputation computation is not yet operational even for signals S1–S2. The event-level extraction function f_s(e), the normalization function Norm(·), the calibration factors W1–W3, and the weights alpha_s are left unspecified; the paper explicitly defers alpha_s to future empirical analysis. For a paper whose contribution is to "operationalize" trust, this leaves the central mechanism as a schema rather than an instantiation. Please provide at least one fully specified baseline (e.g., uniform weights, min-max normalization, event counts weighted by package downloads) so that the framework can be instantiated and the ablation studies in §5.1 can be executed.
  3. [§3.1, §4.5, §6.1] The threat model lists Reputation Spoofing as an in-scope adversary, but the only defenses offered are time-weighted scoring and human oversight (§6.1). The XZ Utils worked example (§4.5.1) is post hoc: it applies the framework after the fact to an actor with sparse public history, but it does not show that the proposed signals would have flagged this actor prospectively, and it does not explain how repository-level signals S3–S7 would be attributed to a non-maintainer contributor. The planned retrospective study in §5.1 is a reasonable start, but it needs to include a concrete test of spoofing resistance, such as measuring how quickly a newly created account can accumulate a high score under the proposed aggregation, or a comparison of pre-incident signal profiles for known spoofing attacks against matched controls.
minor comments (5)
  1. [§3.1] The phrase "ARMS operates considers three kinds of threat actors" is ungrammatical; please revise.
  2. [§4.3] The displayed equation for Score_S_s(a) contains a rendering artifact ("Norm ©" and stray formatting); please fix the equation and ensure all variables are defined in the surrounding text.
  3. [References] Reference [48] contains an editorial placeholder, "Check the exact CCS year/track formatting used by your bibliography style," which must be removed before publication.
  4. [§6.2] The statement "our work assumes that actors are well-intentioned" appears to conflict with the threat model in §3.1, which explicitly includes malicious reputation spoofers; please reconcile the scope description.
  5. [Table 1] The Table 1 note says S3–S7 are treated as context "unless governance control is attributable to the actor (e.g., owner/maintainer)", but no definition of "governance control" is given; please clarify what actions or roles establish attribution.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: ARMS is a design proposal whose seven signals are sourced from external standards and tools, and whose evaluation studies are prospective rather than fitted to the proposed metrics.

full rationale

The paper makes no empirical prediction that is fitted from its own inputs. Section 4.2 states that the security signals are derived from external sources: "we consulted frameworks like the SLSA security framework, the CNCF software supply chain security guidelines, NIST SSDF, NIST SP 800-204D, OpenSSF S2C2F, and the CIS Software Supply Chain Security Guide," and from "security tools available through GitHub's user interface and API." The metrics in Table 1 are explicitly mapped from prior work (e.g., [7], [54], [83]) rather than invented to reproduce an output. The trust-engine formulas in Section 4.3 are presented as candidate instantiations with open design choices: "We treat the selection of alpha_s as an empirical question," and the proposed experiments in Section 5 are prospective evaluations, not post hoc confirmations of a fitted model. Where the authors cite their own prior work, such as Okafor et al. [52] for the artifact-centric framing, it is used as motivational context rather than as a load-bearing uniqueness or derivation premise. There is no equation whose output is identical by construction to an input, and no fitted parameter is renamed as a prediction. The central claim is a design vision, not a derived result, so no circularity is present.

Assumptions & free parameters 5 free parameters · 4 assumptions · 2 invented entities

The central claim depends on the assumption that public GitHub history is a valid measure of security skill and that stable identities hold. The reputation computation requires several parameters (alpha_s, W1-W3, normalization) that are not specified, so the system is not currently reproducible.

free parameters (5)
  • Signal importance weights alpha_s
    Alpha_s coefficients for the composite score R0(a) are left unspecified, to be set by future effectiveness analysis (Section 4.3).
  • W1 package usage factor
    The per-contribution exposure calibration factor is described qualitatively (bounded usage factor) with no formula (Section 4.3, Table 1).
  • W2 community tenure
    Tenure calibration factor for uncertainty; no concrete computation provided (Table 1, Section 4.3).
  • W3 centrality score
    Centrality calibration factor based on connections; no concrete computation provided (Table 1, Section 4.3).
  • Norm normalization function
    Maps aggregated scores to [0,1]; no function specified (Section 4.3).
assumptions (4)
  • domain assumption Stable actor identities
    Paper excludes impersonation attacks, relying on stable identity for reputation (Section 3.1).
  • domain assumption Public contribution history reflects security-relevant behavior
    ARMS uses only GitHub-visible artifact interactions to compute signals (Section 4.2).
  • domain assumption Security standards recommendations are valid proxies for security expertise
    Signals are derived from SLSA, CNCF, NIST, etc. (Section 4.2).
  • domain assumption Repository governance metrics can be attributed to actors when applicable
    S3-S7 are marked as context unless the actor is an owner/maintainer (Table 1, Section 4.2).
invented entities (2)
  • ARMS system
    purpose: Compute and provide actor reputation scores to OSS maintainers
    Proposed system design with no prototype or external validation.
  • Seven security signals S1-S7
    purpose: Quantify facets of contributor security behavior
    Conceptual constructs derived from standards, not yet empirically validated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ARMS: A Vision for Actor Reputation Metric Systems in the Open-Source Software Supply Chain." pith.science (2026). https://pith.science/paper/7DF6SQL4

@misc{pith2026250518760,
  author       = {Pith},
  title        = {Pith review of: ARMS: A Vision for Actor Reputation Metric Systems in the Open-Source Software Supply Chain},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7DF6SQL4}},
  note         = {Machine review of arXiv:2505.18760}
}
read the original abstract

Many critical information technology and cyber-physical systems rely on a supply chain of open-source software projects. OSS project maintainers often integrate contributions from external actors. While maintainers can assess the correctness of a pull request, assessing a pull request's cybersecurity implications is challenging. To help maintainers make this decision, we propose that the open-source ecosystem should incorporate Actor Reputation Metrics (ARMS). This capability would enable OSS maintainers to assess a prospective contributor's cybersecurity reputation. To support the future instantiation of ARMS, we identify seven generic security signals from industry standards; map concrete metrics from prior work and available security tools, describe study designs to refine and assess the utility of ARMS, and finally weigh its pros and cons.

Figures

Figures reproduced from arXiv: 2505.18760 by the authors.

Figure 1
Figure 1. Overview of the proposed ARMS system and context case study. Potential contributors (trustees), who may be malicious ( [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

86 extracted references · 69 canonical work pages

  1. [1]

    Herman Aguinis and Kyle J Bradley. 2014. Best practice recommendations for designing and implementing experimental vignette methodology studies. Organizational research methods17, 4 (2014)

    2014

  2. [2]

    Sabrina Amft, Sandra Höltervennhoff, Rebecca Panskus, Karola Marky, and Sascha Fahl. 2024. Everyone for Themselves? A Qualitative Study about Individ- ual Security Setups of Open Source Software Contributors. InIEEE Symposium on Security and Privacy (SP)

    2024

  3. [3]

    Abhishek Arya, Caleb Brown, Rob Pike, and The Open Source Security Foun- dation. 2023. Open Source Project Criticality Score. https://github.com/ossf/ criticality_score

    2023

  4. [4]

    Sebastian Benthall. 2017. Assessing software supply chain risk using public data. In2017 IEEE 28th Annual Software Technology Conference (STC). 1–5. doi:10.1109/ STC.2017.8234461

    work page arXiv 2017

  5. [5]

    Thomas Bernauer and Marcus M Dapp. 2009. Hot Debate About Chilling Effects: Do Software Patterns Hamper/Free Open Source Software Development? (2009)

    2009

  6. [6]

    Hudson Borges and Marco Tulio Valente. 2018. What’s in a GitHub star? Un- derstanding repository starring practices in a social coding platform.Journal of Systems and Software(2018)

    2018

  7. [7]

    Lina Boughton, Courtney Miller, Yasemin Acar, Dominik Wermke, and Christian Kästner. 2024. Decomposing and Measuring Trust in Open-Source Software Supply Chains. InProceedings of the 2024 ACM/IEEE 44th International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER). 57–61. doi:10.1145/3639476.3639775

    arXiv 2024

  8. [8]

    Tim Bouma. 2024. High Assurance DIDs with DNS. https://www.ietf.org/archive/ id/draft-carter-high-assurance-dids-with-dns-03.html. Internet-Draft. Accessed: 2026-01-26

    2024

Show all 86 references
  1. [9]

    Sam Boysel. 2023. No Free Lunch For Programmers: Digital Supply Chains and the Economics of Software Dependency Management. (2023)

    2023

  2. [10]

    Larissa Braz and Alberto Bacchelli. [n. d.]. Software security during modern code review: the developer’s perspective. In2022 European Software Engineering Conference & Symposium on the Foundations of Software Engineering

  3. [11]

    Moritz Büchi, Noemi Festic, and Michael Latzer. 2022. The chilling effects of digital dataveillance: A theoretical model and an empirical research agenda.Big Data & Society9, 1 (2022), 20539517211065368

    2022

  4. [12]

    Kim Cameron. 2005. The Laws of Identity. https://www.identityblog.com/?p=352. Accessed: 2026-01-26

    2005

  5. [13]

    2021.CIS Software Supply Chain Security Guide

    Center for Internet Security. 2021.CIS Software Supply Chain Security Guide. Technical Report. Center for Internet Security. https://www.cisecurity.org/white- papers/cis-software-supply-chain-security-guide Accessed: 2025-05-20

    2021

  6. [14]

    2024.Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines

    Ramaswamy Chandramouli, Ramaswamy Chandramouli, Frederick Kautz, and Santiago Torres-Arias. 2024.Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines. US Department of Commerce, National Institute of Standards and Technology

    2024

  7. [15]

    Charles Clancy, Joseph Ferraro, Robert Martin, Adam Pennington, Christopher Sledjeski, and Craig Wiener. 2021. Deliver uncompromised: Securing critical software supply chains.MITRE Technical Papers24, 01 (2021)

    2021

  8. [16]

    Cloud Native Computing Foundation. 2021. CNCF paper defines best practices for supply chain security. https://www.cncf.io/announcements/2021/05/14/cncf- paper-defines-best-practices-for-supply-chain-security/. Accessed: 2026-01-26

    2021

  9. [17]

    2021.Bash Uploader Security Update

    Codecov Security Team. 2021.Bash Uploader Security Update. https://tinyurl. com/5d8bd4je Accessed: 2025-05-15

    2021

  10. [18]

    Geoffrey Cramer, William P Maxam III, and James C Davis. 2025. Engineering patterns for Trust and Safety on social media platforms: A case study of Mastodon and Diaspora.Journal of Systems and Software(2025)

    2025

  11. [19]

    2022.ESLint: Compromising the Build Using a Supply Chain Attack

    Cycode Security Team. 2022.ESLint: Compromising the Build Using a Supply Chain Attack. https://cycode.com/blog/eslint-compromising-the-build-using- supply-chain-attack/ Accessed: 2025-05-15

    2022

  12. [20]

    Thiago Melo Stuckert do Amaral and João José Costa Gondim. 2021. Integrating Zero Trust in the cyber supply chain security

    2021

  13. [21]

    John R Douceur. 2002. The sybil attack. InInternational workshop on peer-to-peer systems. Springer, 251–260

    2002

  14. [22]

    Betül Durak, Kim Laine, Simon Langowski, Radames Cruz Moreno, Robert Sim, and Shrey Jain

    F. Betül Durak, Kim Laine, Simon Langowski, Radames Cruz Moreno, Robert Sim, and Shrey Jain. 2023. Sandi: A System for Accountability and Applications in Direct Communication (Extended Abstract). arXiv:2311.04861

    2023 arXiv

  15. [23]

    Sarah Elder, Nusrat Zahan, Rui Shu, Monica Metro, Valeri Kozarev, Tim Menzies, and Laurie Williams. 2022. Do I really need all this work to find vulnerabilities? An empirical case study comparing vulnerability detection techniques on a Java application.Empirical Software Engin...

    2022

  16. [24]

    2018.Postmortem for Malicious Packages Published on July 12th, 2018

    ESLint Team. 2018.Postmortem for Malicious Packages Published on July 12th, 2018. https://eslint.org/blog/2018/07/postmortem-for-malicious-package- publishes/ Accessed: 2025-05-15

    2018

  17. [25]

    2016.General Data Protection Regulation (GDPR)

    European Union. 2016.General Data Protection Regulation (GDPR). https://gdpr- info.eu/ Regulation (EU) 2016/679. Accessed: 2025-04-30

    2016

  18. [26]

    Felix Fischer, Jonas Höbenreich, and Jens Grossklags. 2023. The Effectiveness of Security Interventions on GitHub. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security

    2023

  19. [27]

    Lucas Franke, Huayu Liang, Sahar Farzanehpour, Aaron Brantly, James C Davis, and Chris Brown. 2024. An exploratory mixed-methods study on general data protection regulation (gdpr) compliance in open-source software. InInternational Symposium on Empirical Software Engineering a...

    2024

  20. [28]

    GitHub Docs. [n. d.]. Saving repositories with stars. https://docs.github.com/en/ get-started/exploring-projects-on-github/saving-repositories-with-stars. Ac- cessed: 2026-01-26

    2026

  21. [29]

    Danielle Gonzalez, Thomas Zimmermann, Patrice Godefroid, and Max Schaefer

  22. [30]

    Goodrich and Florian Kerschbaum

    Michael T. Goodrich and Florian Kerschbaum. 2011. Privacy-Enhanced Reputation-Feedback Methods to Reduce Feedback Extortion in Online Auc- tions. InConference on Data and Application Security and Privacy

    2011

  23. [31]

    Sivana Hamer, Nasif Imtiaz, Mahzabin Tamanna, Preya Shabrina, and Laurie Williams. 2025. Trusting Code in the Wild: Exploring Contributor Reputation Measures to Review Dependencies in the Rust Ecosystem.IEEE Transactions on Software Engineering51, 4 (2025), 1319–1333. doi:10.1...

    2025

  24. [32]

    Mark Harman and Peter O’Hearn. 2018. From start-ups to scale-ups: Opportuni- ties and open problems for static and dynamic program analysis. Ininternational working conference on source code analysis and manipulation (SCAM). IEEE

    2018

  25. [33]

    Ferry Hendrikx, Kris Bubendorfer, and Ryan Chard. 2015. Reputation systems: A survey and taxonomy.J. Parallel and Distrib. Comput.75 (2015), 184–197. doi:10.1016/j.jpdc.2014.08.004

    2015 doi

  26. [34]

    Raphael Hiesgen, Marcin Nawrocki, Thomas C Schmidt, and Matthias Wahlisch. [n. d.]. The Race to the Vulnerable: Measuring the Log4j Shell Incident. ([n. d.]). Preprint or manuscript. Accessed: 2026-01-26

    2026

  27. [35]

    Michael A Howard. 2006. A process for performing security code reviews.IEEE Security & privacy4, 4 (2006), 74–79

    2006

  28. [36]

    Chengyou Jia, Minnan Luo, Zhuohang Dang, Qiushi Sun, Fangzhi Xu, Junlin Hu, Tianbao Xie, and Zhiyong Wu. 2025. Agentstore: Scalable integration of heterogeneous agents as specialized generalist computer assistant. InFindings of the Association for Computational Linguistics: AC...

    2025

  29. [37]

    Audun Josang, Roslan Ismail, and Colin Boyd. 2007. A survey of trust and reputation systems for online service provision.Decision Support Systems(2007)

    2007

  30. [38]

    Schorlemmer, Sophie Chen, Kyle A

    Kelechi Kalu, Taylor R. Schorlemmer, Sophie Chen, Kyle A. Robinson, Erik Kocinare, and James C. Davis. 2023. Reflecting on the Use of the Policy-Process- Product Theory in Empirical Software Engineering. InProceedings of the 31st ACM Joint European Software Engineering Confere...

    2023 doi

  31. [39]

    Kelechi G Kalu, Tanya Singla, Chinenye Okafor, Santiago Torres-Arias, and James C Davis. 2025. An Industry Interview Study of Software Signing for Supply Chain Security. In34th USENIX Security Symposium (USENIX Security 25). USENIX Association, Seattle, WA, USA

    2025

  32. [40]

    Oleksii Kononenko, Olga Baysal, and Michael W. Godfrey. 2016. Code review quality: how developers see it. InProceedings of the 38th International Conference on Software Engineering (ICSE ’16)

    2016

  33. [41]

    Mario Lins, René Mayrhofer, Michael Roland, Daniel Hofer, and Martin Schwaighofer. 2024. On the critical path to implant backdoors and the effective- ness of potential mitigation techniques: Early learnings from XZ.arXiv preprint arXiv:2404.08987(2024)

    2024 arXiv

  34. [42]

    Danaja Maldeniya, Ceren Budak, Lionel P Robert Jr, and Daniel M Romero. 2020. Herding a deluge of good samaritans: How GitHub projects respond to increased attention. InThe Web Conference (WWW)

    2020

  35. [43]

    Ben Marder, Adam Joinson, Avi Shankar, and David Houghton. 2016. The extended ‘chilling’effect of Facebook: The cold reality of ubiquitous social net- working.Computers in Human Behavior60 (2016), 582–592

    2016

  36. [44]

    Marti and H

    S. Marti and H. Garcia-Molina. 2003. Identity crisis: anonymity vs reputation in P2P systems. InInternational Conference on Peer-to-Peer Computing (P2P2003). doi:10.1109/PTP.2003.1231513

    2003 arXiv

  37. [45]

    Marcela S Melara and Mic Bowman. 2021. Hardware-Enforced Integrity and Provenance for Distributed Code Deployments. arXiv:2106.09843

    2021 arXiv

  38. [46]

    n.d..Microsoft Entra ID

    Microsoft. n.d..Microsoft Entra ID. https://www.microsoft.com/en-us/security/ business/identity-access/microsoft-entra-id Accessed: 2025-05-20

    2025

  39. [47]

    Sy Mukherjee. 2019. Dexcom Software Outage Draws Fury from Diabetes Patients’ Parents. https://fortune.com/2019/12/02/dexcom-outage-blackout- diabetes-patients-blood-sugar-monitor/. Accessed: 2026-01-26

    2019

  40. [48]

    Zachary Newman, John Speed Meyers, and Santiago Torres-Arias. 2022. Sigstore: Software signing for everybody. InACM Conference on Computer and Communi- cations Security (CCS). Check the exact CCS year/track formatting used by your bibliography style

    2022

  41. [49]

    Donald A. Norman. 2013.The Design of Everyday Things(revised and expanded ed.). MIT Press, Cambridge, MA

    2013

  42. [50]

    Anahad O’Connor. 2019. In Weekend Outage, Diabetes Monitors Fail to Send Crucial Alerts. https://www.nytimes.com/2019/12/02/well/live/Dexcom-G6- diabetes-monitor-outage.html. Accessed: 2026-01-26. Kalu et al

    2019

  43. [51]

    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

    2020

  44. [52]

    Chinenye Okafor, Taylor R Schorlemmer, Santiago Torres-Arias, and James C Davis. 2022. SoK: Analysis of software supply chain security by establishing secure design properties. InACM Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses

    2022

  45. [53]

    OpenID Foundation. [n. d.]. How OpenID Connect Works. https://openid.net/ developers/how-connect-works/. Accessed: 2026-01-26

    2026

  46. [54]

    OpenSSF. [n. d.]. OpenSSF Scorecard. https://scorecard.dev/. Accessed: 2026-01- 26

    2026

  47. [55]

    n.d..s2c2f

    OpenSSF. n.d..s2c2f. https://github.com/ossf/s2c2f Accessed: 2025-05-20

    2025

  48. [56]

    Shengyi Pan, Lingfeng Bao, Jiayuan Zhou, Xing Hu, Xin Xia, and Shanping Li. 2024. Towards More Practical Automation of Vulnerability Assessment. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (ICSE). doi:10.1145/3597503.3639110

    2024

  49. [57]

    Thiruvathukal, and James C

    Erik Pautsch, Tanmay Singla, Wenxin Jiang, Huiyun Peng, Behnaz Hassanshahi, Konstantin Läufer, George K. Thiruvathukal, and James C. Davis. 2025. AgentHub: A Research Agenda for Agent Sharing Infrastructure. arXiv:2510.03495 (Oct. 2025). doi:10.48550/arXiv.2510.03495 arXiv:251...

    2025 doi

  50. [58]

    H Qiu, YL Li, HS Padala, A Sarma, and B Vasilescu. 2019. The Signals that Potential Contributors Look for When Choosing Open-source Projects.ACM Proceedings on Human-Computer Interaction(2019)

    2019

  51. [59]

    Eric Raymond. 1999. The cathedral and the bazaar.Knowledge, Technology & Policy(1999)

    1999

  52. [60]

    James Reason. 1990. The contribution of latent human failures to the breakdown of complex systems.Philosophical Transactions of the Royal Society of London. B, Biological Sciences327, 1241 (1990), 475–484

    1990

  53. [61]

    Taylor R Schorlemmer, Ethan H Burmane, Kelechi G Kalu, Santiago Torres-Arias, and James C Davis. 2025. Establishing Provenance Before Coding: Traditional and Next-Generation Software Signing.IEEE Security & Privacy(2025)

    2025

  54. [62]

    Taylor R Schorlemmer, Kelechi G Kalu, Luke Chigges, Kyung Myung Ko, Eman Abu Ishgair, Saurabh Bagchi, Santiago Torres-Arias, and James C Davis

  55. [63]

    Ankur Shukla, Basel Katt, and Livinus Obiora Nweke. 2019. Vulnerability Dis- covery Modelling With Vulnerability Severity. InIEEE Conference on Information and Communication Technology. doi:10.1109/CICT48419.2019.9066187

    2019

  56. [64]

    Hayden Smith. 2024. Where the Wild Things Are: A Complete Analysis of Jia Tan’s GitHub History and the XZ Utils Software Supply Chain Breach. https: //tinyurl.com/6rush4hd

    2024

  57. [65]

    2021.2021 State of the Software Supply Chain Report

    Sonatype. 2021.2021 State of the Software Supply Chain Report. Technical Report. Sonatype. https://www.sonatype.com/resources/whitepapers/2021-state-of-the- software-supply-chain-report-2021 Whitepaper; accessed: 2025-05-18

    2021

  58. [66]

    2022.Secure Software Development Framework (SSDF) Version 1.1

    Murugiah Souppaya, Karen Scarfone, and Donna Dodson. 2022.Secure Software Development Framework (SSDF) Version 1.1. Technical Report. National Institute of Standards and Technology. doi:10.6028/NIST.SP.800-218

    2022 doi

  59. [67]

    Diomidis Spinellis and Clemens Szyperski. 2004. How is open source affecting software development?IEEE software21, 1 (2004), 28

    2004

  60. [68]

    Stack Overflow Help Center. [n. d.]. What is reputation? https://stackoverflow. com/help/whats-reputation. Accessed: 2026-01-26

    2026

  61. [69]

    Almeroth, and Ben Y

    Gayatri Swamynathan, Kevin C. Almeroth, and Ben Y. Zhao. 2010. The design of a reliable reputation system.Electronic Commerce Research(Dec. 2010)

    2010

  62. [70]

    Mike Sweeney. 2023. What motivates a developer to contribute to open-source software? https://clearcode.cc/blog/why-developers-contribute-open-source- software/. Accessed: 2026-01-26

    2023

  63. [71]

    The Linux Foundation. 2023. Supply-chain Levels for Software Artifacts (SLSA). https://slsa.dev/. Accessed: 2026-01-26

    2023

  64. [72]

    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. InUSENIX Security Symposium

    2019

  65. [73]

    Jason Tsay, Laura Dabbish, and James Herbsleb. 2014. Influence of social and tech- nical factors for evaluating contribution in GitHub. InInternational Conference on Software Engineering (ICSE)

    2014

  66. [74]

    Department of Defense

    U.S. Department of Defense. 2009. Clarifying Guidance Regarding Open Source Software (OSS). Memorandum. https://dodcio.defense.gov/Portals/0/Documents/ FOSS/2009OSS.pdf Accessed: 2026-01-26

    2009

  67. [75]

    Vidos.id. n.d..Google Wallet Adds Digital IDs: What Does This Mean for the Future of Identity?https://vidos.id/blog/google-wallet-adds-digital-ids-what-does- this-mean-for-the-future-of-identity Accessed: 2025-05-20

    2025

  68. [76]

    Duc-Ly Vu, Fabio Massacci, Ivan Pashchenko, Henrik Plate, and Antonino Sabetta

  69. [77]

    Shaowei Wang, Daniel M German, Tse-Hsun Chen, Yuan Tian, and Ahmed E Hassan. 2021. Is reputation on Stack Overflow always a good indicator for users’ expertise? No!. InInternational Conference on Software Maintenance and Evolution (ICSME)

    2021

  70. [78]

    Yanlin Wang, Wanjun Zhong, Yanxian Huang, Ensheng Shi, Min Yang, Jiachi Chen, Hui Li, Yuchi Ma, Qianxiang Wang, and Zibin Zheng. 2025. Agents in software engineering: survey, landscape, and vision.Automated Software Engineering32, 2 (Aug. 2025), 70. doi:10.1007/s10515-025-00544-2

    2025 doi

  71. [79]

    In ESEC/FSE

    Lastpymile: Identifying the discrepancy between sources and packages. In ESEC/FSE

  72. [80]

    Marcus Willett. 2023. Lessons of the SolarWinds hack. InSurvival April–May 2021: Facing Russia. Routledge, 7–25

    2023

  73. [81]

    Tianbao Xie, Fan Zhou, Zhoujun Cheng, Peng Shi, Luoxuan Weng, Yitao Liu, Toh Jing Hua, Junning Zhao, Qian Liu, Che Liu, et al. [n. d.]. OpenAgents: An Open Platform for Language Agents in the Wild. InICLR 2024 Workshop on Large Language Model (LLM) Agents

    2024

  74. [82]

    Klemmer, Marcel Fourné, Yasemin Acar, and Sascha Fahl

    Dominik Wermke, Noah Wöhler, Jan H. Klemmer, Marcel Fourné, Yasemin Acar, and Sascha Fahl. 2022. Committed to Trust: A Qualitative Study on Security and Trust in Open Source Software Projects. InIEEE Symposium on Security and Privacy (SP)

    2022

  75. [83]

    Nusrat Zahan, Parth Kanakiya, Brian Hambleton, Shohanuzzaman Shohan, and Laurie Williams. 2023. Openssf scorecard: On the path toward ecosystem-wide automated security metrics.IEEE Security & Privacy(2023)

    2023

  76. [85]

    Yue Yu, Gang Yin, Huaimin Wang, and Tao Wang. 2014. Exploring the patterns of social behavior in GitHub. InProceedings of the 1st International Workshop on Social Software Engineering. Check exact workshop title/venue if needed

    2014

  77. [2021]

    InInternational Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP)

    Anomalicious: Automated Detection of Anomalous and Potentially Mali- cious Commits on GitHub. InInternational Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP)

  78. [2024]

    InIEEE Symposium on Security and Privacy (SP)

    Signing in four public software package registries: Quantity, quality, and influencing factors. InIEEE Symposium on Security and Privacy (SP)

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.