Prioritize Your Open Source Findings with James Rabon

Welcome to the Test Guild Security Podcast where we all get together to learn more about security testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Security Podcast. Today we're talking with James Rabin all about how to prioritize your open source findings. James is the Director of Product Management at Micro Focus, so he really knows his stuff and so he's going to share an awesome solution that they came up with to actually help you with your open source findings. So if you have any struggle with open source findings, you don't want to miss this episode. Just so you know, this was taken from the 2020 Secure Guild Conference. It's a session that James did for us at that event. So it's a quasi interview. What I did is I took his session, I sliced it up and I added my questions and I made it sound like a real face to face interview because I really wanted to share the awesomeness that he gave us at the event. And if you don't know, you can actually still get tickets for the event. You can get an all access ticket. All you need to do is go secureguild.com and buy a ticket now and you get instant access to James and all the other awesome recordings that happen at the event in 2020. And because you're a loyal Test Guild listener, if you use the discount code GuildCoin20, you'll get 20% off your ticket price.

It's no secret that the number and complexity of applications are growing. But what is alarming is that 90% of security incidents result from exploits or against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components and scale as your needs grow with an on premise as a service or hybrid implementation. Check them out. Head on over to microfocus.com app security.

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.

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% of the components in modern applications are open source. I know even my own product, I build a software security center web application. It's about 175,000 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. Right. The amount, the volume of open source components that we are leveraging today has obviously exploded.

So James, how can you actually manage this open source risk at scale?

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. Right. And so that's typically what companies have been doing, have been doing for quite some time. Right. The known vulnerability space has been alive and well using some kind of known vulnerability technology like a Sonatype or something. Open source like no WASP 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, yet a significant portion of the logic for applications. Right. And significant data flow and code flow paths through our applications are through open source components that anyone can download and understand and break down. Right. And simply look to see are there any known vulnerabilities in a very popular framework, especially ones that are difficult to upgrade, right. And then these vulnerabilities can be scripted and distributed in tools really. I mean a lot of these can be, you know, you can, you can have a very Mickey Mouse ish from a skill set person, you know, exploit your application, you know, if you were leveraging older components or components with known vulnerabilities, right. And it gets even more complex with transitive dependencies. Right. It's not just the library, the you know, calls you make into first level dependencies and also the calls that your dependencies make into others. Right. And so the complexity has, has really gone through the roof. And to find someone, you know, and an application group that could explain end to end all the code flow paths in an application is almost impossible because of the complexity of all of the open source components being Leveraged.

Okay, so why is the open source policy then so critical?

Well, we've been talking about the volume, right? How can you keep up? We are constantly releasing. We are agilely not really a word, but in agile development we are quickly iterating and failing fast. Right? And unfortunately that also has led to, you know, an increase in verified or suspected breaches. Right. It's not just winning in the market is not just about who is first and who has the best feature, right. If you, if your features lead to publicly embarrassing security breaches for your users, right. Or your application that makes your organization more productive leads to a public vulnerability that damages reputation, right? You can't win in the market like that. Customers have to. Your customers and your users need to have confidence in your applications. We've seen it. You know what happens to these companies, stock prices when they have these well known breaches? We're entrusting them with our data. Right? And one in five organizations have 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 the level of risk I am willing to tolerate for this particular application so that I can understand very quickly and communicate to developers really quickly that 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 do I upgrade to? So identifying the next best version to upgrade to that is free from that vulnerability is also a part of this current solution.

So do you think all the open source components you use in your application should be maintained equally?

Right. I love this little cartoon here where you have a critical component of your application that's been, you know, 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? Right. Vulnerabilities occur, right. Someone has to maintain software, right? It's a living, breathing thing that needs to be maintained and upgraded and we can often find ourselves in very precarious situations.

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 Achiev, at.

The enterprise level, you know, speed to market, right? You know that that is how we win in the market, right? We need to be first.

Right.

With the best solution. Right. So how do we achieve this? Well, we know security is needed. Right. 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, you know, daily, thousands. Right. Of the components that are out there in the community that we are losing, we are utilizing. So you know, the enterprise dev teams who contain their supply chains, you know the rewards are impressive. Right. Just by brushing your teeth. What known vulnerabilities do I have in my application? Right. And some kind of basic policy that denotes what types of risk based on either cbss scoring or some other metric that we want to leverage to understand the impact and likelihood of these exploits in our applications was reduced by 55%. So that alone can tell you that there is current solutions that will just the basics can give you a huge advantage in terms of not using known vulnerable components.

So James, can you go over your concept of a technology lifeline for your open source issues?

So we've talked about the solutions that exist today. Known vulnerabilities, fingerprinting, dependencies, checking known databases, providing additional research for those known vulnerabilities. A lot of the different vendors provide additional research above and beyond what's in the nvd. Right. But they don't help you prioritize beyond what's in the CWE and the cv. Right. 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, you know, your custom code vulnerabilities fortify. Static analysis is very good at understanding your custom code, parsing that, understanding that and running our analyzers against that and then co locating. And in this case we've partnered 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. Right. You need to understand vulnerabilities in your custom code, you need to understand vulnerabilities in your known components or open source. Right. And then you co locate those together. Right. That's what? That's what we do today. Right. And that brings us a lot of benefit. We're enforcing open source policy, we're trying to control risk along the sdlc. As I mentioned, we partnered 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 a current fortifier, Sonatype customer integrated experiences help continuous integration, integration platforms, integrations into the IDE. Right. And kind of why software composition analysis.

70% more vulnerability coverage than 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.

So also, James, what do you see as the challenges for people in this current state that you just explained is.

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. Right. He has to, 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. Right. And make a determination of whether they're actually vulnerable or not and what they're going to do about it. Right. The average software composition scan for any application on average is 38. Right. And so you're spending 12 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, right? 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, Right. 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.

These are large frameworks. The known vulnerability that is described can often be very specific. You may not even be leveraging that functionality, may not actually be vulnerable at all. Right? Yes, the vulnerability exists. Yes, you use the component, but you haven't used the vulnerable function or method yet. Right. You could in the future. And the answer is always to upgrade. If you can. Specifically, if it's easy. Right. But we need to understand the risk, the real risk, not that, just you. Yes, you have struts 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 issues we're managing. Right. At any point in time, and these are constantly changing. Right. And 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. Right. That an attacker could take advantage of it. Right. So that's why we audit these issues. Right. So those hours could be spent investigation issues with no security impact at all.

All right, makes sense. So what's the solution then?

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 the 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. Right. So Fortify comes in on the custom code side. We provide the transitive model of your application and the rules engine. Right. To look for usage and user control input that potentially reaches that function or method. So think about it like baking a cake. Right. We invoke the Sonotype 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. Right. The resulting Fortify project report contains the 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. Right. We include the full evidence. There's no guessing. The developer doesn't have to spend 20 minutes, right? Because he 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. 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 in custom code.

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 secure guild from 2020. If you want to actually see this in action, all you need to do is go to secureguild.com and register and get your all access ticket.

Now, I mean some of the uses, 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, right? Here's. Here's a view into our. The Fortify on demand, our SaaS platform of different known public vulnerabilities shown, you know, kind of across the Fortify priority order of critical high, medium low. Right? 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 example of bringing that data in, right? 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 see 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 SQL injection vulnerability is very real and therefore you can prioritize this particular component, upgrading it or removing it or using something else. Right? 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 reach them.

Does this solution give you a way to reduce the number of false positives a lot of people get?

So reduce known vulnerability false positives, right? They're not false positives and it is a vulnerability. Right? 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, right? 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 in custom code, I should, right? Better data, better decisions.

All right James, before we go, are there any potting words of wisdom you want to leave the Guild and what's the best way to find contact you or learn more about Micro Focus Fortify.

All right, so Fortify and Sonotype difference, right? We're the best of, we're the best of breed in our respective spaces, right? We focus specifically on unknown vulnerabilities and custom code with static analysis and dynamic analysis of unknown vulnerabilities. Basically zero days and cenotype focuses on the known vulnerability space, right? And the research side of open source components. And 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 channel for more demo videos. We have a lot of videos. Give us a like and check us out there.

Thank you James for links to everything of value we covered in this episode. Head on over to testguild.com sg.

And while you're there, make sure to click on the Try It Today link under the exclusive Sponsor section to learn all about Micro Focus Fortify, which is the recognized market leader in application security. So that's it for this episode of the Test Guild Security Podcast. I'm Joe. My mission is to help you succeed creating end to end full stack automation testing including security awesomeness and as always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.