Open Source Software: Answering your top 5 questions

In open source (OSS) you want the code to be self-sufficient and evolving without depending on the creator. Therefore, the priority becomes to ensure stability (including documentation and test coverage) as a part of contribution policy.

This becomes quite clear when we know that the knowledge is not shared by people, but is reliant on the documentation. It is actually quite incredible how many lessons open sources can teach us! We can assume that having such a mindset might mean embracing failure; in a way letting go of control can lead to more beneficial outcomes.

Time travel into the open source history 

Going back to the 50’s and 60’s, we time travel to the early days of internet and telecommunication. In those times, developers relied on collaborative research environments. The Advanced Research Projects Agency Network (ARPANET) promoted user peer reviews and feedback, building each other’s code, forums communication, and setting standards for open collaboration. That network eventually became the basis for the Internet.

Therefore, the history of open source goes hand in hand with the history of the World Wide Web. Thus, by the start of the 90’s, the open source principles, such as collaboration, peer review and openness, were all acting as a foundation for the new age of the Internet. 

What is open source code?

Open source code is what the name suggests; open. It’s code whose source code is open for everyone to see, modify and distribute (in a way compliant with its licence, but that’s a story for another time). 

When it comes to software development, the idea that software is better created together with others than alone has been around for many years. Open source projects are collaborative communities around software, dedicated to moving it forward or making it better. 

This means that a project or library can be maintained by hundreds of developers, making sure it’s secure, holds high quality standards and moves forward in terms of capabilities. 

Why do businesses choose to use open source in commercial products?

When choosing between writing your own code or importing an OSS component, the latter usually wins. Especially when it comes to price, longevity and flexibility. It is:

Flexible and agile → keeps the business away from getting blocked in case some capability is not available. 

Cheap → businesses are often limited in their budgets, and OSS can provide cost-effective scaling up for even small companies. Cost-effectiveness is overall much better compared to proprietary solutions, while capability is equal or even greater. Maintenance costs can also be shared, thanks to community involvement. 

Secure → contrary to popular belief, OSS is not automatically less secure than proprietary software. Many communities around open source software work hard to sustain a high level of security, and here the community aspect really comes in handy. The more people engaged in a project, the more likely it is that vulnerabilities are discovered in time. 

Talent pooling → it is becoming more and more evident to tech professionals that the industries are moving towards OSS. Such freedom in collaboration and interaction generally attracts talented specialists. Large players like Facebook, Twitter and Netflix are making the most of their engagement in open source by recruiting the best contributors from their projects; a very successful strategy for both companies and developers. 

Security of open source projects

Security expert Bruce Schneier once said:

“Public security is always more secure than proprietary security… For us, open source isn’t just a business model; it’s smart engineering practice.”

So, how secure is open source? It might seem like it is not when any hacker could see your code. By its definition, OSS could be read by anyone, however, it is actually more complex than that in practice.

Often hackers don’t even need to see the lines of the code to find vulnerabilities. In practice, vulnerabilities can be a threat to any kind of code, making the security the organisation’s and developers’ responsibility. Vulnerabilities are a cause of the violations of security standards, absence of data validation and lack of encryption.

In reality, the openness of the code means there are more opportunities for the experts to examine the code’s security. OSS communities are often there to support the code in their best practices, also driven by the desire to improve or maintain their reputation.

But it is not always the case, and often developers struggle to figure out which communities are more efficient and trustworthy. This may seem like a tough and tedious task to take on, since the evaluation has to be done manually. Wouldn’t it be great if there was a tool that did this? Rumour has it that there might be something along these lines cooking in the Debricked lab, so stay tuned!

Furthermore, it is also quite doubtful that the lack of financial incentives behind open source leads to fewer ambitions for security. Actually, many successful open source projects end up with high profitabilities. Even for the products without much profit, a vulnerability is often either fixed straight away, and disclosed to the public so that the ones affected can take action. 

Reputation for the maintainers is a major driver for motivation, therefore an OSS product often goes through lots of security processes.

To sum up, it is hard to simply say whether OSS is safer than proprietary code. The bottom line is that it is always crucial to have good security processes; regardless of who wrote the code. 

Now that we’ve established that open source is generally safe and nothing to be scared of, let’s look a little closer. What do we mean by open source vulnerabilities, and how can we mitigate the risks?

Examining vulnerabilities

Over 96% of the market applications nowadays use open source. This, in turn, has lots of benefits as explained above. But, when importing an open source library, honestly, how well do you examine it beforehand? 

Today’s development speed can sometimes lead to the neglection of check-ups on pieces of code inserted. The distributed manner of open source often results in vulnerabilities not being identified for some time. Since contributors are often unaccountable, the free and open nature of OSS poses its own greatest threat. 

Everyone knows about risks and vulnerabilities, so one might think that the issue would be shrinking, not growing. 

Why do open source vulnerabilities keep occuring?

→ Many organizations do not have a proper process for open source intake. This means that the responsibility for choosing open source components often lies on the developer. If the developer doesn’t think that security is their responsibility, the equation is simple. 

→  If a company is using open source in their development, it’s likely that they use a lot. That means thousands and thousands of dependencies, direct and indirect. Updating dependencies is a risky business in itself, which is why a vulnerability sometimes can live for longer than it should even though it might have been patched on project level.

→ One of the most arguable dilemmas is whether or not to disclose the vulnerability. The opposing arguments for this are the opportunity for the community to patch it, as well as for the attackers to exploit the newly found failure. 

→ Moreover, unorganised and careless usage of open repositories can result in copying the code with the existing flaws. Then it becomes incredibly troublesome to track or update the external code.

As we have outlined, open source code provides impressive benefits, driving the direction of technological accelerating growth. So, open source is the obvious choice when it comes to modern software development. Especially since there are lots of ways to make sure it’s secure. 

How can we handle open source vulnerabilities?

Every business’ responsibility is to make sure that a continuous plan for identifying and tracking of changes and updates is in place for the portfolio of the application

• First of all, you should always keep your OSS elements up to date. The statistics show that over 80% of vulnerabilities are exposed at the application level, therefore proving how vital it is to always track your code for vulnerabilities
• Creating policies for the usage of open source benefits the organisation, always. 
• Patch management process has to be recurring to get rid of any unnecessary dependencies, keep track of client and server versions.
• Ensure that components are secure and reliable, to not unintentionally include a malicious component.
• Despite the fact that it is possible to do manually, automated tools are needed in order to be efficient when it comes to managing open source. 

Considering the distinguishing features of OSS, it is not surprising that we might need to find special solutions for it, such as Software Composition Analysis. Such tools can help you get a clear view and continuously monitor the open source components in your codebase, generate alerts, suggestions and other useful metrics.

Would you like to save time and energy while still keeping your product secure from public vulnerabilities? Start a free trial or book a demo today and find out how Debricked can help!