What is Open Source Software?
Table of Contents
- Open Source software is software where anyone is allowed to inspect, study, modify, and distribute the software’s source code.
- There are caveats depending on the particular open source license the software is published under.
- Open Source Software has changed the way applications are developed with free, reusable, tools and applications that businesses and individuals use to save time developing new applications.
- Open-source software is free to inspect, modify, and distribute. This does not always mean free of cost.
- Open-source software is developed by individuals and communities. While many open-source software packages are high quality some contain critical security vulnerabilities.
- In more recent years intentionally malicious open-source software packages are becoming more common.
- Monitoring components with Software Bill of Materials (SBOMs) and Software Composition Analysis (SCA) tools is a good way to reduce risk from open source components.
- Packages are stored and distributed in several package registries or central repositories – usually based on the programming language.
- Popular examples include Maven, npm, & PyPi.
Let’s face it — technology jargon gets tossed around as casually as a football at a family picnic. While many people don’t bat an eye when they hear the phrase “open source software,” others may pause slightly before nodding to feign understanding. Knowledge is power, though, so read on to learn more about OSS and how to best utilize it.
What is OSS?
Which terms come to mind when you think of the phrase “open source software?” Perhaps “free code” or maybe “time savings?” While these themes are certain aspects of OSS, there is a lot more to it. The concept of open-source software (OSS) came about in the late 1990s by the Open Source Initiative, a group of software developers who were passionate about “the sharing and collaborative improvement of software source code.” More specifically, they hoped to foster education, advocacy, and stewardship among the software development community.
Okay, tell me more…
At its core, open-source software is code that is created for public use and modification. The general idea is that such modifications will improve the code in some way and simultaneously inspire collaboration among developers. The degree to which someone can use, modify, and distribute the code is outlined in a license that accompanies the code, which license can be very broad or highly specific. Users must abide by the terms of the license or else face consequences, including but not limited to legal actions. Read more about OSS licensing in this Sonatype guide. Also, check out this Sonatype course that further discusses licensing.
How does this fit into my work?
In modern software development, fast and efficient innovation is king. The goal is simple: Develop reusable code in the shortest amount of time possible so as to not reinvent the wheel. To this end, developers rely heavily on third-party OSS packages and libraries. Like most everything with modern technology, these packages and libraries depend on regular updates and improvements (known as “dependencies”) in order to achieve maximum functionality.
Package managers, as their name implies, automate the process of fetching and downloading, installing, and configuring these dependencies as needed in accordance with instructions from the project’s manifest file while trying to resolve conflicting dependency versions. They keep track of software dependencies and version information so that a package is up-to-date and does not miss any necessary components. The process is continuous with new versions of existing projects being released constantly. When all goes as planned, everything happens in a seamless manner, thus helping the developer to achieve that overarching goal of speed and efficiency.
So, what isn’t OSS?
One of the biggest misconceptions about open source software is that it is free, meaning “no-cost”. While most OSS is, in essence, free of charge, the word “free” in the open source context was intended to mean “free to access” and “free to modify.” When software is created by developers with the intention of charging users, this is called proprietary software (think of software such as Adobe Photoshop, Microsoft Windows, etc).
Another misconception is that open-source software is risk-free and safe to use. While openness is the foundation of OSS, it is that same open quality that exposes the software to enormous risks for vulnerabilities. Open source projects become an environment ripe for attackers. This is especially true since not all projects are created equal in terms of quality. If you aren’t proactive with your use of OSS, you are inviting long-term risk into your application development.
Where can I find OSS?
- Java – Maven Central Repository
- Python – Python Package Index (PyPi)
- .Net – NuGet Gallery
These specific repositories use different package managers and are what Sonatype customers most commonly use to maintain the open-source components that comprise their applications.
Describing these ecosystems as “popular” is no understatement. According to Sonatype’s 2021 State of the Software Supply Chain Report, all four of these ecosystems collectively released over 6 million new versions of OSS components in 2021 and introduced nearly 725,000 brand-new projects. That represents a 20% increase in the global open-source supply from the year before. This popularity has a downside, though. The widespread adoption of open-source software has attracted bad actors with unsavory intentions.
What do you mean by ‘bad actors?’
“Bad actors” refers to anyone or any entity intending to wreak havoc in open source software and includes hackers, vandals, and spiteful contributors. Despite its very positive impact on the development landscape, open-source software has become an unintended target for nefarious activities. The very aspect of OSS that makes it so revolutionary – its openness to all users and contributors – is also its curse. These types of attacks erode the trust that has built the open-source community.
There are numerous examples of bad actors in action:
- Joining public projects first by volunteering helpful contributions before maliciously tainting the code.
- Impersonating well-known projects by typosquatting (also called URL hijacking) similar namespaces.
- Causing dependency confusion by publishing harmful components that have the same name as an organization’s internal components.
- Claiming component namespaces after a project has been removed.
- Intentionally breaking or removing popular components that have become critical to an organization’s infrastructure.
Cyber-attackers prey upon the more popular, third-party OSS repositories to exploit vulnerabilities in software supply chains. And the effects of these attacks on the global supply chain have been massive. Check out this report, compiled by the U.S. Counterintelligence and Security Center detailing some of the larger-scale attacks.
The attackers’ methods have grown more sophisticated and faster over time. Up to now, the attackers were known to lurk outside of open source repositories, looking for publicly known vulnerabilities that were not sufficiently mitigated or patched. With next-generation attacks, however, bad actors are not simply waiting for vulnerabilities to surface. Instead, they are actually initiating the attacks themselves by actively planting vulnerabilities into the global supply chain and exploiting those vulnerabilities before they are detected. This proactive tactic is far easier and more effective for the attackers since they gain more control.
So how do I stay on top of this?
Organizations that use OSS components must exercise caution and scrutinize not only the people contributing to projects but also their intentions. Otherwise, this presents an enormous challenge to watch all of the stakeholders, especially when so many components are interdependent. Here are some things to do to keep your code safe:
- Know your application’s components inside and out. While you build your application, create a Software Bill of Materials (SBOM), which is a formal inventory of a software application’s components and dependencies, information about those components, and how they relate to one another. Assign versions to the SBOM just like your version of your application.
- Incorporate smart automation and monitoring tools into the repositories where your code is stored so you can maintain continuous, standardized vigilance and analysis throughout all stages of the development lifecycle.
- Manually set your components’ dependency versions. Don’t auto-enable the latest versions of a component in your code. Instead, manually specify only trusted and tested versions that are known to be safe. Keep these pinned versions in a locks file.
- Test and review new versions, including their transitive dependencies, before deploying them to production.
- Develop a secure development plan for your DevOps teams to follow so everyone knows how to mitigate any discovered vulnerabilities. It is a best practice to include service-level agreements (SLAs) to specify the speed at which risks should be addressed.
Open-source software has changed the software development landscape. It has enabled more efficient and collaborative work among DevOps teams and less redundancy in code. While OSS has had numerous and far-reaching benefits, there are also associated security risks that can consume even the savviest development team. By taking proactive steps, such as arming your applications with automated monitoring tools and having a standardized development plan, your team can ward off bad actors and protect your code.
Visit our Out of the Wild: A Beginner’s Guide to Package and Dependency Management. Also, visit Software Supply Chain Explained for an explanation of how OSS fits into the software supply chain and modern software development. For more on OSS licensing, check out this FAQ guide and this course.
Talk to Us
And visit my.sonatype.com for all things Sonatype.
Written By: Emily Gann
Emily is a Technical Content Developer at Sonatype.