On Good Authority: Release-Authority Measurement for Registry-Mediated Package Ecosystems
arXiv:2606.22593v1 [cs.SE] 21 Jun 2026
Igor Santos-Grueiro International University of La Rioja
Abstract
was released. The 2026 axios compromise, PyPI incidents affecting litellm and telnyx, the Shai-Hulud 2.0 and Mini Shai-Hulud package-worm campaigns, and the xz backdoor provide concrete motivation for this release-authority view. They also delimit its boundary: some attacks create public release-path changes that registry-side measurement can observe [23, 24, 33, 39, 48]. This paper measures that review surface and asks whether public release-path transitions can define an auditable, bounded, release-time review queue. We answer this question by defining a predecessor-aware release-authority record that links observed releases to publishing principals, namespaces, repositories, workflows, provenance identities, signing evidence, mediation type, and downstream exposure. Packages with similar downstream reach can nevertheless have very different control-plane review profiles. Advances in public registry feeds, trusted-publishing evidence, provenance APIs, portable package identifiers, and ecosystem stitching now make audited reconstruction feasible at scale [9, 13, 30]. We build a release-level object that treats registry and provenance evidence as authority and then uses observed release-path transitions as the basis for triage [8, 16, 21, 29, 50, 55]. We evaluate the approach across five registry-mediated ecosystems. We call npm, PyPI, Maven Central, crates.io, and RubyGems registry-mediated because each public package registry exposes release records and at least some combination of publisher, owner, namespace, provenance, signing, repository, or integrity evidence. Go ecosystem is reported separately because its public authority path centers on VCS origin, module-proxy observation, and checksum-log evidence under a different authority regime. We focus on the operational task of release-time triage: once a release and its public metadata are observable, decide whether an observed release-path change should enter a candidate review queue and receive a disposition. The historical-context forecasting baseline tests whether pre-release history can anticipate those discontinuities. Across a purposefully sampled, audited April 2024–June 2026 corpus spanning the five registry-mediated
Dependency graphs show where released code can flow, while leaving implicit whether the public path used to publish a release changed. We introduce a predecessor-aware releaseauthority record that compares each package release with its immediate predecessor across publisher, repository, workflow, provenance, signing, and mediation evidence. We instantiate the record over 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. Go is reported separately as a VCS/proxy/checksumlog boundary adapter. Transparent rules identify 204 policytriggering public release-path discontinuities. The exact trigger policy is the primary candidate 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. 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. These signals are review cues over public release-path evidence. Exact malicious versions in our external alignment have zero overlap with the policy triggers. Same-path compromise, unchanged compromised CI, and versions absent from public snapshots require separate evidence beyond this release-path record.
1
Introduction
Modern software supply-chain measurement often begins with dependency graphs. That perspective is necessary, but incomplete. A dependency graph may remain unchanged even as the release path changes: a new publisher account, a new CI workflow, a provenance disappearance, a repository relink, or a signing-key switch. These public control-plane discontinuities can justify review well before payload analysis is available, because they reveal a shift in who or how a package 1
ecosystems, the useful signal is release-time: simple transition rules deliver high-coverage screening, and learned ranking compresses broad queues when needed. The main claim of this paper is that release-authority transitions define an auditable review surface for registry-mediated ecosystems. Simple transition rules open that surface, while learned ranking helps when the queue remains broad. The operational result is a threshold-defined workload over the five-registry corpus, with Go retained as a boundary adapter. The npm/PyPI/Maven subset supports the most complete external incident, registry-action, advisory, and practitionerreview checks. The automated policy trigger marks a public control-plane discontinuity; public incidents, maliciouspackage feeds, and blinded rubric checks help interpret that boundary. We make three contributions:
once the release and its public metadata are observable in the frozen evidence used by the study. The release-time policy trigger used in this paper opens a candidate review queue. A positive trigger marks a visible public release-path change that is worth checking under the study policy. Human review can then classify the release as review_now, monitor, or no_review. Payload analysis and incident attribution happen in separate workflows.
2.2
For each package release, we build a release-authority record. The record contains the publishing principal, namespace, source repository, workflow identity, provenance state, signing state, and mediation type. We record mediation as workflowbacked observed when public workflow or provenance evidence is present, as workflow not observed when that evidence is absent, and as unknown when predecessor evidence is missing. The second state records missing public workflow evidence, not actor identity. The unit of comparison is the immediate predecessor of the same package. For a release package@v, we compare the release-authority record with package@v-1 and record typed changes: publisher, workflow, repository, provenance, signing, or mediation. This comparison makes the object predecessoraware; release timing comes from registry timestamps and release-linked public evidence. The representation yields two kinds of signal. Observable state captures what is visible at the release, such as a workflow, provenance record, or signing identity. Typed transitions capture what changed relative to the prior release. Both matter. A release with rich authority evidence is easier to interpret, and a release that suddenly changes publisher, workflow, repository, provenance, signing, or mediation may enter the candidate review queue even when its dependency graph is unchanged. Figure 1 shows the object as local release-centered records. The same comparison spans five registry-mediated regimes, while the public evidence differs by ecosystem. Go is separate because its public authority path uses VCS/proxy/checksumlog evidence.
• We define and audit a predecessor-aware releaseauthority record that captures public publisher, repository, workflow, provenance, signing, mediation, and typed predecessor-change evidence across five registrymediated ecosystems. • We show that release-authority transitions define an operational review surface distinct from dependency reach. In the five-registry corpus, we measure 45,812 releases, 43,100 eligible predecessor comparisons, and 204 policytriggering transitions. The exact transparent policy is the primary 204-release candidate queue; distance thresholds are simpler rules that trade workload for portability. • We interpret the policy trigger using incident, maliciouspackage, registry-action, advisory, practitioner, and rubric checks. These checks assess the interpretation and severity of review cues over public release-path discontinuities.
2 2.1
Predecessor-Aware Release Authority
Background and System Model Defender View and Release-Time Review
Dependency graphs describe software consumption: which packages depend on which others, how central a package is, and where code can flow after publication. We study software production: the public path used to publish a package release. The defender is a registry analyst, downstream security team, or ecosystem observer with limited review time. A new release appears. Before spending time on payload analysis, the defender wants to know whether the publication path itself deserves attention: who published it, through which namespace and repository, with which workflow, provenance, signing, and registry mediation. We define observation time as the first frozen public observation associated with a release. It may differ from the registry publication timestamp. Thus, release-time triage means triage
2.3
Running Example
Table 1 gives a concrete example from an incident-adjacent PyPI package. It shows the record created when a package moves from an opaque publication path to a workflow-backed, attested path. The example illustrates the main contrast: a dependency graph can be unchanged while the release path changes sharply. Throughout this paper, we use the following terminology. Release authority is public evidence about who or what path can publish a release. The release path is the publisher, namespace, repository, workflow, provenance, signing, and media2
npm diff
v-1
PyPI
release
repo
publisher
provenance
diff
v-1
v workflow
repo
diff
repo
checksum
diff
v-1
v trusted pub.
namespace
signing
checksum
workflow PGP key
Go boundary v-1
v repo
SCM
provenance
integrity
release
owner
release
v
RubyGems
release
owner
trusted pub.
attestation
diff
v-1
v
crates.io v-1
release
releaser
signing
Maven Central
workflow
diff
v
module path
metadata
module
VCS tag sumdb
proxy
registry pub.
Figure 1: Release-authority records across the measured regimes. Each card uses the same predecessor-aware comparison, but the visible authority evidence differs: npm and PyPI expose workflow or attestation evidence, Maven exposes namespace and signing continuity, crates.io and RubyGems expose registry metadata and integrity fields, and Go is a VCS/proxy/checksum-log boundary adapter. Dashed boxes mark fields that are absent or not comparable in that regime. Table 1: Running example of predecessor-aware release authority. The dependency graph can remain stable while the releaseauthority record captures a visible change in the publication path. View or field
Previous release
Observed release
Why it matters
Dependency graph
Same package and dependency edges
Same package and dependency edges
Release key
pypi:[email protected]
pypi:[email protected]
Publishing identity/path
unknown; workflow not observed
GitHub workflow in project-releaser
Repository and workflow
berriai/litellm
berriai/project-releaser
Provenance and signing
No public provenance; no signing
PyPI publish attestation; keyless signing
Mediation
workflow not observed
workflow-backed observed
Policy trigger
Reference state
Public control-plane discontinuity
A dependency-only analysis would not explain why this release enters review. Same package, adjacent predecessor comparison. First visible workflow-backed publication path. Release-engineering path becomes visible and differs from the source repository. Release-linked integrity evidence becomes publicly observable. Publication mediation changes from lower-observability to workflow-backed. Opens a review queue; payload analysis and incident attribution are separate steps.
tion evidence for one release. A transition is a field-level difference from the immediate predecessor of the same package. A policy-triggering release enters the automated release-time queue. Human disposition records the downstream review judgment: review_now, monitor, or no_review. Releasepath distance counts changed path fields between adjacent releases.
2.4
while an early public signal available to an outside defender is a release-path change. The defender has public registry-side evidence, provenance or attestation metadata, and limited archive-style backfill. Private maintainer communications, internal CI logs, and complete incident reconstructions require private or forensic evidence beyond this model. The measurement supports controlplane review and triage; payload forensics, malware reverse engineering, and causal attribution are separate workflows.
Threat Model and Scope
Visible publication-path discontinuities include a new publisher or workflow, provenance or signing disappearance, repository relinking, signing-key movement, and workflowobservability changes. Same-path token reuse, unchanged compromised CI, ordinary payload compromise, and deleted versions absent from the snapshot require payload, private,
We focus on attackers who obtain or abuse effective release authority. Examples include compromised maintainer credentials, leaked registry tokens, misused CI workflows, and other publish-path mechanisms that let an adversary ship a release. In this threat model, the dependency graph can remain stable 3
3
or deleted-release evidence. The motivating incidents span both sides of that boundary: axios and PostHog/Shai-Hulud expose snapshot limits, LiteLLM/Telnyx shows same-path versions plus later authority movement, and xz sits outside this registry-mediated corpus.
2.5
Methodology
3.1 Cohort Construction Regimes
and Authority
Window and regimes. The study uses one April 6, 2024– June 13, 2026 window across five registry-mediated ecosystems: npm, PyPI, Maven Central, crates.io, and RubyGems. Go modules use the same window as a boundary adapter for VCS/proxy/checksum-log evidence. Fixed acquisition limits keep the comparison reproducible while preserving different public authority regimes: npm is workflow/provenancevisible; PyPI is integrity/releaser-visible; Maven Central is namespace/signing-centric and workflow-sparse; crates.io is publisher/checksum-visible with emerging trusted publishing; RubyGems is metadata/integrity-visible with weaker public release-publisher history; and Go uses VCS/proxy/checksumlog evidence.
Registry Evidence and Audit Boundary
Authority evidence is grounded in registry and provenance records. npm provides replication-feed packuments and registry-side provenance metadata. PyPI provides BigQuery release records and per-file attestations from its Integrity and Trusted Publishing APIs. Maven Central provides namespace and signing signals, together with effective-POM SCM metadata and detached-signature continuity. crates.io contributes crate owner, publisher, checksum, repository, and trusted-publishing evidence where available. RubyGems contributes version, repository, and integrity metadata but weaker public release-level publisher history. Go contributes VCS origin, module proxy, and checksum-log evidence as a boundary adapter outside the registry-publisher regime. deps.dev stitches package-to-repository links; GH Archive and Software Heritage provide backfill and case anchors. When sources conflict, registry and provenance evidence take precedence over stitched metadata. This precedence matters because two layers are brittle: repository stitching and transition-trigger assignment. We audit those layers before treating the resulting release paths as measurement input. Section 3 describes the audit protocol, and Section 4 reports how the corrections change controlplane interpretation.
Pipeline and corpus. Figure 2 summarizes the pipeline. A single registry-first workflow discovers packages, acquires release-level authority evidence, stitches candidate repositories, normalizes one predecessor-aware release path per observed release, applies bounded audit corrections, and emits policy triggers and features. The main five-ecosystem corpus is a purposefully sampled, audited cohort. It contains 45,812 releases, 43,100 eligible predecessor comparisons, 204 policy-triggering transitions, and 942 ecosystem-package coordinates. The Go boundary adapter adds 7,123 releases and 6,653 eligible comparisons. Keeping Go separate keeps the main denominator aligned with registry-publisher semantics, while still testing whether the record transfers to a VCS/proxy/checksum-log regime while preserving nonequivalent trigger semantics.
2.6 Release-Time Triage and Historical Context
Frozen reconstruction. Given the frozen cohort and fixed evaluation configuration, release-path reconstruction, policy-trigger assignment, and evaluation are deterministic. Discovery-stage provenance is only partially retained, so cohort membership is reproducible while every package’s original discovery path is not. The pipeline collects registry, provenance, signing, and repository evidence; resolves one registryfirst release path; selects the immediate predecessor after warm-up filtering; compares publisher, workflow, repository, provenance, signing, and mediation fields; assigns policy triggers and trigger families; emits historical-context forecasting and triage feature sets; and evaluates screening, queue compression, overlap stress, and external alignment separately.
Release-time triage. After a release and its public metadata appear, we use its observed release-path state and predecessor transition to decide whether it should enter the candidate queue for human review. The policy-triggered queue is the initial screening result; human reviewers then examine the release-path record and assign a disposition: review_now (check before adoption), monitor (track but not block), or no_review (accept as routine). Historical-context forecasting baseline. We also run a narrow pre-release baseline that uses only historical features to ask whether future policy-triggering states are predictable before the observed release appears. This baseline bounds what historical context alone provides and explains why the release-time predecessor comparison—comparing each release directly to the one before it—carries the operational signal that forecasting cannot match.
Evidence acquisition. The five registry-mediated ecosystems are instantiated differently but normalized into the same release-level object. npm and PyPI combine seeded packages with ranked registry discovery and provenance or integrity expansion. Maven Central combines curated tooling seeds 4
I. PUBLIC EVIDENCE
II. INGESTION
III. NORMALIZATION
IV. ARTIFACT
V. TASKS
õ
O
À
V
¢
Registry evidence npm, PyPI, Maven crates.io, RubyGems
Raw evidence releases, attestations checksums, signatures
Registry-first precedence resolve disagreement apply audit repair
Policy triggers policy state trigger family
Baseline historical context observability checks
Feature sets historical context release-time triage
Release-time triage screen queues rank if broad
audit + checks
i
¨
Context evidence deps.dev, GH, SWH Go VCS/proxy/sumdb
Repository stitching project URLs continuity cues
Predecessor compare
è
package@v-1 → v typed field deltas
Figure 2: Registry-first release-authority pipeline. Public registry and context evidence are preserved as raw inputs, normalized under registry-first precedence, compared with the immediate predecessor, and emitted as policy triggers and feature sets. Evaluation keeps the historical-context forecasting baseline separate from release-time triage; audit and external checks repair or interpret the measurement after policy construction. with Central Search, POM and parent metadata, signatures, and recoverable SCM evidence. crates.io and RubyGems use registry adapters over version, owner or publisher, checksum, repository, and integrity metadata. Go uses VCS origin, module proxy, checksum-log, and tag evidence.
across two audit queues. Those 17 row-level findings collapse to 16 ledger entries because repeated audited rows can map to the same underlying correction. The three transitiontrigger findings collapse to one unique false positive in the corpus-level delta. Table 3 summarizes the protocol.
Scope boundaries. The five registry-mediated ecosystems form the main corpus because each exposes public release records that support a predecessor comparison. RubyGems remains in this corpus even though its public release-level publisher history is narrow; it contributes boundary evidence under the conservative policy. Go tests the boundary where VCS tags, module proxies, and checksum logs stand in for a registry publication path. It remains outside the registrypublisher denominator. The incident, registry-action, advisory, and practitioner-review layers are most complete for npm, PyPI, and Maven, so we report that subset as the externalevidence subset [4, 40, 45, 46, 49].
3.2 Unit of Analysis, Cohort Subsets, and Policy Triggers Release key and cohort subsets. The unit of analysis is a release key (ecosystem, package, version). We report one main corpus and five derived or diagnostic subsets over the same measurement program. The five registry-mediated corpus is the main descriptive release-authority cohort. The Go boundary adapter uses VCS/proxy/checksum-log evidence and is kept separate from registry-publisher semantics. The combined portability cohort adds Go to the five-registry corpus for operational screening and portability diagnostics. The external-evidence subset contains npm, PyPI, and Maven records used for the most complete incident, registry-action, advisory, and practitioner review. The workflow-visible subset is the npm+PyPI subview used when the discussion depends on public workflow or provenance exposure. Highobservability subset is the diagnostic subset with known project key, continuous repository continuity, no disagreement flag, and observability score at least 2.0.
Release-path object. Raw evidence preservation, releasepath resolution, audit correction, and evaluation remain separate layers. Each normalized release path records the publishing principal, namespace, linked repository, workflow identity when exposed, provenance state, signing state, mediation type, and typed comparison against the previous release. The object is predecessor-indexed by release timestamp.
Observability. The observability score sums four public signals: known project key, workflow present, provenance present, and signing present. It ranges from 0 to 4, and mean observability is the cohort average of that score. The highobservability subset tests whether weak signals in the full corpus come from missing public authority evidence.
Audit protocol. Audit sits inside that reconstruction. We audit the two brittle layers that most directly affect interpretation: package-to-repository stitching and policy-triggering release-path events. An audit queue is the bounded set of candidate records presented for manual adjudication. A row is one package–repository link decision or one release-transition trigger decision. The correction ledger contains 14 incorrect repository links and 3 incorrect transition-trigger decisions
Policy trigger. The automated rule output is policy_trigger: a public control-plane discontinuity 5
Table 2: Temporal semantics of public authority fields. The release-time interpretation is strongest when evidence is releasespecific and timestamped; mutable or retrospectively observed fields are used with audit and lower-confidence interpretation. Field
Main sources
Release-specific?
Mutable or retrospective?
Version and timestamp
Registry release records
Yes
Low; deleted versions can be absent from later snapshots Current owner fields can be retrospective Can arrive late or be unavailable in workflow-sparse regimes Mutable and affected by stitching errors Semantics differ by ecosystem
Publisher, releaser, owner
Registry release or package records Workflow, provenance, attesta- npm/PyPI provenance and tion trusted-publishing records Repository or SCM link Registry metadata, POM SCM, deps.dev, GH/SWH backfill Signing, checksum, integrity Registry integrity metadata, detached signatures, checksum logs Mediation state Derived from observed workflow/provenance evidence Go boundary evidence
Regime-dependent Usually yes where exposed Often package-level Usually release-specific Derived
VCS tags, module proxy, check- Release/module-version sum database specific
Use in the study
Defines the release key, predecessor order, and measurement window. Used when exposed at release level; weaker fields support boundary reads. High-confidence release-path evidence for workflow-backed publication. Audited before use; repository relinks require continuity evidence. Supports ecosystem-specific integrity/signing continuity. Absence of evidence is lower- Reported as workflow-backed observed or confidence workflow not observed; records visibility rather than actor identity. No registry publisher account Used for boundary-adapter comparison outside registry-publisher trigger assignment.
Table 3: Audit protocol summary. Two bounded audit queues are adjudicated before final policy-trigger assignment and evaluation. The table records queue size, error rate, and dominant corrected error pattern.
Table 4: Evaluation layers used in the study. The releasepath policy defines the queue; human and external evidence interpret it; operational results report workload under that policy definition.
Queue
Sampling
Layer
Role
Policy trigger
Repo stitch
Stratified over disagreement/confidence buckets Stratified/resampled over trigger families
Transparent release-path rules identify releases whose public authority path changed. Practitioner and rubric checks test whether records selected by the policy are interpretable as review cues. Workload tables report how many releases a policy queue sends to review and how many policy-triggering releases it contains. Incidents, malicious-package feeds, registry actions, and advisories show where the public release-path scope aligns with or misses external security evidence.
Policy-trigger audit
Rows Incorrect 200
Rate Dominant corrected error pattern
14 7.0% Placeholder or wrong repository
Review judgment Operational workload
150
3 2.0% Parser-induced false first-seen transition External boundary
used to open the candidate queue, with maliciousness assessed separately. A policy trigger is assigned after a stable three-release warm-up when a release shows one or more of the following: first-seen authority or workflow, provenance disappearance or downgrade, repository relink without continuity, signing disappearance or switch, or a workflow-observability mediation change. These policy triggers require enough regime-specific release-level authority evidence to distinguish a control-plane discontinuity from metadata churn. RubyGems repository relinks without release-account history are recorded as boundary evidence under the conservative corpus policy.
den policy-triggering transitions and 30 matched or boundary controls. One reviewer also completed the full 120-row workbook. The shared core is the practitioner result used for inter-annotator agreement and the main-text disposition table; the single-reviewer extension is used only for descriptive trigger-family coverage in Appendix 21. Reviewers saw predecessor/current release-path fields and dependency context while blinded to stored triggers, trigger families, reason codes, model scores, release-path distance, or author decisions. Third, we completed a 120-row trigger-blinded author workbook using review_now, monitor, and no_review. Finally, we ran an automated rubric-consistency diagnostic on a 373-release stratified sample; model judges saw only predecessor/current records and were blinded to stored triggers, reason codes, model scores, and release-path distance. Appendix A.3 reports this diagnostic as a reproducibility check. These checks test interpretability and severity thresholds. The practitioner pass provides inter-annotator agreement on the shared core and broader one-practitioner coverage on the full workbook.
Interpretation checks. We interpret the policy trigger with three calibration layers plus one automated rubric diagnostic. We first sampled 132 policy-triggering releases and 132 controls for a balanced, trigger-blinded diagnostic over predecessor/current release-path records. Reviewers were blinded to the stored policy trigger and reason code; two authors reviewed the records independently, and disagreements were adjudicated against the frozen predecessor/current record. This pass refined rubric wording and severity boundaries, with nine low-distance uncertainties adjudicated as lower-severity authority/workflow novelty. Second, three practitioner reviewers completed a 60-row realistic-context shared core: 30 hid-
External feeds. For the malicious-package alignment, we use two external feeds: OpenSSF/OSV MAL records and Datadog manifests [6, 31, 32]. We pin both feeds to fixed 6
repository commits before joining affected versions to release keys. We normalize package names using ecosystem conventions and join explicit affected versions to frozen release keys. Dated external records published after the measurement window are excluded from the reported table. Package-level external rows without explicit versions are treated as packagescope evidence rather than exact release-level outcomes. For dated OpenSSF/OSV records, we also collect same-package policy-triggering transitions within ±90 days. For explicit malicious versions absent from the frozen snapshot, we run a separate post-hoc live-registry recovery check against public version endpoints. The primary policy triggers, features, and model inputs remain frozen. These external feeds are joined after policy-trigger construction.
relative to the previous release of the same package, computed over publisher, workflow, repository, provenance state, signing state, and mediation type. It ranges from 0 to 6. The three-release warm-up avoids treating the first observed releases of a package as authority transitions before there is enough predecessor context to distinguish novelty from churn. The key policy parameters are fixed before evaluation: a shared 2024-04-06–2026-06-13 measurement window, a three-release warm-up, a 90-day history horizon, a 180day authority-reach window, a ±90-day incident alignment window, and a high-observability threshold of at least two public authority signals. We treat these as pre-specified reproducible policy choices; Tables 13 and 19 report how semantic grouping, release-linked fields, and temporal drift affect the measured queues. The regime-specific distance threshold is reported separately as a retrospective descriptive policy selected after inspecting regime semantics: Maven at d ≥ 1 and npm/PyPI/crates.io at d ≥ 2. Table 19 evaluates temporal application and workload drift in the replayed observations.
Mediation and trigger families. The normalized mediation field records observed workflow evidence. It is workflow_backed_observed when workflow identity or provenance is public and workflow_not_observed otherwise. The latter value means that public workflow evidence is absent. Unknown is reserved for missing predecessor state in transition comparisons, so unknown-to-observed or unknownto-not-observed changes can still contribute to mediation mismatch and release-path distance. We treat those cases as lowerconfidence observability changes, inspect them in the policytrigger audit and rubric checks, and keep the three-release warm-up before assigning policy triggers. When multiple triggers fire, the pipeline stores both the full reason set and one canonical primary trigger by fixed precedence. For robustness analysis, we also group triggers into broader families: authority/workflow, provenance/mediation, repository continuity, and signing. The family semantics are shared across ecosystems, but their visible instantiation differs by regime.
3.4
Evaluation
Tasks and splits. The historical-context forecasting baseline predicts 90-day future policy-triggering state from historical features. Release-time triage ranks the observed releaselevel target from contemporaneous release-path deltas plus historical context. Triage is an offline replay over frozen public observations; prospective metadata-arrival latency is left for deployment study. We evaluate triage through controlled held-out ranking on the canonical 18–3–3 split, full-queue operational screening rules, and two-stage compression after a coarse queue is open. The 18–3–3 split uses 18 months of training, a 3-month middle holdout block, and a 3-month test block. The split is fixed before model evaluation.
Historical-context forecasting baseline. The historicalcontext forecasting baseline uses a different target family: whether the same package enters a policy-triggering releasepath state within the next 90 days. It uses only historical features. Release-time triage, by contrast, may use contemporaneous release-path deltas because the operational question is whether the observed release should enter the policy queue.
Triage Signals and Context Features
Learned ranking protocol. For secondary learned-ranking analyses, we use one fixed recipe across information bundles so performance differences reflect information content, not model tuning: class-balanced logistic regression and shallow calibrated histogram boosting. Both the historical-context forecasting baseline and release-time ranking use temporal evaluation. The main protocol is month-based train-gap-test splitting, with grouped temporal package holdout as the primary guard against package memorization.
Table 5 separates context from release-time signals. The main policy uses observed predecessor deltas; historical features are retained as baselines, controls, and context for ranking inside already-open queues. Authority reach uses a trailing 180-day window. For the current publishing principal, it sums reverse-dependency reach over the packages that principal published during the previous 180 days. It therefore measures recently controlled downstream exposure, not package centrality alone. Releasepath distance is the count of mismatched release-path fields
Policy baselines and ranking inputs. Policy baselines are deliberately simple: dependency reach, dependency indegree, maintainer count, inverse cadence, random ranking, releasepath distance, provenance or signing change, first-seen authority or workflow, and mandatory review of any nonzero path-distance transition. Dependency-only uses dependency baselines alone; Dependency+social adds maintainer-count and visible-popularity signals; Authority-transition adds contemporaneous transition deltas; and Authority-triage further
3.3
7
Table 5: Triage signals and context features. Release-time deltas are the operational screening signal; historical features provide context and a weak pre-release baseline. Family
Examples
Source
Timing
Direct policy-trigger Role in the study overlap?
Dependency context
reach, indegree, age, cadence, Registry, deps.dev, package Historical or release-time No maintainer count, visible popu- metadata non-authority context larity
Historical authority context authority reach, concentration, Prior release-authority Pre-release / historical No direct overlap mediation history, signing his- records tory, recent churn Path context dominant-path stability, reposi- Current and recent release- Mixed; release-time for Partial / indirect tory churn, signing churn, path authority records current-state interpretation novelty, transition motifs publisher, workflow, repository, Current release compared Release-time only Yes, by design Release-path transition provenance, signing, and media- with immediate predecessor tion deltas; release-path distance
Exposure baseline; checks whether dependency graph structure alone opens useful queues. Pre-release baseline; tests whether past authority state anticipates later triggers. Interprets whether an observed transition is unusual for that package or regime. Primary release-time screening signal and source of transparent policy queues.
Table 6: Audit-induced graph and policy-trigger delta on the npm/PyPI/Maven external-evidence subset. One concentrated stitching error and one false policy trigger are removed.
adds contemporaneous observability and short-horizon authority context. These learned bundles are secondary to the exact trigger policy and transparent distance rules.
Quantity
Operational queues. The primary policy read uses complete threshold queues. For a discrete score such as releasepath distance, a threshold queue includes every release at or above the chosen score and never cuts through tied releases. We report selected releases, captured policy triggers, policypositive yield, policy coverage, and authority-reach capture. Authority-reach capture sums authority reach over captured triggers and normalizes by total trigger authority reach in the corpus or subset. Budgeted prefixes remain a ranking diagnostic: a k% review budget selects the top max(⌊k · n⌋, 1) releases. The main policy evidence uses complete threshold queues because prefixes may cut through large tied groups.
Materialized release→repo links Rows on canonical repo Placeholder repo degree Policy triggers First-seen triggers
Before After
∆
3059 3058 -1 22 36 +14 14 0 -14 180 179 -1 85 84 -1
from dependency context alone. In this way, the model compresses an already-open review queue after policy has selected candidate release-path events for review.
4
Results
We report four results. Audit correction changes the measured control plane. The predecessor-aware record spans five registry-mediated ecosystems, with Go as a boundary adapter. External evidence interprets the policy trigger. The useful operating mode is release-time screening: simple release-path rules open the queue, and learning helps mainly when the queue is still broad.
Overlap stress. Triage AUPRC measures recovery and ordering of policy-triggering release-path discontinuities under explicit overlap stress. We report four increasingly strict reads. Held-out-family stress removes one trigger family from positive training targets. The masked comparison also removes the directly aligned contemporary feature family. The orthogonal-context comparison drops the full contemporary transition block and asks whether historical authority context still ranks held-out-family triggers. The matched-trigger comparison evaluates family-specific ranking inside simple family-aligned queues with exact release-path-distance pairwise checks. These tests target residual queue-compression utility under explicit overlap stress; full structural independence would require a separately defined security target.
4.1 RQ1: Audit Correction and Control-Plane Interpretation Audit effect. Table 3 reports two bounded audit queues. The package-to-repository queue has 14 wrong links out of 200 audited rows. The policy-trigger audit queue has 3 wrong trigger decisions out of 150 audited rows. Table 6 shows their effect on the graph and policy-trigger set.
Two-stage compression. On the canonical held-out split, Stage 1 opens a coarse queue with a simple screening rule and Stage 2 ranks only inside that queue. If Stage 1 is authorityaligned, Stage 2 masks directly aligned contemporary feature families. If Stage 1 is dependency-defined, Stage 2 may use authority-transition features because the queue was opened
Repair anchor. The errors are concentrated: one placeholder repository pattern and one parser-induced false firstseen event. We run the remaining analyses on the corrected evidence. In authentik-client, the repository-stitch repair 8
4.3 RQ3: External Alignment and PolicyTrigger Boundaries
moves 14 releases onto the source repository and removes the false downstream transitions induced by the bad link. Appendix A.2, including Tables 17 and 18, gives the packagelevel repair view, recurring error patterns, and audit-ledger reference.
Policy triggers versus incidents. A positive policy trigger marks a release for queueing. Incident status is assessed separately. This boundary matters because many real compromises reuse an existing visible release path, disappear from public snapshots, or require payload analysis.
4.2 RQ2: Five Registry-Mediated Ecosystems and One Boundary Adapter
Public incident anchors. No exact public malicious version is also policy-triggering: axios exact versions are absent from the frozen snapshot; LiteLLM/Telnyx exact versions are present but reuse the same measured release path, while nearby [email protected] opens a review question; and PostHog/Shai-Hulud is only partially observable. The broader OpenSSF/OSV MAL and Datadog alignment covers the npm/PyPI/Maven external-evidence subset: 9 corpus packages and 23 explicit malicious versions, with 7 exact eligible versions, 16 absent exact versions, 0 exact triggers, and 6 same-package triggers within ±90 days of dated OpenSSF/OSV records [1, 5, 6, 32, 34].
Cohort and boundary adapter. The predecessor-aware object can be instantiated across all five registry-mediated ecosystems, but review semantics differ by regime. The main corpus contains 45,812 releases, 43,100 eligible predecessoraware comparisons, and 204 policy-triggering transitions across 942 ecosystem-package coordinates. Go adds 7,123 releases and 6,653 eligible comparisons and is reported separately because its authority path is VCS/proxy/checksum-log based.
Authority fields differ by regime. Table 7 shows the regime differences. npm is workflow/provenance-rich; PyPI exposes releaser, trusted-publishing, attestation, and integrity signals; Maven centers on namespace and signing continuity; crates.io exposes owner and publisher continuity plus emerging trusted publishing; RubyGems exposes repository and integrity metadata but weak release-level publisher history; Go uses VCS/proxy/checksum-log evidence. The shared unit is the predecessor comparison, but the signals carry different meanings. Maven can expose signing-key movement under stable namespace and SCM evidence, RubyGems remains zero-trigger under the conservative release-account evidence, and Go is interpreted through VCS/proxy/checksum-log continuity rather than registry-publisher authority.
Interpretation checks. These checks calibrate how to read a policy trigger. Registry actions are sparse, advisories name affected code, and rubric checks test severity boundaries. The practitioner review is the direct severity check: Table 10 reports whether shared-core triggers and matched controls receive review_now, monitor, or no_review. Candidate queue, downstream disposition. The practitioner review interprets the policy triggers; the corpus policy selection remains fixed. The 204 triggers form a candidate queue; immediate review, monitoring, and context-only treatment are downstream deployment decisions. Appendix Table 21 reports dispositions by trigger family and ecosystem using the single-reviewer extension as descriptive coverage, and Appendix Table 22 states the supported and unsupported claims for each evidence layer.
Regime anchors. A provenance disappearance in npm, a releaser change in PyPI, a signing-key movement in Maven, and missing publisher history in RubyGems therefore require regime-specific interpretation.
4.4 RQ4: Transparent Policies Define Operational Workload Historical-context forecasting is weak. Before a release is observed, many policy-triggering states have no release-path change to compare yet. The historical-context forecasting baseline is weak under grouped package holdout and serves mainly as a scope check: history can provide context, but the review cue appears when the predecessor comparison becomes observable. The main result is a post-publication triage replay.
Transition landscape. Table 8 shows the descriptive measurement result. The five-registry corpus contains 43,100 eligible predecessor comparisons and 204 policy-triggering transitions. PyPI contributes most low-distance public changes because repository and workflow evidence are often partial; Maven contributes few but high-yield signing-centered changes; crates.io contributes a small trusted-publishing and publisher/owner evidence; RubyGems contributes visible repository and metadata changes but no triggers under the conservative release-level publisher policy.
Exact policy first, distance rules second. Release-time triage uses the observed release path. In offline replay, the 9
Table 7: Authority-evidence coverage across five registry-mediated ecosystems and the Go boundary adapter. The same April 2024–June 2026 window is used for every row. Go is marked as boundary because its public path uses VCS/proxy/checksum-log evidence. Percentages indicate visibility of regime-specific fields under ecosystem-specific semantics; Obs. is the row mean of the four-field observability score. Ecosystem
Releases / triggers
npm
3,427 / 66
PyPI
27,925 / 99
Maven
8,040 / 14
crates.io
2,229 / 25
RubyGems
4,191 / 0
Go modules 7,123 / N/A
Repo
¨ Workflow è Prov./proxy À Sign./integrity Obs. Interpretation
100%
64%
64%
100%
89%
16%
16%
16%
100%
0%
0%
100%
99%
5%
5%
100%
94%
0%
0%
100%
100%
0%
100%
100%
3.27 Workflow/provenance plus registry signing. 1.35 Releaser/integrity with partial workflow evidence. 2.00 Namespace/signing; workflow mostly absent. 2.08 Publisher, checksum, and emerging trusted publishing. 1.94 Metadata/integrity; no release-level publisher history. 3.00 VCS/proxy/checksum-log path; no registry publisher.
Table 8: Transition landscape in the five-registry corpus. Family counts are not mutually exclusive because a release can trigger more than one policy family. Ecosystem
Eligible
Triggers
d≥1
d≥2
Auth./wf
Prov./med.
Repo
Signing
Obs.
npm PyPI Maven crates.io RubyGems
3,196 26,710 7,732 1,739 3,723
66 99 14 25 0
134 2,659 17 131 8
84 211 0 25 0
28 56 0 20 0
52 90 0 24 0
0 0 0 0 0
57 90 14 0 0
3.31 1.36 2.00 2.11 1.96
Table 9: Interpretation checks for the policy trigger. These checks calibrate interpretation after trigger construction. Check
Table 10: Human disposition of policy triggers and matched controls in the 60-row shared core. Three practitioner reviewers saw predecessor/current release-path records and context while blinded to policy triggers, trigger families, model scores, and release-path distance.
Result and read
Public incidents
0 exact malicious versions are policy-triggering. The cases define observability limits: absent versions, same visible path, and partial snapshots. External malicious In the npm/PyPI/Maven external-evidence subset: 9 packages, feeds 23 explicit versions, 7 eligible exact versions, 16 absent versions, 0 exact triggers, and 6 window triggers. Exact malicious versions serve as external boundary evidence. Registry/advisory out- Registry actions are support-limited: the matched outcome comes table contains zero exact policy-trigger registry actions. OSV/GHSA advisories track affected code. Practitioner reviewers Three practitioner reviewers with security expertise annotate a 60-row shared core with mean exact pairwise agreement 0.800 and Fleiss’ κ = 0.666. In the shared core, 20/30 triggers receive review_now, 9/30 receive monitor, 1/30 receives no_review, and observed controls receive zero review_now or monitor judgments. Rubric stress checks Label-blinded author and automated rubric checks mainly downgrade severity on signing-only and low-observability cases. These checks refine severity thresholds alongside practitioner and incident evidence.
Reviewers
State
n Now Monitor No
3, majority Trigger 30 3, majority Control 30
20 0
9 0
1 30
Transparent workload. Table 11 reports transparent queues over the five-registry corpus. The exact trigger policy selects 204 releases by definition, or 0.47% of eligible predecessor comparisons. A uniform semantic-distance rule (s ≥ 2) selects 320 releases and covers 190/204 triggers, 93.1% policy coverage, and 99.9% of measured trigger authority reach. The descriptive regime distance rule uses d ≥ 1 for Maven and d ≥ 2 for npm, PyPI, and crates.io; it selects 337 releases and covers all 204 triggers. Any nonzero path change selects 2,949 releases. RubyGems remains in the denominator and contributes boundary evidence, but has no triggers under the conservative policy. The broader queue admits a wider range of releases because policy triggers open the queue for staged triage. The Maven signing-only anchor illustrates this separation: stable namespace and SCM evidence can turn a policy trigger into context-only review.
exact transparent trigger policy runs on the reconstructed release-authority record and opens the policy-defined 204release candidate queue. Distance thresholds are simpler rules that trade workload and coverage for portability. Learned ranking is a second-stage tool for broad queues, so triage performance is workload accounting for a policy-defined candidate queue. 10
Table 11: Transparent policy queues over the five-registry corpus. The exact trigger policy defines the primary candidate queue, so its inclusion metrics hold by construction. Distance thresholds are simpler rules; each includes every release tied at the threshold. Policy-positive yield and policy coverage are measured against the automated release-path policy; security interpretation comes from the separate calibration layers. Policy
Rule
Queue size
Exact trigger policy Uniform semantic distance Regime distance rule Any path change
trigger rule s≥2 Maven d ≥ 1; npm/PyPI/crates.io d ≥ 2 d≥1
204 320 337 2,949
Share
Triggers
Yield Coverage Auth. reach Function
0.47% 204, policy-defined N/A—defined by policy 0.74% 190/204 59.4% 93.1% 99.9% 0.78% 204/204 60.5% 100.0% 100.0% 6.84% 204/204 6.9% 100.0% 100.0%
Table 12: Per-ecosystem threshold queues. RubyGems remains in the five-registry corpus; it contributes no policytriggering releases under the conservative release-level publisher evidence policy.
Table 14: Authority-reach concentration among policytriggering releases. This table explains why authority-reach capture and policy coverage are reported separately. Quantity
Ecosystem Threshold Eligible Triggers Queue size Captured npm d≥1 npm d≥2 PyPI d≥1 PyPI d≥2 Maven d≥1 Maven d≥2 crates.io d≥1 crates.io d≥2 RubyGems d ≥ 1 RubyGems d ≥ 2
3,196 3,196 26,710 26,710 7,732 7,732 1,739 1,739 3,723 3,723
66 66 99 99 14 14 25 25 0 0
134 84 2,659 211 17 0 131 25 8 0
Yield Coverage
66 49.3% 66 78.6% 99 3.7% 99 46.9% 14 82.4% 0 – 25 19.1% 25 100.0% 0 0.0% 0 –
204 Automated release-path policy triggers in the five-registry corpus. Total trigger authority reach 67,498 Trailing 180-day reach controlled by policytriggering releases. Median trigger authority 0.0 Most triggers have little measured downstream reach authority reach. Top 1 trigger share 7.6% Largest trigger dominates less than a tenth of total trigger reach. Top 5 trigger share 36.0% Reach is concentrated in a small set of PyPI releases. Top 10 trigger share 66.2% Authority-reach capture should be reported with policy coverage.
100.0% 100.0% 100.0% 100.0% 100.0% 0.0% 100.0% 100.0% – –
Rule
Queue
Trig.
Yield
Cov.
Raw field d≥2 Semantic s≥2 Release-linked r≥2 Regime semantic regime
320 320 319 337
190/204 59.4% 93.1% 99.9% 190/204 59.4% 93.1% 99.9% 189/204 59.2% 92.6% 99.9% 204/204 60.5% 100.0% 100.0%
Value Read
Policy-triggering releases
Table 13: Sensitivity to correlated field changes and retrospective fields. Semantic-family distance counts at most one change in each family: authority identity, repository continuity, workflow/provenance/mediation, and signing/integrity evidence. The release-linked sensitivity excludes repository/SCM continuity fields. View
Policy-defined candidate queue. Portable simplified rule. Regime-specific rule. High-coverage baseline.
the same retrospective regime threshold before and after the 18-month cutoff. It preserves policy coverage in both windows, but queue share, trigger prevalence, and yield drift over time. Authority reach and ranking. Authority reach is concentrated. Table 14 shows that the median policy-triggering release has zero measured authority reach, while the top 10 triggers account for 66.2% of trigger authority reach. We report authority-reach capture with policy coverage as a secondary exposure-weighted read of the same queue. Learned ranking remains a second-stage diagnostic. In the two-stage split, the 50-release path-distance queue needs 39 reviews for full policy coverage under simple magnitude ordering. Learning helps most inside broad queues opened by non-authority policies: in the 179-release dependency topdecile queue, authority-transition ranking finds all 5 triggers after 5 reviews, while dependency-only sorting needs 171. This supports the operational ordering: transparent releasepath rules open the queue; learned ranking helps when that queue remains broad.
Reach
Ecosystem thresholds. The per-ecosystem breakdown in Table 12 makes a single universal distance threshold too coarse. Maven triggers sit at d = 1 because signing is the main visible authority evidence. crates.io triggers are exactly captured at d ≥ 2. PyPI has many low-distance public changes, so d ≥ 2 is the useful workload threshold. These queues include every release tied at the threshold, so score-bin ordering does not affect the reported result. Semantic and temporal sensitivity. Table 13 checks whether correlated fields drive the distance-rule result. Raw field distance and semantic-family distance produce the same d ≥ 2/s ≥ 2 queue in this corpus. A release-linked sensitivity that excludes repository/SCM continuity fields changes one selected trigger. The regime semantic threshold still covers all 204 policy-triggering transitions. Appendix Table 19 shows
5
Discussion
Findings Release authority and dependency structure point to different review surfaces. Dependency links show where code can flow; 11
External alignment. The policy-trigger boundary is anchored in public incidents, OpenSSF/OSV and Datadog malicious-package matches, registry actions and advisories, matched controls, temporal placebos, practitioner review, and rubric checks. The malicious-package join covers 9 inwindow corpus packages and 23 explicit malicious versions; 7 exact versions are present and eligible, 16 are absent from the frozen snapshot, none are policy-triggering, and 6 samepackage triggers appear near dated OpenSSF/OSV records. A post-hoc audit finds those 16 absent versions are also unavailable from current registry endpoints. These checks delimit where malicious-package evidence is observable, where unavailable versions lie outside the frozen snapshot, and where visible release-path changes appear near public incidents. Registry actions are sparse and the matched outcome table has zero exact policy-trigger registry actions; OSV/GHSA advisories track affected code rather than review triggers. A future compromise-detection study needs a larger verified incident corpus with exact affected versions and independent stop/review judgments. Practitioner and trigger-blinded author checks test whether the trigger is usable and how severity should be read. Three practitioner reviewers completed the shared core with mean exact pairwise agreement 0.800 and Fleiss’ κ = 0.666. Controls received no review_now or monitor judgments. Disagreements were mainly downgrades: authority/ workflow triggers often stay immediate-review or monitor, while signing-only Maven cases often move to no_review. The single-reviewer extension is descriptive, and the automated rubric diagnostic is reported in the appendix.
release authority shows who published a release and how that path surfaced: registry account, workflow, provenance, signing key, owner, repository link, VCS tag, proxy, or checksum log. We measure predecessor-aware release paths across five registry-mediated ecosystems and report Go as a boundary adapter. The main result is a release- time triage signal. A historical-context baseline confirms the claim: authorityhistory features help, but they are weak until a release-path change is visible. Once it is, publication-path transitions expose an interpretable review surface that dependency structure alone cannot supply. Simple transition rules capture most operational value as policy queues; distance thresholds are portable proxies, and learned ranking adds second-stage ordering when Stage 1 still leaves a broad queue. This is strongest for authority/workflow cases and weaker for signing- centered queues. Regime differences matter. npm, PyPI, Maven Central, crates.io, and RubyGems expose different authority signals, while Go differs because its module resolution relies on VCS tags, proxies, and checksum logs instead of registry publisher authority. A common release-authority object fixes the release view while preserving regime-specific trigger semantics and keeping Go outside the registry-publisher regime.
Scope and Limits Cohort and observability. The study uses a bounded, audited April 2024–June 2026 window. The five- registry corpus contains 204 policy-triggering transitions, and the npm/PyPI/Maven external-evidence subset contains 179. Appendix Table 15 summarizes cohort construction and the remaining reconstruction limit: cohort membership and evaluation parameters are fixed, while detailed per-package discovery-stage provenance is summarized rather than fully replayed.
Learning identification. The historical-context forecasting baseline shows that ordinary temporal splits can overstate pre-release prediction by leaking package identity across train and test. Because triage features and the policy trigger both derive from observed release-path changes, some primitives overlap. We probe overlap with held-out-family removal, aligned-feature masking, orthogonal-context ablations, matched-trigger queue ranking, and two-stage queue compression. These checks support second-stage queue-compression utility, strongest for authority/workflow and weaker for signing, under an explicit policy target. Full structural independence from broader path-context features would require a separately defined security target.
Portability boundary. The five-registry corpus preserves regime-specific authority semantics. crates.io and RubyGems are registry-mediated but differ in owner, trusted-publishing, MFA, signing, and publisher-history evidence; RubyGems has zero triggers under the conservative policy. Go tests the boundary where VCS/proxy/checksum-log authority replaces registry-publisher authority, so it is reported as an adapter. External alignment is most complete for npm, PyPI, and Maven; extending it requires ecosystem-specific incident corpora and rubrics. Audit and incident visibility. The correction ledger follows a fixed single-adjudication workbook. It exposes recurring error patterns in raw release-path evidence and records the before/after corrections used in the reported counts. Briefly published then deleted releases can disappear from later snapshots, so incident-boundary analysis may capture surrounding authority instability around the exact released version.
Implications Operationally, the results support a two-step review process. Stage 1 is a transparent policy rule tied to an observed releasepath event; Stage 2 is optional and only orders releases already selected for review. Cross-regime deployment needs one stable releaseauthority object plus regime-specific rules for the strongest public signals: workflow/provenance and releaser changes 12
in npm and PyPI; namespace/signing/SCM continuity in Maven; ownership and trusted-publishing evidence in crates.io; narrower metadata and integrity in RubyGems; and VCS/proxy/checksum-log evidence in Go. Human review then separates immediate-review, monitoring, and contextonly cases. Provenance loss, mediation downgrade, publisher or releaser discontinuity, and signing changes with other path movement are higher severity; first adoption of workflow/provenance and stable-namespace signing-only cases are often lower severity. A release may enter the queue because its control plane changed sharply even if it later proves benign. The queue surfaces publisher, workflow, signing, repository-continuity, or mediation discontinuities that need explanation, documentation, or confirmation. Rubric checks refine severity by separating transport-only repository changes from true repository moves and keeping workflow-file or signing-only changes lower severity when provenance, mediation, repository identity, and surrounding authority stay stable. As registries add better trusted-publishing, provenance, and signing signals [12,35,47], defenders should get cleaner Stage 1 rules and more reliable Stage 2 ranking.
6
we give registry and provenance evidence precedence and treat repository and archive evidence as context. That choice matters for release-engineering repositories, mirrors, placeholder URLs, generated SDKs, and owner transfers. PyRadar, Dirty-Waters, and Scorecard show both the value and fragility of repository-centric operational signals [10, 22, 54]. Measurement reliability and archival infrastructure. This work also follows security measurement that treats data quality, linkage reliability, and reproducibility as first-order concerns. The audit protocol, disagreement analysis, and correction ledger are part of the result. Software Heritage and GH Archive provide backfill and case support beneath the registry-defined control plane [3, 11, 44]. Malicious-package detection and operational triage. Malicious-package datasets, incident reports, and attack taxonomies support payload inspection, incident reconstruction, and downstream detection workflows [6, 8, 16, 21, 29, 32]. Our object sits earlier in the workflow: it records public releasepath changes before payload analysis. This makes it closer to alert-routing instrumentation than to malware classification. The output is a bounded queue whose rows still need explanation, confirmation, or payload review. Scorecard and actor-reputation metrics also target scalable prioritization, but score projects, maintainers, or practices. We score releasepath transitions within a package’s own history [2,17,52,54].
Related Work
Dependency-centric ecosystem measurement. Empirical software supply-chain measurement often treats the package dependency graph as the main object. Studies of ecosystem evolution and dependency topology document concentration, fragility, and transitive exposure across ecosystems [7, 20, 53, 55]. Review priority is commonly proxied through centrality, downstream reach, maintainer concentration, malicious-package prevalence, or vulnerability propagation over dependency edges [8, 15]. We add a production-side layer: which principals, workflows, namespaces, and signing paths can create those releases.
7
Conclusion
Dependency graphs show downstream exposure; releaseauthority records show the public path that ships a release. Across the audited five-registry cohort, transparent predecessor-change rules define a bounded candidate queue asking why a package shipped through a changed authority path, with maliciousness assessed by separate evidence. Under the reconstructed evidence model, the exact trigger policy is most interpretable because it names release-path discontinuities directly. Semantic and regime-specific distance thresholds provide simpler first-pass or portable workload summaries. The study separates queue construction from severity. Practitioner review separates immediate-review, monitoring, and context-only cases. Provenance loss or publisher discontinuity can justify immediate review; first workflow-evidence adoption or stable-namespace signing-only changes can be monitoring or documentation. Historical context is weak before the release-path change occurs; learning is most useful after a broad queue is open. Same-path compromise, unchanged compromised automation, and snapshot-absent versions remain outside this surface and need forensic or snapshot evidence; release-authority transitions still complement dependency reach as a concrete, auditable review surface.
Trusted publishing, provenance, and signing. Work on provenance, trusted publishing, keyless signing, and attestations focuses on mechanism design and ecosystem hardening [25, 41, 43, 50, 51]. Measurement and practitioner studies show that signing support and verification quality remain uneven [18,19,42]. npm and PyPI now expose related controlplane evidence through trusted publishing, provenance, signatures, and integrity APIs [26–28, 35–38, 47]. We measure how those signals change across releases. Registry-first measurement and audited stitching. Other work infers package repositories, maintainer relationships, or release processes from package metadata and public repository history. Forge-side work on attribution and identity practices reaches a related conclusion: repository-derived provenance is security-relevant but noisy [14]. For release authority, 13
Ethical Considerations
Open Science An anonymous review artifact is available at:
This work measures public software-registry metadata, public provenance or attestation records, public repository links, and public incident or malicious package feeds. The measurement uses public records and avoids maintainer contact, registry-user interaction, production-system access, exploit development, vulnerability discovery, malware execution, and active probing.
https://anonymous.4open.science/r/good-authority/
It is a snapshot-based repository: reviewers can inspect and rerun the reported outputs without a live recrawl of package registries, GitHub, Software Heritage, deps.dev, BigQuery, OSV, or model APIs. The repository includes a README quickstart and a claim-to-artifact map. Manuscript sources are omitted from the anonymous bundle. If accepted, we will archive the reviewed artifact under a permanent public identifier.
Registry operators and downstream defenders. The expected benefit is defensive: the work helps operators and downstream security teams decide which public release-path changes should enter a candidate review queue before payload analysis. The main deployment risk is alert overuse. We therefore frame outputs as threshold review queues and report workload, policy-positive yield, policy coverage, and authority-reach concentration.
• Code: Python package, SQL transforms, and reviewerfacing scripts under src/, sql/, and scripts/. • Frozen snapshot: curated releases, release paths, policytrigger tables, feature store, DuckDB database, manifests, audit workbooks, and correction ledger.
Package maintainers and projects named in cases. The main ethical concern is reputational: a release-path discontinuity can be mistaken for evidence of compromise. We address that concern in the study design and claims. Policy triggers are public control-plane discontinuities; maliciousness is assessed with separate evidence. Case studies illustrate the measurement object. External malicious-package feeds serve as boundary checks after policy construction.
• Reported outputs: policy-queue CSVs, semantic-distance sensitivity, temporal workload drift, cohort characterization, practitioner dispositions, audit summaries, figures, and the lightweight six-ecosystem evidence package. • Calibration materials: practitioner-review summaries, external incident and malicious-package alignment outputs, trigger-blinded author calibration, and automated rubricconsistency diagnostics.
Practitioner reviewers. Human review used release records derived from public metadata. Three practitioner reviewers outside the author team completed blinded review tasks over predecessor/current release-path records and provided expert judgments for aggregate reporting; one reviewer completed an additional extension workbook. They were blinded to hidden labels, trigger families, model scores, and author decisions. The reviewers were not compensated. The public artifact contains no identities, contact metadata, or raw personal notes. Reported judgments are aggregated and not attributed to individuals. No institutional human-subjects determination was sought or obtained; the activity was treated as voluntary practitioner review over public package metadata and collected no private participant data. Identifying correspondence is omitted during anonymous review.
• Reproduction entry points: the README smoke test verifies the frozen counts 52,935/49,753/204. The queuesummary script regenerates the main workload tables; optional queue-compression scripts reproduce the secondary learned-ranking diagnostics. The bundle excludes live credentials, fresh recrawls, manuscript source, and exploratory runs outside the reported results. Some frozen files retain legacy schema names for checksum and script compatibility; the README maps those names to the policy-trigger and workflow-observability terminology used in the paper. No identifiable participant data, secrets, or private maintainer communications are included. Generative AI tools were used in two bounded ways. OpenAI Codex assisted with coding and manuscript maintenance tasks. OpenAI, Anthropic, and Gemini models were run as automated judges for the rubric-consistency diagnostic under the disclosed prompt and rubric. The judge identifiers recorded in the artifact are anthropic_claude_haiku_4_5, gemini_cli_flash_lite, and openai_gpt_4_1_mini; the run records include the prompt, rubric, model identifier, date, temperature, and decoding parameters used for each adjudication. Those outputs are included for reproducibility as automated rubric diagnostics; practitioner review and external evidence provide separate calibration layers. The authors reviewed the paper and artifact outputs and take responsibility for the submission.
Artifact users and the public. The artifact excludes credentials, private maintainer communications, non-public registry data, secrets, and live tokens. Legacy field names are mapped to the policy-trigger terminology used in the study. LLM-assisted judging is disclosed as an automated rubricconsistency stress test; practitioner review and external evidence remain separate calibration layers. Decision to publish. We publish the measurement, aggregate results, and reproduction materials because the data are public, the claims are bounded to review routing, and the artifact excludes private evidence and identifiable participant information. 14
References
[11] GH Archive. GH Archive. https://www.gharchive. org/, 2026. Accessed 2026-04-04.
[1] Axios Project. Post mortem: axios npm supply chain compromise. https://github.com/axios/axios/ issues/10636, 2026. Accessed 2026-06-12.
npm trusted publishing [12] GitHub Changelog. with OIDC is generally available. https : / / github . blog / changelog / 2025 - 07 - 31 - npm trusted-publishing-with-oidc-is-generallyavailable/, 2025. Accessed 2026-04-04.
[2] Ramaswamy Chandramouli, Frederick Kautz, and Santiago Torres-Arias. Strategies for the integration of software supply chain security in DevSecOps CI/CD pipelines. Technical report, National Institute of Standards and Technology, 2024.
[13] GitHub, Inc. Reminder for changes to npm replication feeds APIs. https://github.blog/changelog/ 2025 - 04 - 22 - reminder - for - changes - to - npm replication- feeds- apis/, 2025. Accessed 202604-04.
[3] Roberto Di Cosmo and Stefano Zacchiroli. Software heritage: Why and how to preserve software source code. In Proceedings of the 14th International Conference on Digital Preservation (iPRES 2017), pages 1–10, Kyoto, Japan, 2017.
[14] Jan-Ulrich Holtgrave, Kay Friedrich, Fabian Fischer, Nicolas Huaman, Niklas Busch, Jan H. Klemmer, Marcel 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 Security Symposium (NDSS). Internet Society, 2025.
[4] crates.io. Trusted publishing. https://crates.io/ docs/trusted- publishing, 2026. Accessed 202606-13. [5] Datadog Security Labs. LiteLLM and Telnyx compromised on PyPI: Tracing the TeamPCP supply chain campaign. https://securitylabs.datadoghq.com/ articles/litellm- compromised- pypi- teampcpsupply-chain-campaign/, 2026. Accessed 2026-0612.
[15] Nasif Imtiaz, Aniqa Khanom, and Laurie A. Williams. Open or sneaky? fast or slow? light or heavy?: Investigating security releases of open source packages. IEEE Transactions on Software Engineering, 49(4):1540– 1560, 2023.
[6] Datadog Security Labs. Malicious software packages dataset. https://github.com/DataDog/malicioussoftware-packages-dataset, 2026. Accessed 202606-13.
[16] 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.
[7] Alexandre Decan, Tom Mens, and Philippe Grosjean. An empirical comparison of dependency network evolution in seven software packaging ecosystems. Empirical Software Engineering, 24(1):381–416, 2019.
[17] 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 reputation metric systems in the open-source software supply chain. https://arxiv.org/abs/2505.18760, 2025. Preprint.
[8] Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan Elder, Brendan Saltaformaggio, and Wenke Lee. Towards measuring supply chain attacks on package managers for interpreted languages. In Network and Distributed System Security Symposium (NDSS), Virtual, 2021. Internet Society.
[18] Kelechi G. Kalu, Tanmay Singla, Chinenye Okafor, Santiago Torres-Arias, and James C. Davis. An industry interview study of software signing for supply chain security. In 34th USENIX Security Symposium (USENIX Security 25), pages 81–100, Seattle, WA, USA, 2025. USENIX Association.
[9] Ecma International. ECMA-427: Package URL. https: //ecma- international.org/publications- andstandards/standards/ecma-427/, 2025. Accessed 2026-04-04.
[19] Kelechi G. Kalu, Hieu Tran, Santiago Torres-Arias, Sooyeon Jeong, and James C. Davis. A longitudinal study of usability in identity-based software signing. https://arxiv.org/abs/2603.17133, 2026. Preprint.
[10] Kai Gao, Weiwei Xu, Wenhao Yang, and Minghui Zhou. PyRadar: Towards automatically retrieving and validating source code repository information for PyPI packages. Proceedings of the ACM on Software Engineering, 1(FSE):2608–2631, 2024.
[20] Riivo Kikas, Georgios Gousios, Marlon Dumas, and Dietmar Pfahl. Structure and evolution of package dependency networks. In 2017 IEEE/ACM 14th International 15
[30] Open Source Insights. deps.dev API v3alpha. https: //docs.deps.dev/api/v3alpha/, 2026. Accessed 2026-04-04.
Conference on Mining Software Repositories (MSR), pages 102–112, Buenos Aires, Argentina, 2017. IEEE. [21] Piergiorgio Ladisa, Henrik Plate, Matias Martinez, and Olivier Barais. SoK: Taxonomy of attacks on opensource software supply chains. In IEEE Symposium on Security and Privacy (SP), pages 1509–1526, San Francisco, CA, USA, 2023. IEEE.
[31] 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.
[22] Raphina Liu, Sofia Bobadilla, Benoit Baudry, and Martin Monperrus. Dirty-waters: Detecting software supply chain smells. In Companion Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering (FSE Companion ’25), pages 1045–1049, Trondheim, Norway, 2025. ACM.
[32] Open Source Security Foundation. Malicious packages. https://github.com/ossf/malicious-packages, 2026. Accessed 2026-06-13. [33] Orca Security. TanStack and 160+ npm/PyPI packages compromised in supply chain worm attack. https:// orca.security/resources/blog/tanstack- npmsupply-chain-worm/, 2026. Accessed 2026-06-21.
[23] Microsoft Threat Intelligence. Shai-Hulud 2.0: Guidance 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-0404.
[34] PostHog. Post-mortem of Shai-Hulud attack on November 24th, 2025. https://posthog.com/blog/nov24- shai- hulud- attack- post- mortem, 2025. Accessed 2026-06-12.
[24] Microsoft Threat Intelligence and Microsoft Defender Security Research Team. Mitigating the Axios npm supply 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.
[36] Python Packaging Authority. Integrity API. https: //docs.pypi.org/api/integrity/, 2026. Accessed 2026-04-04.
[35] Python Enhancement Proposals. PEP 740: Index support for digital attestations. https://peps.python. org/pep-0740/, 2024. Accessed 2026-04-04.
[37] Python Packaging Authority. PyPI publish attestation v1. https://docs.pypi.org/attestations/publish/ v1/, 2026. Accessed 2026-04-04.
[25] Zachary Newman, John Speed Meyers, and Santiago Torres-Arias. Sigstore: Software signing for everybody. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pages 2353– 2367, Los Angeles, CA, USA, 2022. ACM.
[38] Python Packaging Authority. Trusted publishers. https: / / docs . pypi . org / trusted - publishers/, 2026. Accessed 2026-04-04.
[26] npm, Inc. About ECDSA registry signatures. https:// docs.npmjs.com/about- registry- signatures/, 2026. Accessed 2026-04-04.
[39] Red Hat. Understanding Red Hat’s response to the XZ security incident. https://www.redhat.com/ en/blog/understanding-red-hats-response-xzsecurity-incident, 2024. Accessed 2026-04-04.
[27] npm, Inc. Generating provenance statements. https: / / docs . npmjs . com / generating - provenance statements/, 2026. Accessed 2026-04-04.
[40] RubyGems. Setting up multi-factor authentication. https : / / guides . rubygems . org / setting - up multifactor - authentication/, 2026. Accessed 2026-06-13.
[28] npm, Inc. Trusted publishers. https://docs.npmjs. com/trusted- publishers/, 2026. Accessed 202604-04.
[41] Taylor R. Schorlemmer, Ethan H. Burmane, Kelechi G. Kalu, Santiago Torres-Arias, and James C. Davis. Establishing provenance before coding: Traditional and next-generation software signing. IEEE Security & Privacy, 23(2):14–22, 2025.
[29] Marc Ohm, Henrik Plate, Arnold Sykosch, and Michael Meier. Backstabber’s knife collection: A review of open source software supply chain attacks. In Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA), pages 23–43, Cham, 2020. Springer International Publishing.
[42] 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, quality, and influencing factors. In 2024 IEEE Symposium on Security and Privacy (SP), pages 1160–1178. IEEE, 2024.
[53] Erik Wittern, Philippe Suter, and Shriram Rajagopalan. A look at the dynamics of the JavaScript package ecosystem. In Proceedings of the 13th International Conference on Mining Software Repositories, pages 351–361, Austin, TX, USA, 2016. ACM.
[43] SLSA Framework. SLSA specification v1.2. https: //slsa.dev/spec/v1.2/, 2025. Accessed 2026-0404.
[54] Nusrat Zahan, Parth Kanakiya, Brian Hambleton, Shohanuzzaman Shohan, and Laurie A. Williams. OpenSSF Scorecard: On the path toward ecosystemwide automated security metrics. IEEE Security & Privacy, 21(6):76–88, 2023.
[44] Software Heritage. Software heritage API documentation. https : / / docs . softwareheritage . org / devel/getting-started/api.html, 2026. Accessed 2026-04-04.
[55] Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel. Small world with high risks: A study of security threats in the npm ecosystem. In 28th USENIX Security Symposium (USENIX Security 19), pages 995–1010, Santa Clara, CA, USA, 2019. USENIX Association.
[45] The Go Project. Go module mirror, index, and checksum database. https://proxy.golang.org/, 2026. Accessed 2026-06-13. [46] The Go Project. Go modules reference. https://go. dev/ref/mod, 2026. Accessed 2026-06-13. [47] The Python Package Index Blog. PyPI now supports digital attestations. https : / / blog . pypi . org / posts / 2024 - 11 - 14 - pypi - now - supports digital-attestations/, 2024. Accessed 2026-0404.
A
Technical Appendix
This appendix keeps support material needed to read the main claims: cohort scope, audit effects, policy robustness, practitioner review, and external boundary checks. Row-level artifacts, full reports, judge outputs, and extended case material remain in the anonymous artifact.
[48] 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- supplychain-attack/, 2026. Accessed 2026-04-04. [49] The Rust Project. Publishing on crates.io. https : / / doc . rust - lang . org / cargo / reference / publishing.html, 2026. Accessed 2026-06-13.
A.1
[50] The Update Framework. TUF specification (latest). https://theupdateframework.github.io/ specification/latest/, 2026. Accessed 2026-0404.
Table 15 records the construction flow recoverable from the frozen snapshot and run manifests. Together with the temporal-semantics table, it separates the five-registry corpus from the Go boundary adapter and keeps reported rates scoped to the audited cohort.
[51] Santiago Torres-Arias, Hammad Afzali, Trishank Karthik Kuppusamy, Reza Curtmola, and Justin Cappos. in-toto: Providing farm-to-table guarantees for bits and bytes. In 28th USENIX Security Symposium (USENIX Security 19), pages 1393–1410, Santa Clara, CA, USA, 2019. USENIX Association.
Cohort and Evidence Semantics
Table 15: Cohort construction flow recoverable from the frozen snapshot and run manifests. Counts describe construction stages for the measured cohort. The final snapshot records cohort membership and run parameters; detailed per-package discovery-stage provenance is summarized rather than fully replayed.
[52] 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. Research directions in software supply chain security. ACM Transactions on Software Engineering and Methodology, 34(5):1–38, 2025.
Stage
Pkgs.
Audited npm/PyPI/Maven base Registry discovery extension Five-registry corpus Go boundary adapter
590 39,392 37,638 6,420
Elig. Trig. Role
5,462
179 External-evidence checks and original audited registry regimes.
25 crates.io and RubyGems discovery extension; RubyGems remains zero-trigger. 942 45,812 43,100 204 Main registry-mediated measurement and workload corpus. 159 7,123 6,653 N/A VCS/proxy/checksum-log adapter, outside the registrypublisher denominator. Combined portability co- 1,101 52,935 49,753 204 Combined reproducibility cohort and portability stress read. hort
17
352
Rel.
Table 16: Cohort characterization for the purposefully sampled, audited five-registry corpus. Package counts are coordinates with at least one eligible predecessor comparison after warm-up; the full audited corpus has 942 ecosystem-package coordinates. Values describe the measured cohort.
Table 21: Practitioner disposition by trigger family and ecosystem. Rows group the 60 trigger rows from the review workbook. Core rows use majority vote; extension rows use one practitioner. The balanced workbook makes these rows descriptive of disposition patterns.
Ecosystem Packages Eligible Median rel./pkg Median age days Median cadence days Median dep. indegree Project key known npm PyPI Maven crates.io RubyGems
A.2
75 399 101 135 131
3,196 26,710 7,732 1,739 3,723
45.0 81.0 93.0 6.0 26.0
95 35 48 382 326
2.3 0.6 0.6 22.2 12.7
0.0 0.0 1.0 0.0 0.0
Grouping
100.0% 88.8% 100.0% 98.7% 95.9%
Group
Rows Now Monitor No
Family authority/workflow Family provenance/mediation Family signing Ecosystem Maven Ecosystem PyPI Ecosystem npm
Audit and Policy Construction
29 7 24 6 27 27
20 7 18 0 24 21
9 0 0 0 3 6
0 0 6 6 0 0
The audit tables document corrections that change the measured control plane. Table 17 gives package-edge and rewiring effects that complement the release-row counts in Table 6; Table 18 lists recurring failure modes and policy effects. Together they support registry-first stitching and policy-trigger reproducibility.
rule result. Table 19 applies the retrospective regime threshold around the 18-month cutoff. Table 22 summarizes what each evidence layer supports and where its claim boundary lies. The automated rubric-consistency diagnostic uses three model judges on the 373-release stratified sample; full outputs remain in the artifact.
Table 17: Graph and policy-trigger delta induced by the current correction ledger. Counts are unique package-level edges and rewiring effects, complementing the materialized releaselevel link counts in the main audit table. The row-level audit findings collapse to one concentrated stitching error and one unique false policy-triggering release.
Table 19: Temporal application and workload drift of the regime-specific threshold. The same descriptive rule is applied before and after the 18-month cutoff; coverage is measured against the policy trigger, while queue volume, trigger prevalence, and yield vary across time. Window
Quantity
Before After
Unique package→repo edges Release rows rewired to canonical repo Placeholder repo degree Repo nodes with changed degree
618 22
Policy triggers
180
First-seen triggers
85
14 0
∆ Interpretation
617 -1 One spurious package→repo edge disappears after audit. 36 +14 authentik-client rows move from placeholder linkage onto the canonical repo. 0 -14 The placeholder repo node vanishes from the measured graph. 2 +2 Two repo nodes change centrality: the placeholder disappears and the canonical repo absorbs the rewired releases. 179 -1 One false policy-triggering release disappears after the transitionlabel correction. 84 -1 The label correction affects the same trigger family that dominates broad transition detection.
Error pattern
Repo-link audit
Placeholder GitHub repo accepted as canonical source
Rows Unique releases Example 14
Policy-trigger audit Parser-induced false firstseen authority transition
3
68/68 81.9% 136/136 53.5% 204/204 60.5%
Semantic co-change motif authority+workflow/prov+signing authority+repo+workflow/prov+signing authority+workflow/prov signing authority+signing authority+repo+workflow/prov Other
Measured consequence
14 git _ user _ id / False source attribution git_repo_id and false continuity until corrected to goauthentik / client python. 1 npm : Spurious policy trigger prettier@4 . and inflated first-seen trig0.0- alpha.13 ger prevalence in an otherwise stable release path.
A.4 The automatic signal is policy_trigger. Human disposition and external security outcomes are separate layers; legacy artifact names are retained only for compatibility.
A.3
Queue/share Captured Yield Coverage 100.0% 100.0% 100.0%
Table 20: Most common semantic co-change motifs among policy-triggering releases. Correlated fields often move together, so semantic-family distance is reported beside raw field distance.
Table 18: Audit errors cluster in a small number of systematic error patterns. Counts report audited rows; repeated audited rows can collapse to the same corrected release. Artifact
Triggers/eligible
First 18 months 68/5,332 (1.3%) 83 (1.6%) Post-cutoff months 136/37,768 (0.4%) 254 (0.7%) Full corpus 204/43,100 (0.5%) 337 (0.8%)
Triggers
Share
131 31 22 14 3 2 1
64.2% 15.2% 10.8% 6.9% 1.5% 1.0% 0.5%
External Boundary Checks
External outcomes are checked after policy-trigger construction. In the external-evidence subset, 179 policy triggers reduce to 137 outcome-eligible triggers after requiring npm/PyPI/Maven coverage, exact version-level outcomes, warm-up eligibility, and a matched control by ecosystem, observability bin, dependency quintile, and nearest publication time. The matched outcome table has zero exact registry actions and zero exact OSV/GHSA advisories among policy
Robustness and Calibration
The main sensitivity table checks whether correlated fields or retrospective repository/SCM evidence drive the distance18
Table 22: Reviewer-facing interpretation of each evidence layer. The study separates review-queue performance from external security evidence and states the claim boundary for each layer. Evidence layer
What is measured
Policy-trigger recovery
Automated release-path policy trigger
Overlap stress tests
Supported
Recovery and prioritization of measured control-plane discontinuities Held-out families, masking, orthogonal context, Queue compression after a policy queue is matched-trigger queues open
External incident benchmark
Exact incident versions and same-package windowed signals External malicious-package OpenSSF/OSV MAL records, Datadog manifests, corpus live recovery checks External registry/advisory npm deprecations, PyPI yanks, OSV/GHSA advioutcomes sories, controls, placebos Practitioner review Three-reviewer shared core plus single-reviewer extension Trigger-blinded author rubric Balanced blinded sample and trigger-blinded auchecks thor workbook Automated rubric diagnostic Anonymized and realistic model adjudication with label and score blinding
Absent versions, nearby authority signals, same-path reuse Snapshot observability limits and partial samepackage alignment Sparse support-limited registry actions; advisory mismatch Human disposition, core agreement, severity downgrades Release-time queue semantics and low-severity boundary cases Rubric interpretability and severity-boundary stress
triggers. Full registry-action, advisory, incident-alignment, and malicious-corpus joins remain in the artifact. Case anchors follow in Appendix B.
B.2
B
Malicious-release identification Full structural independence from release-path context Complete incidentdetection benchmark Complete compromisedetection benchmark Malicious-release detection accuracy Maliciousness assessment and natural-rate prevalence Practitioner-review validation Supplementary reproducibility check
Workflow-Rich Anchors
The npm and PyPI cases illustrate workflow and provenance evidence. [email protected], the first row of Figure 3, moves from workflow-not-observed publication to a GitHub workflow and adds SLSA provenance plus Sigstore-backed signing. This is a high-signal release-path transition near a public incident window; the exact malicious axios versions are absent from the frozen cohort. The row therefore demonstrates the distinction used throughout the paper: release-path changes are review cues over public control-plane evidence, while payload-level compromise and exact incident attribution require separate data. [email protected], the second row, shows the related PyPI pattern. The predecessor uses a lower-observability path. The observed release uses a GitHub workflow, PyPI publish attestation, and Sigstore signing. The repository evidence also moves from the package repository to a release repository, so the review reason is both workflow novelty and unresolved repository continuity. truss and pnpm repeat the motif: stable releases use an attested path, while release candidates, alpha builds, or workflow-not-observed fallbacks move onto a lowerobservability path. These examples also explain why workflow, provenance, signing, and mediation often co-change. The raw field distance counts each changed field, while the semantic-family sensitivity treats the publication-path migration as a smaller number of related changes.
Case Anchors
This section grounds the aggregate evidence in local release records. Figure 3 gives one anchor per regime. The cases serve as local record-level anchors; they make the measurement boundary concrete by showing which predecessor fields change, which fields stay stable, and where the record deliberately leaves an interpretation unresolved.
B.1
Claim boundary
Measurement-Boundary Cases
authentik-client and numpy illustrate the audit boundary. In authentik-client, a placeholder repository stitch changed the inferred repository, continuity state, and releasepath interpretation. The correction moves 14 release rows to the canonical repository and removes the false transitions induced by the bad stitch. Appendix Table 17 shows the aggregate effect. The case is useful because the error is small in row count but material in interpretation: a wrong repository edge rewrites source attribution, then downstream predecessor comparison treats the bad stitch as an authority event. This makes the correction ledger part of the measured controlplane result. numpy marks a different boundary. The source repository and the release-engineering repository can both be relevant, so the record keeps repository continuity unresolved instead of forcing a binary match. This is a conservative choice: the release record still captures the observable path, but the policy avoids converting an ambiguous source/release split into a confident repository discontinuity.
B.3
Regime-Specific Anchors
The remaining rows cover regimes with different visible authority evidence. The Maven row uses org.apache.maven:[email protected] to show signingcentered evidence: in Maven’s workflow-sparse regime,
19
Previous: workflow not observed; no provenance; ECDSA signing
Observed: GitHub workflow; SLSA provenance; Sigstore + ECDSA
Interpretation: workflow, provenance, signing, and mediation change.
PyPI [email protected]
Previous: workflow not observed; no attestation; package repo
Observed: GitHub workflow; PyPI attestation; release repo
Interpretation: workflow novelty plus unresolved repo continuity.
Maven org.apache.maven: [email protected]
Previous: stable namespace and SCM; no workflow field
Observed: stable namespace and SCM; signing key changes
Interpretation: signing-key movement is the visible Maven authority event.
crates.io [email protected]
Previous: publisher briansmith; repo briansmith/ring
Observed: publisher ctz; repo ctz/ring
Interpretation: publisher and repo move together; checksum visible.
RubyGems [email protected]
Previous: stable author; repo shopify/bootsnap
Observed: stable author; repo rails/bootsnap
Interpretation: repository relink is visible; conservative policy assigns no corpus trigger.
Go x/[email protected]
Previous: VCS origin; module proxy; checksum log
Observed: same VCS origin; proxy; checksum log
Interpretation: VCS/proxy/checksum comparison is possible; no registry-publisher policy trigger.
Figure 3: Case anchors from predecessor comparison to interpretation. Each row uses the same structure: previous release-path evidence, observed release-path evidence, and the changed or regime-specific authority evidence. RubyGems and Go are boundary examples under the conservative policy definition. the visible event is signing-key movement under stable namespace and SCM evidence. This has different semantics from an npm Trusted Publishing transition. It is the Maven-visible authority evidence available to a release-level replay, and practitioner dispositions in the review workbook treat stable-namespace signing-only cases as lower-severity context below the immediate-review tier. [email protected] changes both publisher and repository from briansmith/briansmith/ring to ctz/ctz/ring, while checksum and mediation remain comparable. This row is the clearest registry-mediated identity change among the non-npm examples: publisher identity and repository continuity move together, so the case uses owner and repository fields available in that regime. [email protected] shows the narrower RubyGems evidence: repository evidence moves from shopify/bootsnap
to rails/bootsnap, but the conservative policy assigns no RubyGems triggers because release-account history is limited. golang.org/x/[email protected] illustrates the Go boundary adapter over VCS origin, module proxy, and checksum-log evidence, outside registry-publisher policy-trigger assignment. Together, these two rows keep the portability claim bounded. RubyGems remains inside the five-registry corpus but has zero triggers under the conservative policy-trigger definition; Go is reported as a boundary adapter with different trigger semantics from a registry-publisher regime. axios, LiteLLM/Telnyx, PostHog, and Shai-Hulud define the observation boundary: absent versions, same-path malicious releases, and partial snapshots require evidence beyond the policy-trigger surface. Release-path changes open review; payload analysis, registry-private evidence, and incident attribution come from separate sources.
20