To maintain good open source code hygiene in the development process, you must first establish what you mean by open source code hygiene, including good and bad hygiene. “By hygiene, we just mean is it appropriate? Is it clean for the intended use?” says Mike Pittenger, VP of Strategy at Black Duck Software.
Black Duck suggests three metrics it uses to determine whether it is appropriate to apply a given open source code project to a certain development endeavor:
- For software that will be distributed at large, avoid open source code that the development community has made available through a GPL license.
- For secure software, check your potential open source code for vulnerabilities in general and make sure to use the most secure version available.
- Monitor the code periodically to check for new vulnerabilities or other concerns.
As an example of the third point, Pittenger notes OpenSSL is no longer a viable option because of the vulnerabilities that have come to light in the form of Heartbleed.
Checking Source Code for Open Source Concerns
While the InfoSec Institute recommends at least 14 different open source vulnerability scanners for web applications alone, offerings such as Black Duck’s can serve as a shortcut to discovery of known bad open source components. “Instead of having to load Nessus, Metasploit or Nexpose with a Heartbleed rule and scanning every application, every server that they’ve got, they can just go into their Black Duck console, type in OpenSSL, and it would immediately show them every version they used in their software applications,” says Pittenger. Of course, you should always do your own due diligence to determine whether any scanning product is the best choice for your organization and aligns with your needs and requirements.
Due to the many open source code reuse scenarios active in enterprise DevOps shops, you will want to continually monitor code for newly registered vulnerabilities. Enterprises can view reusing existing assets as a built-in savings by not having to purchase or create new assets. In the case of reusing legacy source code, there is also a time savings, as developers want to shrink time to market for code-based projects.
“Let’s say you have a company that is pulling information from a database to display in pie charts. You have a rendering component that you will reuse. When you’re starting on a new product, do you build a new rendering library from scratch or do you use the existing one?” asks Pittenger.
Even if those components are open source, there can be great savings in reusing the library.
The fact that enterprises do this underlines the importance of continuing to check any code that leverages open source code, as this is how vulnerabilities can spread over time. It’s also important to check open source code, because it may be a form of low-hanging fruit for attackers. Open source code is fully viewable by attackers who build malware and launch attacks, whereas proprietary code is closed.
Since people constantly discover new vulnerabilities in open source code components that previously had tested free of such holes, it’s important to monitor those components for newly uncovered weaknesses, even as you reuse open software in new projects.
Containers are a great example. You may want to dismantle an image in varying degrees to build a new application. “If I have a base image and it’s built using a LAMP stack (i.e., a Linux OS, an Apache HTTP server, a MySQL RDBMS and PHP), I can strip down my base image, take away the existing app and take it all the way down to the Linux component, then build it up for the new application,” Pittenger said. “That is a typical, consistent reuse of open source components.”
During the process, recheck every component for vulnerabilities. Even if everything checks out doesn’t mean you have the best assurance of security for those components going forward. By monitoring those components, you can stay on top of updates to fix any newly discovered security holes.
