Although I am a security student, I am not a security expert; please read my general disclaimer. This post was written for IGME 599, an Honors FOSS Independent Study (Summer 2022).
How does open source software relate to security?
Before we learn about specific steps you can take to become involved in the open source security community, it is critical to understand the history behind open source security. As a collective, the open source community is opinionated, and ignoring its history may get you into trouble.
That being said, the historical context section is a super condensed version of open source software (OSS) history. The OSS community is a very passionate and vibrant one. I am sorry if I excluded your favorite FOSS influencer or historical moment. History is not the primary focus of this piece.
The story of open source begins with Richard M. Stallman, an ex-MIT professor who was mad that he could not 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.
People from various political and ideological backgrounds were drawn to the movement like Linus Torvalds and an ex-UPenn professor, 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 open source movement boomed.
Within the OSS 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. At the same time, 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. Whereas in contrast, proprietary software is—in many cases—illegal to test the security without explicit permission and conditions. As a result, it is challenging to conclude security findings of proprietary software without legal risk.
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.
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.
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.
Please note that there are other open source security concerns, but these are just a few. 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.
Now, we can cover some actionable items of becoming involved in the open source security community. 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.
Ethics and politics
Let’s dive into 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 folks 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.
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 ethical debates are not your forte or you feel strongly about one specific ideology, keep two things in mind to get along with most people: personal enjoyment and transparency.
Almost everyone respects them as reasons to like open source, and you won’t upset anyone if that is where you say your motivation originates. Otherwise, expect debates. I find political debates challenging since I also need to defend my contributions; I only have so much time and energy.
You will probably encounter the stereotypical arrogant contributor. Security has these folks too: “I hacked the BeepBoop9000 and placed first in Russia’s national championship for HackHackHack.” Jokes on you; I don’t know what those things mean.
Weirdly, I don’t mind most arrogant folks. I wouldn’t want to hang out with them, and it can be painful to work with them. At the same time, they are often the people forcing others to prove the merit of their ideas and contributions.
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., Atrophy)|
|Low contributor growth||Stadiums (e.g., Babel)||Toys (e.g., ssh-chat)|
Source: Working in Public by Nadia Asparouhova
|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. Further reading: 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.
- Do I use this program? Do not contribute to a project you do not use. You will annoy the users and developers.
- Do I like this program? Do I 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.
- Update your PR and or learn something new
There are thousands of open source security projects. Although these links list hundreds of projects, they are only a few of the opportunities available. Open source security is a huge space.
- GitHub: General list of open source security projects
- GitHub: projects tagged as #offensive-security, #security, or #cybersecurity
- GitHub 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
This program is beneficial for even those who are not interested in joining. Its website lists some great projects with supportive mentors available. You can search their webpage to find multiple security projects with supportive contributors looking for mentees.
However, if you are a student or interested in the program, Google Summer of Code offers projects at various companies. The program lasts twelve weeks during the summer.
I TA for some of these classes.
|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.|