Review Package: Authority Measurement in Ecosystems

• Review Package is a framework that analyzes release-authority by comparing consecutive releases to identify public control-plane discontinuities.
• It quantifies changes using metrics like release-path distance and observability score to measure shifts in publisher, repository, and workflow evidence.
• The framework offers actionable insights for maintainers, registry operators, and reviewers by flagging publication cues without directly inferring compromise.

Searching arXiv for the primary paper and closely related package-ecosystem security literature. Release-authority measurement is a package-ecosystem analysis framework that asks not only what code can propagate through dependency graphs, but also who published a release and through what public path. In this formulation, a package release is evaluated against its immediate predecessor to detect typed changes in the public publication control plane, including publisher, repository, workflow, provenance, signing, and mediation evidence. The central claim is not that such changes prove compromise, but that they constitute review cues that can define an auditable candidate-review queue for package security review in registry-mediated ecosystems (Santos-Grueiro, 21 Jun 2026).

1. Conceptual basis

Dependency graphs show where released code can flow, but they leave implicit whether the public path used to publish a release changed. Release-authority measurement addresses that omission by shifting attention from dependency structure to publication control. Its core object is the release path: the public evidence of how a package version was published, by whom, and with what workflow, provenance, signing, repository linkage, and registry mediation (Santos-Grueiro, 21 Jun 2026).

This emphasis differs from package-ecosystem analyses centered on dependency topology alone. Package-ecosystem mining has long treated dependency and update information, release histories, and registry metadata as primary research data, while also warning that ecosystems are versioned, dynamic, heterogeneous, and incomplete (Kula et al., 2023). Release-authority measurement narrows that broader observational surface to predecessor-to-successor transitions in publication authority. It therefore treats a release as a control-plane event rather than only as a node in a dependency graph.

The approach is also distinct from compromise attribution. The measured object is a public release-path discontinuity, not malicious payload behavior, exploitability, or provenance-ground-truth compromise. This distinction is central: the framework defines a review surface over public authority evidence, not a detector of malicious versions (Santos-Grueiro, 21 Jun 2026).

2. Predecessor-aware release-authority record

The framework introduces a predecessor-aware release-authority record for each release $package@v$, defined by comparison with the immediate predecessor $package@v-1$. The record captures typed field changes over public evidence about publisher or releaser or owner, namespace, source repository, workflow identity, provenance or attestation state, signing or integrity state, and mediation type (Santos-Grueiro, 21 Jun 2026).

Two formal notions organize this comparison. A transition is a field-level difference from the immediate predecessor. Release-path distance is the count of mismatched release-path fields relative to the previous release, computed over publisher, workflow, repository, provenance state, signing state, and mediation type. The paper states explicitly that

$d \in \{0,1,2,3,4,5,6\}.$

A distance of $0$ denotes no measured path change across those fields, while larger values indicate broader discontinuity (Santos-Grueiro, 21 Jun 2026).

The paper also defines an observability score as the sum of four public signals: known project key, workflow present, provenance present, and signing present. Accordingly,

$\text{observability score} \in [0,4].$

This score summarizes how much public evidence is available for evaluating a release path, rather than whether the release is trustworthy or compromised (Santos-Grueiro, 21 Jun 2026).

Operationally, the comparison is predecessor-aware and warm-up constrained. A three-release warm-up is used so that a package’s first observed releases are not treated as authority transitions. The study also reports a trailing 180-day authority-reach window in which authority reach sums reverse-dependency reach over packages published by the current principal during the previous 180 days. This indicates that the framework is designed not only to count discontinuities but also to situate them within a recent publisher-centered exposure surface (Santos-Grueiro, 21 Jun 2026).

3. Ecosystems, cohort design, and authority regimes

The main audited cohort covers five registry-mediated ecosystems: npm, PyPI, Maven Central, crates.io, and RubyGems. Its observation window runs from April 6, 2024 to June 13, 2026, and includes 45,812 releases, 43,100 eligible predecessor comparisons, 942 ecosystem-package coordinates, and 204 policy-triggering transitions (Santos-Grueiro, 21 Jun 2026).

Go is treated separately as a boundary adapter rather than as part of the registry-publisher denominator. The reason is that its public authority path is not registry-publisher centered; it instead uses VCS origin, module proxy, and checksum database or checksum log. The Go portability or boundary-adapter cohort contains 7,123 releases and 6,653 eligible comparisons. With Go included only as a separate portability cohort, the combined totals become 52,935 releases, 49,753 eligible comparisons, and 204 triggers (Santos-Grueiro, 21 Jun 2026).

This regime distinction matters because package ecosystems expose different public authority signals. The literature on mining software package ecosystem data has already emphasized that package managers do not always define real ecosystem boundaries, that dependency structures differ across registries, and that generalization across languages and ecosystems is nontrivial (Kula et al., 2023). Release-authority measurement adopts that lesson directly: npm, PyPI, Maven, crates.io, RubyGems, and Go are treated as different authority regimes rather than as interchangeable metadata surfaces (Santos-Grueiro, 21 Jun 2026).

The package-manager threat literature provides a complementary context. Package managers mediate resolution, fetching, verification, installation, and acknowledgement, and attacks can occur at each of those stages, including dependency confusion, lockfile tampering, misconfigured integrity checks, man-in-the-middle substitution, and command injection (Bos, 2023). Release-authority measurement does not replace such lifecycle-based threat analysis. Instead, it isolates a narrower question: whether the public release path itself changed between adjacent releases (Santos-Grueiro, 21 Jun 2026).

4. Policy-triggering discontinuities and candidate-review queues

The framework compares each observed release to the prior release of the same package and flags releases with public control-plane discontinuities. After the stable three-release warm-up, the transparent policy trigger is assigned 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 workflow-observability mediation change (Santos-Grueiro, 21 Jun 2026).

These events are the paper’s policy-triggering public release-path discontinuities. The exact policy-triggering rule is designated as the primary candidate queue, yielding 204 policy-triggering releases in the main audited cohort. The policy is transparent and release-path based, and human review is downstream of that queue (Santos-Grueiro, 21 Jun 2026).

The paper also evaluates simpler proxy regimes. A uniform semantic-distance rule with $s \ge 2$ selects 320 releases, covers 190/204 triggers, achieves 93.1% policy coverage, and 99.9% of trigger authority reach. A descriptive regime-specific distance rule uses $d \ge 1$ for Maven and $d \ge 2$ for npm, PyPI, and crates.io; it selects 337 releases, covers all 204 triggers, and achieves 100% coverage and 100% trigger authority reach. A broader baseline of any path change with $d \ge 1$ selects 2,949 releases and also covers all 204 triggers, but with much larger workload (Santos-Grueiro, 21 Jun 2026).

These selection regimes turn a typed release-difference record into an operational queue design problem. This suggests a staged review architecture: exact triggers define the primary queue, while distance rules offer simpler or more portable surrogates when a registry-specific policy is unavailable. The paper’s practical guidance is aligned with that reading: use the exact trigger policy as the first-pass queue opener, and use distance-based rules when a simpler or portable proxy is needed (Santos-Grueiro, 21 Jun 2026).

5. Evaluation and interpretive status of the signals

The paper reports a blinded practitioner review built around a 60-row shared core comprising 30 hidden policy-triggering transitions and 30 matched or boundary controls. Reviewers were blinded to stored triggers, trigger families, reason codes, model scores, release-path distance, and author decisions (Santos-Grueiro, 21 Jun 2026).

The resulting judgments were sharply asymmetric. For the 30 triggers, three practitioners rated 20 as review_now, 9 as monitor, and 1 as no_review. For the 30 controls, all 30 were rated no_review, with 0 assigned to review_now and 0 to monitor. Agreement metrics were reported as mean exact pairwise agreement of 0.800 and Fleiss’ kappa of 0.666 (Santos-Grueiro, 21 Jun 2026).

These findings support the paper’s interpretive claim that release-authority signals are useful review cues. The evidence does not support a stronger compromise interpretation. The paper is explicit that the signals are cues, not proof, and that human review remains the mechanism that converts a public discontinuity into any stronger security conclusion (Santos-Grueiro, 21 Jun 2026).

The broader literature on trust reinforcement in package ecosystems helps situate this result. That literature emphasizes that many npm security tools operate post-installation, that warning effectiveness is often poor, and that trust is frequently inferred from indirect signals such as popularity, maintenance, documentation, downloads, and stars rather than from direct security assurance (Temelko et al., 2024). Release-authority measurement differs by using typed public publication evidence as the signal substrate. It still produces a queue rather than a verdict, but it moves trust assessment toward concrete release-path change rather than reputational proxy (Santos-Grueiro, 21 Jun 2026).

6. Coverage boundaries, failure modes, and relation to supply-chain risk

A central empirical finding is that exact malicious versions in the paper’s external alignment had zero overlap with the policy triggers. The paper uses this result to reinforce its scope claim: policy triggers are review cues based on public release-path evidence, not proof of compromise (Santos-Grueiro, 21 Jun 2026).

The stated limitations are specific. Same-path compromise, unchanged compromised CI, and versions absent from public snapshots require separate evidence beyond the release-authority record. The model uses public registry or provenance evidence and limited archival backfill. Deleted or absent versions may not appear in the frozen corpus. If an attack does not change public release authority, the method may not detect it. Registry regime differences are material, and Go is outside the registry-publisher regime (Santos-Grueiro, 21 Jun 2026).

Those limits are consistent with the package-manager attack literature. Resolution attacks such as dependency confusion, parsing ambiguities such as lockfile tampering, verification failures, and command injection can subvert trust without necessarily producing the specific public authority discontinuities captured by predecessor-aware release records (Bos, 2023). Likewise, package-ecosystem mining research has emphasized snapshot effects, sampling problems, and temporal change as recurrent threats to valid interpretation (Kula et al., 2023). Release-authority measurement makes those constraints explicit rather than treating the observed surface as exhaustive (Santos-Grueiro, 21 Jun 2026).

A common misconception is therefore that a release-path discontinuity is equivalent to a compromise claim. The paper rejects that equation directly. Another misconception is the converse: that zero trigger overlap with exact malicious versions invalidates the method. The paper instead argues that the method measures a different surface. Malicious versions may be absent from the frozen snapshot, may reuse the same visible release path, or may require payload-level or private evidence outside the release-authority record (Santos-Grueiro, 21 Jun 2026).

7. Practical significance for maintainers, registries, and reviewers

For package maintainers, the paper treats publication-path changes as security-sensitive events. It recommends documenting or justifying changes in publisher or releaser identity, CI workflow, provenance or attestation, signing identity, and repository linkage. Stable packaging practices are presented as a way to reduce false alarms and improve reviewer trust (Santos-Grueiro, 21 Jun 2026).

For registry operators, the practical implication is that better provenance, trusted publishing, signing support, public APIs, and consistent metadata make the review surface cleaner. The paper further states that registry-side evidence should remain the first-class source when conflicts arise. This suggests that release-authority measurement is most effective where registry metadata is rich, stable, and publicly queryable (Santos-Grueiro, 21 Jun 2026).

For security reviewers, the recommended workflow is triage rather than automatic adjudication. The exact trigger policy is the first-pass queue opener; distance-based rules serve as simpler proxies; and outputs should be treated as review-now, monitor, or no-review candidates rather than compromise findings. The paper specifically recommends immediate attention to provenance loss, publisher or releaser discontinuity, repository relinking, signing changes, and workflow novelty or downgrade (Santos-Grueiro, 21 Jun 2026).

Within the larger research landscape, release-authority measurement occupies a specific niche. Package-ecosystem mining studies focus on dependencies, updates, and ecosystem structure (Kula et al., 2023); package-manager threat reviews classify attacks across resolution, fetching, verification, installation, and acknowledgement (Bos, 2023); trust-tool reviews emphasize warnings, scanners, and package-selection signals in ecosystems such as npm (Temelko et al., 2024). Release-authority measurement adds a predecessor-aware, publication-control-plane view that is auditable, typed, and explicitly scoped to public release-path discontinuities (Santos-Grueiro, 21 Jun 2026).