This is a guide to getting involved in open source security: how to pick a project, how to read a community’s ethics and attitudes, and the steps to your first pull request. It starts with a short history, because the community is opinionated and knowing the history keeps you out of trouble. If you want to start contributing now, skip to how to get involved.
TLDR
- Security: open source is not automatically more secure than proprietary software, but it has unlimited security potential.
- Finding a project: search by your niche, or by the languages you already know.
- Finding a community: check its values and attitudes. Arrogance is common and tolerable; toxicity is not.
- Getting involved: read the README, join the chat, learn the current issues, then open a pull request and expect feedback.
- Where to look: GitHub topics, Kali’s tool list, OWASP, and Google Summer of Code.
How does open source software relate to security?
The open source software (OSS) history below is super condensed.
Historical context
The story of open source begins with free software and Richard M. Stallman, a programmer at MIT’s Artificial Intelligence Lab who was mad that he couldn’t fix a printer because its source code was proprietary. His conclusion from the printer experience was that software should be free* to use, study, share, and modify, but not necessarily monetarily free.
* free as in open or accessible.
People from various political and ideological backgrounds were drawn to the movement, like Linus Torvalds and Eric S. Raymond. For instance, Raymond’s blog is Armed and Dangerous: Sex, software, politics, and firearms. Life’s simple pleasures; very different from Stallman’s work and views.
The crowd was mostly white guys, but their political and open source beliefs differed. Their commonality was embracing the general concept of shared code.
Together, these people and many others not mentioned in this post, birthed the open source movement. They wrote books, held conferences, and the movement boomed.
Within the movement, there were many debates and struggles. One of which concerned whether changes to OSS should be allowed, and if they were allowed, can those changes be shared.
The debate about changing and sharing OSS caused a complex divide—this post does not do it justice—in the open source community. Yet, I feel that this debate is at the heart of securing OSS, so I included some relevant moments.
Great, short read: 6 pivotal moments in open source history by Dave Neary
The security debate
The debate starts with Linus’ law: “given enough eyeballs, all bugs are shallow.” A common conclusion from this quote is that open source is always more secure than proprietary software, and that conclusion is wrong. Open source is not inherently more secure than proprietary software.
Given enough eyeballs, all bugs are shallow.
Linus’ Law in The Cathedral and the Bazaar by Eric S. Raymond
Like Linus’ law states, you need eyes; you need people. Specifically, you need people capable of understanding your code and willing to devote time to it. Thus, open source has unlimited security potential. Proprietary software, by contrast, is often illegal to security-test without permission. As a result, it is challenging to conclude security findings of proprietary software without legal risk.
Open source is not inherently more secure than proprietary software. Open source has unlimited security potential.
Shameless plug: if you have heard me say “open source has unlimited security potential” before, it is because it’s a central finding of one of my research projects.
Companies
Regardless, some companies adopt OSS because of the unlimited security potential, shared technologies, and diversity. “Shared technologies” refers to the technologies used between companies like Ansible, React, and Python. Diversity refers to the fact that companies can only hire so many people, so having teams at multiple organizations contribute may be mutually beneficial. This taps into Linus’ law.
I’m not of the opinion that all software will be open source software. There is certain software that fits a niche that is only useful to a particular company or person: for example, the software immediately behind a web site’s user interface. But the vast majority of software is actually pretty generic.
Brian Behlendorf
Furthermore, if your organization is using a specific open source project, having a say in its development is beneficial because it may become more catered to your needs and goals.
Unfortunately, there are drawbacks to collaborative development depending on the project, its size globally, and how you measure productivity and effectiveness; for instance, are you including language barriers, regulations, and laws? All of these things can affect security.
Since this post deals with contributing to open source software, I assume you have already gauged the security risk of contributing to a project. If not, I recommend exploring the security concerns that may be specific to your organization and if contributing to a given project is a good fit.
Navigation
First, consider how you plan to navigate the hundreds of thousands of projects available: do you know which subset of security you want to work on (i.e., offensive, networking, static analysis, or educational content)?
If you know your subset, great! Search the web for your niche, like “open source web hacking tools.” If not, that’s OK! You can narrow down projects by skill set. For example, if you know Python and C, find a tool built with Python or C. Lastly, if you don’t have any skills required for contributions, you can learn them once you’ve found an interesting project or contribute to documentation.
A lot of OSS is community-based. Thus, your next step is to find communities you like by examining their respective ethics, politics, and attitudes.
🌸👋🏻 Enjoying this post? Get the next issue of [ret]2read. Once a month, I’ll email you whatever’s on my mind, usually Apple security research, offensive security, open source software freedom, and operating system internals.
Ethics and politics
In Stallman’s essay, Why Open Source Misses the Point of Free Software, he states that “the two terms describe almost the same category of software, but they stand for views based on fundamentally different values. Open source is a development methodology; free software is a social movement.”
Today, FOSS comes with less ethical discussion. However, some people still value it as a social movement.
FOSS vs OSS
If you know the difference already, continue to ethics.
The word “free” in FOSS represents “freedom,” like “free speech,” not like “free” as in “free of cost,” or “free beer.” In general, labeling a program as FOSS guarantees four freedoms—that its source code is open for anyone to use, study, share, and modify.
FOSS is different from OSS. Similar to the word “natural” on food packaging, OSS is a vague term that does not guarantee the four freedoms. Most OSS consists of some of these freedoms, with licenses restricting their respective usage. This article concerns OSS. Please remember that OSS does not come with the simplicity that FOSS does.
Want your company or product in front of [ret]2read readers?
One sponsor per issue →
Back to ethics
Regardless of FOSS or OSS, try to find what you value within open source. Is it the content or ethics of the project? Or both? If you only care about the technical content, skip to the section about Asparouhova’s community classifiers.
Activist groups power many projects. Even within a project, contributors will cover the gamut of political ideologies; I’ve chatted with folks who support capitalism, libertarianism, socialism, and various other beliefs. Everyone has different opinions on why people should use and/or abandon OSS. In my experience, discussing project abandonment is always controversial; however, the least controversial reasons for supporting open source are personal enjoyment and transparency.
If you’d rather skip ethics debates, say you’re in it for enjoyment and transparency; almost nobody argues with that.
Otherwise, expect debates. I find political debates challenging since I also need to defend my contributions; I only have so much time and energy.
Did you know that the National Security Agency and United Nations have open source projects?
Attitudes
Arrogance
You will probably encounter the stereotypical arrogant contributor. They are often the people forcing others to prove the merit of their ideas and contributions. Security has these folks too.
Arrogance is not a synonym for toxic! Toxicity is unacceptable, while arrogance is tolerable.
Although it can become aggravating and unproductive, interactions with arrogant contributors have helped me learn how to convey ideas, recognize when I need to back down, and determine when an argument isn’t worth my time.
As a result, don’t fear a project because of a few salty people you’ve encountered. They will be the people defending your project when some “security expert” on Twitter finds irreplicable vulnerabilities without evidence.
Outside of arrogance
Outside of arrogance, open source folks and communities have various attitudes and structures, just like offline culture. Find one you vibe with. If none stick out to you, that is OK! You will learn how to navigate these things with time.
Asparouhova’s community classifiers
Nadia (Eghbal) Asparouhova—a technology researcher and writer—wrote a book about modern open source software development and its social influence online. She categorized projects into four categories based on contributor and user growth. Note that a project’s category can change with time.
| High user growth | Low user growth | |
| High contributor growth | Federations (e.g., Rust) | Clubs (e.g., ssh-chat) |
| Low contributor growth | Stadiums (e.g., Babel) | Toys (e.g., bot-sshca) |
Source: Working in Public by Nadia Asparouhova.
Examples
| Category | Example |
|---|---|
| Toy: Low User and Contributor Growth | DiscordGo, a Discord Command and Control tool. Note that most personal and group projects fall into the Toy category. |
| Club: Low User and High Contributor | FarmBot and its webapp. Further reading: FarmBot’s Community Architecture. |
| Stadium: High User and Low Contributor | Debian. Read more: Debian’s Community Architecture. |
| Federation: High User and Contributor Growth | VS Code. Further reading: VS Code’s Community Architecture. |
Which community should I choose?
This is a personal decision, unique to you. However, I can try to guide you with some questions.
Questions
- Do I use this program? I do not recommend contributing to a project you do not use. You will annoy the users and developers.
- Do I like or need this program? Is it useful to others?
- Interested + learning → Enjoyment
- Getting noticed by others like employers or users
- Is their (hopefully) public workflow compatible with mine?
- Impossible to guarantee
- Does this community represent my values?
- Will this community respect me?
- Again: impossible to guarantee
How to get involved?
- Find where the project hosts its code and where to submit changes (i.e., GitHub, GitLab, or Codebase)
- Read the README
- Join their respective communication channels (i.e., Discord or Slack)
- Find your group within the project.
- If it is a larger project, you will probably be working with a group of people focused on a specific goal.
- Understand the current issues
- If meetings are a thing in the project you contribute to, meet with the group in a video chat with screen sharing. I have found this to be the most productive communication method.
- Make changes and submit a pull request (PR)
- Get feedback (sometimes criticized)
- There is a high chance your PR will cause some disruption if it is your first time or if you are making substantial changes.
- Improve
- Update your PR and/or learn something new
- Repeat
Opportunities
Project lists
There are thousands of open source security projects. These lists cover hundreds of projects, and that’s still a small slice.
- GitHub:
- General list of open source security projects
- Projects tagged as #offensive-security, #security, or #cybersecurity
- Its showcase for securing systems, monitoring, and incident response.
- List of tools installed on Kali Linux
- Open Web Application Security Project (OWASP) project list
Google Summer of Code
Even if you don’t apply, its project list is worth browsing for security projects with active mentors. If you do apply, Google Summer of Code offers projects at various open source organizations. Projects run 12 to 22 weeks, and you don’t have to be a student.
RIT Specific
I TA for some of these classes.
| Course number | Title | Description |
|---|---|---|
| IGME 582 | Humanitarian FOSS Development | Learn about OSS and make your first contributions to a project of your choice. I wrote my community analysis posts on FarmBot, Debian, and VSCode for this course. |
| IGME 584 | Project development in FOSS | You either create or contribute to a project throughout the class. That is it! |
| Varies | Independent Study (1 – 6 credits) | Find a prof that wants to work with you and an OSS community you want to work with. Develop project curriculum and have it approved by the head of your major’s department by the end of the add/drop period. |
This post was written in the summer of 2022 for an Honors FOSS Independent Study (IGME 599) at the Rochester Institute of Technology.
