Technical Lag as Latent Technical Debt: A Rapid Review
Shane K. Panter
shanepanter@boisestate.edu
Boise State University
Boise, Idaho, USA
Nasir U. Eisty
neisty@utk.edu
University of Tennessee
Knoxville, Tennessee, USA
Abstract
Context: Technical lag accumulates when software systems fail to
keep pace with technological advancements, leading to software
quality deterioration. Objective: This paper aims to consolidate
existing research on technical lag, clarify definitions, explore its
detection and quantification methods, examine underlying causes
and consequences, review current management practices, and lay
out a vision as an indicator of passively accumulated technical debt.
Method: We conducted a Rapid Review with snowballing to select
the appropriate peer-reviewed studies. We leveraged the ACM Digi tal Library, IEEE Xplore, Scopus, and Springer as our primary source
databases. Results: Technical lag accumulates passively, often unno ticed due to inadequate detection metrics and tools. It negatively
impacts software quality through outdated dependencies, obsolete
APIs, unsupported platforms, and aging infrastructure. Strategies
to manage technical lag primarily involve automated dependency
updates, continuous integration processes, and regular auditing.
Conclusions: Enhancing and extending the current standardized
metrics, detection methods, and empirical studies to use technical
lag as an indication of accumulated latent debt can greatly improve
the process of maintaining large codebases that are heavily depen dent on external packages. We have identified the research gaps
and outlined a future vision for researchers and practitioners to
explore.
CCS Concepts
• General and reference → Surveys and overviews; Measure ment; • Software and its engineering → Software libraries and
repositories; Software maintenance tools; Software evolution; Main taining software; • Social and professional topics → Software
maintenance.
Keywords
Technical Lag, Technical Debt, Rapid Review, Software Quality,
Software Health, Software Ecosystems, Dependency Management,
Software Maintenance, Software Evolution, Software Metrics, Soft ware Engineering
ACM Reference Format:
Shane K. Panter and Nasir U. Eisty. 2026. Technical Lag as Latent Technical
Debt: A Rapid Review. In Proceedings of International Conference on Technical
Debt (TechDebt 2026). ACM, New York, NY, USA, 6 pages. https://doi.org/
XXXXXXX.XXXXXXX
1 Introduction
Gonzalez-Barahona et al. [9] coined the term “technical lag” (TL)
to recognize the differences between technical debt (TD), which
TechDebt 2026, Rio de Janeiro, Brazil
2026. ACM ISBN 978-x-xxxx-xxxx-x/YYYY/MM
https://doi.org/XXXXXXX.XXXXXXX
is the result of deliberate trade-offs in software design and imple mentation [4], and the impact of outdated dependencies that are
used in the deployment process. TL accumulates passively rather
than through intentional design decisions and measures how an
ecosystem “degrades” with just the passing of time [22, 25]. Both
TL and TD can be challenging to detect or quantify without the use
of appropriate tools and metrics [13, 16]. Additionally, as demon strated in the recent XZ Utils1
supply chain incident and research
on npm packages [22], driving TL to zero by running bleeding-edge
software also carries risk by introducing components that may not
have been thoroughly vetted.
The prevalence of TL is not new and is alarmingly widespread. By
establishing a clearer connection between these two constructs, we
aim to position TL not merely as a maintenance nuisance, but as a
hidden dimension of TD and a potential indicator of latent technical
debt (LTD). Studies demonstrate that one out of four dependen cies and two out of five releases in the npm ecosystem suffer from
TL [5]. Operating system package managers may sometimes be
outdated for months or even years [12, 16]. This difference between
the upstream source and what is being used significantly elevates
the risk of vulnerability exposure relative to regularly maintained
components [3, 26].
To address these challenges, researchers and practitioners have
increasingly emphasized the need for comprehensive approaches
to detect, quantify, and mitigate TL [8, 16, 25]. However, despite
significant contributions in recent years, there is still much work
to be done regarding the application of metrics, the development
of robust empirical methodologies, and the exploration of broader
ecosystems. Additionally, prior studies quantify the time to update,
but not the safety of updating; there is no metric for “safe to adopt”
time under supply-chain compromise.
By consolidating existing definitions, processes, empirical find ings, and management strategies, we provide a comprehensive syn thesis that clarifies the scope of TL, examines its root causes and
consequences, evaluates the effectiveness of current detection and
mitigation practices, and identifies gaps and opportunities for fu ture research. Through this Rapid Review synthesis, we contribute
essential foundations for future research and practical approaches
to improve software sustainability, reliability, and innovation.
The contributions of this paper are:
(1) Consolidating and categorizing metrics and methods for
detecting TL.
(2) Identifying five key research gaps across ecosystems.
(3) Establishing the conceptual link between TL and LTD.
1https://nvd.nist.gov/vuln/detail/CVE-2024-3094
arXiv:2601.11693v1 [cs.SE] 16 Jan 2026

TechDebt 2026, April 12–15, 2026, Rio de Janeiro, Brazil Panter and Eisty
2 Background
TL and TD share common consequences (Table 2), including in creased maintenance costs, reduced developer productivity, and ele vated security risks. For example, studies consistently demonstrate
that outdated dependencies are significantly more likely to contain
vulnerabilities and defects [3, 11, 23]. These risks parallel those de scribed in the TD literature, where unaddressed shortcuts manifest
as higher defect rates and system fragility over time [1, 7, 20]. Thus,
TL can be seen as a “debt-like liability” incurred not by intentional
shortcuts, but by inaction and inertia in dependency management.
Fig. 2 illustrates the relationship between TL and TD.
TL introduces a form of compound interest in the repayment of
TD. When dependencies are left outdated, their eventual update
not only requires larger effort due to version incompatibilities but
also forces developers to refactor dependent modules, adjust tests,
and retrain teams on new APIs. This compounding effect aligns
closely with the “interest” metaphor in TD, where the longer the
debt is left unaddressed, the more costly it becomes to repay.
3 Goal and Research Questions
The goal of our study is to establish the current state of TL research
with a Rapid Review and establish a future vision for identifying
LTD. We aim to identify all the metrics that have been created, the
ecosystems studied, and the research gaps that exist.
Based on this goal, our research questions are as follows:
RQ1: What are the primary causes of technical lag in software
projects?
RQ2: What metrics and methods have been proposed to detect or
quantify technical lag?
RQ3: What are the research gaps in understanding or addressing
technical lag?
4 Search Strategy
We conducted a Rapid Review following Cartaxo et al. [2] and
Wohlin’s snowballing guidelines [19] to synthesize existing re search on TL. Searches were conducted in the ACM Digital Library,
IEEE Xplore, Scopus, and Springer. We included peer-reviewed stud ies published between 2015 and 2025 that explicitly addressed TL
in software ecosystems and answered at least one of our research
questions. Initial queries identified 43 unique papers, of which 15
met the inclusion criteria. Snowballing added 3 more, resulting in
a final dataset of 18 studies (Fig. 1). The complete dataset has
been made available for replication [15].
The final search strings are as follows:
ACM “query”: “Technical Lag” “filter”: {Article Type: Research Ar ticle}, {ACM Content: DL}
IEEE “All Metadata”: “Technical Lag”
Scopus TITLE-ABS-KEY (“Technical Lag”) AND (LIMIT-TO (SUB JAREA, “COMP”)) AND (LIMIT-TO (DOCTYPE, “ar”)) OR
(LIMIT-TO DOCTYPE, “cp”)
Springer Keywords: “Technical Lag” Content Type: (Research Ar ticle, Conference Paper) Disciplines: (Computer Science)
4.1 Selection Procedure
The first author performed each step detailed in Fig. 1 while the sec ond author confirmed the results. Any disagreements were resolved
through discussion. In steps ➀, ➁, and ➂, papers were screened in
two rounds. The first round screened each potential paper based
on its title and abstract. The second round consisted of a full-text
review to select the most relevant studies.
4.2 Extraction Procedure
Data relevant to our research questions were extracted from each
paper and grouped by research question by the first author for
analysis and synthesis. The second author reviewed the results to
ensure all relevant data were correctly identified.
5 Results
In this section, we present the results of our Rapid Review and
answer the research questions posed in Section 3.
5.1 RQ1: Primary Causes
TL in software projects arises from a mix of rigid dependency
policies, slow update practices, ecosystem-specific requirements,
and tooling limitations [12, 16, 18, 22]. Studies in the npm ecosystem
report that strict version constraints and fixed declarations are a
significant cause of TL, where the typical TL is 7 to 9 months, with
25% having a TL of more than 9 months and only 25% with a TL
less than 52 days [5].
These findings underscore that TL is not a single factor but
rather the combined effect of ecosystem factors, developer decision
patterns, and infrastructure and tooling challenges [6, 10, 12, 14, 16,
25].
5.1.1 Ecosystem Factors. Software ecosystems exhibit distinct
characteristics significantly influencing how TL manifests and
evolves. Different package managers and distribution platforms
have developed unique approaches to managing dependencies and
updates, leading to varying outcomes in terms of TL [16]. Packages
can be provided by the language ecosystem (e.g., npm, Maven), op erating system distributions (e.g., apt, yum) [12, 16], or container
registries (e.g., Docker Hub) [26], making it difficult to get a com plete picture.
In the Linux distribution landscape, contrasting philosophies
drive update patterns. Arch Linux prioritizes freshness in its pack age management, resulting in lower TL across its ecosystem. In
stark contrast, CentOS takes a more conservative approach, em phasizing stability over currency, which naturally leads to a higher
TL but potentially more stable systems [12]. This approach makes
direct comparisons difficult [16] when applications are deployed in
multiple environments.
The Maven, Docker, and npm ecosystems present their unique
challenges. These platforms struggle particularly with transitive
dependencies and the ongoing maintenance of images and pack ages [21, 23, 25]. In Docker’s case, there’s a notable difference be tween official and community images, with nearly 70% of popular
child images inheriting an outdated parent with a median of 5.63
months, and community images having higher lag than officially
maintained images [14].

Technical Lag as Latent Technical Debt: A Rapid Review TechDebt 2026, April 12–15, 2026, Rio de Janeiro, Brazil
ACM Digital Library (20 results)
IEEE Xplore (5 results)
Scopus (7 results)
Springer Link (11 results)
○1 Database Query
Merge Results
Remove Duplicates
(43 merged)
Meets Inclusion
Criteria
(15 included)
Excluded Papers
(28 results)
➁ Base Set of Papers
Backward Snowball
(20 results)
Forward Snowball
(46 results)
Merge Results
Remove Duplicates
(60 merged)
Meets Inclusion
Criteria
(3 included)
Excluded Papers
(57 results)
➂ First Snowball Iteration
Backward Snowball
(8 results)
Forward Snowball
(0 results)
Merge Results
Remove Duplicates
(8 merged)
Meets Inclusion
Criteria
(0 included)
Excluded Papers
(8 results)
➃ Second Snowball Iteration
➄ 18 Papers Total
15 from step ➁
3 from step ➂
0 from step ➃
No
yes
No
yes
No
yes
Figure 1: Results from the initial database query ➀ were filtered by our inclusion and exclusion criteria ➁. Two rounds of
forward and backward snowballing were completed ➂, ➃ to yield a final set of studies.
A common thread across ecosystems is the impact of dependency
tree complexity [16, 25]. Deep dependency trees that span multiple
package managers at both the language and operating system levels
may not be accurate and can create additional package maintenance
and update complications. This complexity is particularly evident
in npm, where the depth and interconnectedness of dependencies
can create significant bottlenecks in the update process [10].
5.1.2 Developer Decision Patterns. In the complex software
development landscape, developers face ongoing decisions about
managing their project dependencies. This leads to distinct patterns
in how they approach updates and manage any potential breaking
changes [17, 25]. These patterns reveal a delicate balance between
maintaining stability and staying current with the latest versions.
Developers often find themselves at a crossroads between restric tive and permissive approaches when choosing update strategies.
The consequences of these choices are significant; studies show that
Java projects in the Maven ecosystem experience significant update
delays [3, 18]. Fear plays a crucial role in these decisions. Developers
frequently avoid updates due to concerns about breaking changes,
prioritizing stability over currency. This cautious approach is fur ther reinforced by the high costs associated with testing updates
and developers’ limited influence over their dependencies [3, 5, 18].
5.1.3 Infrastructure and Tooling Impact. The infrastructure
and tooling landscape is pivotal in managing and combating TL,
yet current solutions present opportunities and significant chal lenges [6, 10]. The effectiveness of these tools can make the differ ence between maintaining current dependencies and falling behind
in critical updates [11, 25].
At the foundation of modern dependency management are de pendency graphs, which provide clear visibility into project de pendencies. However, these crucial tools often fall short of their
intended purpose [16]. Recent studies have revealed that depen dency graphs can contain significant noise and increase workloads,
potentially leading to undetected vulnerabilities [10]. This unrelia bility in fundamental tooling creates a challenging foundation for
dependency management.
5.2 RQ2: Metrics and Methods
Table 1 maps each study to one of six categories of TL, the metrics
used or defined, and the ecosystems studied. The categories are not
mutually exclusive, as some studies proposed multiple metrics or
modified existing ones to address ecosystem-specific challenges.
The most common categories were Time Lag (10 studies) and Ver sion Lag (6 studies), while Package Lag, Vulnerability and Bug Lag,
Opportunity Lag, and Conceptual frameworks were less frequently
addressed.
The TL categories are defined as follows:
(1) Time Lag measures the temporal gap between the release
of a newer version and its adoption.
(2) Version Lag counts the number of releases newer than the
latest installable and is optionally weighted by SemVer class
(major.minor.patch).
(3) Package Lag focuses on the number or proportion of out dated packages within a system
(4) Vulnerability and Bug Lag assesses lag based on known
vulnerabilities and bugs in dependencies, highlighting secu rity risks associated with outdated components.
(5) Opportunity Lag measures the time window of active avail ability when updates were available but not adopted, empha sizing missed opportunities for improvement.
(6) Conceptual has defined theoretical aspects of technical lag
that can be adopted to any ecosystem.
5.3 RQ3: Research Gaps
TL appears to be widespread in package management ecosystems [5,
12, 16, 21]. Studies report that dependency updates are often de layed because existing metrics typically focused on time and version
lag do not capture key factors such as update effort, security risks,

TechDebt 2026, April 12–15, 2026, Rio de Janeiro, Brazil Panter and Eisty
Table 1: Crosswalk of technical lag metric categories, concrete metrics, and ecosystems used in the literature.
Lag Category Metric Study Ecosystem
Time TimeΔ expressed in months between the release of an Action and the latest
available release.
Decan et al. [6] GitHub Actions (SEART GitHub
Search Engine)
time-lag(i) per release time difference in packages Zerouali et al. [24] Debian-based Docker images
TimeΔ Delay in adopting newer library releases in apps (project history) Salza et al. [17] Android apps (ANDROID TIMEMACHINE)
TimeΔ calculated as the number of days (major, minor, and micro lag) Stringer et al. [18] 14 package managers (libraries.io)
TimeΔ date of first appearance of package version Legay et al. [12] Arch, Debian, CentOS, Fedora,
Ubuntu
tLag(d) for a dependency package network Zerouali et al. [22] npm (libraries.io)
TimeΔ with modifications He et al. [10] GitHub repos (GHTorrent)
Δt(d, t) Lag of dependency d at time t Decan et al. [5] npm (libraries.io)
TimeΔ version release dates Zerouali et al. [23] Docker Hub
TimeΔ push date of latest parent vs. inherited date Opdebeeck et al. [14] Docker Hub
Version vers-lag(i) number of missed versions Zerouali et al. [24] Debian-based Docker images
VersionΔ (major, minor and micro lag) Stringer et al. [18] 14 package managers (libraries.io)
vLag(d) for a dependency package network Zerouali et al. [22] npm (libraries.io)
VersionΔ package number of versions behind Zerouali [21] Alpine-based Docker images
VersionΔ version behind latest Zerouali et al. [23] Docker Hub
Version Number Delta (VND) aggregated SemVer deltas Panter et al. [16] Debian/Ubuntu apt ecosystem
(Ultimate Debian Database)
Package pkg-lag(i) number of outdated packages in the image Zerouali et al. [24] Debian-based Docker images
package time lag (in days) Zerouali [21] Alpine-based Docker images
Activity Categorizer (AC) Activity lag of Debian packages Panter et al. [16] Debian/Ubuntu apt ecosystem
(Ultimate Debian Database)
Vulnerability &
Bug
vuln-lag(i) Count/severity of known CVEs present in the used versions vs what
would be present if updated
Zerouali et al. [24] Debian-based Docker images
Vulnerabilities and bugs in images (correlational analysis) Zerouali et al. [26] Debian-based Docker images
bug-lag(i) Open/known bug counts persisting in the used versions vs updated
baseline
Zerouali et al. [24] Debian-based Docker images
Patch lagging time T_fix(commit), T_ver(version), T_index(Index) Hu et al. [11] Golang
Opportunity Total time an update has been available (opportunity window) but not adopted Decan et al. [6] GitHub Actions (SEART GitHub
Search Engine)
Conceptual Theoretical model of Technical Lag Gonzalez-Barahona et al. [9] Debian Packages
TimeΔ and VersionΔ formal definitions Zerouali et al. [25] npm (libraries.io)
Characterizing outdateness and technical lag Gonzalez-Barahona et al. [8] Examples for language and OS
package managers
Introduced Ver_Sequence, Ver_Release, Ver_Delta Cox et al. [3] Java (Maven)
ecosystem-specific practices [3, 12, 22, 24] or lost opportunities [6].
In npm, Maven, and Docker ecosystems, research indicates that TL
grows over time due to transitive dependencies, versioning policies,
and challenges in automated tooling [5, 16, 18, 21, 22]. Inaccura cies in data sources and dependency graphs further complicate
measurement [10, 14].
5.3.1 Research Gap 1 Methods and Metrics. Conceptual Frame works have laid the groundwork for measuring TL. However, each
ecosystem presents unique challenges in applying these frame works, which need to be refined to account for the differences in
available metadata between ecosystems. The complexity of man aging these dependencies is compounded by versioning policies
and the need to balance update frequency with associated risks
and effort [10, 18]. Developing new methods and metrics that ad dress specific ecosystem challenges is crucial for a comprehensive
understanding of the system [16].
5.3.2 Research Gap 2 Data Quality and Coverage. Most work
focuses on a few ecosystems (Table 1), leaving many systems un touched. Real-world ecosystems often lack the necessary data to
evaluate TL [14], which is filtered out [16], resulting in incomplete
datasets and underscoring the need for improved data collection and
validation in real-world systems. Additionally, studies have found
significant variations in TL patterns based on package manager
policies, distribution types, and community practices [12, 16, 21, 25].
Ecosystems such as Chocolatey for Windows, Homebrew for ma cOS, and vcpkg for C/C++ remain unexplored. The lack of data on
these ecosystems limits the understanding of TL in these environ ments.
5.3.3 Research Gap 3 Automation and Tooling. Although
tools like Dependabot help mitigate lag, compatibility assessments
and developer trust remain problematic [10]. Tooling that works
out of the box without extensive customization would improve the
adoption of TL methods. Continuous Ecosystem-level monitoring
to spot problematic packages early can help teams actively manage
their TL before it becomes problematic [16]. Additionally, the auto mated tooling itself can suffer from TL due to the need for manual
updates and maintenance. This can lead to outdated tools used to
manage dependencies, creating a vicious cycle of TL [6, 10].
5.3.4 Research Gap 4 Security and Risk Integration. A gap
remains in integrating security considerations into lag metrics and
management tools. While some studies have explored the relation ship between TL and security vulnerabilities, there is a need for

Technical Lag as Latent Technical Debt: A Rapid Review TechDebt 2026, April 12–15, 2026, Rio de Janeiro, Brazil
more comprehensive frameworks that incorporate security risk
assessments into lag management practices [3, 11, 17, 23, 26]. Ad ditionally, TL metrics need to include data to distinguish between
deliberate protective delay and debt accruing neglect to avoid po tential supply-chain attacks.
5.3.5 Research Gap 5 Developer Guidelines and Predictive
Modeling. Limited guidance exists for dependency management
practices, and predictive models require greater sophistication.
While some studies have proposed models for predicting TL, these
models often lack the necessary complexity to account for the fac tors influencing lag accumulation [16]. More sophisticated models
that consider the interplay of various factors, such as developer
behavior, ecosystem policies, and tooling limitations, are needed to
provide actionable insights for practitioners [5, 21, 22].
6 Technical Lag as Latent Technical Debt
Technical Lag
Outdated dependencies
Obsolete APIs / toolchains
Unsupported platforms
Accumulated Burden
Breaking changes, migrations
Transitive dependency ripple
Regression risk & test cost
Latent Technical Debt
Compounded remediation effort
Fragility & defect proneness
Security exposure
Larger & riskier
eventual updates
“Interest” (effort)
accrues with delay
Hotfixes
Workarounds
Delay updates
Figure 2: A Technical Lag feedback loop for Technical Debt.
TL manifests as a hidden liability and, as shown in Fig. 2, can
create a feedback loop where accumulated burden leads to LTD.
Inaction, hotfixes, and workarounds all contribute to deferred costs
that resemble traditional debt, even though their origins differ.
Just as unresolved TD accrues “interest” in the form of additional
maintenance effort, TL compounds the cost of eventual updates.
Delayed upgrades often require larger migrations, adjustments
to dependent modules, and extensive retesting. This mirrors the
repayment of debt with interest: the longer the lag persists, the
more costly and disruptive the resolution becomes.
Table 2 compares the two constructs across key dimensions. The
table highlights that while TD arises from deliberate shortcuts,
TL emerges passively through inaction. Despite this difference in
origin, both produce debt-like liabilities with compounding costs,
reduced quality, and increased risk.
Table 2: Comparison of Technical Debt and Technical Lag
Dimension Technical Debt Technical Lag
Origin Intentional shortcuts or
trade-offs in design or im plementation
Passive accumulation from
outdated dependencies, APIs,
or platforms
Visibility Often identifiable
through code smells,
static analysis, or archi tectural violations
Often invisible without
ecosystem-level metrics and
tooling
Accumulation Results from conscious
choices (e.g., deferring
refactoring)
Results from inaction and in ertia (e.g., not updating de pendencies)
Cost Dynamics “Interest” accrues as de fects, fragility, and main tenance effort
“Compound Interest” accrues
as larger migrations, compati bility issues, dependency dep recation
Impact Reduced maintainability,
higher defect rates,
slower development
velocity
Increased vulnerability expo sure, fragile update processes,
and ecosystem-wide risks
Management Refactoring, redesign,
debt tracking, repayment
planning
Automated dependency up dates, ecosystem monitoring,
lag-aware tooling
Conceptual Posi tion
Explicit, intentional liabil ity
Latent, passive liability a hid den form of debt
7 Threats to Validity
7.0.1 Internal Validity. Selection bias may impact internal validity,
as our initial search was limited to studies that specifically men tioned TL and software ecosystems. This could exclude relevant
studies that may be valuable but were not identified due to limited
information on how TL was measured, or they lacked the correct
keywords. Additionally, the snowballing process may have intro duced bias by relying on citations from the initial set of studies,
potentially overlooking less-cited but relevant work.
7.0.2 External validity. Given that most studies heavily focus on
ecosystems such as npm and Debian, our conclusions might not
fully apply to less-studied ecosystems or niche technological en vironments. Therefore, caution is warranted when generalizing
findings beyond the contexts explored in existing literature.
7.0.3 Construct validity. Variations in how TL metrics were applied
and modifications due to ecosystem challenges could impact our
groupings. For example, some Time Lag metrics were dependent on
the semantic versioning of the project and could have been classified
as Version Lag, rather than Time Lag. Additionally, findings that
equate newer with safer may overstate risk; recent high-profile
supply-chain attacks show the need for risk-aware, signal-informed
lag metrics.
8 Conclusion
As summarized in this review, reframing TL as LTD gives organiza tions another tool to monitor software health. By positioning TL
as a quantifiable contributor to TD, organizations can incorporate
it into existing debt monitoring frameworks, creating a unified ap proach to managing both intentional and unintentional liabilities.

TechDebt 2026, April 12–15, 2026, Rio de Janeiro, Brazil Panter and Eisty
References
[1] Nanette Brown, Yuanfang Cai, Yuepu Guo, Rick Kazman, Miryung Kim, Philippe
Kruchten, Erin Lim, Alan MacCormack, Robert Nord, Ipek Ozkaya, Raghvinder
Sangwan, Carolyn Seaman, Kevin Sullivan, and Nico Zazworka. 2010. Managing
Technical Debt in Software-Reliant Systems. In Proceedings of the FSE/SDP Work shop on Future of Software Engineering Research (FoSER ’10). ACM, Santa Fe New
Mexico USA, 47–52. doi:10.1145/1882362.1882362.1882373
[2] Bruno Cartaxo, Gustavo Pinto, and Sergio Soares. 2018. The Role of Rapid
Reviews in Supporting Decision-Making in Software Engineering Practice. In
Proceedings of the 22nd International Conference on Evaluation and Assessment in
Software Engineering 2018 (EASE ’18). ACM, Christchurch New Zealand, 24–34.
doi:10.1145/3210459.3210462
[3] Joel Cox, Eric Bouwers, Marko Van Eekelen, and Joost Visser. 2015. Measur ing Dependency Freshness in Software Systems. In 2015 IEEE/ACM 37th IEEE
International Conference on Software Engineering. IEEE, Florence, Italy, 109–118.
doi:10.1109/ICSE.2015.140
[4] Ward Cunningham. 1992. The WyCash Portfolio Management System. In Adden dum to the Proceedings on Object-oriented Programming Systems, Languages, and
Applications (Addendum) (OOPSLA ’92). ACM Press, Vancouver, British Columbia,
Canada, 29–30. doi:10.1145/157709.157715
[5] Alexandre Decan, Tom Mens, and Eleni Constantinou. 2018. On the Evolution of
Technical Lag in the Npm Package Dependency Network. In 2018 IEEE Interna tional Conference on Software Maintenance and Evolution (ICSME). IEEE, Madrid,
404–414. doi:10.1109/ICSME.2018.00050
[6] Alexandre Decan, Tom Mens, and Hassan Onsori Delicheh. 2023. On the Outdat edness of Workflows in the GitHub Actions Ecosystem. Journal of Systems and
Software 206 (Dec. 2023), 111827. doi:10.1016/j.jss.2023.111827
[7] Joshua Aldrich Edbert, Sahrima Jannat Oishwee, Shubhashis Karmakar, Zadia
Codabux, and Roberto Verdecchia. 2023. Exploring Technical Debt in Security
Questions on Stack Overflow. In 2023 ACM/IEEE International Symposium on
Empirical Software Engineering and Measurement (ESEM). IEEE, New Orleans, LA,
USA, 1–12. doi:10.1109/ESEM56168.2023.10304868
[8] Jesus M. Gonzalez-Barahona. 2020. Characterizing Outdateness with Technical
Lag: An Exploratory Study. In Proceedings of the IEEE/ACM 42nd International
Conference on Software Engineering Workshops (ICSEW’20). ACM, Seoul Republic
of Korea, 735–41. doi:10.1145/3387940.3392202
[9] Jesus M. Gonzalez-Barahona, Paul Sherwood, Gregorio Robles, and Daniel
Izquierdo. 2017. Technical Lag in Software Compilations: Measuring How Out dated a Software Deployment Is. In Open Source Systems: Towards Robust Practices,
Federico Balaguer, Roberto Di Cosmo, Alejandra Garrido, Fabio Kon, Gregorio
Robles, and Stefano Zacchiroli (Eds.). Vol. 496. Springer International Publishing,
Cham, 182–192. doi:10.1007/978-3-319-57735-7_17
[10] Runzhi He, Hao He, Yuxia Zhang, and Minghui Zhou. 2023. Automating
Dependency Updates in Practice: An Exploratory Study on GitHub Depend abot. IEEE Transactions on Software Engineering 49, 8 (Aug. 2023), 4004–4022.
doi:10.1109/TSE.2023.3278129
[11] Jinchang Hu, Lyuye Zhang, Chengwei Liu, Sen Yang, Song Huang, and Yang Liu.
2024. Empirical Analysis of Vulnerabilities Life Cycle in Golang Ecosystem. In
Proceedings of the IEEE/ACM 46th International Conference on Software Engineering
(Icse ’24). ACM, Lisbon Portugal, 1–13. doi:10.1145/3597503.3639230
[12] Damien Legay, Alexandre Decan, and Tom Mens. 2021. A Quantitative Assess ment of Package Freshness in Linux Distributions. In 2021 IEEE/ACM 4th Inter national Workshop on Software Health in Projects, Ecosystems and Communities
(SoHeal). IEEE, Madrid, Spain, 9–16. doi:10.1109/SoHeal52568.2021.00008
[13] Eric L. Melin and Nasir U. Eisty. 2025. Exploring the Advances in Using Ma chine Learning to Identify Technical Debt and Self-Admitted Technical Debt.
In 2025 IEEE/ACIS 23rd International Conference on Software Engineering Re search, Management and Applications (SERA). IEEE, Las Vegas, NV, USA, 15–22.
doi:10.1109/SERA65747.2025.11154577
[14] Ruben Opdebeeck, Jonas Lesy, Ahmed Zerouali, and Coen De Roover. 2023. The
Docker Hub Image Inheritance Network: Construction and Empirical Insights.
In 2023 IEEE 23rd International Working Conference on Source Code Analysis and
Manipulation (SCAM). IEEE, Bogotá, Colombia, 198–208. doi:10.1109/SCAM59687.
2023.00029
[15] Shane Panter. 2026. Technical Lag as Latent Technical Debt: A Rapid Review.
doi:10.6084/M9.FIGSHARE.30011638
[16] Shane K. Panter, Lucas S. Hindman, and Nasir U. Eisty. 2025. PVAC: Package
Version Activity Categorizer, Leveraging Semantic Versioning in a Heterogeneous
System. Empirical Software Engineering 30, 5 (Sept. 2025), 118–149. doi:10.1007/
s10664-025-10678-2
[17] Pasquale Salza, Fabio Palomba, Dario Di Nucci, Andrea De Lucia, and Filomena
Ferrucci. 2020. Third-Party Libraries in Mobile Apps: When, How, and Why
Developers Update Them. Empirical Software Engineering 25, 3 (May 2020),
2341–2377. doi:10.1007/s10664-019-09754-1
[18] Jacob Stringer, Amjed Tahir, Kelly Blincoe, and Jens Dietrich. 2020. Technical Lag
of Dependencies in Major Package Managers. In 2020 27th Asia-Pacific Software
Engineering Conference (APSEC). IEEE, Singapore, Singapore, 228–237. doi:10..
1109/APSEC51365.2020.00031
[19] Claes Wohlin. 2014. Guidelines for Snowballing in Systematic Literature Studies
and a Replication in Software Engineering. In Proceedings of the 18th International
Conference on Evaluation and Assessment in Software Engineering. ACM, London
England United Kingdom, 1–10. doi:10.1145/2601248.2601268
[20] Nico Zazworka, Michele A. Shaw, Forrest Shull, and Carolyn Seaman. 2011.
Investigating the Impact of Design Debt on Software Quality. In Proceedings of
the 2nd Workshop on Managing Technical Debt (MTD ’11). ACM, Waikiki, Honolulu
HI USA, 17–23. doi:10.1145/1985362.1985366
[21] Ahmed Zerouali. 2018. Analyzing Technical Lag in Docker Images. In CEUR
Workshop Proceedings (CEUR Workshop Proceedings, Vol. 2361), Gousios G. and
Hejderup J. (Eds.). CEUR-WS, Delft, Netherlands, 11–15.
[22] Ahmed Zerouali, Eleni Constantinou, Tom Mens, Gregorio Robles, and Jesús
González-Barahona. 2018. An Empirical Analysis of Technical Lag in Npm
Package Dependencies. In New Opportunities for Software Reuse, Rafael Capilla,
Barbara Gallina, and Carlos Cetina (Eds.). Springer International Publishing,
Cham, 95–110.
[23] Ahmed Zerouali, Valerio Cosentino, Tom Mens, Gregorio Robles, and Jesus M.
Gonzalez-Barahona. 2019. On the Impact of Outdated and Vulnerable Javascript
Packages in Docker Images. In SANER - Proc. IEEE Int. Conf. Softw. Anal.,
Evol., Reengineering. IEEE, Hangzhou, China, 619–623. doi:10.1109/SANER.2019.
8667984
[24] Ahmed Zerouali, Tom Mens, Alexandre Decan, Jesus Gonzalez-Barahona, and
Gregorio Robles. 2021. A Multi-Dimensional Analysis of Technical Lag in Debian Based Docker Images. Empirical Software Engineering 26, 2 (March 2021), 19–64.
doi:10.1007/s10664-020-09908-6
[25] Ahmed Zerouali, Tom Mens, Jesus Gonzalez-Barahona, Alexandre Decan, Eleni
Constantinou, and Gregorio Robles. 2019. A Formal Framework for Measuring
Technical Lag in Component Repositories — and Its Application to Npm. Journal
of Software: Evolution and Process 31, 8 (Aug. 2019), e2157. doi:10.1002/smr.2157
[26] Ahmed Zerouali, Tom Mens, Gregorio Robles, and Jesus M. Gonzalez-Barahona.
2019. On the Relation between Outdated Docker Containers, Severity Vulnera bilities, and Bugs. In 2019 IEEE 26th International Conference on Software Anal ysis, Evolution and Reengineering (SANER). IEEE, Hangzhou, China, 491–501.
doi:10.1109/SANER.2019.8668013
Received 10 October 2025; accepted 5 January 2026