The Need For Open Source Security

We’ve previously covered what open source is and why businesses prefer to develop their applications using open source, even when it incorporates risks. Let’s now take a look at how to securely use open source components in development so that its benefits outweigh its risks.

Why the fuss?

As we discussed in our previous post, the characteristics of OSS enable businesses to increase productivity. Not surprisingly, these very characteristics are often exploited by adversaries to breach the businesses’ applications.

Moreover, same OSS components are often reused across the organisation by developers, leading to the same vulnerabilities being present in different applications of the same business. This provides adversaries more ways of obtaining what they seek – be it data or control over the application.

Open source vulnerabilities are also disclosed on public security advisories and databases like the National Vulnerability Database (NVD) maintained by the U.S. Government. These vulnerabilities are disclosed by developers or security researchers and assigned a score based on a variety of factors; including but not limited to the ease of exploit and the extent of damage. Although the NVD helps to promote security awareness of vulnerable OSS, its transparency also reduces the effort required on the adversary’s end in breaching these vulnerable components.

Open source vulnerabilities are more attractive to adversaries

It’s known that some open source repositories are used by developers in many applications across different enterprises or businesses. When adversaries understand and can carry out an exploit for a popular open source vulnerability, they can easily replicate it against any applications they can get their hands on – and breach any application unfortunate enough to have not yet patched the vulnerability.

This is quite a rewarding effort for today’s adversaries, compared to the old days where they had to put more effort into understanding the closed source codes of each of the applications.

Does that mean OSS is inherently less secure?

Despite all the security issues associated with open source components, OSS is still deemed to be more secure than closed source codes. Users are inherently trusting the vendors to conduct security checks on their own closed source codes.

Moreover, OSS is extremely transparent with its vulnerabilities - there are more pairs of eyes looking at OSS libraries and their vulnerabilities and the users of OSS often report bugs. So maintainers work to fix these bugs in the latest release of software. So theoretically speaking - the most updated version is also the most secured one.

So what is the challenge?

Although OSS might be more secure than closed source codes, the weight of responsibility in vulnerability prevention is unfortunately shifted from vendors to developers. Developers are recommended to constantly patch their libraries to the latest version, as the latest versions usually fixes bugs that have been disclosed in previous versions that were used.

Despite expert advice on the need to constantly patch open source libraries, developers would rather put their effort on developing new functionalities on a day to day basis. These vulnerabilities are not affecting their code performance in the time being, and afterall, why fix what is not broken?

So whose responsibility is it anyway?

While developers are responsible for the codes they write, they also have a million other things to do, and have no way of determining which libraries are vulnerable. Fortunately, the amount of effort required for organisations to secure their OSS can be minimised by automating the detection and remediation of vulnerabilities.

With a Software Composition Analysis (SCA) tool, developers do not need to waste time in determining the next secure version to patch to. A good SCA tool will be able to recommend which library versions are secure, and which of these secure versions have a higher compatibility with the current version to reduce the developers’ efforts in rewriting codes. A good SCA tool will also be able to monitor open source components and alert developers of new vulnerabilities disclosed, allowing for fast and easy action by development teams in patching vulnerabilities.

Conclusion

As with dealing with any security vulnerability, the efficient way in managing such risks is not to try patching every single vulnerability – big or small. Organisations should prioritise the vulnerabilities they need to patch, typically the ones that can cause severe consequences, are easiest to exploit, but are also easiest to deal with. With a good SCA tool, organisations can lower the costs of fixing high priority vulnerabilities and make it harder for adversaries to breach their applications.