We notice a major trend towards adopting open source software (OSS) solutions for private data security, as more companies start emerging worldwide. Many governments are finding it hard to trust closed software for their security infrastructure. It was predicted in 2016 by Gartner that 99 percent of Global enterprises will use open source in mission-critical software. MySQL was acquired by Sun Microsystems for US$1 billion in 2008, while Red Hat Enterprise Linux now balances a whopping amount of US$14 billion – both companies are open source based.
Since, transparency and openness increase security protection levels, OSS solutions for controlling company data are, therefore, becoming the new de facto standard.
Companies reaching an ‘all-time high’
Developing investment firm North Bridge and OSS logistics and legal solutions provider Black Duck Software affirmed via the Future of Open Source Survey in 2015 that regardless of their low standard administration strategies, many enterprises are receiving open source security arrangements like ‘crazy’.
Black Duck CEO Lou Shipley also mentioned in a separate statement that more and more companies are requiring the apt governance of open source to catch up to their usage. This is important to reduce legal and operational risks, allowing companies to ‘reap the full benefits OSS provides’.
By looking at the survey results from C-level executives and managed IT servicers, Shipley’s statement becomes clearer:
- As many as 93 percent of respondents admitted that their organisation’s use of open source increased or remained the same in the past year.
- Nearly 78 percent said that their companies run part or all of their operations on OSS.
- Over 64 percent of participants mentioned about participating in open source projects and over the next two-three years, around 88 percent are predicted to contribute to the campaigns.
It is clear that open source has officially become the default approach for company security software with more than half of the participants saying they consider OSS before other options.
Open source and data security
Open source security managers tend to spend a considerable amount of time working with engineers and security developers, helping them build a more productive open source management process. One theme always seems to pop up in their discussions: why companies are using so much open source in their product manufacturing processes, yet are unware of the basic facts about OSS security?
Based on the hours of ‘expert’ conversations and countless coaching sessions, here are five interesting facts that any business person would want to know about open source security:
The ‘Linus law’
A recent discovery by Coverity that comprises a number of defects in the Android kernel proves to be the best testament to the superior security of open source software. The kernel code being open to public view is probably the most encouraging thing about this discovery.
The example is a great illustration of what is known as “Linus’ Law”, even though Android may not be entirely open source. Named for Linus Torvalds, the creator of Linux, the maxim calls all security bugs ‘shallow’, which means the more individuals are capable of detecting and setting a code, the more likely any flaws will be quickly mended. It is technically the polar opposite of the proprietary product argument over “security through obscurity” – a justification for using expensive security software.
Generic application security testing tools are inapplicable to code
In order to find the potential vulnerabilities in your code, several analysts are currently running static application security tests (SAST) on the source code and dynamic application security tests (DAST), while an app is running.
A better way to detect vulnerabilities in your company’s open source components is by matching between the reported OSS security vulnerability and the current open source features you are using.
Non-vulnerable alternative
The open source security communities are quick to respond to vulnerabilities and, in most cases, a fix is released the same day the liability details are published.
The open source project managers are contacted about the issue and are asked to offer a solution – a customary step. Mostly 60 – 90 days, a ‘grace’ period, is often extended to provide the experts enough time to fix the bug. During this phase, the vulnerability details are not published to prevent hackers from taking advantage of sorts.
As an alternative, a CVE – reserved with no information – is usually given out, only to increase awareness that soon a solution will be available for users to patch their software, as soon as all relevant details are released.
Because of this, there’s viable remediation for almost all pronounced protection vulnerabilities, users must only realise what they are. The WhiteSource security answer is one of the ‘mechanically suggested’ answers for each hazard, while alerting operators as a way to take the important steps to stay clear of exploitation.
Avoiding false positives
In an open source or commercial library, whenever a developer or researcher finds a threat, he or she requests MITRE for a plausible CVE identifier, eventually adding to the CVE database.
Providing a CVE identifier through MITRE means the vulnerability was checked and thoroughly verified. While it may not be a potential risk, there are still chances that it could become dangerous by a real security issue that must quickly be fixed. You are leaving your software vulnerable otherwise, and doing so while all attackers out there are aware of the susceptibility and how to exploit it.
This is the reason why CVEs are published every time a security threat is discovered. It also explains the essentiality of tracking published CVEs and matching it with the open source components in your software.
A race against the hacker
Through open source vulnerabilities, hackers can easily obtain multiple leads on any open source security threat. But the availability of the code from multiple sources enable users to easily find the loopholes and sometimes even make them in the reach of hackers.
In a nutshell…
Is open source software necessarily more secure than proprietary tools? Of course not. In order to thoroughly investigate the efficacy of a product, you must look at the security-reputation of each piece on an individual basis; reviewing its version history and rummaging through previous security issues. You may find certificates proving its reliability, or link to a renowned colleague who can assure you that it’s the best option on the market.
Moreover, you can see what security tools your partners and established businesses are using. Ruby on Rails, for example, is used by Airbnb and 500px, and that alone is a great indicator that the OSS framework is reliable enough for all companies.
