Containerization has become increasingly essential in the machine learning (ML) domain, providing reproducibility, portability, and environment consistency. While prior studies have analyzed Dockerfile structures and best practices, none have examined ML projects in depth to reveal how the iterative nature of ML workflows influences container footprint, build performance, and caching behavior.

The rapid emergence of the Model Context Protocol (MCP) has introduced a new standard for connecting large language models to external tools and services. Despite its rapid adoption in open-source development, systematic understanding of how MCP is implemented, structured, and maintained remains limited. This study presents the first large-scale, evidence-based dataset of real-world MCP implementation collected directly from GitHub. Using a hybrid pipeline that integrates the GitHub REST and GraphQL APIs with custom Python verification scripts, 3,238 candidate repositories were discovered, filtered, and validated through multi-stage evidence checks. Each verified project was classified by operational role (e.g., client, server, gateway) and exported in a reproducible JSONL schema. A manual review of a representative subset confirmed an overall precision of 83% at a 95% confidence level, and additionally revealed a set of repositories functioning primarily as educational samples, tutorials, or demonstration templates. A targeted exclusion rule was then applied to remove these non-operational repositories, resulting in a final dataset of 2,297 validated MCP projects. The analysis shows that Python and TypeScript dominate MCP development, with hybrid architectures emerging as the most common design pattern. By emphasizing transparent verification strategies, structured evidence tagging, and reproducible data organization, this work establishes a foundational benchmark for studying real-world MCP ecosystems and supports future research on integration, connectivity, and compatibility across the broader developer community.

Docker-based software containerization has recently emerged as the de facto standard for delivering reusable software artifacts. With a plethora of publicly available Docker images, developers can easily build and deploy their applications, resulting in an industry-wide shift toward containerized solutions. Container-based projects, on the other hand, include several components, such as the Docker and Docker-compose files, as well as several dependencies in the source code, combining different containers and simplifying interactions with them. Like any other complex system, Container-based projects are prone to multiple quality and technical debt issues relating to several artifacts, namely, Docker and Docker-compose files. In a previous work, we conducted the first foundational study on refactorings, i.e., structural changes, while preserving the behavior applied in open-source Docker projects and the technical debt issues they alleviate. The findings suggest that developers refactor these Docker projects for a variety of reasons specific to the configuration, combination, and execution of containers. We defined different best practices and introduced 24 new Dockerspecific refactorings and 7 technical debt categories. In this paper, we extend our prior study by expanding the dataset nearly sixfold, from 68 to 443 projects, and refining our selection methodology. These changes reveal 17 additional Docker-specific refactorings, bringing our catalog to 41 distinct mechanisms, and introduce two new technical-debt categories, for a total of nine. We also derive 48 role-aware (Dev vs. Ops) recommendations and quantify the operational impact of refactorings on release-image size and build time, analyzing size–time trade-offs.These extensions not only expand the known landscape of Docker-specific quality issues but also provide deeper insights into how practitioners manage and alleviate technical debt in container environments.

Docker, the industry standard for packaging and deploying applications, leverages Infrastructure as Code (IaC) principles to facilitate the creation of images through Dockerfiles. However, maintaining Dockerfiles presents significant challenges. Refactoring, in particular, is often a manual and complex process. This paper explores the utility and practicality of automating Dockerfile refactoring using 600 Dockerfiles from 358 opensource projects. Our study reveals that Dockerfile image size and build duration tend to increase as projects evolve, with developers often postponing refactoring efforts until later stages in the development cycle. This trend motivates the automation of refactoring. To achieve this, we leverage In Context Learning (ICL) along with a score-based demonstration selection strategy. Our approach leads to an average reduction of 32% in image size and a 6% decrease in build duration, with improvements in understandability and maintainability observed in 77% and 91% of cases, respectively. Additionally, our analysis shows that automated refactoring reduces Dockerfile image size by 2x compared to manual refactoring and 10x compared to smellfixing tools like PARFUM. This work establishes a foundation for automating Dockerfile refactoring, indicating that such automation could become a standard practice within CI/CD pipelines to enhance Dockerfile quality throughout every step of the software development lifecycle.

Serverless computing significantly alters software development by abstracting infrastructure management and enabling rapid, modular, event-driven deployments. Despite its benefits, the distinct characteristics of serverless functions, such as ephemeral execution and fine-grained scalability, pose unique security challenges, particularly in open-source platforms like OpenFaaS. Existing approaches typically address isolated phases of the DevSecOps lifecycle, lacking an integrated and comprehensive security strategy. To bridge this gap, we propose FaaSGuard, a unified DevSecOps pipeline explicitly designed for open-source serverless environments. FaaSGuard systematically embeds lightweight, fail-closed security checks into every stage of the development lifecycle—planning, coding, building, deployment, and monitoring—effectively addressing threats such as injection attacks, hard-coded secrets, and resource exhaustion. We validate our approach empirically through a case study involving 20 real-world serverless functions from public GitHub repositories. Results indicate that FaaSGuard effectively detects and prevents critical vulnerabilities, demonstrating high precision (95%) and recall (91%) without significant disruption to established CI/CD practices.

Software containerization using Docker has recently become the de facto standard for delivering reusable software artifacts. Integral to Docker's functionality are Dockerfiles, which serve as scripts that define the layers and components to be incorporated within a container. Although these files serve as the bedrock of container creation, their maintenance presents intricate challenges. Specifically, the task of Dockerfile refactoring is compounded by its inherent complexity. Although the importance of refactoring inside Docker ecosystems is apparent, detecting it remains challenging. Developers usually avoid documenting their refactoring efforts, often combining them with other changes.

Software containers, such as Docker, are recently considered as the mainstream technology of providing reusable software artifacts. Developers can easily build and deploy their applications based on the large number of reusable Docker images that are publicly available. Thus, a current popular trend in industry is to move towards the containerization of their applications. However, container-based projects compromise different components including the Docker and Docker-compose files, and several other dependencies to the source code combining different containers and facilitating the interactions with them. Similar to any other complex systems, container-based projects are prone to various quality and technical debt issues related to different artifacts: Docker and Docker-compose files, and regular source code ones. Unfortunately, there is a gap of knowledge in how container-based projects actually evolve and are maintained.In this paper, we address the above gap by studying refactorings, i.e., structural changes while preserving the behavior, applied in open-source Docker projects, and the technical debt issues they alleviate. We analyzed 68 projects, consisting of 19,5 MLOC, along with 193 manually examined commits. The results indicate that developers refactor these Docker projects for a variety of reasons that are specific to the configuration, combination and execution of containers, leading to several new technical debt categories and refactoring types compared to existing refactoring domains. For instance, refactorings for reducing the image size of Dockerfiles, improving the extensibility of Docker-compose files, and regular source code refactorings are mainly associated with the evolution of Docker and Docker-compose files. We also introduced 24 new Docker-specific refactorings and technical debt categories, respectively, and defined different best practices. The implications of this study will assist practitioners, tool builders, and educators in improving the quality of Docker projects.