In an industry dominated by straight men, many developers representing other gender identities and sexual orientations often encounter hateful or discriminatory messages. Such communications pose barriers to participation for women and LGBTQ+ persons. Due to sheer volume, manual inspection of all communications for discriminatory communication is infeasible for a large-scale Free Open Source Software (FLOSS) community. To address this challenge, this study proposes an automated mechanism to identify Sexual Orientation and Gender Identity Discriminatory (SGID) texts in software developers’ communications. On this goal, we trained and evaluated SGID4SE (Sexual orientation and Gender Identity Discriminatory text identification for (4) Software Engineering texts), a supervised learning-based tool. SGID4SE incorporates six preprocessing steps and 10 state-of-the-art algorithms. SGID4SE employs six distinct strategies to enhance the performance of the minority class. We empirically evaluated each strategy and identified an optimum configuration for each algorithm. In our ten-fold cross-validation-based evaluations, a BERT-based model achieves the best performance with 85.9% precision, 80.0% recall, and 82.9% F1-score for the SGID class. This model achieves 95.7% accuracy and a Matthews Correlation Coefficient of 80.4%. Our dataset and tool establish a foundation for further research in this direction.

This study investigates the software vulnerability resolution time in the Maven ecosystem, focusing on the influence of CVE severity, library popularity as measured by the number of dependents, and version release frequency. The results suggest that critical vulnerabilities are addressed slightly faster compared to lower-severity ones. Library popularity shows a positive impact on resolution times, while frequent version updates are associated with faster vulnerability fixes. These statistically significant findings are based on a thorough evaluation of over 14 million versions from 658,078 libraries using the dependency graph database of Goblin framework. These results emphasize the need for proactive maintenance strategies to improve vulnerability management in open-source ecosystems.

Vulnerabilities in software libraries and reusable components cause major security challenges, particularly in dependency-heavy ecosystems such as Maven. This paper presents a large-scale analysis of vulnerabilities in the Maven ecosystem using the Goblin framework. Our analysis focuses on the aspects and implications of vulnerability types, documentation delays, and resolution timelines. We identify 77,393 vulnerable releases with 226 unique CWEs. On average, vulnerabilities take nearly half a decade to be documented and 4.4 years to be resolved, with some remaining unresolved for even over a decade. The delays in documenting and fixing vulnerabilities incur security risks for the library users emphasizing the need for more careful and efficient vulnerability management in the Maven ecosystem.

During code reviews, software developers often raise security concerns if they find any. Ignoring such concerns can bring a severe impact on the performance of a software product. This risk can be reduced if we can automatically identify such code reviews that trigger security concerns so that we can perform additional scrutiny from the security experts. Therefore, the objective of this study is to develop an automated tool to identify code reviews that trigger security concerns.

Peer code review has been found to be effective in identifying security vulnerabilities. However, despite practicing mandatory code reviews, many Open Source Software (OSS) projects still encounter a large number of post-release security vulnerabilities, as some security defects escape those. Therefore, a project manager may wonder if there was any weakness or inconsistency during a code review that missed a security vulnerability. Answers to this question may help a manager pinpointing areas of concern and taking measures to improve the effectiveness of his/her project's code reviews in identifying security defects. Therefore, this study aims to identify the factors that differentiate code reviews that successfully identified security defects from those that missed such defects. With this goal, we conduct a case-control study of Chromium OS project. Using multi-stage semi-automated approaches, we build a dataset of 516 code reviews that successfully identified security defects and 374 code reviews where security defects escaped. The results of our empirical study suggest that the are significant differences between the categories of security defects that are identified and that are missed during code reviews. A logistic regression model fitted on our dataset achieved an AUC score of 0.91 and has identified nine code review attributes that influence identifications of security defects. While time to complete a review, the number of mutual reviews between two developers, and if the review is for a bug fix have positive impacts on vulnerability identification, opposite effects are observed from the number of directories under review, the number of total reviews by a developer, and the total number of prior commits for the file under review.

Prior studies found peer code review useful in identifying security defects. That is why most of the commercial and open-source software (OSS) projects embraced peer code review and mandated the use of it in the software development life cycle. However, despite conducting mandatory peer code review practices, many security-critical OSS projects such as Chromium, Mozilla, and Qt are reporting a high number of post-release vulnerabilities to the Common Vulnerabilities and Exposures (CVE) database. Practitioners may wonder if there is any missing piece in the puzzle that leads code reviews to miss those security defects. Therefore, the primary objective of this dissertation study is to improve the effectiveness of peer code review in identifying security defects.

As most of the software development organizations are male-dominated, many female developers encounter negative workplace experiences and report feeling like they “do not belong”. Exposures to discriminatory expletives or negative critiques from their male colleagues may further exacerbate those feelings. The primary goal of this study is to identify the differences in expressions of sentiments between male and female developers during various software engineering tasks. On this goal, we mined the code review repositories of six popular open source projects. We used a semi-automated approach leveraging the name as well as multiple social networks to identify the gender of a developer. Using SentiSE, a customized and state-of-the-art sentiment analysis tool for the software engineering domain, we classify each communication as negative, positive, or neutral. We also compute the frequencies of sentiment words, emoticons, and expletives used by each developer. Our results suggest that the likelihood of using sentiment words, emoticons, and expletives during code reviews varies based on the gender of a developer, as females are significantly less likely to express sentiments than males. Although female developers were more neutral to their male colleagues than to another female, male developers from three out of the six projects were not only writing more frequent negative comments but also withholding positive encouragements from their female counterparts. Our results provide empirical evidence of another factor behind the negative work place experiences encountered by the female developers that may be contributing to the diminishing number of females in the SE industry.