The Most Overlooked Risk in Software Development Today

4 steps to safely using open source in application development

When Bill Gates and Paul Allen built their first commercial software in the 70’s, every line of code was written solely by the two of them. And for the decades following, large teams of developers rented out big office spaces to collaborate and build software, and then that software was sold commercially.

In the last decade, however, the software development lifecycle has changed dramatically. Not only do we not have to sit next to each other in order to work on the same software nowadays, our brainpower is not limited to just the people on our teams. The explosion of open source code has revolutionized software development because instead of developers writing every line of code, they can take several coding components that are found in the public domain and blend them into a fully functioning product in a fraction of the time it took in the 90’s. Software development teams in 98% of the world’s companies admit to using open source in their applications.

While the use of open source code is the latest phenomenon in commercial application development, most companies still haven’t figured out how to control it. When people outside of your organization build up to 80% of your code, there has to be some risks that you are taking on.

So what exactly are the risks?

Most people will automatically assume there has to be security risks. How do I know there isn’t some malicious developer out there trying to break into my application through open source? Although this is possible, it isn’t very likely if you are using open source that multiple developers have contributed to. But open source code, just like proprietary code, is susceptible to exploitable security gaps. However, with open source, these security vulnerabilities, once identified by the ‘community’, are often published to help users respond to the threat. The difficulty in keeping on top of security risks is keeping track of not only what open source you use, but also security advisories as they are published.

Another risk in using open source in a commercial setting is legal compliance. Each open source project has a license associated with it. Licenses range from permissive (i.e. MIT and BSD) to restrictive (i.e. GPL). Just because something is made available ‘open source’ doesn’t mean that you can freely use it without adhering to certain requirements. Some licenses include a caveat that require the code of your derivative product to be open sourced as well. This is a caveat that has turned many products from a licensed product suddenly into a free product.

The third risk in using open source is maintenance risk. By using a component that is maintained by a worldwide community of developers, you are hanging the health of your application on the willingness of the community to continue to patch and improve the project. The health of an open source project is very finicky and deprecated open source projects in your applications can lead to bugs that the developers in your organization will not be able to fix very easily. The support level in the millions of open source options range vastly from “robust and well-financed” to “hackathon project” that nobody works on anymore. Your developers’ job is to assess which open source solution has the highest likelihood of being maintained over the long term.

So how do you take charge of these risks in using open source? Check out our follow-up posts which will break down the 4 step process to being a proactive steward of your codebase.

1. Identify what open source is already used in your application.
2. Look up licenses, check for updates, and cross reference security vulnerabilities.
3. Add all new open source components to your inventory list.
4. Develop a schedule to continually look for needed updates and security vulnerabilities.

Full disclosure: I work for GitLinks and we have built these four steps into an automated SaaS platform.