Context: Security is vital to software developed for commercial or personal use. Although more organizations are realizing the importance of applying secure coding practices, in many of them, security concerns are not known or addressed until a security failure occurs. The root cause of security failures is vulnerable code. While metrics have been used to predict software vulnerabilities, we explore the relationship between code and architectural smells with security weaknesses. As smells are surface indicators of a deeper problem in software, determining the relationship between smells and software vulnerabilities can play a significant role in vulnerability prediction models. Objective: This study explores the relationship between smells and software vulnerabilities to identify the smells. Method: We extracted the class, method, file, and package level smells for three systems: Apache Tomcat, Apache CXF, and Android. We then compared their occurrences in the vulnerable classes which were reported to contain vulnerable code and in the neutral classes (non-vulnerable classes where no vulnerability had yet been reported). Results: We found that a vulnerable class is more likely to have certain smells compared to a non-vulnerable class. God Class, Complex Class, Large Class, Data Class, Feature Envy, Brain Class have a statistically significant relationship with software vulnerabilities. We found no significant relationship between architectural smells and software vulnerabilities. Conclusion: We can conclude that for all the systems examined, there is a statistically significant correlation between software vulnerabilities and some smells.

Context: Software security is an imperative aspect of software quality. Early detection of vulnerable code during development can better ensure the security of the codebase and minimize testing efforts. Although traditional software metrics are used for early detection of vulnerabilities, they do not clearly address the granularity level of the issue to precisely pinpoint vulnerabilities. The goal of this study is to employ method-level traceable patterns (nano-patterns) in vulnerability prediction and empirically compare their performance with traditional software metrics. The concept of nano-patterns is similar to design patterns, but these constructs can be automatically recognized and extracted from source code. If nano-patterns can better predict vulnerable methods compared to software metrics, they can be used in developing vulnerability prediction models with better accuracy. Aims: This study explores the performance of method-level patterns in vulnerability prediction. We also compare them with method-level software metrics. Method: We studied vulnerabilities reported for two major releases of Apache Tomcat (6 and 7), Apache CXF, and two stand-alone Java web applications. We used three machine learning techniques to predict vulnerabilities using nano-patterns as features. We applied the same techniques using method-level software metrics as features and compared their performance with nano-patterns. Results: We found that nano-patterns show lower false negative rates for classifying vulnerable methods (for Tomcat 6, 21% vs 34.7%) and therefore, have higher recall in predicting vulnerable code than the software metrics used. On the other hand, software metrics show higher precision than nano-patterns (79.4% vs 76.6%). Conclusion: In summary, we suggest developers use nano-patterns as features for vulnerability prediction to augment existing approaches as these code constructs outperform standard metrics in terms of prediction recall.

Context: It is important to maintain software quality as a software system evolves.Managing code smells in source code contributes towards quality software.While metrics have been used to pinpoint code smells in source code, we present an empirical study on the correlation of code smells with class-level (micro pattern) and methodlevel (nano-pattern) traceable patterns of code.Objective: This study explores the relationship between code smells and class-level and method-level structural code constructs.Method: We extracted micro patterns at the class level and nano-patterns at the method level from three versions of Apache Tomcat and PersonalBlog and Roller from Standford SecuriBench and compared their distributions in code smell versus non-code smell classes and methods.Result: We found that DataM anager, Record and Outline micro patterns are more frequent in classes having code smell compared to non-code smell classes in the applications we analyzed.localReader, localW riter, Switcher, and ArrReader nano-patterns are more frequent in code smell methods compared to the non-code smell methods.Conclusion: We conclude that code smells are correlated with both micro and nano-patterns.

It is important to maintain software quality as a software system evolves. Managing code smells in source code contributes towards quality software. While metrics have been used to pinpoint code smells in source code, we present an empirical study on the correlation of code smells with class-level (micro pattern) and method-level (nano-pattern) traceable code patterns. This study explores the relationship between code smells and class-level and method-level structural code constructs. We extracted micro patterns at the class level and nano-patterns at the method level from three versions of Apache Tomcat, three versions of Apache CXF and two J2EE web applications namely PersonalBlog and Roller from Stanford SecuriBench and then compared their distributions in code smell versus noncode smell classes and methods. We found that Immutable and Sink micro patterns are more frequent in classes having code smells compared to the noncode smell classes in the applications we analyzed. On the other hand, LocalReader and LocalWriter nano-patterns are more frequent in code smell methods compared to the noncode smell methods. We conclude that code smells are correlated with both micro and nano-patterns.

Abstract Context Technical debt refers to the consequences of taking shortcuts when developing software. These consequences can impede the software growth and have financial implications. The software engineering research community needs to explore technical debt further from a practitioner standpoint. Objective This study gathers insights from practitioners on key components of technical debt such as its definition, characterization, consequences, benefits, and how it is communicated. Method We conducted semi‐structured interviews with a convenience sample of 17 practitioners and a survey of 67 participants. Results Despite the lack of consensus, we identified the most commonly accepted definition, method to measure technical debt (as person hours), and method to reduce debt (by allocating time in iterations to address the debt). Defects were also identified as type of debt and the cost of technical debt is more than the cost to make changes to source code. Three distinct company profiles emerged. Conclusion Despite increasing research on technical debt, the field lacks consensus on its many facets. One interesting outcome of this study is how to assess the risks of technical debt by evaluating liabilities beyond costs of directly handling debt.

Security breaches in software systems cause massive financial and reputation losses to organizations and put their customers at risk by having their confidential data stolen. Delivering proper software security training to software developers is key to prevent such breaches. Conventional training methods do not take into account the code written by developers. The recommender system described in this paper analyzes developer code for security vulnerabilities and recommends mitigation strategies specific to each developer based on the detected vulnerabilities. The system utilizes a public vulnerability repository as its knowledge base. Such mitigation strategies are platform independent, giving further strength to the utility of the system. This paper extends our previous work and describes a human subject evaluation conducted to determine the usefulness of the system. Our evaluation suggests that this system successfully retrieves relevant training articles from the public vulnerability repository and human subjects found these articles to be suitable for training. The recommender system was found to be as effective as a commercial tool.

Software security plays a significant role in ensuring software quality. The goal of this study is to conduct a preliminary analysis to find hidden relationships between source code patterns and security defects. We describe a study in which we focus on evaluating software security using nano-patterns to reduce security risks during the development lifecycle. Nano-patterns are simple properties of Java methods. In our research, we investigate the correlation between software vulnerabilities and nano-patterns using data mining techniques. Identifying these relationships can assist developers to quickly assess the likelihood that they are writing vulnerable code and recommend tests to uncover the vulnerability. The goal of this research is to reduce the amount of vulnerable code developers write. We successfully apply data mining techniques to identify vulnerable code characteristics and apply hypothesis testing to validate the findings. This preliminary study shows that certain nano-patterns localReader, jdkClient, tailCaller are significantly present in vulnerable methods. These findings can be used to recommend security test patterns to improve vulnerability testing and reduce the number of vulnerabilities in released code.

With today's ever increasing demands on software, developers must produce software that can be changed without the risk of degrading the software architecture. Degraded software architecture is problematic because it makes the system more prone to defects and increases the cost of making future changes. The effects of making changes to software can be difficult to measure. One way to address software changes is to characterize their causes and effects. This paper introduces an initial architecture change characterization scheme created to assist developers in measuring the impact of a change on the architecture of the system. It also presents an initial study conducted to gain insight into the validity of the scheme. The results of this study indicated a favorable view of the viability of the scheme by the subjects, and the scheme increased the ability of novice developers to assess and adequately estimate change effort.