When people make software choices, security is often near the top of their priority lists. And if it's not, it should be! However, they typically wonder about the differences between closed- and open-source software.
So what's the difference between open- and closed-source? Is open-source software really secure?
Open-Source vs. Closed-Source Software
People make open-source software freely available to everyone. The public can use, copy, change, and redistribute it. Plus, as the name suggests, anyone can see the source code.
Closed-source software features tightly guarded code that only authorized people can see or change. The cost covers people’s right to use it, but only within the boundaries of the license agreement for the end-user.
Open-Source Visibility Has Security Pros and Cons
The ability of anyone to see the source code brings major advantages for open-source security. Development becomes a community effort participated in by people from all over the world.
That means errors often get spotted and fixed faster than if only a much smaller group of individuals examined the code.
However, hackers capitalize on the accessibility of open-source code too. They could use it to plan attacks or take note of vulnerabilities.
Developers with a genuine interest in improving open-source software address the issues they find or at least report the problems to someone with the skills to tackle them. Anyone with malicious intentions hope things go unnoticed for as long as possible.
These realities cause cybersecurity professionals to warn that open-source software can put organizations at risk. One issue is that criminals could see the code and inject dangerous content into it. Alternatively, those parties could target companies that don’t have strict practices for downloading software patches with sufficient frequency.
Since open-source software has no central authority managing it, it’s difficult for anyone to know which versions are used most often. Titles could be updated so frequently that an organization’s IT teams don’t realize they have an old version with severe security issues.
Third-Party Software Libraries Pose Open-Source Security Risks
Developers often use third-party software libraries to save time. They’re reusable components developed by an entity other than the original provider. One advantage is that they allow the use of pre-tested code.
Popular libraries are tested in numerous environments for a wide range of use cases. The natural frequency of usage means bugs are reported often. However, that doesn’t necessarily mean third-party software libraries have superior security, even when discussing those associated with open-source software.
One study found that, in almost 80 percent of cases, third-party libraries for open-source software are not updated after developers add them to codebases. The researchers involved in the study cautioned how the lack of updates could have knock-on effects.
Some of the newest and widely used software titles rely on third-party software libraries during development. One flaw could affect all the products associated with a problematic library. Another worrying finding is that more than a quarter of developers surveyed were unaware or unsure of any formal process used to select third-party libraries.
However, a positive conclusion from the study was that software updates fix 92 percent of flaws in third-party software libraries. Additionally, 69 percent of updates only require a minor version change or something even less extensive.
Even more promising was that developers could fix 17 percent of these flaws in one hour. That means that addressing these open-source library issues is not always extremely time-intensive or complicated.
How Bug Resolution Speed Affects Open-Source Security
One of the main issues with outdated software is that it leaves users at risk of potential security flaws. In an ideal world, developers would notice and fix all bugs before software reaches the public. That’s an unrealistic goal, however.
The next best option is to release software patches soon after vulnerabilities become apparent. Security researchers often alert providers of closed-source software about problems that need quick fixes. However, the people developing those products follow release schedules chosen by superiors.
Decision-makers don’t always prioritize all vulnerabilities, either. Some remain unaddressed for months or years after the initial identification occurs. A related issue is that many developers struggle with excessive or imbalanced workloads that may severely limit their ability to fix bugs quickly, even with the best intentions.
Another survey found that 38 percent of developers spend a quarter of their available time fixing software bugs. About 26 percent of respondents said the task takes half of their workdays. Another eye-opening finding was that 32 percent of developers spend up to 10 hours per week fixing bugs instead of writing code.
Developers take numerous precautions to avoid releasing problematic code. For example, coverage from Blue Sentry discussed how a sandbox database gives a mirror version of the production environment and any current deployment cycle changes.
Web development professionals can learn and test things without any major adverse consequences that affect an entire team. But bugs still happen.
Since open-source software has entire development communities working to improve it, there’s a high chance that someone with the right skills and schedule availability can target a bug and get it fixed. That can mean known vulnerabilities don’t remain unaddressed for as long as they might with a closed-source software title.
Google Launches a Tool to Improve Open-Source Security
Software dependencies exist when one operating system relies on another one to work. When it comes to open-source software, the fast pace of change often makes it difficult for developers to understand whether any of their dependencies concern outdated versions.
However, Google recently released a web-based visualization tool called Open Source Insights to address that problem. It gives users an overview of the components associated with a software package.
Since the information includes details about dependencies and their properties, development professionals get a clearer idea of whether outdated open-source software could cause issues later.
Besides looking at dependency graphs, people can use a comparison tool that shows how different package versions may affect dependencies. Sometimes, a newer one addresses a security issue. By offering this tool, Google aims to make it easier for developers to become more aware of how they use open-source software.
Having that new knowledge could improve security and overall usability.
Open-Source Software: Not a Total Security Solution
This overview shows why open-source software is not always the most secure choice compared to closed-source software. Nonetheless, there are lots of good things about open-source software too.
People who intend to use it for personal reasons or within their organizations should weigh the pros and cons to reach a decision.