From

Thank you

Sorry

Recently, SAS issued a rather plaintive call for enterprises to limit the number of open source projects they use to a somewhat arbitrary percentage. That seems a rather obvious attempt to protest the rise of the open source R programming language for data science and analysis in a market where SAS has been dominant. But there is a good point hidden in the bluster: Using open source responsibly means knowing what you’re using so you can track and maintain it.

Most enterprises aren’t aware of how much open source their developers use and what vulnerabilities that might expose them to. You can’t do security assessments or patch management on open source projects you don’t know you’re relying on.

Sonatype’s 2016 software supply chain study found that third-party components comprise eighty to ninety percent of the code in a typical enterprise Java application — and one in sixteen of those components that enterprises download has a security vulnerability. Older components have three times as many security flaws as newer versions, and over half of the components used in enterprise apps are over two years old. Two years after the Heartbleed bug was found, more than half of the OpenSSL versions Cisco Security Research tested in 2015 were still vulnerable.

“Even software companies that already know they’re using open source code may need tools to manage that better. Enterprises rarely know just how much open source they’re using,” Rami Sass, CEO and co-founder of open source monitoring and management service WhiteSource tells CIO.com. “Enterprises like banks, financial services companies, media companies have large software engineering departments these days. They’re often surprised to find out how extensive their use of open source is and how little of that their manual inventory processes have been tracking. On average, they find three times the number of components they thought they had. Sometimes it’s as high as 10 times.”

This isn’t to say that you don't want your developers to take advantage of open source, especially if you’re moving towards DevOps, because there are so many useful tools available in areas where writing your own code doesn’t do anything to differentiate you from your competitors. “Using open source in business makes sense, because you want your developers to stay focused on your core business,” Sass says. “So much of what you need has already been invented; you want to reuse something that’s already been tested and that’s maintained by the community, so that you don’t have to do all the heavy lifting. That’s why everyone loves open source — but unfortunately, open source has its own issues.”

Open source license liabilities

In the past, businesses were often most concerned with the licensing side of open source. “Open source is free but it does come with a lot of strings attached,” Sass points out. Open source licensing can be a minefield for commercial organizations. Although an increasing number of projects use permissive licenses like the MIT and Apache licences, which have minimal requirements about how the code can be redistributed, other licenses have more onerous requirements. Google’s recent guidance on how it uses open source includes notes on which licenses, like AGPL, are banned internally because of the requirements to publish the code of derivative works.