pith. sign in

arxiv: 2606.22593 · v2 · pith:LBJEZR7Bnew · submitted 2026-06-21 · 💻 cs.SE · cs.CR

On Good Authority: Release-Authority Measurement for Registry-Mediated Package Ecosystems

Igor Santos-Grueiro This is my paper

Pith reviewed 2026-07-01 07:12 UTC · model grok-4.3

classification 💻 cs.SE cs.CR
keywords release authoritypackage ecosystemsregistry mediationpredecessor comparisondiscontinuity detectionsupply chain reviewpublic control plane
0
0 comments X

The pith

A predecessor-aware record of release authority detects 204 public path discontinuities across package releases for review.

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

The paper shows that comparing each release to its immediate predecessor on publisher, repository, workflow, provenance, signing, and mediation evidence reveals changes in how a release reaches users. These changes create a review surface based on public control-plane data, before any payload or incident appears. Transparent rules applied to 43,100 comparisons in a sampled cohort from five ecosystems flag 204 such discontinuities and define a candidate queue. Selection rules based on semantic distance or regime-specific descriptions cover nearly all or all triggers, and blinded practitioner review rates many as immediate review while known malicious versions show zero overlap.

Core claim

We introduce a predecessor-aware release-authority record that compares each package release with its immediate predecessor across publisher, repository, workflow, provenance, signing, and mediation evidence. Applied to 45,812 releases yielding 43,100 eligible comparisons from npm, PyPI, Maven Central, crates.io, and RubyGems, transparent rules identify 204 public release-path discontinuities that define a 204-release candidate review queue. A uniform semantic-distance rule selects 320 releases covering 190 of the 204 triggers; a descriptive regime-specific rule selects 337 releases covering all 204. Practitioner review of a blinded core set rates 20 of 30 triggers as immediate review and al

What carries the argument

The predecessor-aware release-authority record, which tracks changes between consecutive releases on six dimensions of public evidence to surface control-plane discontinuities.

If this is right

  • The record can be computed for any registry-mediated ecosystem that exposes predecessor links and the six evidence fields.
  • A uniform semantic-distance rule already covers 190 of 204 discontinuities while keeping the selected set to 320 releases.
  • A regime-specific descriptive rule covers every discontinuity at the cost of selecting 337 releases.
  • Blinded practitioner assessment separates triggers from controls with high agreement on immediate-review cases.
  • The surface remains distinct from payload-based detection because malicious versions in the cohort trigger none of the rules.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The method could be run continuously on live registry feeds to maintain an ongoing review queue without requiring full historical reprocessing.
  • Ecosystems that currently lack one or more of the six evidence fields could still apply a reduced version of the record using the available dimensions.
  • Combining the authority record with existing checksum or signature checks might allow automated dismissal of some low-risk discontinuities.
  • The zero-overlap result with known malicious versions suggests the record could serve as an independent early filter even when attackers control compromised CI.

Load-bearing premise

The sampled April 2024-June 2026 cohort and the defined discontinuity rules produce review signals whose operational value generalizes beyond the sampled packages and time window.

What would settle it

Application of the same rules to a fresh uncurated cohort of releases in which a non-negligible fraction of the flagged discontinuities later prove to be routine maintenance with no security relevance.

Figures

Figures reproduced from arXiv: 2606.22593 by Igor Santos-Grueiro.

Figure 1
Figure 1. Figure 1: Release-authority records across the measured regimes. Each card uses the same predecessor-aware comparison, but [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Registry-first release-authority pipeline. Public registry and context evidence are preserved as raw inputs, normalized [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Case anchors from predecessor comparison to interpretation. Each row uses the same structure: previous release-path [PITH_FULL_IMAGE:figures/full_fig_p020_3.png] view at source ↗
Figure 3
Figure 3. Figure 3: Case anchors from predecessor comparison to interpretation. Each row uses the same structure: previous release-path [PITH_FULL_IMAGE:figures/full_fig_p019_3.png] view at source ↗
read the original abstract

Dependency graphs reveal where released code can flow; release-authority records reveal how a release reached users. A package can keep the same downstream exposure while its public authority path changes: a new publisher account, a repository relink, a new workflow, a provenance change, a signing-key movement, or a shift in publication mediation. These transitions expose a release-time review surface over public control-plane evidence, before payload evidence or incident attribution is available. We introduce a predecessor-aware release-authority record that compares each package release with its immediate predecessor across publisher, repository, workflow, provenance, signing, and mediation evidence. We apply the record to a purposefully sampled, audited April 2024-June 2026 cohort from npm, PyPI, Maven Central, crates.io, and RubyGems: 45,812 releases, 43,100 eligible predecessor comparisons, and 942 package coordinates. We report Go separately as a VCS/proxy/checksum-log boundary adapter. Transparent rules identify 204 public release-path discontinuities and define a 204-release candidate review queue. A uniform semantic-distance rule selects 320 releases and covers 190/204 triggers; a descriptive regime-specific rule selects 337 releases and covers all 204. Practitioner review supports the operational reading of this queue. In a blinded 60-row shared core, three practitioners rated 20/30 triggers as immediate review, 9/30 as monitoring, 1/30 as no review, and all 30 controls as no review. External alignment defines the boundary of the surface: exact malicious versions have zero overlap with policy triggers in our cohort. Compromises that reuse the same public release path, unchanged compromised CI, and versions absent from public snapshots require separate evidence beyond this release-authority record.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper introduces a predecessor-aware release-authority record that compares each package release to its immediate predecessor across publisher, repository, workflow, provenance, signing, and mediation evidence. Applied to a purposefully sampled, audited cohort of 45,812 releases (43,100 eligible comparisons) from npm, PyPI, Maven Central, crates.io, and RubyGems (942 packages, with Go handled separately), transparent rules identify 204 public release-path discontinuities forming a candidate review queue. A uniform semantic-distance rule selects 320 releases covering 190/204 triggers; a regime-specific rule selects 337 releases covering all 204. Blinded practitioner review of a 60-row core rates 20/30 triggers as immediate review (vs. 0/30 controls), and the triggers show zero overlap with known malicious versions.

Significance. If the results hold, the work supplies a concrete, registry-native method for surfacing authority-path changes as a review surface using only public data, prior to payload or attribution evidence. Strengths include the scale of the empirical application, explicit coverage statistics for the two selection rules, the blinded practitioner validation exercise, and the reported zero overlap with malicious versions, which helps bound the proposed surface. These elements could support operational review queues in package ecosystems if the sampling and rule definitions are made fully reproducible.

major comments (2)
  1. [Abstract (cohort description)] Abstract (cohort description): The purposeful sampling of the 942-package April 2024–June 2026 cohort is described only as 'audited' with no stratification criteria, inclusion probabilities, or direct comparison to the full population of releases in each registry. This is load-bearing for the generalization claim, because the 204 discontinuities, the coverage figures (190/204 and 204/204), and the 20/30 immediate-review rating were all derived from this single cohort.
  2. [Abstract (rule definitions)] Abstract (rule definitions): The abstract states that 'transparent rules' identify the 204 discontinuities and that the semantic-distance threshold and regime-specific rule parameters produce the reported coverage, yet supplies neither the exact comparison logic across the six evidence dimensions nor the numerical thresholds. This directly affects reproducibility of the 204-release queue and the claim that the selectors are operational.
minor comments (1)
  1. [Abstract] Abstract: The cohort window ends in June 2026; clarify whether data collection is ongoing or projected and how this affects the reported counts.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments on the abstract. We address each major point below and indicate where revisions will be made to improve clarity and reproducibility.

read point-by-point responses

  1. Referee: [Abstract (cohort description)] Abstract (cohort description): The purposeful sampling of the 942-package April 2024–June 2026 cohort is described only as 'audited' with no stratification criteria, inclusion probabilities, or direct comparison to the full population of releases in each registry. This is load-bearing for the generalization claim, because the 204 discontinuities, the coverage figures (190/204 and 204/204), and the 20/30 immediate-review rating were all derived from this single cohort.

    Authors: We agree that the abstract's cohort description is brief and could better support the reported figures. The full manuscript (Section 3) details the purposeful sampling as selecting packages with multiple releases and sufficient public metadata across the five registries, followed by an audit for data completeness; it is not a probability sample of the full population. We will revise the abstract to add a concise statement of these selection criteria and explicitly note the purposeful (non-representative) nature of the cohort, thereby clarifying the scope of the 204 discontinuities and validation results. revision: yes

  2. Referee: [Abstract (rule definitions)] Abstract (rule definitions): The abstract states that 'transparent rules' identify the 204 discontinuities and that the semantic-distance threshold and regime-specific rule parameters produce the reported coverage, yet supplies neither the exact comparison logic across the six evidence dimensions nor the numerical thresholds. This directly affects reproducibility of the 204-release queue and the claim that the selectors are operational.

    Authors: The referee is correct that the abstract omits the precise logic and thresholds. The full manuscript defines the six evidence dimensions (publisher, repository, workflow, provenance, signing, mediation), the predecessor comparison procedure, the uniform semantic-distance rule, and the regime-specific parameters in Section 4, with the resulting coverage statistics. To make the abstract more self-contained for reproducibility, we will add a brief clause summarizing the rule framework and key thresholds while remaining within length limits. revision: yes

Circularity Check

0 steps flagged

No significant circularity; derivation is self-contained from public records

full rationale

The paper constructs a predecessor-aware release-authority record directly from public registry data (publisher, repository, workflow, provenance, signing, mediation) and applies transparent, explicitly stated rules to a sampled cohort to identify 204 discontinuities. Selection rules are then measured for coverage on those same discontinuities, but the uniform semantic-distance rule achieves only partial coverage (190/204) while the regime-specific rule is presented as descriptive rather than tautological. No equations, fitted parameters, self-citations, uniqueness theorems, or ansatzes appear in the provided text; all outputs derive from external public data without reducing to self-definition or input renaming. The sampling and generalization concerns affect external validity but do not create circularity in the derivation chain.

Axiom & Free-Parameter Ledger

2 free parameters · 1 axioms · 0 invented entities

The central claim rests on a domain assumption about cohort representativeness and on two selection rules whose thresholds appear tuned to the observed data; no new physical entities are postulated.

free parameters (2)
  • semantic-distance threshold
    Used to select 320 releases covering 190 of 204 triggers; value chosen to achieve stated coverage.
  • regime-specific rule parameters
    Descriptive rules that select 337 releases covering all 204 triggers; parameters defined per ecosystem.
axioms (1)
  • domain assumption The purposefully sampled April 2024-June 2026 cohort from the five registries is representative of release-authority behavior in those ecosystems.
    The study relies on this cohort to define and validate the 204 discontinuities and review queue.

pith-pipeline@v0.9.1-grok · 5851 in / 1471 out tokens · 37913 ms · 2026-07-01T07:12:55.993185+00:00 · methodology

Review history (2 revisions) →

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

55 extracted references · 3 canonical work pages

  1. [1]

    Post mortem: axios npm supply chain compromise

    Axios Project. Post mortem: axios npm supply chain compromise. https://github.com/axios/axios/ issues/10636, 2026. Accessed 2026-06-12

    2026

  2. [2]

    Strategies for the integration of software supply chain security in DevSecOps CI/CD pipelines

    Ramaswamy Chandramouli, Frederick Kautz, and San- tiago Torres-Arias. Strategies for the integration of software supply chain security in DevSecOps CI/CD pipelines. Technical report, National Institute of Stan- dards and Technology, 2024

    2024

  3. [3]

    Software heritage: Why and how to preserve software source code

    Roberto Di Cosmo and Stefano Zacchiroli. Software heritage: Why and how to preserve software source code. InProceedings of the 14th International Conference on Digital Preservation (iPRES 2017), pages 1–10, Kyoto, Japan, 2017

    2017

  4. [4]

    Trusted publishing

    crates.io. Trusted publishing. https://crates.io/ docs/trusted- publishing, 2026. Accessed 2026- 06-13

    2026

  5. [5]

    LiteLLM and Telnyx compro- mised on PyPI: Tracing the TeamPCP supply chain cam- paign

    Datadog Security Labs. LiteLLM and Telnyx compro- mised on PyPI: Tracing the TeamPCP supply chain cam- paign. https : / / securitylabs . datadoghq . com / articles/litellm- compromised- pypi- teampcp- supply-chain-campaign/, 2026. Accessed 2026-06- 12

    2026

  6. [6]

    Malicious software packages dataset

    Datadog Security Labs. Malicious software packages dataset. https://github.com/DataDog/malicious- software-packages-dataset, 2026. Accessed 2026- 06-13

    2026

  7. [7]

    An empirical comparison of dependency network evolu- tion in seven software packaging ecosystems.Empirical Software Engineering, 24(1):381–416, 2019

    Alexandre Decan, Tom Mens, and Philippe Grosjean. An empirical comparison of dependency network evolu- tion in seven software packaging ecosystems.Empirical Software Engineering, 24(1):381–416, 2019

    2019

  8. [8]

    Towards measuring supply chain attacks on package managers for interpreted languages

    Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan El- der, Brendan Saltaformaggio, and Wenke Lee. Towards measuring supply chain attacks on package managers for interpreted languages. InNetwork and Distributed System Security Symposium (NDSS), Virtual, 2021. In- ternet Society

    2021

  9. [9]

    ECMA-427: Package URL

    Ecma International. ECMA-427: Package URL. https: //ecma- international.org/publications- and- standards/standards/ecma-427/, 2025. Accessed 2026-04-04

    2025

  10. [10]

    Kai Gao, Weiwei Xu, Wenhao Yang, and Minghui Zhou. PyRadar: Towards automatically retrieving and validat- ing source code repository information for PyPI pack- ages.Proceedings of the ACM on Software Engineering, 1(FSE):2608–2631, 2024

    2024

  11. [11]

    GH Archive

    GH Archive. GH Archive. https://www.gharchive. org/, 2026. Accessed 2026-04-04

    2026

  12. [12]

    npm trusted publishing with OIDC is generally available

    GitHub Changelog. npm trusted publishing with OIDC is generally available. https : / / github . blog / changelog / 2025 - 07 - 31 - npm - trusted-publishing-with-oidc-is-generally- available/, 2025. Accessed 2026-04-04

    2025

  13. [13]

    Reminder for changes to npm replica- tion feeds APIs

    GitHub, Inc. Reminder for changes to npm replica- tion feeds APIs. https://github.blog/changelog/ 2025 - 04 - 22 - reminder - for - changes - to - npm - replication- feeds- apis/, 2025. Accessed 2026- 04-04

    2025

  14. [14]

    Klemmer, Mar- cel Fourné, Oliver Wiese, Dominik Wermke, and Sascha Fahl

    Jan-Ulrich Holtgrave, Kay Friedrich, Fabian Fischer, Nicolas Huaman, Niklas Busch, Jan H. Klemmer, Mar- cel Fourné, Oliver Wiese, Dominik Wermke, and Sascha Fahl. Attributing open-source contributions is critical but difficult: A systematic analysis of GitHub practices and their impact on software supply chain security. In Network and Distributed System S...

    2025

  15. [15]

    Williams

    Nasif Imtiaz, Aniqa Khanom, and Laurie A. Williams. Open or sneaky? fast or slow? light or heavy?: Investi- gating security releases of open source packages.IEEE Transactions on Software Engineering, 49(4):1540– 1560, 2023

    2023

  16. [16]

    Melara, and Santiago Torres-Arias

    Eman Abu Ishgair, Marcela S. Melara, and Santiago Torres-Arias. SoK: A defense-oriented evaluation of software supply chain security. https://arxiv.org/ abs/2405.14993, 2024. Preprint

    work page arXiv 2024

  17. [17]

    Kalu, Sofia Okorafor, F

    Kelechi G. Kalu, Sofia Okorafor, F. Betül Durak, Kim Laine, Radames Cruz Moreno, Santiago Torres-Arias, and James C. Davis. ARMS: A vision for actor reputa- tion metric systems in the open-source software supply chain. https://arxiv.org/abs/2505.18760, 2025. Preprint

    work page arXiv 2025

  18. [18]

    Kalu, Tanmay Singla, Chinenye Okafor, San- tiago Torres-Arias, and James C

    Kelechi G. Kalu, Tanmay Singla, Chinenye Okafor, San- tiago Torres-Arias, and James C. Davis. An industry interview study of software signing for supply chain se- curity. In34th USENIX Security Symposium (USENIX Security 25), pages 81–100, Seattle, WA, USA, 2025. USENIX Association

    2025

  19. [19]

    Kalu, Hieu Tran, Santiago Torres-Arias, Sooyeon Jeong, and James C

    Kelechi G. Kalu, Hieu Tran, Santiago Torres-Arias, Sooyeon Jeong, and James C. Davis. A longitudi- nal study of usability in identity-based software sign- ing. https://arxiv.org/abs/2603.17133 , 2026. Preprint

    work page arXiv 2026

  20. [20]

    Structure and evolution of package depen- dency networks

    Riivo Kikas, Georgios Gousios, Marlon Dumas, and Di- etmar Pfahl. Structure and evolution of package depen- dency networks. In2017 IEEE/ACM 14th International 15 Conference on Mining Software Repositories (MSR), pages 102–112, Buenos Aires, Argentina, 2017. IEEE

    2017

  21. [21]

    SoK: Taxonomy of attacks on open- source software supply chains

    Piergiorgio Ladisa, Henrik Plate, Matias Martinez, and Olivier Barais. SoK: Taxonomy of attacks on open- source software supply chains. InIEEE Symposium on Security and Privacy (SP), pages 1509–1526, San Francisco, CA, USA, 2023. IEEE

    2023

  22. [22]

    Dirty-waters: Detecting software sup- ply chain smells

    Raphina Liu, Sofia Bobadilla, Benoit Baudry, and Mar- tin Monperrus. Dirty-waters: Detecting software sup- ply chain smells. InCompanion Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering (FSE Companion ’25), pages 1045–1049, Trondheim, Norway, 2025. ACM

    2025

  23. [23]

    Shai-Hulud 2.0: Guid- ance for detecting, investigating, and defending against the supply chain attack

    Microsoft Threat Intelligence. Shai-Hulud 2.0: Guid- ance for detecting, investigating, and defending against the supply chain attack. https://www.microsoft. com / en - us / security / blog / 2025 / 12 / 09 / shai - hulud - 2 - 0 - guidance - for - detecting - investigating - and - defending - against - the - supply- chain- attack/, 2025. Accessed 2026-04- 04

    2025

  24. [24]

    Mitigating the Axios npm sup- ply chain compromise

    Microsoft Threat Intelligence and Microsoft Defender Security Research Team. Mitigating the Axios npm sup- ply chain compromise. https : / / www . microsoft . com / en - us / security / blog / 2026 / 04 / 01 / mitigating - the - axios - npm - supply - chain - compromise/, 2026. Accessed 2026-04-04

    2026

  25. [25]

    Sigstore: Software signing for everybody

    Zachary Newman, John Speed Meyers, and Santiago Torres-Arias. Sigstore: Software signing for everybody. InProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pages 2353– 2367, Los Angeles, CA, USA, 2022. ACM

    2022

  26. [26]

    About ECDSA registry signatures

    npm, Inc. About ECDSA registry signatures. https:// docs.npmjs.com/about- registry- signatures/ ,

  27. [27]

    Generating provenance statements

    npm, Inc. Generating provenance statements. https: / / docs . npmjs . com / generating - provenance - statements/, 2026. Accessed 2026-04-04

    2026

  28. [28]

    Trusted publishers

    npm, Inc. Trusted publishers. https://docs.npmjs. com/trusted- publishers/, 2026. Accessed 2026- 04-04

    2026

  29. [29]

    Backstabber’s knife collection: A review of open source software supply chain attacks

    Marc Ohm, Henrik Plate, Arnold Sykosch, and Michael Meier. Backstabber’s knife collection: A review of open source software supply chain attacks. InDetection of Intrusions and Malware, and Vulnerability Assessment (DIMVA), pages 23–43, Cham, 2020. Springer Interna- tional Publishing

    2020

  30. [30]

    deps.dev API v3alpha

    Open Source Insights. deps.dev API v3alpha. https: //docs.deps.dev/api/v3alpha/ , 2026. Accessed 2026-04-04

    2026

  31. [31]

    Detecting malicious packages using the OSV API

    Open Source Security Foundation. Detecting malicious packages using the OSV API. https : / / openssf . org / blog / 2026 / 05 / 20 / detecting - malicious - packages- using- the- osv- api/, 2026. Accessed 2026-06-13

    2026

  32. [32]

    Malicious packages

    Open Source Security Foundation. Malicious packages. https://github.com/ossf/malicious-packages ,

  33. [33]

    TanStack and 160+ npm/PyPI packages compromised in supply chain worm attack

    Orca Security. TanStack and 160+ npm/PyPI packages compromised in supply chain worm attack. https:// orca.security/resources/blog/tanstack- npm- supply-chain-worm/, 2026. Accessed 2026-06-21

    2026

  34. [34]

    Post-mortem of Shai-Hulud attack on Novem- ber 24th, 2025

    PostHog. Post-mortem of Shai-Hulud attack on Novem- ber 24th, 2025. https://posthog.com/blog/nov- 24- shai- hulud- attack- post- mortem, 2025. Ac- cessed 2026-06-12

    2025

  35. [35]

    PEP 740: Index sup- port for digital attestations

    Python Enhancement Proposals. PEP 740: Index sup- port for digital attestations. https://peps.python. org/pep-0740/, 2024. Accessed 2026-04-04

    2024

  36. [36]

    Integrity API

    Python Packaging Authority. Integrity API. https: //docs.pypi.org/api/integrity/, 2026. Accessed 2026-04-04

    2026

  37. [37]

    PyPI publish attestation v1

    Python Packaging Authority. PyPI publish attestation v1. https://docs.pypi.org/attestations/publish/ v1/, 2026. Accessed 2026-04-04

    2026

  38. [38]

    Trusted publishers.https: / / docs

    Python Packaging Authority. Trusted publishers.https: / / docs . pypi . org / trusted - publishers/, 2026. Accessed 2026-04-04

    2026

  39. [39]

    Understanding Red Hat’s response to the XZ security incident

    Red Hat. Understanding Red Hat’s response to the XZ security incident. https://www.redhat.com/ en/blog/understanding-red-hats-response-xz- security-incident, 2024. Accessed 2026-04-04

    2024

  40. [40]

    Setting up multi-factor authentication

    RubyGems. Setting up multi-factor authentication. https : / / guides . rubygems . org / setting - up - multifactor - authentication/, 2026. Accessed 2026-06-13

    2026

  41. [41]

    Schorlemmer, Ethan H

    Taylor R. Schorlemmer, Ethan H. Burmane, Kelechi G. Kalu, Santiago Torres-Arias, and James C. Davis. Es- tablishing provenance before coding: Traditional and next-generation software signing.IEEE Security & Pri- vacy, 23(2):14–22, 2025

    2025

  42. [42]

    Schorlemmer, Kelechi G

    Taylor R. Schorlemmer, Kelechi G. Kalu, Luke Chigges, Kyung Myung Ko, Eman Abu Ishgair, Saurabh Bagchi, 16 Santiago Torres-Arias, and James C. Davis. Signing in four public software package registries: Quantity, qual- ity, and influencing factors. In2024 IEEE Symposium on Security and Privacy (SP), pages 1160–1178. IEEE, 2024

    2024

  43. [43]

    SLSA specification v1.2

    SLSA Framework. SLSA specification v1.2. https: //slsa.dev/spec/v1.2/ , 2025. Accessed 2026-04- 04

    2025

  44. [44]

    Software heritage API documen- tation

    Software Heritage. Software heritage API documen- tation. https : / / docs . softwareheritage . org / devel/getting-started/api.html, 2026. Accessed 2026-04-04

    2026

  45. [45]

    Go module mirror, index, and check- sum database

    The Go Project. Go module mirror, index, and check- sum database. https://proxy.golang.org/ , 2026. Accessed 2026-06-13

    2026

  46. [46]

    Go modules reference

    The Go Project. Go modules reference. https://go. dev/ref/mod, 2026. Accessed 2026-06-13

    2026

  47. [47]

    PyPI now sup- ports digital attestations

    The Python Package Index Blog. PyPI now sup- ports digital attestations. https : / / blog . pypi . org / posts / 2024 - 11 - 14 - pypi - now - supports - digital-attestations/ , 2024. Accessed 2026-04- 04

    2024

  48. [48]

    Incident report: LiteLLM/Telnyx supply-chain attacks, with guidance

    The Python Package Index Blog. Incident report: LiteLLM/Telnyx supply-chain attacks, with guidance. https : / / blog . pypi . org / posts / 2026 - 04 - 02- incident- report- litellm- telnyx- supply- chain-attack/, 2026. Accessed 2026-04-04

    2026

  49. [49]

    Publishing on crates.io

    The Rust Project. Publishing on crates.io. https : / / doc . rust - lang . org / cargo / reference / publishing.html, 2026. Accessed 2026-06-13

    2026

  50. [50]

    TUF specification (lat- est)

    The Update Framework. TUF specification (lat- est). https://theupdateframework.github.io/ specification/latest/, 2026. Accessed 2026-04- 04

    2026

  51. [51]

    in-toto: Providing farm-to-table guarantees for bits and bytes

    Santiago Torres-Arias, Hammad Afzali, Tris- hank Karthik Kuppusamy, Reza Curtmola, and Justin Cappos. in-toto: Providing farm-to-table guarantees for bits and bytes. In28th USENIX Security Symposium (USENIX Security 19), pages 1393–1410, Santa Clara, CA, USA, 2019. USENIX Association

    2019

  52. [52]

    Research directions in software supply chain se- curity.ACM Transactions on Software Engineering and Methodology, 34(5):1–38, 2025

    Laurie Williams, Giacomo Benedetti, Sivana Hamer, Ranindya Paramitha, Imranur Rahman, Mahzabin Tamanna, Greg Tystahl, Nusrat Zahan, Patrick Morri- son, Yasemin Acar, Michel Cukier, Christian Kästner, Alexandros Kapravelos, Dominik Wermke, and William Enck. Research directions in software supply chain se- curity.ACM Transactions on Software Engineering and...

    2025

  53. [53]

    A look at the dynamics of the JavaScript package ecosys- tem

    Erik Wittern, Philippe Suter, and Shriram Rajagopalan. A look at the dynamics of the JavaScript package ecosys- tem. InProceedings of the 13th International Confer- ence on Mining Software Repositories, pages 351–361, Austin, TX, USA, 2016. ACM

    2016

  54. [54]

    Williams

    Nusrat Zahan, Parth Kanakiya, Brian Hambleton, Shohanuzzaman Shohan, and Laurie A. Williams. OpenSSF Scorecard: On the path toward ecosystem- wide automated security metrics.IEEE Security & Pri- vacy, 21(6):76–88, 2023

    2023

  55. [55]

    Small world with high risks: A study of security threats in the npm ecosystem

    Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel. Small world with high risks: A study of security threats in the npm ecosystem. In28th USENIX Security Symposium (USENIX Security 19), pages 995–1010, Santa Clara, CA, USA, 2019. USENIX Association. Appendices These appendices collect the details needed to audit the main claims. A...

    2019