Open Source Software Can Make or Break Your Business. Don’t Let It Break You
It’s become a cliché because it’s true: If you’re in business, you’re a software company. But these days that cliché has become a bit more specific: You’re an open source software (OSS) company.
Because virtually all software products built and in use today include open source — the kind that’s free and available for anyone to use, modify, or share as they please, although it usually comes with some licensing restrictions or obligations.
Which is why, if you’re in business, you should check out a report released last week by the Synopsys Cybersecurity Research Center (CyRC) on how organizations around the world are managing both the security risks and the licensing requirements of their OSS. It can help you get a handle on how to reap the benefits while avoiding the risks of the major digital building blocks of everything from networks to systems to applications to smart devices.
(Disclosure: I write for the Synopsys Software Integrity Group.)
Open source is especially attractive because it’s the free version of what any modern business needs no matter what it sells — shoes, cars, accounting services, entertainment, whatever. You need software to operate the business — manage your supply chain, communicate with customers, run your website, handle transactions and billing, manage employees etc.
In fact, given that the Internet of Things (IoT) is rapidly becoming the Internet of Everything (IoE), chances are your products also have software in them. In an “everything-is-a-computer” world, the majority of physical products on the market today have sensors or other components powered by software.
And the massive amount and variety of OSS available means entrepreneurs don’t have to start from scratch every time they build a product. It amounts to free raw material — a foundation that makes application development faster, more efficient and cheaper. Depending on your creativity with those raw materials, it can make your product the coolest, hottest new thing.
Risks can undermine benefits
But the more ominous reality is that software can also break you.
If hackers are able to exploit vulnerabilities in software, it can lead to the now familiar parade of horribles — hijacking of systems, data leaks (and therefore theft of both corporate and customer data), denial-of-service attacks, brand damage, loss of market share, legal liability, response and recovery expenses, compliance sanctions etc. Catastrophic damage, in other words.
So it’s well worth understanding the risks of the software that’s “under the hood” of your networks, operations, and products. And one of the best ways to manage and minimize those risks is to see what other companies are doing — or not doing — to ensure that the open source software they’re using is not only functional but secure.
That’s the purpose of “DevSecOps Practices and Open Source Management in 2020,” the report by the Synopsys CyRC on the results of a survey it conducted in August of 1,500 IT professionals worldwide about how their organizations are managing their open source software.
The findings confirm what the Synopsys CyRC documented this past spring in its fifth annual Open Source Security and Risk Analysis (OSSRA) report — OSS is not only mainstream but is dominant. Virtually all codebases in use today have open source components — a lot of it. An average of 70% per codebase, which is nearly double the 36% found by the first OSSRA report.
Among the encouraging responses to the recent survey was that the ubiquitous use of open source has boosted awareness of the need to make sure it’s secure and stays secure.
The research firm Gartner reported earlier this year that corporate interest in software composition analysis (SCA) tools, which help developers manage both the security and licensing requirement of OSS, is growing rapidly. It said inquiries on the topic spiked nearly 40% from 2019 to 2020.
Also, a large majority of respondents (72%) said their organization has a published policy for OSS use. Fewer, but still a significant majority, said their policy defined acceptable open source licenses (62%) and prescribed patch or update requirements. About half (51%) said the security of an open source component is the most important factor in vetting it.
You have to pull the patches
That’s significant, because patching and updating in the open source world is different than in the proprietary world.
All software has bugs and other defects, and open source is no more or less secure than the proprietary or commercial variety. But in most cases, when a vulnerability is discovered in proprietary software, the maker will “push” a patch out to users. You don’t have to look for it. Perhaps the most common example is that almost every morning your smartphone will tell you that one or more updates are available for the apps you have on that phone.
With OSS, a community of volunteers that sometimes numbers in the thousands may spot vulnerabilities and produce patches quickly.
Phil Odence, senior director of professional services at Synopsys, said one of the benefits of vulnerability detection in open source is that “there are many eyeballs on it. When researchers find one, they want to let people know so they can fix it.”
But applying those patches is not as simple as enabling a version of auto-update. It’s up to users to be aware of when patches become available and “pull” them in to install them.
“Typically, when vulnerabilities are published, it’s only when a fix has already been created,” Odence said.
But as he and any other security expert will tell you, once a vulnerability is made public, hackers will race to exploit it as quickly as possible — often within days or even hours — before organizations apply the patch.
That means it’s crucial for organizations to keep track of the open source components they are using. Another cliché in the world of software security is, “You can’t protect what you don’t know you have.”
Manual tracking won’t work
And that’s where some of the survey results are less encouraging.
SCA tools are designed to help software developers build an inventory, or Bill of Materials (BOM), of all open source in the codebase, and they will flag any known vulnerabilities and potential licensing conflicts in those components. But only 38% of the respondents said their organization is using SCA.
That’s risky, because besides that basic inventory, a good SCA tool will specify the versions of the OSS component, the download locations for each project and all dependencies, the libraries the code calls to, and the libraries those dependencies themselves link to. All of which let users know exactly what they need to monitor for updates and patches.
That kind of tracking is difficult and time-consuming to do manually. So the likelihood is that without an SCA tool, it isn’t getting done in any comprehensive way.
That likelihood gets some confirmation from another one of the survey results. About half (51%) of the respondents said it takes two to three weeks for their organization to apply a patch to a critical open source vulnerability. Another 24% said it takes a month. Only 16% said they got it done within a week.
That’s a bit like a bank leaving the door to the vault open. Because while many vulnerabilities may not lead to catastrophic hacks, some of them can.
Perhaps the most notorious example was the 2017 breach of credit reporting giant Equifax, which compromised the Social Security numbers and other personal data of more than 147 million customers because the company failed to apply a patch to the popular open source web application framework Apache Struts — a patch that had been available for several months.
Tim Mackey, principal security strategist within the Synopsys CyRC, said organizations should work to improve the security of their OSS both by participating in the development of open source projects they depend on, which will help find undiscovered defects, and by using SCA to track known vulnerabilities so they can be patched quickly.
“Doing both places businesses in a position of strength because not only are they able to influence the future strength of the code they depend on, but they are also ensuring that weaknesses criminals might exploit don’t impact them or others,” he said.
Aging out
Another takeaway from the report on the importance of keeping track of OSS is that, like all products, it ages. And support for it, in the form of updates and patches, can wane and eventually stop.
As the survey report put it, “of the 1,200-plus codebases examined for the 2020 OSSRA report, 88% contained open source components that had no development activity in the past two years.”
That doesn’t automatically mean an organization should stop using it. Odence said it depends on other factors as well. “It may be a small, perfectly functional, and stable piece of code that’s just not evolving, and that may be fine,” he said. “Or, it could be a complex component on which an app is highly dependent, and that’s risky.”
But aging does mean an organization should step up monitoring of those components. In some cases, Mackey said, support stops simply because there’s a newer version.
“For example, within the last two years major versions of Apache Struts and Python have gone end-of-life,” he said. “But in both cases, development activity in the project didn’t stop, it simply refocused on the now-current versions. This is part of the normal evolution of software.”
Bottom line? As Mackey puts it, “unpatched vulnerabilities are the main cause of developer distress and, ultimately, business risks.”
But that’s a problem that can largely be mitigated with the right tools, like SCA, plus what Odence calls “managing open source properly with strategy/policy, process, and training.”
Doing all that takes time and resources. And you may never know the actual ROI of that investment. But as any security expert will tell you, you don’t want to know.
