Author: Andrew Mikhaliuk, CEO of CoreWin
One of the key issues in today’s digital world is the security of software, and thus data and systems. Software is distinguished by the technologies used to write it, but beyond technology, there is another age-old distinction: whether the code is open-source. As technologies change, but the nature of intellectual property remains unchanged, the debate has been going on for decades among both professionals and academics: what is safer, open or closed source?
To begin with, let’s disprove 3 main myths about open-source:
- Anyone can read open-source code and exploit vulnerabilities.
Although open-source code can be read and compromised in theory, the reality is much more complicated. First, people who hack software don’t actually need to look at the source code. For an experienced hacker, there is no need to dig through thousands of lines of code to find a vulnerability. Attackers are more likely to focus on what the program does rather than how it is written. Second, the fact that anyone has access to the code actually increases the chances of finding bugs and vulnerabilities.
- The lack of financial incentives means there is no motivation to secure FOSS.
In fact, many successful open-source products have become profitable for the teams that create them. For example, Mozilla receives a significant portion of its revenue from Firefox for user clicks on ads on search pages. And Wazuh makes money from support, paid customization, and training. Most projects of this caliber have their security response teams that fix vulnerabilities.
- Closed source software is inherently more secure than open-source software.
This myth stems from many prejudices. But the closed nature of the code (or its openness) does not guarantee that it is free of flaws. Unlike proprietary software, an open-source project is transparent about potential vulnerabilities. With paid software, the development team controls the detection and correction of errors. With FOSS, you can also participate in code review and then either stay with the previous version, release your patch, or even disable certain features.
Key elements of security enhancement
Since open-source and proprietary code, packages, and systems require the same technical and organizational protections, government regulation of their security usually does not differ. While the specifics of each cybersecurity incident may vary, their subject remains the same: from supply chain attacks to malware infections. The cybersecurity community regularly updates recommended best practices based on new information, which requires constant vigilance, analysis, and testing of existing code and components. Based on this, the community is increasingly leaning towards the following consensus: it is not so essential whether the solution has open or closed source code, but what work has been done to improve security. These efforts can be divided into two key elements:
- Work on the security of the development, quality control, and support teams. This means not only the availability of resources and the normal speed of fixing vulnerabilities, but also the availability of an effective support and quality control team that detects flaws.
- Work on the security of a specific system and a specific implementation. Since there is no theoretical system in a vacuum and all information systems work only in interaction with other systems and users, this requires security control at the level of each specific implementation.
Possible risks
Going deeper into the topic, free and open-source systems (FOSS) have a key feature: an active community that prevents and fixes vulnerabilities. However, often the community that maintains the code is not contracted and does not receive payment for its work. This carries a certain risk in two ways:
- Using a FOSS system as a component of your infrastructure, for example, an open-source SIEM. Here it is worth investigating and finding out whether this system has a core of developers and a team that works on this solution for a fee and professionally. This will indicate that there is quality control and policies in place to check for security issues and prioritize their elimination. Examples of such teams are Wazuh or Red Hat. If this solution was written by a student, picked up by unrelated people who are not working on it professionally and for free, the risk of using such a solution increases dramatically.
- Free components and libraries. Closed source solutions use both free and paid third-party components and libraries. It is not commercially viable to write all software from scratch, but rather to focus on innovation and leverage the achievements of other organizations. By choosing FOSS, you can openly analyze and inventory all third-party components. These solutions are open, and their components are reviewed by the core team, the community, and users.
Conclusion
The conclusion that follows from the last thesis is that open-source and closed source solutions are more connected than it seems at first glance.
Researchers from the DevSecOps community came to the same conclusion. Their additional conclusion is that the secrecy of the program code does not directly affect the number of existing vulnerabilities. Its openness does not increase its riskiness. This means that it is obvious that the secrecy or openness of the code does not directly impact the number of errors in it. The decisive factor is only the efforts made and their effectiveness.
Joe Brockmeier in his article “Open Source Software Security: Is Open Source Software Safe?” comes to the following conclusion: “So… is it safe? The real answer is, of course, the disappointing but realistic “it depends.” Open source software is not inherently unsafe or less safe than proprietary software.”
We see that the boundaries between open and closed source are blurring. On the one hand, closed-source companies are increasingly trying to find a compromise and take advantage of FOSS solutions. For example, all tech giants have a bug hunting policy. FOSS solutions are no longer student projects, they are supported by full-fledged companies and teams. Some startups immediately decide to open source their code and work in this model.
In today’s world, it is crucial to use resources, both intellectual and financial, efficiently. Therefore, the following conclusion can be drawn from the above. There is no free software, only open source. In any case, the system needs to be customized, checked, and finalized. Therefore, you should definitely pay attention to:
- Available functions
- The level of support
The cost of the license itself is not a useful value. It is the amount of support and features you get with the purchase of the license that matters.
