Open source libraries or programming languages: Are they vulnerable?

 

As an architect, when I recommend open source, the team expresses many concerns about open-source security. If the source code is open, does it become vulnerable? I say no. Even closed source code is vulnerable and subject to attack, so both closed source code and open source code are equally vulnerable if we do not pay attention to security measures.

Some people will argue that closed source is more secure because the source code is not publicly available and it is harder for attackers to crack the code. Source code is needed to develop a new feature, attackers will not develop any new features to attack. The attacker's goal is to discover a flaw to exploit.

In general, attackers use a variety of tools to identify security flaws in a system, regardless of whether it is closed or open source. They do not require the source code in order to crack. 

Generally, open source has a lot of advantages in terms of getting security fixes very quickly compared to closed source. The community maintains open source, which is mostly active in looking for security flaws and providing fixes as soon as possible. Closed source means we need to wait for the vendor to release a fix.

Some argue that as long as the source code is available, Trojan viruses could be introduced. It is all dependent on which open source software you are using. Mostly, the source code community will do the code review before it goes to release, so it is not easy to introduce a Trojan virus.

Before using any open-source technology, find out the answers to the following questions:

• The open-source community is active.
• One person or a group of people maintains open source software.
• how frequently codes are updated and releases are made available.

On top of it, use a proper static code analysis tool at the time of development and use open-source security vulnerability management tools to identify open-source vulnerabilities.

My final piece of advice is to not be constrained when selecting any technology, tool, library, or framework; instead, choose what is best suited for your team and match it with the business use case. Security should be part of your process and day-to-day activities, so just don't be strict only with code. Some people think once they have selected a framework for development, it will automatically take care of security, This is not correct.