Search for: All records

Despite yielding benefits for organizations, infrastructure as code (IaC) scripts are susceptible to security weaknesses, such as hard-coded passwords. Existence of such security weaknesses necessitate integration of education materials related to secure development of IaC scripts. In this preliminary work, we describe our experiences of how application of authentic learning helped students learn about secure development of IaC scripts. Our paper shows education materials based on authentic learning to help students learn about secure IaC development. 

Context: Supervised learning-based projects (SLPs), i.e., software projects that use supervised learning algorithms, such as decision trees are useful for performing classification-related tasks. Yet, security weaknesses, such as the use of hard-coded passwords in SLPs, can make SLPs susceptible to security attacks. A characterization of security weaknesses in SLPs can help practitioners understand the security weaknesses that are frequent in SLPs and adopt adequate mitigation strategies. Objective: The goal of this paper is to help practitioners securely develop supervised learning-based projects by conducting an empirical study of security weaknesses in supervised learning-based projects. Methodology: We conduct an empirical study by quantifying the frequency of security weaknesses in 278 open source SLPs. Results: We identify 22 types of security weaknesses that occur in SLPs. We observe ‘use of potentially dangerous function’ to be the most frequently occurring security weakness in SLPs. Of the identified 3,964 security weaknesses, 23.79% and 40.49% respectively, appear for source code files used to train and test models. We also observe evidence of co-location, e.g., instances of command injection co-locates with instances of potentially dangerous function. Conclusion: Based on our findings, we advocate for a shift left approach for SLP development with security-focused code reviews, and application of security static analysis. 

Machine learning (ML) operations or MLOps advocates for integration of DevOps- related practices into the ML development and deployment process. Adoption of MLOps can be hampered due to a lack of knowledge related to how development tasks can be automated. A characterization of bot usage in ML projects can help practitioners on the types of tasks that can be automated with bots, and apply that knowledge into their ML development and deployment process. To that end, we conduct a preliminary empirical study with 135 issues reported mined from 3 libraries related to deep learning: Keras, PyTorch, and Tensorflow. From our empirical study we observe 9 categories of tasks that are automated with bots. We conclude our work-in-progress paper by providing a list of lessons that we learned from our empirical study. 

The programming language Julia is designed to solve the 'two language problem', where developers who write scientific software can achieve desired performance, without sacrificing productivity. Since its inception in 2012, developers who have been using other programming languages have transitioned to Julia. A systematic investigation of the questions that developers ask about Julia can help in understanding the challenges that developers face while using Julia. Such understanding can be helpful (i) for toolsmiths who can construct tools so that developers can maximize their experience of using Julia, and (ii) for Julia language maintainers with empirical evidence on areas to improve the language as well as the Julia ecosystem. We conduct an empirical study with 3,093 Stack Overflow posts where we identify 13 categories of questions related to Julia-based software development. We observe developers to ask about a diverse set of topics, such as GC, Julia's garbage collector, JuMP, a domain-specific language constructed using Julia, and symbols, a metaprogramming utility in Julia. Based on our emerging results, we recommend enhancing support for developers with Julia-based tools and techniques for cross language transfer, type-related assistance, and package resolution. 

Since its inception in 2011, Elixir has emerged as a popular programming language. Currently, Elixir is used in a diverse set of domains, such as instant messaging, smart farming, and e-commerce. Usage of Elixir in above-mentioned domains necessitates gaining an understanding of the state of vulnerabilities that are reported for Elixir programs. An empirical analysis of vulnerability-related commits, i.e., commits that indicate action taken to mitigate vulnerabilities, can help us understand how frequently vulnerabilities appear in Elixir programs. Such understanding can also be a starting point to integrate secure software development practices into the Elixir ecosystem. We conduct an empirical study where we mine 4,446 commits from 25 open source Elixir repositories from GitHub. Our findings show that (i) 2.0% of the 4,446 commits are vulnerability-related, (ii) 18.0% of the 1,769 Elixir programs in our dataset are modified in vulnerability-related commits, and (iii) the proportion of vulnerability-related commits is highest in 2020. Despite Elixir being perceived as a 'safe' language, our empirical study shows programs written in Elixir to contain vulnerabilities. Based on our findings, we recommend researchers to investigate the root causes of introducing vulnerabilities in Elixir programs. 

Infrastructure as code (IaC) scripts, such as Ansible scripts, are used to provision computing infrastructure at scale. Existence of bugs in IaC test scripts, such as, configuration and security bugs, can be consequential for the provisioned computing infrastructure. A characterization study of bugs in IaC test scripts is the first step to understand the quality concerns that arise during testing of IaC scripts, and also provide recommendations for practitioners on quality assurance. We conduct an empirical study with 4,831 Ansible test scripts mined from 104 open source software (OSS) repositories where we quantify bug frequency, and categorize bugs in test scripts. We further categorize testing patterns, i.e., recurring coding patterns in test scripts, which also correlate with appearance of bugs. From our empirical study, we observe 1.8% of 4,831 Ansible test scripts to include a bug, and 45.2% of the 104 repositories to contain at least one test script that includes bugs. We identify 7 categories of bugs, which includes security bugs and performance bugs that are related with metadata extraction. We also identify 3 testing patterns that correlate with appearance of bugs: 'assertion roulette’, 'local only testing’, and 'remote mystery guest‘. Based on our findings, we advocate for detection and mitigation of the 3 testing patterns as these patterns can have negative implications for troubleshooting failures, reproducible deployments of software, and provisioning of computing infrastructure. 

Infrastructure as Code (IaC) scripts, such as Puppet scripts, provide practitioners the opportunity to provision computing infrastructure automatically at scale. Poorly written IaC scripts impact various facets of quality (such as security and maintainability) and, in turn, may lead to serious consequences. Many of the ill-effects can be avoided or rectified easily by following recommendations derived from research and best practices gleaned from experience. While researchers have investigated methods to improve quality aspects of Puppet scripts, such research needs to be summarized and synthesized for industry practitioners. In this article, we summarize recent research in the IaC domain by discussing key quality issues, specifically security and maintainability smells, that may arise in an IaC script. We also mine open-source repositories from three organizations (Mozilla, Openstack, and Wikimedia) and report our observations on the identified smells. Furthermore, we also synthesize recommendations from the literature for software practitioners that could improve the quality of IaC scripts. Software development teams dealing with large computing infrastructure can get benefited from the actionable recommended practices. In addition, researchers in the domain may use this study to find opportunities to improve the state-of-the-art. 

This Innovative Practice, work in progress (WIP) paper presents our experience related to two exercises that focus on automated security static analysis, a practice used to integrate security into development and operations (DevOps). The concept has gained popularity amongst information technology (IT) organizations. However, security-related concerns, such as security weaknesses in DevOps artifacts can cause serious consequences. Our preliminary findings indicate that (i) students positively perceive the introduced exercises; and (ii) the students perform well if they are provided necessary background on the exercises. Our WIP paper lays the groundwork to build course materials that will facilitate development, deployment, and dissemination of DevOps-related education materials that also incorporate cybersecurity concepts. 

Despite being beneficial in automated provisioning of computing infrastructure at scale, infrastructure as code (IaC) scripts are susceptible to containing secrets, such as hard-coded passwords. A derivation of practices related to secret management for IaC can help practitioners to secure their secrets, potentially aiding them to securely develop IaC scripts. The goal of the paper is to help practitioners in secure development of infrastructure as code (IaC) scripts by identifying practices for secret management in IaC. We conduct a grey literature review with 38 Internet artifacts to identify 12 practices. We identify practices that are applicable for all IaC languages, e.g., prioritized encryption, as well as language-specific practices, such as state separation for Terraform. Our findings can be beneficial for (i) practitioners who can apply the identified practices to secure secrets in IaC development, and (ii) researchers who can investigate how the secret management process can be improved to facilitate secure development of IaC scripts. 

The ubiquitous use of software in critical systems necessitates integrating cybersecurity concepts into the software engineering curriculum so that students studying software engineering have adequate knowledge to securely develop software projects, which could potentially secure critical systems. An experience report of developing and conducting a course can help educators to gain an understanding of student preferences on topics related to secure software development. We provide an experience report related to the ‘Secure Software Development’ course conducted at Tennessee Technological University. We discuss student motivations, as well as positive and negative perceptions of students towards exercises. Based on our findings, we recommend educators to integrate real-world exercises into a secure software development course with careful consideration of tool documentation, balance in exercise diversity, and student background.