Listen to this podcast on Apple Podcasts, SoundCloud or wherever you find your favorite audio content.
On this week’s episode of the SecurityIntelligence podcast, WhiteSource Senior Director of Product Management Rami Elron joins the dynamic duo of David Moulton and Pam Cobb to crack the case of open-source vulnerabilities. With security risks on the rise, how can organizations effectively prioritize top threats and control cybersecurity complexity?
Open Season for Open-Source Vulnerabilities
As Elron notes, “The number of vulnerabilities has surged during the past couple of years.” In hard numbers, open-source issues rose 50 percent through both 2017 and 2018, and there’s no indication of a slowdown in 2019. For Elron, there are two salient reasons for the open season on open-source vulnerabilities: attention and adoption.
Increasing attention paid to large-scale data breaches informed by critical vulnerabilities boosts their popularity and, in turn, their exploitation, while the increasing level of open-source adoption across solutions such as cloud computing, big data and artificial intelligence (AI) presents a rapidly increasing attack surface.
Add in the fact that companies aren’t writing this code in-house — meaning they don’t know exactly what weaknesses exist or how they might manifest across dependent systems — and the result is “a potential for exposure and grave consequences, including a puissant effect on agility.”
The Vulnerability Prioritization Paradox
Despite the increasing number and negative impact of open-source code vulnerabilities, nonproprietary code “is increasingly being acknowledged as an indispensable means for promoting and driving innovation.” As a result, adoption isn’t slowing down, and organizations need a better way to effectively prioritize and remediate potential weaknesses.
According to Elron, however, existing prioritization metrics aren’t effective because enterprises often use the wrong criteria. Two common prioritization factors are the availability of a fix and the date it was released, but “neither of these attributes serves or qualifies as a security conscience aspect.” In fact, patches designed to eliminate key vulnerabilities may cause new problems across interdependent systems, resulting in even bigger problems.
Another metric that won’t hold up under open-source scrutiny is severity. Organizations typically use reported severity to gauge security response, but current evaluation methods can be misleading. While a growing number of open-source vulnerabilities aren’t classified as “severe,” they are reachable in runtime, making them critical and ongoing threats to applications that can fly under the radar.
Cut Back on Cybersecurity Complexity
To address the growing impact of open-source security risks, Elron points to emerging technologies that help reduce the complexity of vulnerability prioritization by improving accuracy, performance, coverage and ease-of-use. Scalable, cloud-based solutions can help run code analysis in minutes rather than hours while increasing the ability to detect active runtime threats. Large-scale classification libraries will improve the discovery of new issues and trace references from proprietary code to open-source code. Finally, automated processes improve ease of use, reducing the time between vulnerability detection and effective response.
The bottom line is that open-source code flaws are on the rise, and organizations need new ways to solve the vulnerability prioritization paradox to reduce the risk.
Episode Transcript
David: Pam, I noticed a common theme across the last two episodes. Any idea what it is?
Pam: I’m really tempted to call back to “The Animaniacs” and guess that it was someone trying to take over the world because that’s what we do every episode. But I’m gonna guess that’s not the right answer.
David: It’s not “Animaniacs.” What I did notice is that time keeps coming up. So, first, time is critical for adversaries with lateral movement. And then on the other side, time is critical for our ability to find vulnerabilities.
Pam: I think that really plays into the idea of agility and needing to be able to react quickly, not just in incidents, but as you are working through a process and developing and being able to adjust what you’re doing based on new information. And we see that in software development. We see that in a lot of different places in cybersecurity.
Pam: This is the Security Intelligence Podcast where we discuss cybersecurity, industry analysis, tips, and success stories. I’m Pam Cobb.
David: And I’m David Moulton. I spoke with Rami Elron about open source vulnerabilities and prioritization. Rami is the Senior Director of Product Management at WhiteSource. If you’re a developer or work on an agile team, I think this conversation will be especially relevant to you. Let’s turn it over to Rami.
So, welcome back to the podcast. For those listeners who may be joining us for the first time, tell us about your role and how you got started in cybersecurity.
Rami: So, hi. First of all, thank you for having me. My name is Rami Elron, I’m a Senior Director of Product Management with WhiteSource. As for my background, I’m an industrial engineer with the over 25 years of experience in security, in identity management storage and UX design in diverse R&D and IT management roles which include executive and engineering leadership positions.
Over the years, I’ve been extremely fortunate to become deeply acquainted with security aspects that span extensive operating and development and environments and perhaps, more importantly, to drive the design of security offerings for both enterprise and cloud environments, leading development and engineering teams, engaging with clients.
David: And with all that, you’ve found time to talk to us and talk to our audience. So, thank you, Rami. In general, have you noticed a proliferation of open source vulnerabilities?
Rami: Indeed. I think that many hundreds of new open source security vulnerabilities are reported every year. In fact, the number of vulnerabilities has surged during the past couple of years. In particular, it rose over 50% in 2017 alone and it maintained what appears to be a similar, if not a higher growth rate, in the following year. Vulnerabilities are not only multitudinous but extremely varied, which allows for attacks including code injection, denial of service, data theft, and of course, many other cases.
This phenomenon, I believe, is largely attributed to two salient reasons. One would be burgeoning attention to open source security vulnerabilities which follow the publicized data breaches that were associated with exploitation of such vulnerabilities. And perhaps the other reason would be an increasing level of adoption of open source of the market such as cloud, Big data, AI.
As for the notice of proliferation and I think that it has a lot to do also with risks and introduction of risks, accentuation of risk. And the key risk in this proliferation of open source vulnerabilities arguably concerns an inability to detect and address high severity vulnerabilities in a manner that is quickly enough. And that results in a potential for exposure and grave consequences including a puissant effect on agility. I think that tracking those vulnerabilities, let alone remediating them, is an oppress process. And the sheer number of reported security vulnerabilities that warrant attention make it difficult, if not errantly impossible to appropriately accommodate without adversely affecting the agility.
David: So, Rami, you’ve talked a little bit about how companies are seeing more vulnerabilities and that there’s a proliferation of open source vulnerabilities. And I think that if I understood you right, part of that’s coming from the fact that we’re looking more critically at the code and more companies are adopting open source which makes it a bigger target for attackers. But then on the other side, now that you have more of those vulnerabilities documented, what are companies facing as they try to prioritize the different vulnerabilities and assess the risk that they’re exposed to?
Rami: So, I think that, in general, open source is increasingly being acknowledged as an indispensable means for promoting and driving innovation. It has become an enabler for powerful offerings, service advancements which underlie enterprise and service offerings. But there are also issues as were noted and there are certain challenges that companies, that organizations are facing with that regard.
I think that some of the issues I mentioned earlier has to do with the unawareness by organization management concerning the particular way open source is being implemented in the organization, how the open source components are being a used, how they are selected, any processes that are taken to ensure that appropriate security throughout the development life cycle is being done appropriately.
There is also an issue of the paucity or absence of policies that govern the selection and qualification of open source components. That is a risk that definitely should be accentuated.
On top of that, many developers are also unaware of the complexities that are introduced by transitive component dependencies, and that renders many patches or updates less than straightforward because an updated component might introduce problems to dependent components. A larger percentage of the reported security vulnerabilities is, in fact, believed to correspond to indirectly referenced open source components.
And finally, developers and security, they’re often challenged to realize a practical approach to prioritizing vulnerabilities because there has been, at least traditionally speaking, there has been no easy way to establish which vulnerabilities are effective, or in other words, whether or not a reported vulnerability is indeed an effective vulnerability, something that can be reachable from proprietary code during run time.
David: How has the approach to open source software development changed in the last few years?
Rami: So, open source software has a market influence on our business, especially on DevOps, on DevSecOps practices. Open source offers extended choice and an incentive to experience innovative solutions. And the integration of security, for instance, within DevOps is meant to promote and realize attainment of prioritized security targets for development, for developed software.
To that end, open source software can also facilitate better agility, especially in light of emerging technologies such as containers, such as serverless computing, both of which warrant faster than ever responsiveness. And this, in turn, can facilitate opex reduction through, for instance, standardization of processes and automation.
But in spite of all of these benefits, and that actually goes to the point I made earlier, many organizations have not really effectively implemented important practices that reflect the special characteristics of open source. For instance, its consumption, its management, its implications. And consequently, they cannot truly leverage its potential value. I think that these are at least some of the key aspects concerning the changing shape by open source software development over the past few years at least.
David: So, do you think that open source vulnerabilities have become a serious detriment to development agility?
Rami: My quick answer is that, well, it would not really become… It would not qualify as a serious detriment to develop agility. It’s more about inability to handle all security vulnerabilities in an effective manner while maintaining ample security. It’s not really open source components that have become a detriment, so to say, to agility. It’s rather the absence of ample measures to ensure appropriate detection, attention, and response concerning open source security vulnerabilities.
In addition to that, the sheer number of reported open source security vulnerabilities requires both development and security teams to commonly spend an inordinate amount of time in an effort to accommodate what at least appears as the most critical cases. A WhiteSource survey, by the way, shows that each developer typically spends about 15 hours per month. That’s really 15 hours every month concerning security vulnerabilities that spans research processes, discussions, remediation. And given that, I believe it would be unsurprising to note that even a relatively small number of reported vulnerabilities could translate into a significant investment and that would come at the expense of non-security activities.
If I may add, I think that the gravity of this issue becomes serious given the unawareness of many environments to the ramifications of exploited open source security vulnerabilities because responsibility for security is increasingly shifting to developers. Yet many developers, not all obviously, but many developers are not, at least are often not security experts. And security has traditionally been considered unfrequented territory for developers. Developers might not possess the security knowledge required to accommodate the related responsibilities that are bestowed on the development team by security. And security has not traditionally employed any delegation to empower developers to make security conscious decisions.
So, in order to do so, it is required to agree on objective metrics for prioritization. And this is not simple. So, in order to deal effectively with the growing number of security vulnerabilities, I think it is absolutely imperative to minimize the number of vulnerabilities that warrant attention and doing so in a manner that is acceptable by security standards.
David: Earlier you mentioned 15 hours and I’m just thinking about the burden that that puts on teams and the downstream risk if they don’t, they don’t address the security vulnerabilities that are in front of them. What can teams do to reduce the time spent addressing the vulnerabilities?
Rami: Well, they’re not necessarily spending the time in the most efficient manner. In many cases, the problem is not really about efficiency. It’s about effectiveness because it becomes pretty obvious that it is unlikely for many organizations to deal with all reported security vulnerabilities without adversely affecting development and delivery agility. So, prioritization appears to be not a nice to have thing but to basically be an imperative option.
So, the problem is not about the acknowledgment of prioritization being so important, but how prioritization is actually coming into play because some believe that their prioritization is effectively done even though by examining what are the characteristics of that the prioritization, it becomes very easy to note that many of the factors driving such prioritization are not necessarily security conscious.
And that means that, for instance, one of the prioritization factors would be availability of a fix. And another factor would be the date when a fix has been released. None of these attributes serves or qualifies as a security conscience aspect. And that is why when we talk about prioritization, being able to accept the fact that prioritization is important is not the most important thing here. It’s about realizing how prioritization needs to take place, which makes the whole difference here.
David: Yeah. I often try to make simple analogies so that I can get my mind around it. It’s painful to go get a crown on your tooth or have a cavity filled, but if you eat healthy food and brush your teeth quite a bit, you may end up with better hygiene. And I think the same could be applied here. If you have a thought on how you’re going to approach your security hygiene and some discipline before it becomes a problem, then you don’t have to deal with it afterwards. So, maybe security by design is a powerful way to approach your business.
Rami: Absolutely.
David: So, if you think about the way that some teams are approaching prioritization now, what’s inadequate about that approach to effectively deal with the explosion and vulnerabilities that we’re seeing in open source now?
Rami: I think that the major problem is that traditional prioritization is not really based on an objective metric or perhaps objective metrics that define and they confirm whether or not the reported vulnerability is real in terms of the actual running application. It is one thing to acknowledge the fact that there is a reported vulnerability. It’s a totally different thing when you realize that that reported vulnerability is indeed reachable in runtime. A significant rise in the number of open source vulnerabilities presents currently a serious challenge to development and to security teams, both of which endeavor to meet security objectives.
When you have multiple vulnerabilities, each of which is reported to have a certain severity, unless you have any additional information, you would show some inclination towards the severity as the determining factor [00:45:00] for whether or not you should prioritize that vulnerability over the other. You simply do not have ample time to do everything. So, you will focus, you will try to address those that have a higher reported vulnerability.
The problem is, or perhaps the challenge is as it turns out, quite a lot of those reported vulnerabilities are likely to not be reachable in runtime. And this is a process I can expand obviously about, but this serves to denote the significance of having another approach for prioritization because just looking at the reported vulnerability severity appears to be simply not enough. It’s not good enough to drive the right way of prioritization and it will still leave a large number of vulnerabilities to be handled. And the most problematic thing here is that the discussion over which of those vulnerabilities needs to be dealt with, it’s a subjective one. It’s not based on objective metrics. An objective thing is whether or not it can be reachable, it is reachable or it is not. But discussing whether or not it is likely to be reachable, this is a totally different thing.
David: Absolutely. So, how can technology improve the effectiveness of prioritization while maintaining that development agility that companies need?
Rami:There are several ways. Technology could ameliorate prioritization effectiveness and importantly, preserve agility by focusing on well, several key areas. I think that the most important of which are accuracy, performance, coverage, and well, ease of use also.
Part of the challenges that many organizations are facing with regard to technology in service of such endeavors is that running analysis is a lengthy process. In many cases, at least traditionally, many common solutions offering some amenities to deal with this challenge are likely to take hours in some cases even more. And that does not necessarily blend well with an agile process. So, as far as technology goes, being able to accommodate scale and maintain very quick performance so that you could actually run analysis in minutes, not in hours, is one of the goals that technology is expected to accommodate.
Another thing is to accommodate projects that range from a very small to extremely large. That is another facet of scalability that technology is expected to provide. I believe I mentioned coverage as well as one of the characteristics that need to be weighed here. And talking about coverage, I really meant classification. Being able to classify alerts as effective, in that case, it would denote the discovery of any references, trace references from proprietary code to open source code with vulnerabilities or not. That is huge. That is an absolute significant thing that developers and security teams would be craving for.
I also mentioned ease of use. Ease of use is normally taken relatively lightly. And I think that it’s really… This kind of attention is misplaced because ease of use also means not just the user experience in terms of how things are presented through the UI, but also enabling the diagnostics and the reports of software component dependencies in correlation with vulnerability information, being able to automate processes they’re using policies. This is also an ease of use thing because being able to reduce the overhead has immediate implications on ease of use.
So, when people typically talk about ease of use, they, well, at least intuitively think about something that can be viewed, something that is presented on a screen. But in my opinion, it has much more to do with the overall experience, with the overall process, and perhaps in many cases, lack thereof. The more you can actually reduce the overhead, and this is something that technology could definitely address, the more customers, organizations in general, would be inclined to use such prioritization methods.
David: Yeah. Coming from a background in design, I wholeheartedly agree that if you can get to ease of use and/or moving away from asking a user to do something, automating it or simplifying it, not necessarily dumbing it down to the point where it doesn’t do something complex, but it makes the ability to do the right thing at the right time easier. Across the board, you’re seeing better security outcomes when we find ways of executing in that space in technology.
And I think that the demand for that and the demand for prioritization is only going to grow as businesses are moving to the cloud. So, when you’re thinking about that, does a move to a cloud, to these public, private or hybrid environments with open source vulnerabilities following along, do you see that becoming more and more pressing?
Rami:So, will prioritization become more important, more urgent as the organizations move increasingly to the cloud? My answer in a word would be yes. A resounding yes. I think that DevOps, DevSecOps, in fact, teams are often and perhaps unfortunately compelled to a go through circuitous paths to meander, and fractious operational routes to address objectives in a way that is nonfrustraneous. And that is in many cases due to cultural or organization facets or even constraints. There is also an ever-increasing pressure to reduce the release cycles and accommodate faster responsiveness to alerts. So, I think that effective prioritization could really help DevSecOps and DevOps, in general, dedicate the resources to accommodate issues with higher criticality rather than wasting them over issues that warrant lower attention.
And it could also, this type of prioritization, could also maximize the security posture of the developed software solution, and in such a way, it could help the organization attain security objectives much better. It could provide an objective report of security vulnerability severity, it could reduce friction between or among different teams, definitely, between development and security teams.
David: Right. So, when you think about the move to cloud and, or the ability to move security left, appropriate use of technology and prioritization, right? All of those things come together where you’ve got the environments changing, but then the way that security is being approached at a principle level and an execution level. Imagining that, what have you seen when all of those things come together? What sort of things are developers capable of? What sorts of benefits and successes have you noticed once companies are able to get all of these things moving correctly?
Rami: I’ve seen substantial benefits. We did not discuss that earlier, but given the question about what I’ve seen and what type of evidence has been encountered, I think that being able to review not just whether or not alerts concern an effective or ineffective vulnerability, but to be able to extract the details, the file name, the class name, the line in code concerning any evidence for such a path leading from proprietary code to a vulnerability, that is huge. And such detail can considerably facilitate the review and the remediation activities. It would contribute to reduced time, to reduced efforts that is spent by development teams, any teams basically handling a reported security vulnerability case.
And here comes the real thing. This time, the reduced time or the saved resources would allow for time to be spent on expanded and extended productivity. Isn’t this basically what we are all looking to realize with all the agile processes? It’s not just about reducing the time, it’s about being able to allot time to things that are much more productive, things that would bolster the ability to provide stronger solutions, solutions that cater better to customer requirements and the flexibility to do so and not just target the particular requirements, but actually get the flexibility to develop and test a higher number. This is something that I would anticipate for the future in fact, when I come to think about that, that by having such flexibility, it would be possible to test many more use cases, it would be possible to facilitate validation of ideas that would otherwise be simply unattainable. So, that’s at least… I think these are some of the key issues that come to mind.
David: So, that was a really fascinating conversation with Rami. And I think my big takeaway was that you can get better security outcomes if you reduce complexity. And part of that is gonna be through application of technology, part of that’s gonna be through systems design and UX design. And when you put that together, you start to get a couple of things. Better outcomes for sure, but also you get time back to the business to focus on the things that it wants to do rather than going back and cleaning up some of the problems that it faces.
Pam: I think that really speaks to the idea that security is transitioning from being the department of no into being a real partner in how business gets executed, both in IT systems as well as practices and policies.
David: Yeah. Security has got to move its culture from being in a position to stop the business to one that’s an influencer and helps you accelerate. And this is one of those really interesting ways that I think that that will happen.
Pam: Absolutely. So, related, David: do you have any good news to share with us this week?
David: So, Pam, we’re into June and one of the things that’s top of mind for me is the election. It’s all over the news, and we’re going to be hearing about it a lot over the summer. And I’d actually rather hear about the candidates and what they stand for than to hear that the candidates have had a cyber attack that’s taking up their time and resources or distracting them from being able to put their issues forward.
And the FEC has allowed this non-for-profit spinoff from Harvard to offer free cybersecurity services to US elections and to the US campaigns. It’s a program called Defending Digital Democracy Project and any campaign that’s out there can take advantage of it. And I think that’s the good news. There’s this recognition that help is needed, and we can extend it from any domain that we’re in, whether it’s business or elections or politics.
Pam: And that’s it for this episode. Thanks to Rami Elron for joining us as a guest.
David: Yeah. Listen to this podcast on Apple Podcasts, SoundCloud or wherever you get your podcasts. And if you’re feeling up to it, we’d love a great review on Apple Podcasts. If you’re enjoying the show or have friends or colleagues with an interest in cybersecurity, spread the word. A big thanks to Megan and Ted, our awesome producers, and most of all, thanks to you for listening.