Hamid Mohayeji

dblp:265/5663 · DBLP profile ↗
← Back
3ranked-venue papers
3as first author
3since 2021 · last 2025
0000-0002-9434-4618ORCID · corroborated

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 3 · 3 first-author · 3 since 2021Databases, data management, data science and information retrieval · 1 · 1 first-author · 1 since 2021
YearPublicationVenuePosition
2025 Security Vulnerabilities in Docker Images: A Cross-Tag Study of Application Dependencies
abstract
Docker containers are widely used in modern enterprise applications and cloud environments for their efficiency, portability, and rapid deployment. As a leading containerization technology, Docker enables applications to be stored as images containing all required runtime dependencies. Nonetheless, the growing popularity of containers has also raised security concerns as the libraries and dependencies included in Docker images can contain security vulnerabilities. Previous research has predominantly focused on operating system vulnerabilities, with some investigations into application vulnerabilities originating from vulnerable dependencies. However, these studies have focused solely on the latest tag (version) of each Docker image repository, without offering insights into the prevalence and potential resolution of vulnerabilities across different releases. This limitation restricts our understanding of how effectively they are managed over time. In this study, we investigate the prevalence of vulnerable JavaScript packages within Docker containers across multiple release tags. Our time-based analysis enables us to assess the extent to which maintainers resolve these vulnerabilities in subsequent releases, as well as the time required to address them. We analyzed$\mathbf{6, 2 9 2}$unique images gathered from 1,573 active repositories. Our findings indicate that the majority of Docker images contain multiple vulnerabilities across various tags. Nearly 61 % of repositories have vulnerabilities in every examined tag. While some of these vulnerabilities are resolved by maintainers in subsequent releases, many remain unaddressed within our observation timeframe. Moreover, we found that only 10 % of vulnerabilities are typically addressed within the first 6 months, leaving many unattended for considerably longer durations. We also discovered that common repository attributes, including popularity, contributor count, and automation usage, have no significant effect on the timeliness of vulnerability resolution.
Hamid Mohayeji, Eleni Constantinou, Alexander Serebrenik
ICSME1
2025 Securing dependencies: A comprehensive study of Dependabot's impact on vulnerability mitigation
abstract
Abstract The growing use of third-party libraries in software development poses a hidden security risk, as vulnerabilities in these libraries can easily spread to dependent applications. Project maintainers must remain vigilant regarding updates and patches for these external libraries, a responsibility that is facilitated by automated tools, also known as bots . This study centers on Dependabot, a widely adopted bot that offers security and version updates. We aim to scrutinize the impact of Dependabot on mitigating vulnerabilities arising from dependencies, preventing potential prolonged security issues in open-source software. We investigate how developers react to security updates provided by Dependabot within engineered and actively maintained JavaScript projects. We also delve into how project attributes, including the integration of tests and continuous integration (CI) tools, influence the acceptance rate of security updates. Additionally, we perform a detailed analysis of the lifespan of each vulnerability to demonstrate how they are dealt with when Dependabot is in use. Our findings reveal a significant reliance on Dependabot by developers for managing security vulnerabilities in dependencies, with most updates being merged swiftly within days. We find that projects equipped with tests and CI tools are more likely to merge security updates. Conversely, when developers opt not to merge a security update, they often manually address the identified vulnerability. This manual approach, however, could span over several months, potentially exposing projects to security risks. Crucially, in many instances, the manual fixes are potentially inspired by earlier security updates, underscoring Dependabot’s pivotal role in safeguarding dependencies.
Hamid Mohayeji, Andrei Agaronian, Eleni Constantinou, Nicola Zannone, Alexander Serebrenik
Empir. Softw. Eng.1
2023 Investigating the Resolution of Vulnerable Dependencies with Dependabot Security Updates
abstract
Modern software development practices increasingly rely on third-party libraries due to the inherent benefits of reuse. However, libraries may contain security vulnerabilities that can propagate to the dependent applications. To counter this, maintainers of dependent projects should monitor their dependencies and security reports to ensure that only patched releases of the upstream applications are in use. As manual maintenance of dependencies has shown to be ineffective, several automated tools (aka bots) have been proposed to assist developers in rapidly identifying and resolving vulnerable dependencies. In this work, we focus on Dependabot, a popular bot providing security and version updates, and study developers’ receptivity to its security updates in engineered and actively maintained JavaScript projects. Moreover, we carry out a fine-grained analysis of the lifecycle of every vulnerability to manifest how they are dealt with in the presence of Dependabot. Our findings show that the task of fixing vulnerable dependencies is, to a large extent, delegated to Dependabot and that developers merge the majority of security updates within several days. On the other hand, when developers do not merge a security update, they usually address the identified vulnerability manually. This approach, however, often takes up to several months which in turn could expose the projects to security issues.
Hamid Mohayeji, Andrei Agaronian, Eleni Constantinou, Nicola Zannone, Alexander Serebrenik
MSR1