How to mitigate and manage open source risks
FYI, this story is more than a year old
Open source components have long been at the centre of application development, giving developers the readymade building blocks to build software faster and more efficiently. By some estimates, open source components comprise between 60-80% of the code base of modern applications.
According to a recent survey, 97% of developers responded that they use open source components in their applications, with over 87% stating that they use it heavily.
We can assume that the 3% who do not use open source components are restricted by their organisation due to regulatory measures beyond their control, because after all, who wants to write basic code from scratch when there are fantastic components available for free from the open source community?
Considering how dependent the software industry is on open source, we need to ask the question about how organisations are managing their usage of these powerful components.
Addressing the risk from open source security vulnerabilities
Unlike proprietary code that is written in-house and maintained by a single organisation, open source projects are constantly being reviewed by members of the community who report bugs and vulnerabilities. Linux creator Linus Turvold termed this process of community review as the “thousand eyeballs” who help to keep open source secure, passing on their discoveries for the good of the community.
The good news is that the vast majority of the vulnerabilities have fixes available at the time that they are posted to databases like the National Vulnerability Database (NVD).
The challenge though is that once a vulnerability is published to a public database for use by developers in patching their software, hackers can also view this information to get free intelligence on what is newly vulnerable, as well as a detailed explanation on how to exploit it. Their hope is that they can use these vulnerabilities to breach their target’s application and steal their data to sell on the black market.
This strategy has paid off like was seen in the 2017 case of Equifax where the personally identifiable information (PII) belonging to over 147 million people was stolen when hackers exploited a known vulnerability in Apache Struts that the company had been using in their web application. According to reports, the breach was made possible by the fact that the company was not efficiently tracking which open source components were in their applications, and therefore did not know that they needed to patch their software when the vulnerability was disclosed.
Continuous tracking simplifies compliance
Even as security is a primary driver for most organisations to start taking responsibility for their open source usage, utilising an SCA tool can also help make legal compliance far more manageable.
Keeping an inventory of all the open source components that are being used in the development of software is important for ensuring that an organisation’s software is in compliance with company policy, and that open source components which are not compliant will not be incorporated into the product’s code base.
When these risky components are discovered late in the development process, they require more costly tear and replace operations as developers will have to reconfigure the product with an alternate component that will not disrupt the functioning of their product.
Failure to keep an updated inventory can also be an issue for startups looking to sell their company in an exit, as the acquiring company will ask for a Bill of Materials (BoM) that lists all of the components in their product. Tracking licenses is key here as a buyer will want to avoid taking on risks to the IP that they are purchasing.
By using automated tracking to continuously monitor which components are being used, developers can be alerted to known vulnerabilities or licenses associated with the component before it is added to the code base, failing the build if necessary to keep the product secure and in line with an organisation’s policies.
Taking control of open source usage
Given the scale of open source usage within most organisations, manual tracking simply is not an option.
One of the major takeaways from the Equifax case was the need for an automated solution that could track open source components from the time that they enter a developer’s repository, through the software development lifecycle to post-deployment with alerting on newly discovered vulnerabilities.
Organisations can now take advantage of Software Composition Analysis (SCA) tools for managing their open source usage, staying up to date on their vulnerability status, setting and enforcing policies for security and license compliance demands, and making remediations of vulnerable components less painful.
Backed by comprehensive databases that draw from sources like the NVD as well as a wide range of security advisories and issue trackers, advanced SCA solutions can identify the open source components in a software product and match them to known vulnerabilities. Developers can receive warnings that a component is vulnerable before they use it, preventing the need to remediate it later.
With great power comes great responsibility
Open source components offer developers a powerful tool for keeping up with tight deadlines and directing their focus to add innovative features that will make their product stand out from the crowd. As the saying goes though, with great power comes great responsibility.
If organisations are going to benefit from using open source components, they need to use the right tools to keep their product and customers safe from hackers. By setting policies with strong solutions, organisations can let their developers use open source components without fear of compromising their security or compliance needs.
Article by Rami Sass, CEO of WhiteSource