While a lot has been said about how unsecured open source components leave organisations wide open to cyber attacks, the truth is that open source components are essential to software innovation and all an organisation needs to do is take as many active steps to reduce vulnerabilities in such components and their codebases as realistically possible.
In the aftermath of a number of high profile breaches suffered by major brands, organisations are now waking up to the fact that if they do not secure their IT environments from all forms of cyber threats, the next name in the papers could be theirs. The possibility of punishing fines under GDPR and reputational damage are also major concerns for organisations.
According to Synopsys' 2019 Open Source Security and Risk Analysis (OSSRA) report, organisations are now taking concrete and visible steps to secure their open source components and codebases compared to previous years. While the percentage of codebases with vulnerabilities has come down from 78 per cent in 2017 to 60 per cent in 2018, the percentage of open source components with license conflicts has also come down from 74 per cent in 2017 to 68 per cent in 2018.
Even though such achievements deserve appreciation, organisations know too well that these are just incremental steps towards achieving a completely secure IT environment and a lot more needs to be done to, in the event of a breach, convince regulators that they did everything possible to keep hackers at bay.
However, ensuring the security of open source components isn't an easy task considering that any medium or large organisation deploys thousands of such components that need regular scanning for vulnerabilities and the number of open source components per codebase has risen from 257 in 2017 to 298 in 2018.
According to Synopsys, while 96 per cent of codebases it monitored in 2018 contained open source components, 38 per cent of them contained open source components with no identifiable license, and 68 per cent of codebases contained some form of open source license conflict.
At the same time, 85 per cent of codebases contained components that were either more than four years out-of-date or had not been updated in the past two years and 43 per cent of codebases contained vulnerabilities over 10 years old with the average age of vulnerabilities being over six years.
These figures suggest that even though organisations are now scanning codebases and open source components for vulnerabilities, they are not fixing vulnerabilities fast enough or have not been able to identify vulnerabilities even years after they arose. The inability of organisations to mature their DevOps programmes into DevSecOps has also led to a delay in identifying and fixing vulnerabilities in their codebases and components.
"Open source plays an increasingly vital role in modern software development and deployment, but to realise its value organisations need to understand and manage how it impacts their risk posture from a security and license compliance perspective," said Tim Mackey, principal security strategist of the Synopsys Cybersecurity Research Centre.
He added that there are still significant challenges, with the majority of applications containing open source security vulnerabilities and license conflicts. But these challenges can be addressed, as the number of open source vulnerabilities and license conflicts have declined from the previous year.
Commenting on the presence of significant vulnerabilities in a majority of open source components, Reed Loden, security engineer at HackerOne told SC Magazine UK that the higher number of vulnerabilities being observed is a result of greater emphasis in cyber security.
He said that the arrival of vulnerability disclosure programs such as Node.js ecosystem and the Central Security Project have helped organisations uncover flaws in their components and such programmes make it really easy to report security vulnerabilities and assign CVEs.
"For organisations looking to address the risks associated with open source components, treating component security and associated patching in the same way they would treat traditional patching of operating systems and services is a good first step. Organisations should develop a software component patching policy or update their existing management process to also consider open source," said Eoin Keary, CEO and co-founder of edgescan.
"Continuous asset profiling and "Bill of materials" is also key in order to understand what components make up a systems’ tech-stack. Furthermore, regular vulnerability management can help by discovering an outdated component. There are also open source (and commercial) tools available to assist in detecting component versions and vulnerabilities such as OWASP.org’s "Dependency Check". Such tools can be used during the building process to help detect vulnerable components," he added.