The Security Risk of Releasing Software as Open Source

Published 02-11-2022 by Lars-Erik Kindblad | Share

There has been a trend over the last years for the private and the public sector to publish their software as open source. This has been motivated by various internal and external reasons, some are sector specific, others are not. For the private sector, publishing software as open source is usually something that is mainly relevant for companies selling their own software, while for the public sector it's relevant for all the software produced and funded by the taxpayer's money.

There are many good reasons for releasing software as open source, however from a security standpoint it brings some serious security challenges that are often overlooked or taken too lightly. But before we go into more details, let's first agree that no matter if the code is to be open sourced or not, we are still required to implement and follow the same security practices. This includes things like:

• Establishing a solid set of security guidelines and rules that are known and understood by the entire organization, and make as many of these to be enforced automatically
• Facilitating for continuous learning and competence development for all the involved employees and resources
• Doing code review and pair programming
• Having a good automatic test coverage and having testing resources to do manual exploratory testing
• Protecting secrets
• Scanning the code with static and dynamic code analysis tools
• Restricting the use of third-party dependencies and having a tool that continuously scans for vulnerabilities
• Securing the development- and production-environment and the build- and deployment-pipelines

What are the main security challenges with going open source?

1) Little Interests From the Community, High Interest From Attackers

Something I often hear is that open-source software is more secure than closed-source software because more eyes will see and review the source code. For this to be true and have an affect then the project needs to be exceptional attractive for developers. Recently there has been many articles about popular open-source projects struggling due to few or no contributions from the community, where the involved developers end up getting burned out. When this is the reality for projects that are commonly used by a large amount of the developers around the world, what's the status quo for the majority of the lesser popular, niche projects? Probably a lot less interest and few or no contributions.

For the public sector, in any country they have thousands of software systems in their portfolio. These systems are in various sizes, many are large, complex, and highly interconnected and made specific for their organization. This means that they will be hard to understand and not very usable for outsiders who are not working fulltime with the domain and the systems. To get any long-term interests and contributions from developers on these types of systems are unlikely.

For the private sector, open-source projects might attract a large user base, but few will choose to contribute. This is understandable, most developers have hectic full-time jobs and limited time outside working hours.

While the good actors have little interest or time to contribute to the project, the opposite is true for the bad actors. Open-source software is of great interest for attackers, either because they are actively looking for new vulnerabilities and targets or they have a specific target they want to attack where they need to gather more information.

2) Having Access to the Source Code Is Free Lunch for an Attacker

If the attacker does not have access to the source code, then considerable amount of time and effort must be spent to find the details of the systems, what technology that are used, what libraries, what endpoints are exposed, are there any defects that can be exploited etc. On the other hand, if the attacker has access to the source code, then this knowledge and much more, is gained within a short time:

• Details about all the exposed endpoints will be easily available
• The list of all the third-party dependencies and the versions of these are easily available. The attacker can look for vulnerabilities in these or be patient and wait for new vulnerabilities that can be exploited.
• The source code and the history can be analyzed to look for weak developers who have a track record of writing buggy code and use that knowledge to speed up the vulnerability hunting.
• If the organization accepts pull requests from persons outside the organization, then the attacker can submit pull requests with hard to spot vulnerabilities.
• The source code and the history expose information that can be used in social engineering attacks.

3) Software Has a High Risk for Bugs

Most software systems are complex with many moving parts. Many persons are involved and there are continuously made changes. Often specific logic is only understood in detail by few developers. When these quit and/or new developers join there is an increased risk of introducing bugs. Having good tests reduces the risk, however the problem is that even with a good test coverage there are often corner cases that has been overlooked with the effect that the vulnerability is not picked up by the tests.

4) Lack of Security Awareness

The field of software security is still immature, and many developers and organizations are lacking security knowledge and awareness. Even though the community has done an amazing job with initiatives such as OWASP top 10 and OWASP Application Security Verification Standard, and new roles like Security Champion has put security on the map within the teams, most organizations are still far away from having trained and educated all the developers and introduced continuously training programs.

There are countermeasures to try to mitigate some of these risks, but it doesn't change the fact that in many situations a single line of code can be enough to go from something that is secure to something that is insecure. There is a term in security called "security by obscurity", meaning that the secrecy is the main form of providing security to the system. That is not the main point here, the point is to make it as hard as possible for the attacker by not giving away anything for free. Because mistakes will happen, vulnerabilities will exist.

Conclusion

Due to this, from a security standpoint companies and organizations should consider other alternatives before deciding to release the software as open source:

• Can knowledge sharing sessions with customers, partners or others fulfill the requirement?
• What about private code walkthrough/review sessions?
• Should the contract with customers contain statements like if the company providing the software goes bankrupt, the source code will be made available?
• Can the software be made as a "software as a service", where the functionality will be made available through publicly exposed interfaces?
• If no other alternative, does everything need to be open source or can a larger- or more critical part of the software still be closed-source?