So here’s why every VP of engineering needs to know about and control the open source components that are being used in their environment.
We see that about four out of five developers, according to our latest Forrester developer survey, say that they’ve used open-source frameworks or projects in applications that they have developed or delivered in the past 12 months. Now, let that sink in. Four out of five!
Open-source is practically ubiquitous. It’s being used at scale and as a result, you need to know some things about it especially when it’s not necessarily something that you’re consciously dictating is going to be used in your environment. You need to know what’s being used, you need to know who’s using it, you need to know what version they’re using, and you need to know what both the risks and opportunities are.
One of the biggest reasons for managing open source usage is because of the license compliance issues that we see around open-source. There are roughly 70-odd open-source licenses according to the OSI, the Open-source Initiative. Of these, a certain number are what we would call viral or copyleft. Now, the issue with copyleft licenses is they may place certain IP demands on any software that they are linked to and distributed to. And we’ve seen companies get themselves into trouble when they use these sort of software licenses without necessarily knowing what developers are doing.
Let me give you an example: a number of years ago, Cisco used a chip in one of its routers. It was produced by another company and that company used open-source software that was being made available under the GPL license, which is a copyright license. Cisco didn’t necessarily know about it and they only discovered after the case that that had been done and it was actually a third party that discovered that. That third-party sued to get Cisco to open up the firmware for their router. In actuality, it became one of the most popular home routers that Cisco ever manufactured because developers took that open-source hardware and hacked it and added additional features, but it created a lot of risk for Cisco.
I once worked at a company where, completely unbeknownst to us, one of our developers linked to a certain software library that had it not been discovered and disclosed, would’ve required us to potentially open up one of our best selling products. We very quickly and quietly remediated the defect, eliminated the library, shipped an updated patch to our customers and were able to get out from under that risk without anybody else outside the company being the wiser, but it’s an example of the kinds of things that VP of engineering folks have to be concerned about.
So the second reason that VP of engineering folks should be concerned about using open-source is potential security vulnerabilities. Now, we’ve been conditioned to think that open-source is generally more secure than commercial software and that’s because of what we call “security through transparency.” If the source code is open and anybody can look at it, then anybody can identify potential defects or vulnerabilities and those defects can be quickly fixed.
Generally, I believe that this is the case and that we do tend to see very secure open-source software, but there are always exceptions. It’s particularly the case when the algorithms that are being used are very complex or when it’s code that’s a very deep in the software stack and there are not a lot of developer eyeballs on that particular piece. We saw a really good example of where security through transparency broke down last year with the Heartbleed vulnerability. Heartbleed was a vulnerability in Open SSL that caused encryption-based software to be crackable so that you could decrypt information and exploit it.
Now, that’s probably an extreme example, but there are other examples where vulnerabilities in open-source projects do create potential vulnerabilities for the companies that are using those open-source projects. It’s really important to know what those vulnerabilities are and also know if you are using any particular versions of software that are affected by those vulnerabilities so that you can patch that open-source code as quickly as possible.