5 ways to find and fix open source vulnerabilities
Credit to Author: Malwarebytes Labs| Date: Tue, 17 Jul 2018 15:00:00 +0000
Guest post by Limor Wainstein
A recent discovery of surreptitious execution of cryptomining code by a sandboxed app, riding piggyback on the open source software (OSS) ecosystem, raises pertinent questions about the security of open source code and its dependencies. Programmers often use OSS as a jump-off for creating their software—and that includes malware authors.
The rogue app, which was found to be mining customers on May 11, was delivered through snapstore, the new cross-distribution, sandboxed application ecosystem initiated and promoted by Canonical, the developers of Ubuntu. In follow-ups to that incident, Canonical said:
It’s impossible for a large-scale repository to only accept software after every individual file has been reviewed in detail. That’s true whether source code is available or not, as no institution can afford to review hundreds of thousands of incoming source code lines every single day.
As noted by Canonical, reviewing and analyzing open-source dependencies isn’t an easy task. But it’s an important one for programmers who want to make sure their software isn’t infiltrated by bad actors, whether that’s to mine cryptocurrency or to conduct even more nefarious business.
Why do you need to secure your open source libraries?
Developers rely heavily on open source software, and organizations are inclined to use free popular libraries. However, according to Barkley’s 2016 Cybersecurity Confidence Report, only 22 percent of organizations have a framework to regularly identify and analyze the various components built on their applications. With the growth in use of open source code, the risk exposure expands as well.
New vulnerabilities are constantly being unearthed in different open source code and, worryingly, a number of projects have little or no mechanisms in place to identify and fix those problems. According to a recent Snyk survey of open source maintainers, 44 percent have never undergone a security audit of any kind, while only 17 percent can claim to have a high level of security know-how.
In addition, there is no standard operating procedure for documenting security on open source projects. Among the top 400,000 publicly available repositories on GitHub, only 2.4 percent have a form of security documentation in place.
Since an open source dependency might be heavily deployed in a number of web applications, a bug or vulnerability will open up all of those projects to security risks. To improve the security of your open-source components, we recommend the following five best practices for reviewing dependencies, finding vulnerabilities, and patching those vulnerable open-source components once found.
1. Set strict security rules and standards before using a dependency
A good way to improve the security of your open source components is to build and enforce policies that require the developers using them to prove that they do not have any known vulnerabilities.
A lot of developers are largely still unaware of the risks posed by different open source components. It is of utmostimportancet to help them understand that vulnerabilities brought from open source components into the application puts the whole app at risk, if not the organization as a whole.
By creating and enforcing policies that either require the security team to approve of open source components, or require developers to prove the security of the tool, you automatically improve the security of your application—just by making developers aware of such risks.
2. Keep track of security updates for dependencies
Another crucial aspect to the security of open source components is to have an updated inventory of your organization’s open source libraries, both in development as well as in production. There are a fairly large number of organizations that do not have updated information on which open source components are currently under use in their applications. This poses a major security threat.
A lot of the popular proprietary applications contain indirect open source components that might not be in active development. Most of these open-source components remain unpatched and become insecure over time. This is usually because the developers spend their resources on securing and improving the in-house components. However, ignoring the security updates for your OSS components can open up loopholes that will go unnoticed.
A good place to begin rectifying this is by surveying the organization’s development teams on what open source components they use and the last time these were updated. This provides a window into assessing how updated the development team is with open source component security, as well a list of projects in use.
If your organization has the required infrastructure, you can also create a central repository of open source components where security updates and licenses can be managed. Similar to any other security process, managing an open source component is not a one-time effort. It is a continuous process for as long as the app is in deployment. Review, rinse, and repeat.
By ensuring that your policies on open source libraries are being followed, and by monitoring how these are being used, as well as managing your inventory, your overall application security program should be in good stead.
3. Test your components and dependencies
Probably the surest method of improving and ensuring the security of your open source code, and in the process your overall application, is to test the security of open source components being used within your organization once they’ve been identified.
Open source analysis is as important as proprietary code. This is not only because the code could hold unknown security vulnerabilities, but also because its dependencies and functions may differ between different use cases. This could mean that a component may be secure in one application, but found to be insecure when used in a different application. In cases like this, only testing and code review can identify these issues.
4. Build in-house tools instead of unsupported (expired) libraries
For expired libraries, or libraries that no longer have active developer maintenance systems, it is better to build your own in-house tools that you can use to actively check for and fix vulnerabilities. Though the initial cost and time spent might deter some organizations and development teams, in the long run, the functionality of an in-house tool can be an asset to developers.
You can also consider giving your in-house effort back to the community, making the open-source ecosystem stronger. This will encourage more developers to submit patches and revisions and therefore improve the overall security of the library. Apart from that, you will earn the respect of open source developers, which will help you grow as an individual and a business. For instance, over the last couple years, Microsoft has released tons of libraries under an open-source license that have helped them earn the trust of OSS developers and users.
5. Use security tools to check for security vulnerabilities
A number of different open source and commercial tools have been developed over the years to tackle the problem of identifying security vulnerabilities in open source components. Each tool or service tackles the problem a little differently.
Node Security Project (NSP)
The NSP is known largely for its work on Node.js modules and NPM dependencies. The latest version of npm integrates NSP to implement the npm audit script. It checks for any known vulnerabilities in your node modules and related dependencies, and offers support for patching those vulnerabilities.
RetireJS
RetireJS is an open source dependency checker specific to JavaScript. Its unique selling proposition (USP) is its ease of use. RetireJS contains multiple components, including a command line scanner, as well as plugins for Chrome, Firefox, Grunt, Gulp, ZAP, and Burp.
OSSIndex
OSSIndex is a tool that supports several different technologies. It effectively covers JavaScript, .NET/C#, and Java ecosystems. It also provides API vulnerability for free.
Dependency-check
Dependency-check supports Java, .NET, and JavaScript, as well as Ruby. It pulls its vulnerability information from the NIST NVD.
Commercial tools
Apart from the free tools, there are a few commercial tools that you can use to help find vulnerabilities in your open-source code. The popular ones include:
- Hakiri: a commercial tool that provides dependency checks for Rub-y and Rails-based GitHub projects via static code analysis
- Snyk: a commercial service focusing on JavaScript npm dependencies
- WhiteSource: currently supports Ruby, NPM, PHP, Python, and Bower
- SRC:CLR: Source Clear comes with a load of plugins to several IDEs, deployment systems, and source repositories, as well as a command-line interface
Open-source components are generally safe when there are a large number of people reviewing the code. However, making the source code available or having many users look at the source code doesn’t guarantee that all the security issues have been found and fixed. That’s why it’s important to integrate industry standard security policies into your application.
In this post, we’ve covered some of the best possible ways to secure your open source components against vulnerabilities and other security exploits. So, what are your thoughts on securing open source components? Share them in the comments below.
Limor Wainstein is a technical writer and editor at Agile SEO, a boutique digital marketing agency focused on technology and SaaS markets. She has over 10 years’ experience writing technical articles and documentation for various audiences, including technical on-site content, software documentation, and dev guides.
The post 5 ways to find and fix open source vulnerabilities appeared first on Malwarebytes Labs.