Ensuring security in open source software starts before a line of code is written. What role should communities and developers play?

Open source projects are used in commercial products by many companies, from Microsoft and Google to Red Hat. The developers behind these projects and their user accounts are the first element in the supply chain, making their security crucial for maintaining trust and a good reputation. However, these developers are often independent, and essentially anyone can start contributing to open source projects. Since these independent developers are not bound by any company IT security policies, they may not use secure authentication, which means their accounts may be at risk of being misused or stolen. The impact of a compromised developer account can be substantial, given the large number of project users.

Several high-profile incidents in open source projects have shown that weak authentication can lead to account misuse or theft.

Supply chain attacks are a concern for proprietary software as well. A notable example is the 2020 sophisticated attack on SolarWinds, which highlighted the vulnerability of such systems. In early 2021, Microsoft disclosed a critical vulnerability in its Exchange Server to selected security partners, but there were signs that this information was later leaked without authorization. These incidents have seriously undermined trust in the contributors involved in the software development process, given their widespread impact on customers. Several high-profile incidents in open source projects have shown that weak authentication can lead to account misuse or theft. For example, the ctx project, available through the Python Package Index (PyPI), was compromised and replaced with malicious software following an account takeover. Similarly, security researchers were able to regain control of a widely used package in the npm (JavaScript package manager) repository by reclaiming an expired domain. These are not isolated incidents, but part of a broader pattern of security issues in open source ecosystems.

Since there may be no formal security policy for a project and user accounts, it is important to consider users’ perceptions of proper account security and authentication mechanisms. Users are more likely to adopt secure behaviors if they perceive them as meaningful and usable. To better understand user behavior in open source projects, we conducted two user studies. We focused on a specific aspect of upstream development: user authentication. For this purpose, we chose GitHub as the platform for open source projects, given that it is one of the most widely used development platforms.

What 2FA methods on GitHub are used, and how are they perceived

The goal of the first study was to map the usage of authentication methods on GitHub and to understand how these methods are perceived by two groups: people who do not use the methods and those who are current users. The study was conducted online in November 2020 among Red Hat employees who volunteered to participate based on an invitation email sent to the mailing list. We collected data from 83 participants. We discovered that most users primarily use two-factor authentication (2FA) and consider usernames and passwords to be the most user-friendly method. In terms of security, hardware and software tokens were seen as the most secure options. However, the use of a third-party service for fallback authentication (via Facebook, which is no longer offered by GitHub) was generally not favored. You can find more information in the RHRQ article “User authentication for open source developers: what do they use?” (Aug. 2021) and in the conference paper “Authentication of IT professionals in the wild: a survey”(Security Protocols XXVIII, Oct. 2023).

GitHub announcement

However, in May 2022, GitHub announced plans to enforce two-factor authentication for contributors by the end of 2023 (and later extended this deadline to 2024 for some user accounts). They also reported that “only approximately 16.5% of active GitHub users and 6.44% of npm users use one or more forms of 2FA.” This finding contrasts with our first study, where we discovered that 81% of participants used 2FA. However, our sample consisted only of people contributing to public projects.  Also, our participants were employees of an open source-friendly company (in the first study) or attendees of an open source conference (in the second study). This suggests that we did not investigate the representative sample of GitHub users.

Perception of 2FA

In our second, follow-up study, we examined user perceptions of GitHub’s planned 2FA enforcement. Additionally, we investigated the role of authentication in the context of other security measures that can be implemented to enhance project security. 

While discussing the results from the first study during an academic workshop and DevConf talk, some attendees questioned why we did not consider commit signing. While we believe that commit signing is also an important security measure, it serves a different purpose than user authentication. Our goal was to understand whether developers recognize that different security measures address different aspects of security, emphasizing the importance of authentication.

To improve the response rate in the second study and leverage the opportunity for personal contact, which may be more engaging, we continued our investigation at the 2023 Red Hat-sponsored DevConf.CZ in Brno, Czech Republic, with a research booth from Masaryk University. DevConf.CZ participants were invited to take part in the survey and were rewarded with merchandise provided by Red Hat. Data for this study were collected in June 2023, during the period when GitHub’s 2FA enforcement was in progress. 

To gain a better understanding of our participants, we asked them to provide details about a public project of their choice to which they contribute. We collected only publicly available data about these projects, such as the number of commits or stars. Based on this data, we observed a wide range of projects—from very small ones where the participant was the sole contributor to some significantly larger projects.

Overall, we collected data from 110 open source developers on GitHub. Our participants shared some common characteristics typical of this sample (e.g., around 80% male), but compared to the Stack Overflow Developer Survey, our sample was predominantly from the EMEA region and had higher education levels than the general developer population. Participants also rated themselves as generally knowledgeable and experienced in information technology security. Additionally, our participants held varying levels of access rights to the reported projects. Notably, 19% of participants had higher access rights than they actually used. Regularly reviewing and updating access rights for all project members could help in removing unnecessary permissions.

What changed?

Let’s compare the results between the first and second studies. Some authentication methods offered by GitHub changed between the studies. For example, in the first study, fallback methods included recovery codes, SMS codes, and Facebook, while in the second study, only recovery codes were available as fallback options. In both studies, the primary second-factor methods included SMS, software tokens, and hardware tokens. However, in the second study, the software token could be activated either as an authentication application (as in the first study) or as GitHub Mobile via push notification, which was a new feature available in the second study only. Despite these changes, software tokens were positively perceived in both studies in terms of usability and security, and they remained the most commonly used methods.

In both studies, a majority of participants had enabled 2FA at the time of data collection: 81% in the first study and 68% in the second study. Most participants using 2FA in the second study had had it enabled for over a year, indicating that they did not enable it solely because of GitHub’s enforcement. Regarding IT security policies, a similar trend was observed in both studies: approximately one-third of participants reported having a security policy applicable to their project, one-third reported not having such a policy, and one-third were unsure about the policy. Both studies focused on real-world developers and included a sample from this population, which is valuable given that many studies have either very small samples or use computer science students instead of experienced professionals. We would like to take this opportunity to thank all of our participants once again for their time and valuable input.

2FA enforcement perception

Regarding awareness of the planned 2FA enforcement, approximately half of the participants were aware of it at the time of data collection. We gained very positive insights into the planned 2FA enforcement—overall, participants supported it across various scenarios and user groups. Participants were asked to consider 2FA enforcement for three scenarios: when logging from a new device, new location, or for control after 28 days. Figure 1 shows the level of users’ agreement with 2FA enforcement, separated by new devices, new locations, and after 28 days. In the case of new devices, 98 said yes or probably yes, compared to 91 for a new location and 75 for after 28 days.

When evaluating 2FA in the context of other security measures that can enhance project security, we provided participants with a list of security measures, including authentication, and asked them to evaluate them. The list was not comprehensive, as including all possible measures would have been too extensive for participants to consider. Instead, we selected a few relevant examples, including branch protection rules, signing releases, two-factor authentication, information on how to report security vulnerabilities (e.g., the SECURITY.md file), contact details for a security expert or team, signing commits, signing tags, use of release management tools (e.g., Jira), and advanced security testing (e.g., fuzzing). Participants view 2FA as an important element that should be included in a project’s security policy, with a level of importance comparable to other key security measures. When comparing the project owner’s use of 2FA with enforcing 2FA for all contributors, participants consider the owner’s use of 2FA to be the most crucial security measure for protecting the project, and it is also the most commonly implemented. You can find more information in the academic article “What Johnny thinks about using two-factor authentication on GitHub” (Proceedings of the 19th International Conference on Availability, Reliability, and Security, Jul. 2024).

Even though only few participants reported personal or mediated (e.g., through colleagues or friends) experiences with security breaches, it is evident that most of our participants recognize the importance of securing their accounts in the context of open source and are likely aware of the consequences of account takeovers. These contributors are vital for the health and growth of the open source ecosystem. It is encouraging to see that there are user groups who value account security and support 2FA enforcement for contributors, perceiving the offered authentication methods as both usable and secure. However, there remains a concern about the users who have not voluntarily adopted 2FA on GitHub, as we identified that only a minority of users had not adopted 2FA voluntarily (and some users are strongly against the 2FA enforcement on GitHub, e.g., referring to 2FA as “nonsense” which “needs to stop”. We leave it to future work to identify the difference between users who adopted 2FA voluntarily and involuntarily.