Posted by Steve Giguere on December 21, 2018
Hacking Security is a monthly podcast on emerging trends in application security. Episode 3 explores key findings from the 2018 OSSRA report.
Hacking Security is a monthly podcast on emerging trends in application security development hosted by Steve Giguere, lead EMEA engineer at Synopsys.
Episode 3 takes a look at the Open Source Security and Risk Analysis (OSSRA) report, explores its findings, and pulls out the important bits for you. Take 12 minutes to listen to the latest episode below.
Welcome to the Hacking Security podcast. Hacking Security is a podcast for emerging trends in application security development. I am your host, Steve Giguere, and full disclosure: This podcast series is sponsored by the Synopsys Software Integrity Group.
Like all good software development projects, this is a multidiscipline effort where we put together the minds and hearts of the Synopsys Software Integrity Group. And with that, good morning, good afternoon, and good evening, application security fans. This is Episode 3 of Hacking Security, and I am your host, Steve Giguere. This podcast is going to dig into the research and findings found in the OSSRA report.
What is the OSSRA report? you might be asking yourself. Well, strictly speaking, it is the Open Source Security and Risk Analysis (that’s O-S-S-R-A with a silent “and”) report. Now I realize as much as anyone that reports can be a tad on the dull side. I’m going to do my best to keep it lively, but I’m going to start talking about open source generally.
The concept of keeping software “open” was introduced more than 30 years ago, and the adoption of open source software has been accelerating ever since. Today, open source is pervasive across every industry and is used by organizations of all sizes. Really, the reasons are straightforward. Open source lowers development costs; it speeds time to market; it accelerates innovation and developer productivity.
However—and it’s a big “however”—analyst Amy DeMartine said in The Forrester Wave: Software Composition Analysis, Q1 2017, that, roughly quoting, developers use open source components as their foundation, creating applications using only maybe 20% new code. Unfortunately, many of these components used come with liabilities in their license agreements, and one of every 16 open source download requests is for a component with a known vulnerability.
You’re probably getting the gist, but I will clarify what the objective of the OSSRA report was. Each year, a company called Black Duck, a specialist in open source management software and now part of the Software Integrity Group at Synopsys, conducted a survey. A survey is, perhaps, a bit of an understatement, as it really qualifies more as a research project, because over 1,100 commercial codebases are then anonymized. (It’s worth repeating that—anonymized—for the benefits of disclosure. Nothing in the report is attributable.) And those codebases are audited throughout the year—in this particular report, 2017.
The results of the report are designed to give the readers, and you listeners, insight into industry-specific states of play regarding the use of open source software in order to better understand the associated risk, be that cyber security, licensing, or operational risk. What industries is this relevant for? Well, FinTech, enterprise, IoT, manufacturing, automotive AI, BI… Ringing any bells? If so, this is probably for you. It’s probably for you if you write software, to be frank about it.
Now why does this all seem too relevant right now? You may have heard of a little company called Equifax, probably more than you’d care to. The single greatest open source vulnerability exploit in recent history. Five, six, three, eight is not just my PIN number but also the number of the CVE. CVE-2017-5638 is the known vulnerability attackers used to extract personal records from the credit giant using a vulnerability in the Apache Struts open source package.
So many questions arise from that. Why didn’t they just upgrade? Didn’t they have notifications about vulnerable open source? Didn’t they understand that once an open source package is vulnerable, and that it becomes public knowledge, the bad guys are straight on to Shodan, searching for people still using the old version—or actually, probably writing bots to do it for them—and sticking their criminal little cyber fingers into the hole to see what lies inside?
CVEs represent a race against time, period. Best to ensure you don’t have any, and that’s where this report comes in.
It’s interesting that the very first stat in the report is that of all of the codebases analyzed in the research—that was 1,100-plus—8% of them used Apache Struts, of which a third were still using the vulnerable version. Insert sound of long, drawn-out exhale, or perhaps sound of person banging head against wall there.
In the past few months, there’s probably only one phrase or buzzword that has surpassed “Equifax” in popularity, and that would be my other PIN number: GDPR. I don’t think it’s even possible to engage in a cyber security conversation without saying it. It should be some kind of drinking game at cyber security conferences. Nevertheless, it’s relevant. New mandates on privacy mean new initiatives on cyber security, added diligence on the software supply chain, and the addition of gates, checks, and measures regarding deployed web-facing applications are all the rage. The sentiment, in big capital letters in the report, correctly states, “All companies processing and holding the personal information of European citizens must protect that information—regardless of where it is sent, processed, or stored.” And done. That’s pretty simple and summarizes the new regulations succinctly.
I’ve been concentrating on cyber security risk, but let’s talk about licensing risk to do with open source components. Sometimes overlooked—certainly not by your legal department, though, I would imagine. It can be that your developers, in all of their DevOps autonomy, don’t actually understand or check the licensing requirements of some of the open source modules, frameworks, and libraries that they are happily integrating.
The boogeyman of open source licensing for commercial software developers is the GPL license, or General Public License. This is sort of your hippy, free love version of licensing that allows anybody to use it, mod it, redistribute it. But—and it is a big capital B-U-T—the end product also needs to be GPL, so freely open source, which is not what commercial software vendors often have in mind.
GPL is by no stretch of the imagination the only open source license, of course. Oh no, there are thousands of different variations with different requirements on use, redistribution, attribution, etc. Many licenses are totally incompatible to be used together in a product. In fact, getting back to the report, the OSSRA research showed that 74% of codebases audited contained components with licensing requirement conflicts, 44% of which involve GPL.
Let’s let that sink in for a moment. If you write software or you’ve got a large-scale software team, 44% of 74%? There’s a good possibility that you may have a licensing issue on your hands, almost about a 50/50 shot. OK, let’s leave that one for a moment.
Let’s talk about IoT, a.k.a. the Internet of Things, a vague, kind of sloppily contrived acronym describing the often-unnecessary internet-connectedness of stuff that was frankly just fine before we needed iPhone-connected internet-controlled toasters or the ability to have a swinging night out on the town whilst taking care of baby via the internet-friendly baby monitor.
Yes, IoT’s maniacal race to blast anything and everything onto the net has come with risk. From essential innovations like connected heart monitors to the ridiculous internet-connected Y-fronts, the IoT tidal wave has meant a hard and fast feature-first, security-and-privacy-second-and-third approach, with time to market meaning a significant use of open source packages to turbocharge development.
Well then, I guess it’ll be no surprise that 77% of the IoT codebases analyzed showed open source component usage—OK, sure, that doesn’t sound so bad—with an average 677 vulnerabilities per application. Yeah, OK, that sounds bad. But how does that compare with last year? Keep in mind, this is a yearly report.
At the start of this podcast, we alluded to growth in the use of open source, and that would be true. In fact, the report states that the number of open source components per codebase grew 75% between the last report and this one. What is surprising and a touch worrying is that the number of open source vulnerabilities per codebase grew by 134%. This growth isn’t surprising when you hear that in 2016, the NIST NVD database listed 6,400 vulnerabilities in 2016 and a whopping 14,700 by the end of 2017. Open source is growing fast and, it’s fair to say, a bit loose.
We’re going to wrap this podcast up now saying that the report concludes with a plethora of statistics like the top 10 CVEs found, the top 10 high-risk components, the frequency of security licensing risks, as well as identifying high-risk components by industry. The fact of the matter is that the debate over whether you should or shouldn’t use open source is academic. The research showed that we have crossed a threshold where applications are now using more open source than not, and with this change comes a new requirement to the application security evolution. Knowing your application inside and out is almost at odds with the trend to high-agility DevOps-based development but is proving an essential ingredient to the DevSecOps movement.
This has been a podcast from the Synopsys Software Integrity Group. I’ve been your host, Steve Giguere. Special thanks, as usual, goes out to the team at the Software Integrity Group—Beth Gannett and Gabby McDonald—as well as the research team behind the OSSRA report 2018. Thanks for listening. This has been Episode 3 of Hacking Security.
Get the latest AppSec news and trends sent directly to you.