Secure open source components to bypass breaches
As enterprises increasingly turn to open source code to cut dev efforts and costs, IT industry vendors recommend that they secure dependencies and deploy patches to safeguard apps.
The Equifax data breach of 2017 provided a wake-up call for businesses that handle sensitive data. The company attributed the breach to unpatched open source software -- and it wasn't alone. In 2018, security breaches at Aadhaar -- India's national citizen identification database -- and Alaska Airlines were also the results of unpatched open source software.
It's hard to stay aware of problems in open source frameworks, especially less vetted open source packages that developers use to customize apps.
So, ultimately, is open source safe? A survey of more than 2,000 IT professionals conducted by Sonatype, a platform that governs open source components, found that 31% of respondents suspected or verified a breach related to open source components in 2018 -- a 55% increase from the previous year. The threats are real, so enterprises have to know how to avoid them and secure open source software.
Don't get burned
Mik Kersten
The main concern with open source software code is that there's no single governing body that vets each project's components. Open source is not one thing; it's a description of various technological offerings available for consumption and contribution in myriad ways. Open source components can vary quite a bit in terms of reliability, security and quality, said Mik Kersten, author and CEO of Tasktop, a value stream management tool provider.
When developers build on open source software, they can easily bring a significant number of dependent components into an application. And they can do so without understanding the components' quality, which makes it easy to expose a project to dubious security setups. The concerns aren't only about the code itself, but where it runs -- in the cloud or on premises.
"Once you get burned by that once, you realize the concerns are legitimate," Kersten said.
Vulnerabilities aren't unique to open source
Despite these concerns, open source code can be more secure than proprietary code. This is true in the case of well-known projects, like Apache Tomcat or Kafka, which boast large communities of developers that work constantly to improve and secure open source code. Many organizations have determined how to use open source components in a reliable and safe way.
There are no discernible differences between proprietary and open source security vulnerabilities, according to Rami Sass, CEO of WhiteSource, an open source license management and security company. When an open source security vulnerability is found and fixed, the discovery and resolution are published for the entire community to see -- not so for proprietary software. This transparency around open source vulnerabilities kicks off a race for developers to implement a patch before attackers move in.
Enterprises must continuously monitor and take stock of which open source components they use, avoid adding vulnerable components to their software and track down vulnerabilities with diligence.
What to make of open source
Enterprises find they can't fight open source security vulnerabilities with a blanket ban on open source components, which would result in a lot more work for developers.
Isaac Schlueter
"A typical modern web application pulls over 98% of its code from the open source community," said Isaac Schlueter, chief product officer of NPM Inc., a company that maintains the open source package manager for Node.js. That dynamic represents a massive efficiency gain for developers compared to an application written entirely in-house, as well as a tremendous amount of shared interest in boosting security within the digital commons.
Developers can effectively mitigate malware and other threats when they secure open source software's chokepoints along such project's supply chains. Schlueter recommended that teams make decisions based on rational factors so that they don't trade small problems for much larger ones. A team might minimize risks through an infrastructure and code audit that correlates the use of packages with reported vulnerabilities.
Put management safeguards in place
One growing concern with open source vulnerabilities arises from complex dependencies in modern apps. Negligent management practices, not the code itself, are often the biggest inhibitors of open source usage. Tasktop, Kersten's company, implemented a process in which its deployment pipeline will automatically stop if an open source library dependency check fails, even if it's 20 dependency levels deep. If a dependency is not fulfilled, Tasktop won't release the problematic software.
And, if Tasktop engineers discover an upstream component with a problem, they aim to file a bug or issue a patch to that project.
"Like many other companies that grew out of open source, we take an active role in participation and in how we integrate open source into our delivery pipeline," Kersten said. "The better you understand the dynamics of the open source ecosystem, the safer and more productive you will be."
JavaScript-based apps are especially complex -- and problematic -- as one component depends on others. For example, a developer might add one JavaScript framework and end up with over 100 dependent projects sucked into an application. The next time that the framework updates, the application can end up with more dependencies added than anyone realizes. In 2018, as an example, a hacker deliberately took stewardship of a low-level component used in a cryptocurrency wallet and then added code to target the exchange's customers.
Brian Fox
"Without a system to properly understand and track all of these transitive dependencies, even your developers may not realize all the extra baggage that gets included," said Brian Fox, CTO of Sonatype. Any single component, whether it is called by custom code or not, can introduce an exploitable vulnerability.
Prioritize security, training
Organizations need better training to secure open source software and consume it with peace of mind. Even if developers choose libraries with the best ratings by default, such collections might not be the most up-to-date libraries with patched vulnerabilities.
"If we want to look at the challenge of using open source securely, then we need to think about how it is used and how it can end up in our products," Sass said.
Resources like the National Vulnerability Database keep track of known vulnerabilities. Also, some commercial tools continuously inventory open source components and match them against newly discovered vulnerabilities. These tools can catch bugs after the fact and alert teams when a new vulnerability pops up.
Some IT organizations push security testing left, into the development lifecycle, as part of the developer workbench using software composition analysis tools. With this approach, they can set automated policies to block vulnerable components from use in the company's software in the first place. Just as static code analysis evaluates code quality at check-in, these composition analysis tools enable developers to analyze code security at check-in.
Don't forget remediation
In the beginning of an open source security upgrade, it might make sense to triage the removal of known vulnerabilities from a large code base, said Sergiy Golub, senior engineering manager at Assembla, a version control and source code management technology provider. Developers pull specific components of broad open source projects into their applications to work with the custom code they write; so, a known vulnerability might not affect an enterprise if it has no use for that questionable bit of code and removes it.
"An open source component may have a legitimate vulnerability, but if the vulnerable bit of code is not being used by our product, then it does not pose a direct risk," Golub said.
Organizations should identify the most pressing vulnerabilities so that they can prioritize remediation activities for efficient use of developers' time and resources.
