pith. sign in

arxiv: 2506.17948 · v4 · submitted 2025-06-22 · 💻 cs.SE

Your Build Scripts Stink: The State of Code Smells in Build Scripts

Pith reviewed 2026-05-19 08:32 UTC · model grok-4.3

classification 💻 cs.SE
keywords build scriptscode smellsstatic analysisMavenGradleCMakeMakefilesGitHub issues
0
0 comments X

The pith

Build scripts contain over 10,000 instances of 13 code smell categories that can cause failures and technical debt.

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

The paper seeks to help developers write better build scripts by cataloging recurring poor practices through both manual review of issues and large-scale automated checks. It starts by examining thousands of GitHub discussions to spot patterns that lead to problems, then builds a detection tool to measure how often those patterns appear across real projects using four major build systems. If these smells truly drive reliability issues, fixing the most common ones could reduce broken builds and lower long-term maintenance costs for teams relying on automated pipelines.

Core claim

Through qualitative review of 2000 build-script GitHub issues and quantitative scanning of 5882 scripts from 4877 repositories, the authors identified 13 code smell categories and detected 10,895 total occurrences: 3184 in Maven, 1214 in Gradle, 337 in CMake, and 6160 in Makefiles. Insecure URLs were the top smell in Maven, Hardcoded Paths/URLs dominated Gradle and CMake, and Wildcard Usage led in Makefiles. Co-occurrence patterns showed strong links between Hardcoded Paths/URLs and Duplicates as well as between Inconsistent Dependency Management and Empty or Incomplete Tags.

What carries the argument

Sniffer, the static analysis tool that applies detection rules for the 13 smell categories derived from GitHub issue analysis.

If this is right

  • Practitioners can prioritize fixes for the most frequent smells, such as Insecure URLs in Maven scripts and Wildcard Usage in Makefiles.
  • Strong co-occurrences between specific smell pairs point to underlying structural problems in dependency handling and path management.
  • Build tool choice influences which smells are most common, suggesting tool-specific guidelines for script authors.
  • The Sniffer tool provides an automated way to scan projects and flag these issues early in development.

Where Pith is reading between the lines

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

  • Teams adopting continuous integration could integrate smell detection to catch issues before they reach production builds.
  • The distribution of smells across build systems may reflect differences in how each tool encourages or discourages certain practices.
  • Extending similar analysis to private or enterprise repositories could show whether open-source patterns generalize.

Load-bearing premise

The 2000 GitHub issues analyzed capture a complete and representative set of smells, and the rules in Sniffer detect those smells accurately in practice.

What would settle it

A manual audit of a random subset of the 5882 build scripts that finds either many false positives in the reported smells or a large number of additional problematic patterns not captured by the 13 categories.

Figures

Figures reproduced from arXiv: 2506.17948 by Brandon Wroblewski, Dominik Wermke, Laurie Williams, Mahzabin Tamanna, Matthew Burrows, Yash Chandrani.

Figure 1
Figure 1. Figure 1: An annotated Maven script example with all identified code smell [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Heatmap Of Code Smell Co-Occurrence In Build Scripts [PITH_FULL_IMAGE:figures/full_fig_p010_2.png] view at source ↗
read the original abstract

Build scripts automate the process of compiling source code, managing dependencies, running tests, and packaging software into deployable artifacts. These scripts are ubiquitous in modern software development pipelines for streamlining testing and delivery. While developing build scripts, practitioners may inadvertently introduce code smells, which are recurring patterns of poor coding practices that may lead to build failures or increase risk and technical debt. The goal of this study is to aid practitioners in avoiding code smells in build scripts through an empirical study of build scripts and issues on GitHub.We employed a mixed-methods approach, combining qualitative and quantitative analysis. First, we conducted a qualitative analysis of 2000 build-script-related GitHub issues to understand recurring smells. Next, we developed a static analysis tool, Sniffer, to automatically detect code smells in 5882 build scripts of Maven, Gradle, CMake, and Make files, collected from 4877 open-source GitHub repositories. To assess Sniffer's performance, we conducted a user study, where Sniffer achieved higher precision, recall, and F-score. We identified 13 code smell categories, with a total of 10,895 smell occurrences, where 3184 were in Maven, 1214 in Gradle, 337 in CMake, and 6160 in Makefiles. Our analysis revealed that Insecure URLs were the most prevalent code smell in Maven build scripts, while HardcodedPaths/URLs were commonly observed in both Gradle and CMake scripts. Wildcard Usage emerged as the most frequent smell in Makefiles. The co-occurrence analysis revealed strong associations between specific smell pairs of Hardcoded Paths/URLs with Duplicates, and Inconsistent Dependency Management with Empty or Incomplete Tags, which indicate potential underlying issues in the build script structure and maintenance practices.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

1 major / 2 minor

Summary. The paper reports a mixed-methods empirical study of code smells in build scripts. The authors qualitatively analyze 2000 GitHub issues to derive 13 smell categories, implement the Sniffer static analyzer, apply it to 5882 scripts (Maven, Gradle, CMake, Makefiles) from 4877 repositories yielding 10,895 total detections (with per-system breakdowns), validate Sniffer via a user study claiming superior precision/recall/F-score, and perform co-occurrence analysis highlighting pairs such as Hardcoded Paths/URLs with Duplicates and Inconsistent Dependency Management with Empty/Incomplete Tags.

Significance. If the detection rules prove reliable, the work offers a useful catalog of build-script smells and large-scale prevalence data across four build systems, which could guide practitioners and tool builders in reducing build failures and technical debt. The mixed-methods design, scale of the GitHub corpus, and inclusion of a user study for tool validation are positive features that strengthen the contribution to software engineering research on build maintenance.

major comments (1)
  1. [Abstract and Tool Validation] Abstract and Sniffer validation section: the claim that the user study showed 'higher precision, recall, and F-score' provides no numerical values, no sample size, no inter-rater reliability metric, and no per-smell breakdown. Because the reported 10,895 occurrences and the highlighted co-occurrence associations rest directly on Sniffer's correctness, the absence of these concrete validation details is load-bearing for the quantitative claims.
minor comments (2)
  1. [Methodology] The qualitative analysis process that mapped the 2000 issues onto the final 13 categories could be described with more explicit coding steps or examples to improve reproducibility.
  2. [Results] Consider adding a table or figure that reports the exact precision/recall/F-score numbers once supplied, rather than the qualitative statement 'higher'.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for their constructive and detailed review of our manuscript on code smells in build scripts. We address the major comment below and describe the revisions we will make to strengthen the validation of our tool.

read point-by-point responses
  1. Referee: [Abstract and Tool Validation] Abstract and Sniffer validation section: the claim that the user study showed 'higher precision, recall, and F-score' provides no numerical values, no sample size, no inter-rater reliability metric, and no per-smell breakdown. Because the reported 10,895 occurrences and the highlighted co-occurrence associations rest directly on Sniffer's correctness, the absence of these concrete validation details is load-bearing for the quantitative claims.

    Authors: We agree that the current abstract and validation section do not provide sufficient concrete details on the user study results. In the revised manuscript we will expand the Sniffer validation section to report the exact precision, recall, and F-score values, the sample size of the study (number of participants and scripts evaluated), inter-rater reliability metrics (e.g., Cohen's kappa), and a per-smell breakdown of performance. These additions will directly support the reliability of the 10,895 detections and the co-occurrence findings. revision: yes

Circularity Check

0 steps flagged

No circularity in empirical derivation chain

full rationale

The paper's results derive from a qualitative analysis of 2000 external GitHub issues to identify recurring smells, followed by application of the independently implemented Sniffer tool to a separate corpus of 5882 build scripts from 4877 repositories. The reported 10,895 occurrences, per-language breakdowns, and co-occurrence associations are direct outputs of running the predefined detection rules on this new data. A distinct user study is used only for tool validation and does not redefine the smells or feed back into the counts. No equations, fitted parameters, self-citations, or uniqueness claims reduce any central result to its own inputs by construction; the derivation remains self-contained against external data sources.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

This empirical study introduces no mathematical free parameters or invented physical entities. It rests on domain assumptions about what counts as a code smell in build scripts.

axioms (1)
  • domain assumption Recurring patterns of poor practice in build scripts can be reliably extracted from GitHub issue reports and encoded as static analysis rules.
    The entire smell taxonomy and Sniffer implementation depend on this premise.

pith-pipeline@v0.9.0 · 5864 in / 1319 out tokens · 50266 ms · 2026-05-19T08:32:47.248285+00:00 · methodology

discussion (0)

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

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. What Are Adversaries Doing? Automating Tactics, Techniques, and Procedures Extraction: A Systematic Review

    cs.SE 2026-04 accept novelty 5.0

    Systematic review of 80 papers shows TTP extraction shifting to transformer and LLM methods but limited by narrow datasets, single-label focus, and low reproducibility.

Reference graph

Works this paper leans on

94 extracted references · 94 canonical work pages · cited by 1 Pith paper · 2 internal anchors

  1. [1]

    The dispersion of build maintenance activity across maven lifecycle phases,

    C. D ´esarmeaux, A. Pecatikov, and S. McIntosh, “The dispersion of build maintenance activity across maven lifecycle phases,” in Proceedings of the 13th International Conference on Mining Software Repositories , 2016, pp. 492–495

  2. [2]

    A review of bioinformatic pipeline frameworks,

    J. Leipzig, “A review of bioinformatic pipeline frameworks,” Briefings in bioinformatics, vol. 18, no. 3, pp. 530–536, 2017

  3. [3]

    An empirical study of bugs in software build systems,

    X. Xia, X. Zhou, D. Lo, and X. Zhao, “An empirical study of bugs in software build systems,” in 2013 13th International Conference on Quality Software, 2013, pp. 200–203

  4. [4]

    “Java,” https://www.jetbrains.com/lp/devecosystem-2020/java

  5. [5]

    An empirical study of build maintenance effort,

    S. McIntosh, B. Adams, T. H. Nguyen, Y . Kamei, and A. E. Hassan, “An empirical study of build maintenance effort,” in Proceedings of the 33rd international conference on software engineering , 2011, pp. 141–150

  6. [6]

    Change-aware build prediction model for stall avoidance in continuous integration,

    F. Hassan and X. Wang, “Change-aware build prediction model for stall avoidance in continuous integration,” in 2017 ACM/IEEE Interna- tional Symposium on Empirical Software Engineering and Measurement (ESEM). IEEE, 2017, pp. 157–162

  7. [7]

    The evolution of java build systems,

    S. McIntosh, B. Adams, and A. E. Hassan, “The evolution of java build systems,” Empirical Software Engineering , vol. 17, pp. 578–608, 2012

  8. [8]

    Classification of automatic software build methods

    M. Kawalerowicz, “Classification of automatic software build methods,” arXiv preprint arXiv:1305.4776 , 2013

  9. [9]

    An exploratory study of the impact of code smells on software change-proneness,

    F. Khomh, M. Di Penta, and Y .-G. Gueheneuc, “An exploratory study of the impact of code smells on software change-proneness,” in 2009 16th Working Conference on Reverse Engineering . IEEE, 2009, pp. 75–84

  10. [10]

    Quantifying the effect of code smells on maintenance effort,

    D. I. Sjøberg, A. Yamashita, B. C. Anda, A. Mockus, and T. Dyb ˚a, “Quantifying the effect of code smells on maintenance effort,” IEEE Transactions on Software Engineering , vol. 39, no. 8, pp. 1144–1156, 2012

  11. [11]

    Code-smell detection as a bilevel problem,

    D. Sahin, M. Kessentini, S. Bechikh, and K. Deb, “Code-smell detection as a bilevel problem,” ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 24, no. 1, pp. 1–44, 2014

  12. [12]

    Fowler, Refactoring: improving the design of existing code

    M. Fowler, Refactoring: improving the design of existing code . Addison-Wesley Professional, 1999

  13. [13]

    Technical debt: Showing the way for better transfer of empirical results,

    F. Shull, D. Falessi, C. Seaman, M. Diep, and L. Layman, “Technical debt: Showing the way for better transfer of empirical results,” Perspec- tives on the future of software engineering: essays in honor of Dieter Rombach, pp. 179–190, 2013

  14. [14]

    Do code smells reflect important maintainability aspects?

    A. Yamashita and L. Moonen, “Do code smells reflect important maintainability aspects?” in 2012 28th IEEE international conference on software maintenance (ICSM) . IEEE, 2012, pp. 306–315

  15. [15]

    Do developers care about code smells? an exploratory survey,

    A. Yamashita and Moonen, “Do developers care about code smells? an exploratory survey,” in 2013 20th working conference on reverse engineering (WCRE). IEEE, 2013, pp. 242–251

  16. [16]

    An empirical study on the code refactoring capability of large language models,

    J. Cordeiro, S. Noei, and Y . Zou, “An empirical study on the code refactoring capability of large language models,” arXiv preprint arXiv:2411.02320, 2024

  17. [17]

    A large-scale empirical study of code smells in javascript projects,

    D. Johannes, F. Khomh, and G. Antoniol, “A large-scale empirical study of code smells in javascript projects,” Software Quality Journal, vol. 27, pp. 1271–1314, 2019

  18. [18]

    An empirical study of code smells in javascript projects,

    A. Saboury, P. Musavi, F. Khomh, and G. Antoniol, “An empirical study of code smells in javascript projects,” in 2017 IEEE 24th Interna- tional Conference on Software Analysis, Evolution and Reengineering (SANER), 2017, pp. 294–305

  19. [19]

    Why do builds fail?—a conceptual replication study,

    A. Barrak, E. E. Eghan, B. Adams, and F. Khomh, “Why do builds fail?—a conceptual replication study,” Journal of Systems and Software, vol. 177, p. 110939, 2021

  20. [20]

    On the interplay between non-functional requirements and builds on continuous integration,

    K. V . Paix ˜ao, C. Z. Fel ´ıcio, F. M. Delfim, and M. d. A. Maia, “On the interplay between non-functional requirements and builds on continuous integration,” in 2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR) . IEEE, 2017, pp. 479–482

  21. [21]

    Toward a smell-aware prediction model for ci build failures,

    I. Saidani and A. Ouni, “Toward a smell-aware prediction model for ci build failures,” in 2021 36th IEEE/ACM International Conference on Automated Software Engineering Workshops (ASEW). IEEE, 2021, pp. 18–25

  22. [22]

    The seven sins: Security smells in infrastructure as code scripts,

    A. Rahman, C. Parnin, and L. Williams, “The seven sins: Security smells in infrastructure as code scripts,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019, pp. 164–175

  23. [23]

    Detecting code smells using machine learning techniques: Are we there yet?

    D. Di Nucci, F. Palomba, D. A. Tamburri, A. Serebrenik, and A. De Lu- cia, “Detecting code smells using machine learning techniques: Are we there yet?” in 2018 ieee 25th international conference on software analysis, evolution and reengineering (saner) . IEEE, 2018, pp. 612– 621

  24. [24]

    Understanding the longevity of code smells: preliminary results of an explanatory survey,

    R. Arcoverde, A. Garcia, and E. Figueiredo, “Understanding the longevity of code smells: preliminary results of an explanatory survey,” in Proceedings of the 4th Workshop on Refactoring Tools , 2011, pp. 33–36

  25. [25]

    Assessing the impact of bad smells using historical information,

    A. Lozano, M. Wermelinger, and B. Nuseibeh, “Assessing the impact of bad smells using historical information,” in Ninth international workshop on Principles of software evolution: in conjunction with the 6th ESEC/FSE joint meeting , 2007, pp. 31–34

  26. [26]

    Apache maven project,

    “Apache maven project,” https://maven.apache.org/guides/index.html, Apr 2025

  27. [27]

    Gradle 8.14,

    “Gradle 8.14,” https://docs.gradle.org/current/userguide/getting \ started\ eng.html, 2025

  28. [28]

    CMake Documentation and Community,

    “CMake Documentation and Community,” https://cmake.org/documentation/, 2024

  29. [29]

    GNU make,

    “GNU make,” https://www.gnu.org/software/make/manual/make.html

  30. [30]

    Qualitative study,

    S. Tenny, J. M. Brannan, and G. D. Brannan, “Qualitative study,” 2017

  31. [31]

    Deep learning based code smell detection,

    H. Liu, J. Jin, Z. Xu, Y . Zou, Y . Bu, and L. Zhang, “Deep learning based code smell detection,” IEEE transactions on Software Engineering , vol. 47, no. 9, pp. 1811–1837, 2019

  32. [32]

    Automatic detection of long method and god class code smells through neural source code embeddings,

    A. Kova ˇcevi´c, J. Slivka, D. Vidakovi ´c, K.-G. Gruji ´c, N. Luburi ´c, S. Proki ´c, and G. Sladi ´c, “Automatic detection of long method and god class code smells through neural source code embeddings,” Expert Systems with Applications , vol. 204, p. 117607, 2022

  33. [33]

    Are all code smells harmful? a study of god classes and brain classes in the evolution of three open source systems,

    S. M. Olbrich, D. S. Cruzes, and D. I. Sjøberg, “Are all code smells harmful? a study of god classes and brain classes in the evolution of three open source systems,” in 2010 IEEE international conference on software maintenance. IEEE, 2010, pp. 1–10

  34. [34]

    Does your configuration code smell?

    T. Sharma, M. Fragkoulis, and D. Spinellis, “Does your configuration code smell?” in Proceedings of the 13th international conference on mining software repositories , 2016, pp. 189–200

  35. [35]

    A systematic mapping study of infrastructure as code research,

    A. Rahman, R. Mahdavi-Hezaveh, and L. Williams, “A systematic mapping study of infrastructure as code research,” Information and Software Technology, vol. 108, pp. 65–77, 2019

  36. [36]

    The evolution of the linux build system,

    B. Adams, K. De Schutter, H. Tromp, and W. De Meuter, “The evolution of the linux build system,” Electronic Communications of the EASST , vol. 8, 2008

  37. [37]

    Hirebuild: An automatic approach to history- driven repair of build scripts,

    F. Hassan and X. Wang, “Hirebuild: An automatic approach to history- driven repair of build scripts,” in Proceedings of the 40th international conference on software engineering , 2018, pp. 1078–1089

  38. [38]

    Automated reporting of anti-patterns and decay in continuous integration,

    C. Vassallo, S. Proksch, H. C. Gall, and M. Di Penta, “Automated reporting of anti-patterns and decay in continuous integration,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019, pp. 105–115

  39. [39]

    Buildsonic: Detecting and repairing performance-related configuration smells for continuous integration builds,

    C. Zhang, B. Chen, J. Hu, X. Peng, and W. Zhao, “Buildsonic: Detecting and repairing performance-related configuration smells for continuous integration builds,” in Proceedings of the 37th IEEE/ACM international conference on automated software engineering , 2022, pp. 1–13

  40. [40]

    Detecting bad smells in source code using change history information,

    F. Palomba, G. Bavota, M. Di Penta, R. Oliveto, A. De Lucia, and D. Poshyvanyk, “Detecting bad smells in source code using change history information,” in 2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE) . IEEE, 2013, pp. 268–278

  41. [41]

    A review of code smell mining techniques,

    G. Rasool and Z. Arshad, “A review of code smell mining techniques,” Journal of Software: Evolution and Process , vol. 27, no. 11, pp. 867– 895, 2015

  42. [42]

    A systematic review on the code smell effect,

    J. A. M. Santos, J. B. Rocha-Junior, L. C. L. Prates, R. S. Do Nasci- mento, M. F. Freitas, and M. G. De Mendonc ¸a, “A systematic review on the code smell effect,” Journal of Systems and Software , vol. 144, pp. 450–477, 2018

  43. [43]

    Android source code smells: A systematic literature review,

    M. Fawad, G. Rasool, and F. Palma, “Android source code smells: A systematic literature review,”Software: Practice and Experience, vol. 55, no. 5, pp. 847–882, 2025

  44. [44]

    Xz utils backdoor — everything you need to know, and what you can do,

    “Xz utils backdoor — everything you need to know, and what you can do,” https://www.akamai.com/blog/security-research/critical-linux- backdoor-xz-utils-discovered-what-to-know

  45. [45]

    What is github and what is it used for?

    C. Tozzi, “What is github and what is it used for?” https://www. itprotoday.com/devops/what-github-and-what-it-used, Sep 09 2022

  46. [46]

    A systematic mapping study of software development with github,

    V . Cosentino, J. L. C. Izquierdo, and J. Cabot, “A systematic mapping study of software development with github,” Ieee access , vol. 5, pp. 7173–7192, 2017

  47. [47]

    Developer survey,

    “Developer survey,” https://survey.stackoverflow.co/2024/technology# 1-programming-scripting-and-markup-languages

  48. [48]

    31 code smells all software engineers must watch out for,

    “31 code smells all software engineers must watch out for,” https://pragmaticways.com/31-code-smells-you-must-know/, 2025

  49. [49]

    Machine learning techniques for code smell detection: A systematic literature review and meta-analysis,

    M. I. Azeem, F. Palomba, L. Shi, and Q. Wang, “Machine learning techniques for code smell detection: A systematic literature review and meta-analysis,”Information and Software Technology, vol. 108, pp. 115– 138, 2019

  50. [50]

    Code Smells,

    J. Atwood, “Code Smells,” https://blog.codinghorror.com/code-smells/

  51. [51]

    Static code analysis guide,

    “Static code analysis guide,” https://www.jetbrains.com/pages/static- code-analysis-guide/code-smells

  52. [52]

    The coding manual for qualitative researchers,

    J. Salda ˜na, “The coding manual for qualitative researchers,” 2021

  53. [53]

    Using of jaccard coefficient for keywords similarity,

    S. Niwattanakul, J. Singthongchai, E. Naenudorn, and S. Wanapu, “Using of jaccard coefficient for keywords similarity,” in Proceedings of the international multiconference of engineers and computer scientists , vol. 1, no. 6, 2013, pp. 380–384

  54. [54]

    How many interviews are enough? an experiment with data saturation and variability,

    G. Guest, A. Bunce, and L. Johnson, “How many interviews are enough? an experiment with data saturation and variability,” Field methods , vol. 18, no. 1, pp. 59–82, 2006

  55. [55]

    Coding in- depth semistructured interviews: Problems of unitization and intercoder reliability and agreement,

    J. L. Campbell, C. Quincy, J. Osserman, and O. K. Pedersen, “Coding in- depth semistructured interviews: Problems of unitization and intercoder reliability and agreement,” Sociological methods & research , vol. 42, no. 3, pp. 294–320, 2013

  56. [56]

    Data Availability,

    “Data Availability,” https://figshare.com/s/a01bce3da88efb200781

  57. [57]

    Evaluating Large Language Models Trained on Code

    M. Chen, J. Tworek, H. Jun, Q. Yuan, H. de Oliveira Pinto, J. Kaplan, H. Edwards, Y . Burda, N. Joseph, G. Brockman et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374 , 2021

  58. [58]

    Re- search directions in software supply chain security,

    L. Williams, G. Benedetti, S. Hamer, R. Paramitha, I. Rahman, M. Tamanna, G. Tystahl, N. Zahan, P. Morrison, Y . Acar et al. , “Re- search directions in software supply chain security,” ACM Transactions on Software Engineering and Methodology , 2024

  59. [59]

    Towards an understanding of large language models in software engineering tasks,

    Z. Zheng, K. Ning, Q. Zhong, J. Chen, W. Chen, L. Guo, W. Wang, and Y . Wang, “Towards an understanding of large language models in software engineering tasks,” Empirical Software Engineering , vol. 30, no. 2, p. 50, 2025

  60. [60]

    CWE-Common Weakness Enumeration,

    “CWE-Common Weakness Enumeration,” https://cwe.mitre.org/index.html, 2025

  61. [61]

    Mitigating security issues in github actions,

    H. O. Delicheh and T. Mens, “Mitigating security issues in github actions,” in Proceedings of the 2024 ACM/IEEE 4th International Workshop on Engineering and Cybersecurity of Critical Systems (EnCy- CriS) and 2024 IEEE/ACM Second International Workshop on Software Vulnerability, 2024, pp. 6–11

  62. [62]

    Ambush from all sides: Understanding security threats in open- source software ci/cd pipelines,

    Z. Pan, W. Shen, X. Wang, Y . Yang, R. Chang, Y . Liu, C. Liu, Y . Liu, and K. Ren, “Ambush from all sides: Understanding security threats in open- source software ci/cd pipelines,” IEEE Transactions on Dependable and Secure Computing, vol. 21, no. 1, pp. 403–418, 2023

  63. [63]

    Conditional complexity,

    “Conditional complexity,” https://luzkan.github.io/smells/conditional- complexity

  64. [64]

    Understanding the response to open-source dependency abandonment in the npm ecosystem,

    C. Miller, M. Jahanshahi, A. Mockus, B. Vasilescu, and C. K ¨astner, “Understanding the response to open-source dependency abandonment in the npm ecosystem,” in Int’l Conf. Software Engineering (ICSE), IEEE/ACM, 2025

  65. [65]

    Dlfinder: characterizing and detecting duplicate logging code smells,

    Z. Li, T.-H. Chen, J. Yang, and W. Shang, “Dlfinder: characterizing and detecting duplicate logging code smells,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019, pp. 152–163

  66. [66]

    Duplicated code,

    “Duplicated code,” https://luzkan.github.io/smells/duplicated-code

  67. [67]

    Please stop hard-coding file pathst,

    J. Edmunds, “Please stop hard-coding file pathst,” https://medium.com/

  68. [68]

    Source code properties of defective infrastructure as code scripts,

    A. Rahman and L. Williams, “Source code properties of defective infrastructure as code scripts,” Information and Software Technology , vol. 112, pp. 148–163, 2019

  69. [69]

    Rfc2818: Http over tls,

    E. Rescorla, “Rfc2818: Http over tls,” 2000

  70. [70]

    Introduction to the dependency mechanism,

    “Introduction to the dependency mechanism,” https://maven.apache.org/ guides/introduction/introduction-to-dependency-mechanism.html

  71. [71]

    Using resolution rules,

    “Using resolution rules,” https://docs.gradle.org/current/userguide/ resolution rules.html

  72. [72]

    Thou shalt not depend on me: Analysing the use of outdated javascript libraries on the web,

    T. Lauinger, A. Chaabane, S. Arshad, W. Robertson, C. Wilson, and E. Kirda, “Thou shalt not depend on me: Analysing the use of outdated javascript libraries on the web,” arXiv preprint arXiv:1811.00918, 2018

  73. [73]

    Todo or to bug: Exploring how task annotations play a role in the work prac- tices of software developers,

    M.-A. Storey, J. Ryall, R. I. Bull, D. Myers, and J. Singer, “Todo or to bug: Exploring how task annotations play a role in the work prac- tices of software developers,” in Proceedings of the 30th international conference on Software engineering , 2008, pp. 251–260

  74. [74]

    Drift Alert: Why Your Dependencies Are a Ticking Time Bomb,

    T. Sarker, “Drift Alert: Why Your Dependencies Are a Ticking Time Bomb,” https://medium.com/@tirthasarker/drift-alert-why-your- dependencies-are-a-ticking-time-bomb-34edcbb203d9, 2025

  75. [75]

    A longitudinal analysis of bloated java dependencies,

    C. Soto-Valero, T. Durieux, and B. Baudry, “A longitudinal analysis of bloated java dependencies,” in Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering , 2021, pp. 1021–1031

  76. [76]

    Do the dependency conflicts in my project matter?

    Y . Wang, M. Wen, Z. Liu, R. Wu, R. Wang, B. Yang, H. Yu, Z. Zhu, and S.-C. Cheung, “Do the dependency conflicts in my project matter?” in Proceedings of the 2018 26th ACM joint meeting on european software engineering conference and symposium on the foundations of software engineering, 2018, pp. 319–330

  77. [77]

    Qualitative Research and Computers,

    “Qualitative Research and Computers,” https://uh- dcm.github.io/qualitative-research-and-computers/closed-coding/

  78. [78]

    Inter-coder agreement for computational linguistics,

    R. Artstein and M. Poesio, “Inter-coder agreement for computational linguistics,”Computational linguistics, vol. 34, no. 4, pp. 555–596, 2008

  79. [79]

    A systematic process for mining software repositories: Results from a systematic literature review,

    M. Vidoni, “A systematic process for mining software repositories: Results from a systematic literature review,” Information and Software Technology, vol. 144, p. 106791, 2022

  80. [80]

    Curating github for engineered software projects,

    N. Munaiah, S. Kroh, C. Cabrey, and M. Nagappan, “Curating github for engineered software projects,” Empirical Software Engineering, vol. 22, pp. 3219–3253, 2017

Showing first 80 references.