Skip to main content

Avoid open source risks: Keep track of it!

(Image credit: Image Credit: B-lay)

It’s a pretty good bet that most high school seniors don’t tell their career counselor that their dream is to become a Chief Inventory Officer—if the title even exists. It doesn’t imply glamour, prestige or excitement. It carries the scent of drudgery—days on end spent with a clipboard in a warehouse.

But the reality is that inventory is just as important as the more glamorous stuff. Maybe more so when it comes to the software components used to build and run applications, networks and systems.

Especially when those components are open source software, since open source now makes up the large majority of anything made with, or powered by, software. Failure to keep track of them can lead to catastrophic trouble.

Fortunately, nobody needs to dream of spending a career combing through tens of thousands of software components to do that. There is a tool—software composition analysis (SCA)—that automates the task. It helps maintain a complete inventory—a bill of materials (BOM)— so the risks of open source won’t undermine its benefits.

Open source is no more or less risky, than proprietary or commercial software. And in a number of ways it is better. It is increasingly popular for good reasons: It is free and can be modified to suit whatever needs an application developer has. It is an adaptable building block.

As Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Centre (CyRC) has put it numerous times, “open source powers innovation.”

So it is no surprise that the most recent Open Source Security and Risk Analysis (OSSRA) report by Synopsys, out last month, found in audits of more than 1,250 codebases across 17 industries that open source is now the dominant element in them.

Not only did virtually 100 per cent have some open source components, but also an average of 70 per cent of the code was open source, nearly double the 36 per cent found by the first OSSRA report.

Another measure of the increase is that there was an average of 445 open source components per codebase in 2019, up nearly 50 per cent from 298 just a year earlier.

Security and patching

A host of industries depend on open source, ranging from enterprise software to virtual reality, gaming, entertainment, media, internet and software infrastructure, retail and ecommerce, Internet of Things (IoT), financial services, big data, machine learning, energy, cybersecurity and marketing tech.

All of which means that if you are in business, the chances that you are not using open source software are vanishingly small. You’re probably using a lot of it – more than enough to make it impossible to track it all manually.

But it is crucial to keep track of it, because the fact that open source is free doesn’t mean it comes free of risks or obligations. There are two in particular – security and legal. And both of them can be mitigated significantly with a comprehensive BOM that includes all components, the versions in use, and download locations for each project in use or in development.

Regarding security, as noted earlier, open source is no more or less secure than proprietary code. But inevitably, there will be vulnerabilities that will need patching. If you don’t patch, it can cost you, big time. If your applications or networks get breached because of vulnerabilities in open source components you don’t even know you’re using, the parade of potential horrors is by now familiar: stolen IP, theft of customer PII (personally identifiable information), ransomware attacks, loss of reputation, legal liability, punitive fines for noncompliance and more.

And patching open source, while not difficult, requires awareness. It is not as simple as checking an “auto-update” box, which works with commercial software since most vendors automatically “push” patches out to users. Open source patches are made available as well, but users are responsible for keeping track of them and “pulling” them from a repository to install them.

Inventory is crucial

Fail to do that, and you could end up being a version of Equifax, the credit reporting giant that discovered on July 29, 2017, that it had been breached, leaking Social Security numbers and other personal data of more than 147 million customers because it failed to apply a patch to the popular open source web application framework, Apache Struts, which had been available for several months.

That specific problem seems to be going away—this year’s OSSRA report found that none of the codebases audited in 2019 contained the unpatched version of Apache Struts. But there were plenty of other ways to get in trouble. It found that 82 per cent of the open source components in the audited codebases were out of date and that 75 per cent contained at least one public vulnerability.

How out of date? The average age of vulnerabilities found in the audited codebases was a little less than 4 1/2 years. The percentage of vulnerabilities older than 10 years was 19 per cent.

Bottom line: inventory is crucial. As has been said for decades by software experts, you can’t patch what you don’t know you have.

The second risk is legal. While open source code is free, it comes with licensing requirements that can put you at risk if you ignore them. And there are a lot of licenses out there. The OSSRA report found that while the 20 most popular cover approximately 98 per cent of the open source in use, the Black Duck KnowlegeBase contains more than 2,500 open source licenses.

While compliance with most of them isn’t difficult, “even the friendliest open source licenses come with obligations, at a minimum to provide attribution for the copyright holder,” said Phil Odence, senior director of professional services, at Synopsys.

Software isn't bulletproof

Also, the terms of licenses can be a problem. “You may be using software in a way that’s incompatible with them—a license conflict. In the extreme, you could lose the right to use the software or find your company in a lawsuit,” Odence said.

Finally, even if open source components have no identifiable license terms, you’re not off the legal hook. That simply means it is likely you can’t use, modify or share the code, since creative work (which includes code) is under exclusive copyright by default. A license is essentially permission to use. No license, no permission.

So once again, inventory is important. Without a comprehensive BOM, you are blind to any number of risks, some of which could be catastrophic. Which is why an SCA tool ought to be mandatory as part of software development. It will not only help find open source components in a codebase but also report which version you’re using, along with known security vulnerabilities in those components.

It also reports the licensing compliance requirements related to those components.

And it will do it while developers are building apps, throughout the software development lifecycle (SDLC).

No set of experts and tools can make software bulletproof. But an SCA tool can help you manage those risks to the point where you can spend your time growing your business instead of dealing with open source security and legal nightmares.

Taylor Armerding, security advocate, Synopsys (opens in new tab)

Taylor Armerding is a senior infosec writer at Synopsys. He is an award-winning journalist who left the declining field of mainstream newspapers in 2011 to write in the explosively expanding field of information security. He has previously written for CSO Online and the Sophos blog Naked Security.