Keeping track of everything you have can be boring. Chief Inventory Officer—if the title even exists—doesn’t imply glamour, power or riches. It carries the scent of drudgery—days on end spent in a warehouse. But the reality is that it’s just as important as the more glamorous stuff. Maybe more so.
In IT—information technology—that is especially true of software components used to build applications and run networks/systems. Failure to keep track of them can lead to catastrophic trouble.
Especially when those components are open source software.
That doesn’t mean open source is worse, or more risky, than proprietary software. In a number of ways, it is better. It is increasingly popular for good reasons—among them that it is free and can be modified to suit whatever needs an application developer has. It is an adaptable building block. As Tim Mackey, cybersecurity strategist at Synopsys puts it, “open source powers innovation.”
So it is no surprise that the most recent Open Source Security and Risk Analysis (OSSRA) report by Synopsys, out this week, finds that open source has become the dominant element in codebases. The findings are based on audits of more than 1,200 applications across 17 industries.
Why you should track open source
One measure of that is the average number of open source components in a codebase, which jumped 16% in a single year, from 257 in 2017 to 298 in 2018.
Another is that a host of industries—two dozen of them cited in the OSSRA—are building apps with a large majority of open source components—in the 58% to 78% range. Those industries range from enterprise software to virtual reality, gaming, entertainment, and media; internet and software infrastructure; retail and e-commerce; Internet of Things (IoT); financial services; big data and machine learning; energy; cybersecurity; and marketing tech.
All of which means that if you are in business, the chance that you are not using open source software is vanishingly small. You’re probably using a lot of it—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. There are two in particular—security and legal.
A different patching protocol
Open source code is no less secure than proprietary code, but it is not more secure either. 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 you don’t know what open source components 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 is not as simple as enabling a version of “auto-update,” 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.
Fail to do that, and you could end up being a version of Equifax. The credit reporting giant discovered on July 29, 2017, that it had been breached, leaking Social Security numbers and other personal data of more than 147 million customers. Why? Because it failed to apply a patch to the popular open source web application framework Apache Struts—a patch that had been available for several months.
Vulnerabilities down but not out
The trend in open source vulnerabilities is encouraging. Of applications audited in 2018 for the OSSRA report, 60% had vulnerabilities—a significant decrease from 78% in 2017.
But 43% of those had vulnerabilities that were more than 10 years old. And things could easily go back in the other direction—the National Vulnerability Database (NVD) listed more than 16,500 new vulnerabilities in 2018—7,393 of them in open source products.
So inventory is important: As has been said for decades by software experts, you can’t patch what you don’t know you have.
Don’t get burned by ignoring licenses
The second risk is legal—while open source code is free, it comes with licensing requirements that can get you in trouble if you ignore them.
And there are a lot of licenses out there. The OSSRA report found that the 20 most popular licenses cover approximately 98% of the open source in use, but the Black Duck KnowledgeBase™ contains more than 2,500 open source licenses.
“Most licenses are fairly benign and not overly difficult to comply with,” said Phil Odence, senior director, professional services, at Synopsys. “But even the friendliest open source licenses come with obligations, at a minimum to provide attribution for the copyright holder. To comply, you need to know what licenses you are obligated to and therefore what open source components are in the codebase.
“And some 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,” he said.
“No license” doesn’t mean “no liability”
You’re not off the legal hook even if open source components have no identifiable license terms. If they don’t, that likely means 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.
Here again, there are encouraging trends. The OSSRA found that in 2018, license conflicts decreased in most of the industries audited. But they still ranged from a low of 52% to a high of 79%—more than enough to put you at risk.
“Overall, 68% of codebases had license conflicts,” Odence said, “and 61% with the GPL [General Public License] family, which tend to be problematic in ways described above.”
Which means, once again, inventory is important.
To track open source, keep SCA in your toolbox
So what should you do, given that it is impossible to track your open source code components manually?
Well, there isn’t an app for that. But there is a tool that automates what you need to do.
Software composition analysis (SCA) not only finds open source components in a codebase but also reports which versions 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 you’re building your apps, throughout the software development life cycle (SDLC).
There is no way to make software entirely bulletproof. But an SCA tool can lower your risks to the point where you can spend your time growing your business instead of dealing with security and legal horrors.
SCA—don’t use open source without it.
Continue Reading
Introducing fAST Dynamic: Streamlining dynamic application security testing
Mar 19, 2024 / 3 min read
