About this Episode:
Does your team struggle with prioritizing your security open-source findings? In this episode, James Rabon, Director of Product Management at Micro Focus, will share an approach that can help. Discover how James’ team co-developed “susceptibility analysis,” which allows developers and application security engineers determine whether a publicly-disclosed vulnerability has been invoked in their code. It also reveals whether attacker-controlled input reaches that function. Listen now!
TestGuild Security Testing Exclusive Sponsor
Micro Focus Fortify is the recognized market leader in application security and is the most comprehensive and scalable application security solution that works with your current development tools and processes. Try it today
About James Rabon
James is the Director of Product Management at Micro Focus. He is responsible for managing the direction of the Fortify product suite with a focus on Software Security Center, GUI Tools, and the Fortify EcoSystem.
Connect with James Rabon
-
- Company: Fortify:microfocus
- LinkedIn: James Rabon
Full Transcript James Rabon
Joe [00:02:13] Hey, James! Welcome to the Guild. I thought we'd start off just by going over what some of the trends are that you're actually seeing in Security.
James [00:02:21] So it's no secret developers use open-source software, right? I use it. I'm a software Security vendor. Obviously, our applications are built upon open source. We could not compete in the market if we did not leverage open source, just like almost all of you with the exception of various niche applications that have to be custom-built. But almost 90 percent of the components in modern applications are open source. I know even my own product. I built a software Security center web application to about one hundred and seventy-five thousand lines of actual custom code and probably 1.4 million-ish or so lines of code when you count in the open-source components, 1.4 trillion requests across these various technology stacks, almost 400 000 Java components downloaded annually by a single company. The amount of volume of open source components that we are leveraging today has obviously exploded.
Joe [00:03:18] So, James, how can you actually manage this open-source risk at scale?
James [00:03:23] That's typically right through the use of tools that fingerprint these dependencies and then use automated policies so that you can understand with automatic notification that your policy, your risk posture for your particular application has not been met. And so that's typically what companies have been doing and I've been doing for quite some time. The known vulnerability space has been alive and well, using some kind of known vulnerability technology like a Sonatype or something open source like OWASP dependency check. It's like brushing your teeth. If you're going to use open source components, you should know if there are any known vulnerabilities in them, because I can promise you that attackers are very familiar with the national vulnerability database. Why make their job easier? We go to great lengths to protect our own source code that we write, we hold it very tight, our IP that we write, we have a significant portion of the logic for applications. And significant data flow and code flow pass through our applications are through open source components that anyone can download and understand and break down. And simply look to see if there are any known vulnerabilities in a very popular framework, especially ones that are difficult to upgrade. And then these vulnerabilities can be scripted and distributed in tools really it'll mean a lot of these can be…you can have a very Mickey Mouse-ish from a skill set person, exploit your application if you are leveraging older components or components with known vulnerabilities. And it gets even more complex with transitive dependencies. It's not just the library, the calls you make into first-level dependencies, and also the calls that your dependency is making to others. And so the complexity has really gone through the roof. And to find someone and an application group that can explain end-to-end all the code flow past an application, it's almost impossible because of the complexity of all of the open-source components being leveraged.
Joe [00:05:30] Okay, so why is the open-source policy then so critical?
James [00:05:34] Well, we've been talking about the volume, right? How can you keep up? We are constantly releasing. We are Agile-ly not really a word, but in Agile development, we are quickly iterating and failing fast. And unfortunately, that also has led to an increase in verified or suspected breaches. It's not just winning in the market. It is not just about who is first and who has the best feature. If your features lead to publicly embarrassing security breaches for your users or your application that makes your organization more productive leads to a public vulnerability that damages reputation, you can't win in the market like that. Your customers and your users need to have confidence in your applications. We've seen what happens to these companies' stock prices when they have these well-known breaches. We're entrusting them with our data. And one in five organizations has experienced at least one open-source breach in the last 12 months. And almost half of organizations don't have an automated policy. So we even have a lot of ways to go with the current solution, with just the brushing your teeth. Just what known vulnerabilities do I have in my bill of materials? Just doing that in an automated fashion alongside with a policy that says this is a level of risk I'm willing to tolerate for this particular application so that I can understand very quickly and communicate to developers really quickly that the component they're planning to use has a known vulnerability that could result in a very real problem in their application. And specifically, hey, what an upgrade too, so identifying the next best version to upgrade to that is free from that vulnerability is also a part of this current solution.
Joe [00:07:30] So do you think all the open-source components used in your application should be maintained equally?
James [00:07:36] I love this little cartoon here where you have a critical component of your application that's been singly updated and maintained by a single individual in Nebraska. What happens if he gets bored with this project or decides to stop updating it? Vulnerabilities occur, right? Someone has to maintain software. It's a living, breathing thing that needs to be maintained and upgraded. And we can often find ourselves in a very precarious situation.
Joe [00:08:04] So how realistic is this, though, especially if you work for a large enterprise-type company? So I guess my question is, is faster and more secure actually achievable at the enterprise level?
James [00:08:13] Speed to market that that is how we win in the market. We need to be first with the best solution. So how do we achieve this? Well, we know Security is needed. We know we're building our applications. We know we are instantiating open-source components. We know the code is freely available for eyeballs to understand and look at. And we know that known vulnerabilities are published daily. Thousands of the components that are out there in the community that we are where we are utilizing. So the enterprise dev team to contain their supply chains, the rewards are impressive. Just by brushing your teeth, what known vulnerabilities do I have in my application? And some kind of basic policy that denotes what types of risk based on either CVSS scoring or some other metric that we want to leverage to understand the impact and likelihood of these exploits in our applications were reduced by fifty-five percent so that alone can tell you that there are current solutions that will… just the basics can give you a huge advantage in terms of not using known vulnerable components.
Joe [00:09:33] So, James, can you go over your concept of a technology lifeline through your open source issues?
James [00:09:38] So we've talked about the solutions that exist today, known vulnerabilities, fingerprinting dependencies, checking known databases, providing additional research for these known vulnerabilities. A lot of the different vendors provide additional research above and beyond what's in the NVD. But they don't help you prioritize beyond what's in the CWE and the CVE. You're presented with a list of components of problems with the components that you're leveraging and how do you prioritize what you do. So kind of the current solution that we see from a Fortify and open source standpoint, we obviously have static analysis. I've just mentioned that open source known vulnerability detection is like brushing your teeth. Those issues need to be co-located alongside your custom code vulnerabilities. Fortify static analysis is very good at understanding your custom code, parsing that, understanding that and running our analyzes against that, and then co-locating. And in this case, we partner with Sonatype where we leverage their technology and we bring their data into our software Security center platform in addition to their IQ server product so that you can manage your custom vulnerabilities alongside your open source. So that's kind of the current solution that we have today. You need to understand vulnerabilities in your custom code. You need to understand vulnerabilities and your known components or open source. And then you co-locate those together. That's what we do today. And that brings us a lot of benefits. We're enforcing an open-source policy. We're trying to control risk along the SDLC. As I mentioned, we partner with Sonatype for our particular open source analysis. But there are other technologies as well. For those of you listening to this who aren't current Fortify o Sonatype customer integrated experiences help continuous integration platforms, integrations into the IDE. And kind of why software composition analysis. 70 percent more vulnerability coverage than in various databases is kind of why we decided to partner with the founders of Maven and Sonatype in terms of their knowledge of the open-source space.
Joe [00:11:52] So also James, what do you see as the challenges for people in this current state that you just explained?
James [00:11:59] It's that each individual issue on average we spend 20 minutes researching. That is a developer's time, that he is not developing software to help you go in in the market. He or she has to look at this issue, understand it in the context of their custom code, how they're leveraging the application, read the vulnerability, understand it, and make a determination of whether they're actually vulnerable or not and what they're going to do about it. The average software composition scan for any application on average is 38. And so you're spending twelve and a half hours just triaging your known vulnerabilities for every single application. When you think that the average large enterprise typically has between three and five thousand applications, you can see that we spend a lot of time looking at open source vulnerabilities and trying to understand if we are vulnerable and understand what we need to do about it. Why are we spending this time triaging it? Why don't we just upgrade? Because there is no magic with regards to upgrading. It often requires custom code changes. It may break certain portions of your application. It might require significant investment to upgrade a component. If you spent, let's say, I think I gave the example for my own team. We spent three months upgrading from angular one to angular two. If I had done that and prioritized that over other critical features, my customers needed, but found out later that we never actually called the vulnerable component. So these are large frameworks. The known vulnerability that is described can often be very specific. You may not even be leveraging that functionality. You may not actually be vulnerable at all. Yes, the vulnerability exists. Yes, you use the component, but you haven't used the vulnerable function or method yet. You could in the future. And the answer is always to upgrade if you care, specifically if it's easy. But we need to understand the risk, the real risk, not that just you…yes, you have strands and it has a known vulnerability. Can you exploit it? Is there a means of which to attack? Do I call the vulnerable functionality? Because if I spend three months upgrading a dependency over other open-source components, because like I said, we all have a number of open source work issues, we're managing right in point in time and these are constantly changing. And in any of that is going to lead to decisions that have to be made about which components can we upgrade in this time frame. So if you choose the wrong components, you end up being exploited by an actual vulnerability that you actually instantiated in your code and you spent all of your time upgrading a component of which there was no chance that an attacker could take advantage of it. So that's why we audit these issues. So those hours could be spent investigating issues with no Security impact at all.
Joe [00:15:10] Right. Makes sense. So what's the solution then?
James [00:15:13] So we have partnered with Sonatype to introduce a feature called Susceptibility Analysis. What Sonatype research does is they provide the vulnerability signatures which contain a specific method or function that was patched for a particular vulnerable component. So every time you request a component be analyzed by Sonatype, we are looking to see if that vulnerable component has been upgraded and we are writing a signature for that particular method or function so that we can understand the usage of this open-source component in your custom code. So Fortify comes in on the custom code side. We provide the transitive model of your application and the rules engine to look for usage and user control input that potentially reaches that function or method. Think about it like baking a cake. We invoke this Sonatype vulnerability signature API in conjunction with the fingerprint activity of the known components. We are dynamically generating custom data flow rules and structural rules to understand if you are calling the function or method and whether or not user-controlled input reaches the function or method. The resulting Fortify project report contains evidence of whether that function or method is invoked or whether user input, user-controlled input, or attacker-controlled input is in proprietary code. So not only did you call and instantiate the vulnerable function or method, but an attacker has a means of which to manipulate the data that reaches that function or method. So we're not guessing. Fortify is very good at understanding whether a function or method was invoked. We're also very good at doing data flow. So this is right in our wheelhouse. And so really it is the combination of two companies that do something uniquely well and the combination of that can help you prioritize these open source issues. We include the full evidence. There's no guessing. The developer doesn't have to spend 20 minutes because you can click a link and see exactly where he calls this vulnerable function. He knows that it's vulnerable. The risk is very real. And he can focus on what he needs to do to fix the issue as opposed to understanding whether it's a vulnerability or not. And we can do this at scale for an entire organization. The generation of the rules is quite trivial for us. And what we are looking for in custom code is not difficult for us to do. We simply need the data from Sonatype so we can understand how you are utilizing that open source component and custom code.
Joe [00:17:52] All right. So the next part is James talks about some commands you can use. It's kind of hard to visualize. But as I said, this was taken from a session from Security Guild from 2020. If you want to actually see the same action, all you need to do is go to securityguild.com and register and get your all-access ticket now.
James [00:18:08] Now, I mean, some of the usage, just some basic usage commands I'll go through this quickly because we'll have a live demonstration here soon. You can scan your code with Fortify static code analyzer and Sonatype, upload the results. Here's a common command that could be utilized. An example command of how we would execute that in a single command. Here's a view into the Fortify on demand, our SAS platform of different known public vulnerability shown across the Fortify priority order of critical high, medium, low. And you can kind of see here, here's an open-source component view in our on-premise product with regards to software security center. So this is an example of bringing that data in. And if you look here, you can start to see where the susceptibility analysis feature comes in. You'll see that we have the invoked column and the controllable column. So invoked would mean that we see the function directly called and controllable would mean user control input reaches the vulnerable function or method. And the view evidence button that you see there allows you to click into and find the actual Fortify CV Fortify evidence of you calling the function. So the developer doesn't have to spend any time. They can quickly click that link, see that they do call this function or method. And they know that the sequel injection vulnerability is very real and therefore you can prioritize this particular component, upgrading it or removing it, or using something else that can be prioritized. And you don't waste your time on the vulnerabilities that were never invoked and do not have user-controlled input that reaches them.
Joe [00:19:44] Does the solution give you a way to reduce the number of false positives a lot of people get?
James [00:19:49] So reduced known vulnerability false positives, they're not false positives. It is a vulnerability. So it's not a true-false positive, but you're not actually vulnerable. You could spend months upgrading a component and over a component that is actually vulnerable. Who doesn't want to save time on anything that can be automated should? So if I can automate the basic triage of known vulnerabilities and custom code, I should. Better data, better decisions.
Joe [00:20:23] Alright James, before we go, are there any parting words of wisdom you want to leave the Guild? And what's the best way to find and contactor or learn more about Micro Focus Fortify?
James [00:20:32] All right. So Fortify and Sonatype difference, we're the best of breed in our respective spaces. We focus specifically on unknown vulnerabilities in custom code with static analysis and dynamic analysis of unknown vulnerabilities, basically, zero-days and Sonatype focuses on the known vulnerability space and the research side of the open-source component. The combination of us right leads to a very powerful solution that allows you to use their world-class research and our world-class insight into how you use those components. Subscribe to the Fortify Unplugged.
