404 Tech Support

Securing Open Source Components (it’s different)                                  

Introduction

In today’s article we will discuss one of the misconceptions when it comes to understanding the difference between open source and proprietary software — with a special focus on the context of security.

Let’s start with a bit of background of the clear difference. One of the key factors which differentiates open source and proprietary software comes down to how the software is distributed and which licenses are necessary to use the software.

Software distributed under an open source license allows users to modify and share the software’s source code with minimal limitations; whereas software distributed under a proprietary license functions as a sort of “black box” where user access to the source code is restricted.

Open Source vs Proprietary code

Many arguments can be made regarding which type of software is “better” — with the objective answer being that “it depends.” Every organizational use-case tends to be different. Factors such as cost, team composition and developer skill-set all play a role in deciding which type of software to use when engineering a technical solution.

Proprietary software has a number of factors that can be seen as “pros” — such as overall product stability — with a predictable release cycle and usually a vendor commitment to introducing new features and improvements with each release.

Open source software also has a number of “pros” that are usually cited — such as not being dependent on a particular vendor for the maintenance of the product. Open source software is generally considered to be less “buggy” due to the wide involvement of the developer community in testing and overseeing each code release.

Each type of software also has its “cons” that it must contend with. For example, with open source software, technical support is often a deficienciency, while in the case of proprietary software there are the vendor dependencies and cost factors to be concerned with.

Real-world Use Cases

Most organizations use a mix of open source and proprietary software code which comprises that particular organization’s software development “toolbox.” Many factors contribute to that mix – including vendor relationships, developer preferences, etc.

Where security issues arise is when proprietary software and open source software are treated differently, from a standpoint of security.

Often a company leveraging open source software solutions approaches security with the same expectations and process as they would approach proprietary software. This can be very risky.

One widely publicized case of an open source component creating a vulnerability occurred last year as the Equifax breach broke the record for the biggest theft of personally identifiable information. Hackers made off with the personal data of some 147.9 million people.

Equifax’s security was breached via a vulnerable open source component, Apache Struts2, which was used in one of their web applications. The vulnerability present in Struts2 was made public in March of 2017, however Equifax failed to patch it, leaving the door open for the attackers to gain access to their systems.

Had Equifax taken advantage of an open source security solution, such as WhiteSource, they would have been able to identify the open source dependencies in their their products, and would have known that the vulnerable version of Apache Struts2 that they were using needed to be patched.

Differentiating Open Source and Proprietary Security

With proprietary software, when a security risk is discovered, the vendor releases a patch which addresses the vulnerability and notifies users with specific instructions on how to apply the patch. Often the patch is “pushed” to users where they allow the patch to run and the fix is applied.

Usage of proprietary software does not require the users to be proactive in addressing security vulnerabilities. This responsibility falls primarily on the vendor.

Open source software, on the other hand, requires users to consistently monitor the code components that they are using and track these components for vulnerabilities that could be uncovered by the community, among other risk factors which can put their application at risk. Thus the responsibility of addressing any known vulnerability falls to the users.

Due to these factors, organizations that leverage open source components with the same passivity as they would use proprietary components, becomes vulnerable from a security standpoint.

Securing Open Source Components

For organizations that realize the security risks involved with leveraging open source components, lack of resources often times prevents them from taking the necessary security measures when it comes to monitoring and addressing vulnerabilities..

Fortunately, there are a number of solutions available to assist software departments with managing open source security risks.

One such provider for open source security solutions  is WhiteSource.

WhiteSource’s solution compiles and maintains the largest comprehensive database of open source security vulnerabilities. WhiteSource continuously monitors all of the open source components in your codebase; referencing its internal database as well as as security advisories, bug trackers and the NVD ( the primary vulnerability reporting source).

Their comprehensive vulnerability database (containing almost 3X the number of vulnerabilities compared to other solutions), as well as a proprietary algorithm feature, guaranteeing zero false positives, provide WhiteSource with an advantage over competing security solutions which detect a lesser number of vulnerabilities and flag a high percentage of false positives.

In addition to vulnerability detection, WhiteSource alerts their customers and assists with remedying the vulnerabilities by providing actionable recommendations on how to address the issue.

The product interface (illustrated below) is very user friendly and intuitive, with a dashboard and comprehensive reporting functionality providing a well-organized, unified security perspective of all open source components within the codebase.

 

 

 

Conclusion

In the wake of the Equifax breach, businesses no longer have an excuse not to protect themselves. In addition to safeguarding company and customer information, businesses have the responsibility to provide their developers with a secure work environment. Using SCA tools such as WhiteSource allows businesses to fulfill their responsibilities to all stakeholders involved.

WhiteSource holds the distinction of being recommended by Microsoft for open source management, and we at 404TS would like to add our recommendation as well.

The WhiteSource software is available for free trial, here .