Pith. sign in

REVIEW 3 major objections 7 minor 29 references

Multiplying code risk by ecosystem reach exposes invisible supply-chain threats

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · glm-5.2

2026-07-08 21:15 UTC pith:5GTRY5PJ

load-bearing objection Good idea, honest prototype, but the evaluation tests the wrong capability — the central claim is unevaluated. the 3 major comments →

arxiv 2607.05894 v1 pith:5GTRY5PJ submitted 2026-07-07 cs.SE cs.CR

Hidden Amplifiers: Cross-Level Risk in Software Supply Chains

Rakesh Podder , Rafael Fabian Gonzalez Arellano , Indrajit Ray This is my paper
classification cs.SE cs.CR
keywords analysisriskcodecross-levelpackagessoftwareamplifierschains
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper argues that software supply-chain security has a structural blind spot: existing tools either inspect code inside a package or map dependency networks across an ecosystem, but never both at once. This separation means that tiny packages sitting at the center of massive dependency networks—packages with fewer than 50 methods but more than 50,000 dependents—carry enormous systemic risk that no current tool can surface. The authors call these 'hidden amplifiers.' To find them, the paper introduces a multiplicative formula called Cross-Level Risk (CLR), which takes a method's internal code complexity (cyclomatic complexity, betweenness centrality, blast radius, and commit churn) and multiplies it by a logarithmically compressed count of how many projects transitively depend on the method's package. The multiplication is deliberate: a complex function nobody uses is harmless, and a trivial function in an isolated package is harmless—only when both dimensions are elevated does a method become a genuine supply-chain threat. Evaluated on 50 npm and PyPI packages, the framework identifies 12 hidden amplifiers and produces cross-package method rankings that no single-level tool can generate. A retrospective test on the package 'ms'—which had a ReDoS vulnerability discovered in 2017—shows the framework would have flagged it as high-risk based on structure alone, before any advisory existed.

Core claim

The central object is the hidden amplifier: a micro-dependency with trivially simple internal code but extreme ecosystem reach (e.g., 3 methods, 1.19 million dependents). The paper shows these packages form a structurally distinct class—visible as a cluster in the bottom-right quadrant of a method-count-versus-fan-in plot—that is invisible to every existing Software Composition Analysis tool, code-quality analyzer, and ecosystem-level dependency mapper. The mechanism that reveals them is the multiplicative composition of code-level risk and ecosystem exposure into a single CLR score, which enables cross-package method comparison for the first time.

What carries the argument

CLR(m) = φ(m) · f(ψ(pkg(m))), where φ(m) = c(m)·b(m)·r(m)·τ(m) combines cyclomatic complexity, betweenness centrality, blast radius, and commit churn into a per-method code-level risk score, and f(ψ(pkg(m))) = log₁₀(fan-in + 1) compresses ecosystem-wide transitive reverse-dependency counts. A three-layer architecture resolves dependencies (Layer 1), builds static call graphs and computes φ (Layer 2), and synthesizes both into cross-package rankings (Layer 3). An internal resolution rate R = resolved_call_sites / total_call_sites gates confidence in the static analysis.

Load-bearing premise

The formula multiplies code-level risk by ecosystem exposure, which means that if either factor is near zero, the total risk is near zero. This assumes risk requires both complex code and wide reach—but it cannot capture the scenario where a trivially simple one-line function in a massively depended-upon package is itself the systemic risk, because the code-complexity factor drives the product to zero.

What would settle it

If hidden amplifiers (packages with <50 methods and >50K dependents) do not disproportionately appear in future supply-chain attacks or vulnerability discoveries relative to their population size, the structural-risk claim weakens. Conversely, if a large-scale longitudinal study shows that high-CLR methods are no more likely to host vulnerabilities than low-CLR methods, the framework's predictive value would be undermined.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Security teams could audit hidden amplifiers proactively—before any CVE is filed—by ranking methods across their entire dependency tree on a single comparable scale.
  • Registry operators or SBOM platforms could integrate cross-level scoring to flag structurally critical micro-dependencies for enhanced scrutiny or maintainer-account protection.
  • The resolution rate metric R gives practitioners a transparent confidence signal for static analysis results, addressing a gap in current tools that report scores without indicating analysis reliability.
  • The framework's cross-package ranking capability could enable triage dashboards that prioritize which specific functions in which dependencies to audit first, rather than alerting on entire packages indiscriminately.

Where Pith is reading between the lines

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

  • The multiplicative model structurally cannot represent the risk of a one-line package that is a single point of failure for an entire ecosystem—any function with low code complexity scores near zero regardless of fan-in. An additive or max-based composition might capture this 'low complexity, extreme exposure' failure mode that the authors themselves acknowledge.
  • The 24% hidden-amplifier rate reflects a corpus biased toward high-fan-in packages; a random registry sample would likely show a much lower rate, and the practical impact of cross-level analysis depends on how many hidden amplifiers exist in typical real-world dependency trees.
  • The patch-mining precision of 84% and the 70% of packages achieving R ≥ 0.85 suggest the pipeline's reliability varies substantially by language and code style; dynamic-dispatch-heavy packages in the long tail may require complementary runtime analysis to produce trustworthy rankings.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 7 minor

Summary. The paper introduces 'cross-level risk propagation' (CLR), a framework that combines method-level code metrics (cyclomatic complexity, betweenness centrality, blast radius, churn) with ecosystem-level fan-in into a single multiplicative risk score for software supply chain dependencies. The authors define a 'hidden amplifier' class of packages (fewer than 50 methods, over 50,000 dependents) and identify 12 such packages in a curated 50-package corpus from npm and PyPI. A retrospective analysis of the `ms` package (CVE-2015-8315) is used to illustrate that CLR could have flagged the package pre-advisory. The evaluation compares CLR against code-only (CR) and fan-in-only (FI) baselines using Precision@K across 10 CVE-bearing root packages, and assesses static analysis reliability via an internal resolution rate metric. A 16,000-LOC prototype is publicly available.

Significance. The paper addresses a genuine gap in supply-chain security: the separation between ecosystem-level dependency analysis and code-level static analysis. The identification of 'hidden amplifiers' as a structural class is a compelling conceptual contribution. The authors provide a publicly available, reproducible prototype (16,000 LOC) and a replication package, which is a significant strength. The internal resolution rate metric for call-graph confidence is a useful transparency mechanism. However, the central empirical claim—that CLR improves vulnerability prioritization—is not adequately validated by the evaluation design, as the metric used (per-root Precision@K) structurally cannot test CLR's distinguishing cross-package capability.

major comments (3)
  1. §IV.B, Table III: The central claim that CLR 'substantially improves prioritization precision' (Abstract, Contribution 3) is not supported by the evaluation. Table III shows CR (code-only) matches or exceeds CLR at every K (P@3: 0.50 vs 0.43; P@5: 0.44 vs 0.44; P@10: 0.42 vs 0.38). The paper acknowledges this, arguing CLR's value is cross-dependency ranking, but then states this capability is left unevaluated: 'Evaluating whether this re-ordering correlates with actual vulnerability outcomes requires a larger corpus' (§IV.B). The abstract's claim of improvement is technically supported only relative to fan-in-only (FI), the weakest baseline. The unique contribution of CLR is simultaneously claimed as the main benefit and left unvalidated against ground truth. The abstract and Contribution 3 should be revised to accurately reflect what was and was not demonstrated.
  2. §IV.A, Retrospective validation: The `ms` retrospective is presented as validation of the hidden-amplifier concept, but it is a projection rather than a demonstrated result. The paper uses an estimated 2017 fan-in (~73K, proportionally scaled from current numbers) rather than actual historical data, and asserts without running the framework that `ms` would rank 'in the top 10 methods' across any dependency tree containing it. The proportional scaling assumption (current fan-in × ratio of registry sizes) is unvalidated—npm's growth has not been uniform across packages. This case study would be strengthened by actually running the framework on a dependency tree containing `ms` with the estimated parameters, or by framing it more cautiously as a hypothetical illustration rather than a validation.
  3. §II.B, Eq. (2): The multiplicative composition CLR(m) = φ(m) · f(ψ(pkg(m))) structurally assigns zero risk when either dimension is absent. The paper justifies this qualitatively ('A complex function in a package with zero dependents poses no supply-chain risk') but does not validate it against data or attack outcomes. This modeling choice is load-bearing: it means a one-line package that is a single point of failure for an entire ecosystem receives a low score if its single method has low complexity. The paper notes this limitation briefly ('methods with zero betweenness but high complexity may be underweighted') but does not address the converse scenario where low code complexity combined with extreme exposure is itself the risk. An ablation against an additive alternative, or at least a discussion of this specific failure mode, would strengthen the justification.
minor comments (7)
  1. §II.B, Eq. (1): The temporal factor τ(m) = max(log₂(1 + churn), 1) uses a floor of 1, but the rationale for this specific floor value is not explained. A brief justification would help readers understand this design choice.
  2. §III, Layer 3: The bottleneck score (in-degree × out-degree) and the default N=20 selection are introduced without justification or sensitivity analysis. How sensitive are the final CLR rankings to the choice of N?
  3. Table I: The CLR values appear inconsistent with the formula. For readStream(), CR=8.33 and FI=63,898, giving CLR=8.33 × log₁₀(63,899) ≈ 8.33 × 4.805 ≈ 40.0, which checks out. But for compile(), CR=3.93 and FI=261,831, giving CLR=3.93 × log₁₀(261,832) ≈ 3.93 × 5.418 ≈ 21.3, which also checks out. However, next() in router has CR=4.48 and FI=57,674, giving CLR=4.48 × log₁₀(57,675) ≈ 4.48 × 4.761 ≈ 21.3, which matches. The values are correct but the table caption should clarify that CLR = CR × log₁₀(FI + 1) for transparency.
  4. §IV.C: The patch mining results (69% yield, 84% precision) are reported without explaining the methodology in sufficient detail. How were the 45 advisories selected? What constituted a precision error? A brief expansion would improve reproducibility.
  5. Figure 2: The axis labels show '100 101 102 103 102 104 106' which appears garbled. The y-axis should likely show fan-in values in scientific or log scale with clearer labels.
  6. §V, Discussion: The note that 'CVE-affected functions do not cluster in the top-20 (function-level P@5 = 0.029)' is an important negative result that deserves more prominence and discussion, as it suggests the top-N bottleneck selection may be filtering out exactly the methods of interest.
  7. Table IV: The 'Reach.' column marks Eclipse Steady with '✓*' and a footnote about dynamic reachability, but the 'Cross' column marks it with '—'. It would help to clarify whether 'Cross' means cross-level (code + ecosystem) or cross-package, as Steady does perform some cross-package analysis within Java applications.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for a careful and constructive review. The referee correctly identifies that our central empirical claim is overstated relative to what Table III demonstrates, that the ms retrospective relies on an unvalidated scaling assumption, and that the multiplicative composition has a failure mode we have not adequately addressed. We agree with all three major comments and will revise accordingly. The core conceptual contribution—identifying hidden amplifiers as a structural class and providing a working cross-level framework—remains valid, but the framing of our empirical claims must be brought into alignment with what the data actually show.

read point-by-point responses

  1. Referee: §IV.B, Table III: The central claim that CLR 'substantially improves prioritization precision' (Abstract, Contribution 3) is not supported by the evaluation. Table III shows CR (code-only) matches or exceeds CLR at every K. The abstract's claim of improvement is technically supported only relative to fan-in-only (FI). The unique contribution of CLR is simultaneously claimed as the main benefit and left unvalidated against ground truth. The abstract and Contribution 3 should be revised to accurately reflect what was and was not demonstrated.

    Authors: The referee is correct on all counts. Table III shows that CR matches or exceeds CLR on per-root Precision@K at every K value (P@3: 0.50 vs 0.43; P@5: 0.44 vs 0.44; P@10: 0.42 vs 0.38). Our abstract and Contribution 3 claim that CLR 'substantially improves prioritization precision,' but this is supported only relative to the fan-in-only baseline (FI: P@3=0.20, P@5=0.20, P@10=0.23), which is the weakest comparator. The claim is not supported against the code-only baseline. Furthermore, the unique capability of CLR—cross-package ranking—is acknowledged in the paper as unevaluated against ground truth ('Evaluating whether this re-ordering correlates with actual vulnerability outcomes requires a larger corpus,' §IV.B). This is a genuine gap between our claims and our evidence. We will revise the abstract, Contribution 3, and the conclusion to accurately state that: (1) code-aware metrics (both CLR and CR) improve prioritization over ecosystem-only analysis (FI); (2) CLR's distinguishing capability is cross-package ranking, which CR cannot perform; and (3) validation of CLR's cross-package ranking against vulnerability outcomes is left to future work with a larger corpus. We will remove the word 'substantially' from the prioritization claim and reframe Contribution 3 as a feasibility demonstration rather than a validated improvement. revision: yes

  2. Referee: §IV.A, Retrospective validation: The ms retrospective is presented as validation but uses an estimated 2017 fan-in (~73K, proportionally scaled from current numbers) rather than actual historical data. The proportional scaling assumption is unvalidated. The case study would be strengthened by actually running the framework on a dependency tree containing ms with the estimated parameters, or by framing it more cautiously as a hypothetical illustration rather than a validation.

    Authors: We agree that the ms case study is a projection rather than a demonstrated result. The proportional scaling assumption (current fan-in × ratio of registry sizes) is unvalidated—npm's growth has not been uniform across packages, and ms may have had a different relative position in 2017 than this estimate suggests. We also did not actually run the framework on a reconstructed 2017-era dependency tree; we computed the CLR score manually from estimated parameters and asserted the ranking without executing the pipeline. We will take the referee's suggestion and actually run the framework on a dependency tree containing ms with the estimated 2017 parameters, reporting the concrete ranking the pipeline produces. If the result confirms our projection, we will present it as an illustrative computation with clearly stated assumptions. If it does not, we will report that honestly. In either case, we will reframe the case study from 'retrospective validation' to 'hypothetical illustration' or 'retrospective analysis' to accurately convey its evidentiary status. The footnote acknowledging the lack of historical fan-in snapshots will be expanded to explicitly state the limitation of the scaling assumption. revision: yes

  3. Referee: §II.B, Eq. (2): The multiplicative composition CLR(m) = φ(m) · f(ψ(pkg(m))) structurally assigns zero risk when either dimension is absent. The paper justifies this qualitatively but does not validate it against data or attack outcomes. This modeling choice is load-bearing: a one-line package that is a single point of failure for an entire ecosystem receives a low score if its single method has low complexity. The paper notes this limitation briefly but does not address the converse scenario where low code complexity combined with extreme exposure is itself the risk. An ablation against an additive alternative, or at least a discussion of this specific failure mode, would strengthen the justification.

    Authors: This is a well-taken point. The multiplicative composition is load-bearing, and the referee correctly identifies a real failure mode: a one-line package that is a single point of failure for an ecosystem (e.g., escape-html, which appears in our Table II with 1 method and 327,489 dependents) would receive a low CLR score if its single method has low cyclomatic complexity and low betweenness. In fact, this is not hypothetical—escape-html is in our hidden amplifier table precisely because it has extreme exposure, yet under the multiplicative formula its CLR score would be dominated by its trivial code-level risk. The referee is right that we note this limitation only in passing ('methods with zero betweenness but high complexity may be underweighted') without addressing the converse and arguably more important case: low complexity combined with extreme exposure. We will address this in two ways. First, we will add a discussion of this specific failure mode, acknowledging that the multiplicative form systematically underweights packages where the risk is the exposure itself rather than code complexity. Second, we will conduct an ablation against an additive alternative (e.g., CLR_additive = α·φ(m) + (1-α)·f(ψ(pkg(m)))) on our existing corpus, reporting how rankings change and whether the additive form better captures packages like escape-html. We cannot promise that the ablation will resolve the tension—it may reveal that no single composition is universally appropriate—but it will make the trade-off explicit. revision: yes

Circularity Check

0 steps flagged

No significant circularity: CLR formula is parameter-free, hidden amplifier thresholds are explicitly acknowledged as sample-dependent, and the ms retrospective uses a structural argument independent of the 2017 CVE.

full rationale

The paper's core derivation chain does not reduce to its inputs by construction. The CLR formula (Def. 3, Eq. 2) is parameter-free — no constants are fitted to the evaluation data. The multiplicative composition φ(m)·f(ψ(pkg(m))) is a modeling choice (acknowledged in §V Threats to Validity), not a fit renamed as prediction. The hidden amplifier definition (|M|<50, ψ>50,000) is a threshold applied to the corpus, and the authors explicitly state 'This rate reflects our selection of high-fan-in packages' and 'In a random registry sample the prevalence would be much lower' — they do not claim the 24% rate generalizes. The ms retrospective (§IV.A) uses a structural argument: ms has 5 methods and (estimated) 73K dependents, placing it in the hidden amplifier quadrant by definition of the thresholds, independent of whether the 2017 ReDoS CVE actually occurred. The P@K evaluation (Table III) is presented as 'feasibility demonstration' with the caveat that 'The sample size precludes statistical generalization.' The paper acknowledges that CLR's cross-package ranking capability is not validated against vulnerability ground truth ('Evaluating whether this re-ordering correlates with actual vulnerability outcomes requires a larger corpus'). No self-citation chain is load-bearing: the framework is self-contained, citing only external tools (deps.dev, OSV, OpenSSF) and prior empirical work by other authors. The one minor concern — that the hidden amplifier thresholds could be post-hoc tuned to the corpus — is mitigated by the authors' explicit acknowledgment and the structural gap argument in Figure 2. This is a standard preliminary evaluation paper with honest limitations, not a circular derivation.

Axiom & Free-Parameter Ledger

4 free parameters · 4 axioms · 1 invented entities

The axiom ledger captures the modeling choices that structure the framework. The multiplicative composition and the specific code-level metric product are the most significant ad-hoc assumptions — they define the risk model's behavior but are not derived from or validated against attack outcome data. The four free parameters are thresholds and function choices that affect results but are shown to be relatively stable (ρ≥0.97 for dampening function choice).

free parameters (4)
  • θ_M (hidden amplifier method threshold) = 50
    Chosen threshold for hidden amplifier detection (§II.C). The paper states this is configurable and claims the class persists across reasonable choices, but 50 is the value used for all results.
  • θ_ψ (hidden amplifier fan-in threshold) = 50000
    Chosen threshold for hidden amplifier detection (§II.C). Same configurability claim as θ_M.
  • N (bottleneck package count) = 20
    Top-N bottleneck packages selected for method-level analysis in Layer 3 (§III). Default value; affects which packages get full code analysis.
  • f (dampening function) = log_10(x+1)
    Chosen as default dampening function for ecosystem exposure (§II.B). Sensitivity analysis shows ρ≥0.97 across four alternatives, but log_10 is the value used for all reported results.
axioms (4)
  • ad hoc to paper Risk is zero when either code-level risk or ecosystem exposure is absent (multiplicative composition).
    §II.B: 'We choose a multiplicative form because an additive alternative would assign non-zero risk even when one dimension is absent.' This is a modeling assumption, not derived from data. Stated again in §V Threats to Validity.
  • ad hoc to paper Cyclomatic complexity, betweenness centrality, blast radius, and churn are the relevant code-level risk dimensions and their product is the correct composition.
    §II.B, Definition 1: φ(m) = c(m)·b(m)·r(m)·τ(m). No justification is given for why these four metrics and their multiplicative product capture code-level structural risk. No ablation on individual components.
  • domain assumption Fan-in (transitive reverse-dependency count) is the correct measure of ecosystem exposure.
    §II.B, Definition 2: ψ(p) = FanIn(p). This is a reasonable domain choice but alternatives (e.g., download counts, criticality score) are not discussed.
  • ad hoc to paper Internal resolution rate R ≥ 0.85 indicates reliable call graphs.
    §III, Layer 2: 'Packages with R < 0.85 produce unreliable call graphs.' The 0.85 threshold is asserted without calibration against ground-truth call graph quality.
invented entities (1)
  • Hidden amplifier (structural class) independent evidence
    purpose: Names the class of packages with few methods but high fan-in that carry outsized supply-chain risk invisible to current tools.
    The ms retrospective case (§IV.A) provides a falsifiable historical validation: ms would have been flagged before its 2017 CVE. The class is defined by thresholds on measurable quantities (method count, fan-in), making it independently checkable on any registry.

pith-pipeline@v1.1.0-glm · 12772 in / 3123 out tokens · 515843 ms · 2026-07-08T21:15:26.149277+00:00 · methodology

0 comments
read the original abstract

Modern software supply chains comprise hundreds of transitive dependencies, yet existing analysis tools operate at either the ecosystem level (dependency graphs) or the code level (static analysis within packages). This separation creates two failure modes. First, false-positive CVE alerts for unreachable code. Second, blind spots for structurally critical micro-dependencies. We introduce cross-level risk propagation, a framework that bridges code-level risk metrics with ecosystem-level dependency exposure through a unified risk formula. Preliminary evaluation on 50 packages across npm and PyPI reveals a class of hidden amplifiers -- micro-dependencies with fewer than 50 methods but over 50,000 dependents -- that carry outsized supply-chain risk invisible to all current Software Composition Analysis (SCA) tools. Without cross-level analysis, such packages can harbor exploitable code for years because no current tool considers both internal code structure and ecosystem position simultaneously. These results suggest that cross-level analysis opens a new design space for supply-chain security.

Figures

Figures reproduced from arXiv: 2607.05894 by Indrajit Ray, Rafael Fabian Gonzalez Arellano, Rakesh Podder.

Figure 1
Figure 1. Figure 1: Cross-level analysis workflow. Layer 1 resolves dependencies and [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Method count vs. fan-in across 50 corpus packages (log-log). The [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Distribution of internal resolution rate ( [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

discussion (0)

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

Reference graph

Works this paper leans on

29 extracted references · 29 canonical work pages

  1. [1]

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

    M. Ohm, H. Plate, A. Sykosch, and M. Meier, “Backstabber’s knife collection: A review of open source software supply chain attacks,” in International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, 2020, pp. 23–43

    work page 2020

  2. [2]

    Sok: Taxonomy of attacks on open-source software supply chains,

    P. Ladisa, H. Plate, M. Martinez, and O. Barais, “Sok: Taxonomy of attacks on open-source software supply chains,” in2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023, pp. 1509–1526

    work page 2023

  3. [3]

    Perspectives on the SolarWinds incident,

    S. Peisert, B. Schneier, H. Okhravi, D. Maughan, V . Pillitteriet al., “Perspectives on the SolarWinds incident,”IEEE Security & Privacy, vol. 19, no. 2, pp. 7–13, 2021

    work page 2021

  4. [4]

    CVE-2021-44228: Apache Log4j2 JNDI features remote code execution,

    MITRE, “CVE-2021-44228: Apache Log4j2 JNDI features remote code execution,” 2021. [Online]. Available: https://nvd.nist.gov/vuln/detail/ CVE-2021-44228

    work page 2021

  5. [5]

    Detecting suspicious package updates,

    K. Garrett, G. Ferreira, L. Jia, J. Sunshine, and C. K ¨astner, “Detecting suspicious package updates,” inProceedings of the 41st International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER). IEEE, 2019, pp. 13–16

    work page 2019

  6. [6]

    Executive Order 14028: Improving the Nation’s Cybersecurity,

    E. O. of the President, “Executive Order 14028: Improving the Nation’s Cybersecurity,” pp. 26 633–26 647, 2021

    work page 2021

  7. [7]

    An empirical comparison of dependency network evolution in seven software packaging ecosystems,

    A. Decan, T. Mens, and P. Grosjean, “An empirical comparison of dependency network evolution in seven software packaging ecosystems,” Empirical Software Engineering, vol. 24, no. 1, pp. 381–416, 2019

    work page 2019

  8. [8]

    Snyk: Developer security platform,

    Snyk Ltd., “Snyk: Developer security platform,” 2024. [Online]. Available: https://snyk.io

    work page 2024

  9. [9]

    Dependabot: Automated dependency updates,

    GitHub, “Dependabot: Automated dependency updates,” 2024. [Online]. Available: https://github.com/dependabot

    work page 2024

  10. [10]

    Understanding software vulnerabilities in the maven ecosystem: Patterns, timelines, and risks,

    M. F. Rabbi, R. Paul, A. I. Champa, and M. F. Zibran, “Understanding software vulnerabilities in the maven ecosystem: Patterns, timelines, and risks,” in2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR). IEEE, 2025, pp. 290–294

    work page 2025

  11. [11]

    On the impact of using trivial packages: An empirical case study on npm and pypi,

    R. Abdalkareem, V . Oda, S. Mujahid, and E. Shihab, “On the impact of using trivial packages: An empirical case study on npm and pypi,” Empirical Software Engineering, vol. 25, no. 2, pp. 1168–1204, 2020

    work page 2020

  12. [12]

    Reachcheck: Compositional library-aware call graph reachability analysis in the ides,

    C. Wang, L. Lin, C. Wang, J. Huang, C. Wu, and R. Wu, “Reachcheck: Compositional library-aware call graph reachability analysis in the ides,” ACM Transactions on Software Engineering and Methodology, vol. 35, no. 6, pp. 1–30, 2026

    work page 2026

  13. [13]

    Do developers update their library dependencies? an empirical study on the impact of security advisories on library migration,

    R. G. Kula, D. M. German, A. Ouni, T. Ishio, and K. Inoue, “Do developers update their library dependencies? an empirical study on the impact of security advisories on library migration,”Empirical Software Engineering, vol. 23, no. 1, pp. 384–417, 2018

    work page 2018

  14. [14]

    On the effectiveness of machine learning-based call graph pruning: An empirical study,

    A. M. Mir, M. Keshani, and S. Proksch, “On the effectiveness of machine learning-based call graph pruning: An empirical study,” inProceedings of the 21st International Conference on Mining Software Repositories, 2024, pp. 457–468

    work page 2024

  15. [15]

    Insight: Exploring cross-ecosystem vulnerability impacts,

    M. Xu, Y . Wang, S.-C. Cheung, H. Yu, and Z. Zhu, “Insight: Exploring cross-ecosystem vulnerability impacts,” inProceedings of the 37th IEEE/ACM International Conference on Automated Software Engineer- ing, 2022, pp. 1–13

    work page 2022

  16. [16]

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

    M. Zimmermann, C.-A. Staicu, C. Tenny, and M. Pradel, “Small world with high risks: A study of security threats in the npm ecosystem,” in28th USENIX Security symposium (USENIX security 19), 2019, pp. 995–1010

    work page 2019

  17. [17]

    GHSA-3fx5-fwvr-xrjg: Regular expression denial of service in ms,

    GitHub Advisory Database, “GHSA-3fx5-fwvr-xrjg: Regular expression denial of service in ms,” 2016, cVE-2015-8315. [Online]. Available: https://github.com/advisories/GHSA-3fx5-fwvr-xrjg

    work page 2016

  18. [18]

    deps.dev: Open source insights,

    Google, “deps.dev: Open source insights,” 2023. [Online]. Available: https://deps.dev

    work page 2023

  19. [19]

    OpenSSF Scorecard,

    O. S. S. Foundation, “OpenSSF Scorecard,” 2023. [Online]. Available: https://securityscorecards.dev

    work page 2023

  20. [20]

    Measuring dependency freshness in software systems,

    J. Cox, E. Bouwers, M. Van Eekelen, and J. Visser, “Measuring dependency freshness in software systems,” in2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, vol. 2. IEEE, 2015, pp. 109–118

    work page 2015

  21. [21]

    OSV: Open Source Vulnerabilities,

    Google, “OSV: Open Source Vulnerabilities,” 2023. [Online]. Available: https://osv.dev

    work page 2023

  22. [22]

    Vuln4real: A methodology for counting actually vulnerable dependen- cies,

    I. Pashchenko, H. Plate, S. E. Ponta, A. Sabetta, and F. Massacci, “Vuln4real: A methodology for counting actually vulnerable dependen- cies,”IEEE Transactions on Software Engineering, vol. 48, no. 5, pp. 1592–1609, 2020

    work page 2020

  23. [23]

    Renovate: Automated dependency updates,

    Mend.io, “Renovate: Automated dependency updates,” 2024. [Online]. Available: https://docs.renovatebot.com

    work page 2024

  24. [24]

    Impact assessment for vulnera- bilities in open-source software libraries,

    H. Plate, S. E. Ponta, and A. Sabetta, “Impact assessment for vulnera- bilities in open-source software libraries,” in2015 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2015, pp. 411–420

    work page 2015

  25. [25]

    Pycg: Practical call graph generation in python,

    V . Salis, T. Sotiropoulos, P. Louridas, D. Spinellis, and D. Mitropoulos, “Pycg: Practical call graph generation in python,” in2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 2021, pp. 1646–1657

    work page 2021

  26. [26]

    Beyond metadata: Code-centric and usage-based analysis of known vulnerabilities in open-source soft- ware,

    S. E. Ponta, H. Plate, and A. Sabetta, “Beyond metadata: Code-centric and usage-based analysis of known vulnerabilities in open-source soft- ware,” in2018 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2018, pp. 449–460

    work page 2018

  27. [27]

    A manually-curated dataset of fixes to vulnerabilities of open-source software,

    S. E. Ponta, H. Plate, A. Sabetta, M. Bezzi, and C. Dangremont, “A manually-curated dataset of fixes to vulnerabilities of open-source software,” in2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR). IEEE, 2019, pp. 110–114

    work page 2019

  28. [28]

    Demystifying the vulnerability propagation and its evolution via dependency trees in the npm ecosystem,

    C. Liu, S. Chen, L. Fan, B. Chen, Y . Liu, and X. Peng, “Demystifying the vulnerability propagation and its evolution via dependency trees in the npm ecosystem,” inProceedings of the 44th international conference on software engineering, 2022, pp. 672–684

    work page 2022

  29. [29]

    Identifying challenges for oss vulnerability scanners-a study & test suite,

    A. Dann, H. Plate, B. Hermann, S. E. Ponta, and E. Bodden, “Identifying challenges for oss vulnerability scanners-a study & test suite,”IEEE Transactions on Software Engineering, vol. 48, no. 9, pp. 3613–3625, 2022

    work page 2022