Olivia A. Gallucci

How does open source software relate to security?

Before we discuss the 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 vibrant, opinionated, and passionate; 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.

Historical context

The story of open source begins with Richard M. Stallman, an ex-MIT professor 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 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 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. 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.

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. 

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.

Navigation

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 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. 

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.  

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)

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

1. Do I use this program? I do not recommend contributing to a project you do not use. You will annoy the users and developers. 
2. Do I like or need this program? Is it useful to others?
   • Interested + learning → Enjoyment
   • Getting noticed by others like employers or users
3. Is their (hopefully) public workflow compatible with mine?
   • Impossible to guarantee 
4. Does this community represent my values?
5. Will this community respect me?
   • Again: impossible to guarantee 

How to get involved? 

1. Find where the project hosts its code and where to submit changes (i.e., GitHub, GitLab, or Codebase)
2. Read the README 
3. Join their respective communication channels (i.e., Discord or Slack)
4. 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. 
5. 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. 
6. Make changes and submit a pull request (PR)
7. 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. 
8. Improve
   • Update your PR and or learn something new 
9. Repeat 

Opportunities

Project lists

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
  • 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

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 you are interested in the program, Google Summer of Code offers projects at various companies. The program lasts twelve weeks during the summer.

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.