How to Spend Less Time Fixing CVEs

Bill Manning:
Whenever you’re ready, man.

Speaker 2:
Okay. Hi there. Thank you for joining us. We’ll give a minute or two for some people to keep hopping on, but our webinar today is how to spend less time fixing CVEs. And to begin, I want to introduce our senior solution engineer, Bill Manning, who’s going to help us with running this webinar and teaching you how to spend less time. Bill, you want to take it over?

Bill Manning:
Hey guys, how you doing? So yeah, so today we’re going to be talking about all the various things you can do to basically remediate faster. One of the major drives we hear, we have here is basically how do you do things to make it more efficient? I mean, that’s what we do as a platform. We are the software supply chain platform. And so today we are going to talk about how to spend less times fixing CVEs. As stated, I’m Bill Manning or it says William here. Yeah, because I go by both. I don’t… You know, it works anyway, but I am one of the solution engineering managers for the Americas here. And the thing is that when we start talking about CVEs, we need to have some context behind it. We all kind of know what it means. But the big thing is we see headlines all the time.

We’re inundated with all these headlines. And when we say software supply chain, we mean those third party transitive dependencies. And now the thing is, it’s not just the direct dependencies. We all know the implicit, the direct, the ones that we request as part of what we do. We’re doing MPM, we’re doing Python. If you’re not familiar with J Frog, I mean what we do, definitely there’s other things on that. I’m assuming that you have some context behind who we are. But the thing is that we see these all the time and software supply chain is one of the biggest threats to most corporations in America today. And the thing is, is that the reason why is, is that most of the time people don’t even realize it, but 40% of the Zero Days… Think about this. If you’re not familiar with Zero Day either, the idea of a Zero Day is that when any time that there’s a CVE, that has created, right?

They’re not just thrown out there. There is a time period involved as part of this where an issue is discovered, it’s tested, it’s over tested, it’s then peer reviewed, it’s agreed upon, and then the CVE is created. Well, 40% of the Zero Days exploit of all time increased in 20 for 2021. And it’s constantly increasing. The threat is real. When we go through this you’ll understand that corporations spends so much money all the time on remediating this. And the reason why the remediation takes time is because of time. The more time that you spend working on discovering or if you find a CVE and discovering what other… Where is it affecting, how many projects it’s affecting, it takes longer. You know, got to go through. There’s a lot of diligence involved and there’s a lot of discovery and you have to go digging through and read the CVE and understand the CVE.

But the thing is, is that a lot of these take longer and longer to identify, which means that you’re more susceptible to whatever sort of nefarious or malicious cause these libraries might have to inflict. I mean, the thing is, is developers are artists. I always say this all the time. And the thing is, the medium they use is the coding language they’ve chosen and the libraries they use to do their job more effectively. Now, at the same time, you want your developers to be able to go forward and innovate and create KPIs and the faster releases that get out there allows you to have fixes and more features and enticements for your customer. But the thing is, is that these attacks, when they go on, can damage your company, not just financially but your reputation, which thus in turn will affect your company financially and things like that.

And the thing is, is that the actual amount of time for an exploit decreased from 42 days to 12 days. And think about that. This is kind of a little insane when you think about it. The thing is, it’s gotten faster and faster over time and it seems like we’re constantly being inundated. That’s the reason why I chose, in the beginning, Maurice, the fire as he’s trying to work. This is what we’re doing, because the thing is, is that all these threats are real and most of the time, most corporations it takes. So in the meantime to remediation is one of the statistics that’s used in the industry when determining whether or not a security issue is discovered. And by the time it’s either it’s time, it’s remediated 58 days. That’s an eternity. Think about this. You’re always constantly working on busy cycles. You suddenly get a notification from your security team and that takes time and the older processes of like, “Oh, we’re an air gap environment because we don’t want to let this in.”

That’s even kind of antiquated at the same time too, right? You’re actually hindering the velocity of an organization to develop what they do. And the thing is, these larger threats that go on all the time, it can be insurmountable for most organizations. It really can. It can be completely insurmountable. The idea of do we take our developers off to work on the security issues, but at the same time we’re detracting for our ability, our KPIs are going to be reduced, releases are going to be delayed, and things like that. But what if you can do it in such a way that you suddenly have the tool sets that are available to help you. Not only tell you immediately that there’s a CVE with what you’re doing, but also provide you where it is, how it’s affecting you, or even better, if you have all these CVEs, are you truly being affected by it?

Listen, 21,000 CVEs were registered in 2022. Think about that. I mean, seriously. Just to let you know, at J frog we are a CNA, we are a CVE number authority. We have a massive research team. And by the way, one of the things that I will share with you guys is that if you guys want, we actually do have a research page that’s available with all the information on how, what we’re doing and things that we found and lots of great, great blog articles on how to protect yourself. But the thing is, is that these number of CVs we have is because 85 to 90% of your software that you built is someone else’s, right? Your code is only around anywhere from 15 to… 10 to 15%. The rest is all these things that you have there in the world.

And the thing is, is that you still want to be able to provide the ability for your developers to develop but not squish their ability to innovate and at the same time add a layer of protection in there. Everything from shift left, which we’ll discuss, right, at the developer level where the ROI is greatest on any security tool. Listen, if you’re discovering CVEs from your security team all the way at the production level, it’s a hundred times more expensive for your company to remediate that. So giving you all the proper tool sets, the ability to remediate faster, automation behind it, these are the things that we’re going to talk about because think about this, every time you do a PIP install, a GoGet Maven fetch or something like that, is the equivalent of plugging your thumb drive. You found it on the street and plugging it into your production server.

Seriously, you do not know how this happens. And remember, most of these CVE attacks don’t happen at the implicit level, the one that you’re doing, right? These all happen behind the scenes, usually at the third or fourth transit of dependency level. I mean, look at things like SolarWinds, right? Perfect example. That was a fourth level transit of dependency attack. And we’ll talk about why. And the thing is, is that when you go into typical developments, you guys know this, right? You’re a developer, you’re given a KPI to build a piece of a… To build a product or something and you go, “Okay, assess it. What technology works best?” Maybe MPM is the language that you’ve chosen to build this. Maybe it’s a web facing example. And here’s giving a quick scary thought here is, is that you go through and you design this and you put your package at JSON together where your dependency is.

I found a library to parse a string that pulls back a hash value that I need to go do. All the things you do, you pick those libraries that best are applicable to do the issues you’re trying to build in your product and you put it into your package like JSON and I always jokingly call MPM the house party.

You put three things in your package like JSON and 500 show up unexpectedly? Well, that’s really what we’re trying to make sure. Those 500 plus things that are coming in unexpectedly, how do you know? How do you security vent them? How do you make sure that you’re not introducing something that’s going to go ahead and open your firewalls or release your customer data or all these kinds of components? Because when you do this, you know, you do an MPM install, it goes and gets your third party transitive dependencies, it brings them in and you’re all happy. I’m going to show you today how you can do things such as, first of all, you should know, you can go ahead and pre-vet any of the libraries that are coming in before they even get into the developer’s hands. This is basically your preemptively stopping before it starts. But what about things that are in process?

What about the Zero Day? And we’ll talk about too is the fact that one key factor to keep in mind if you are a J Frogg artifactory with x-ray kind of customer, the thing is, is that our key differentiator within compared to any other product in the market is we’re continuous. We stored the binaries as a check sum, right? It’s Shaw 2 56. It has context behind it with what that actual software package means. On the other side, we have this massive repository of CVE data that we’ve accumulated between our security team, our partnership with risk-based security, the largest proprietor of vulnerability data. NIS sources, MVD sources. And you have both of these things. A metadata list of binaries and the metadata list of potential CVEs, thus the reason why our x-ray products is super efficient, because it’s only share metadata to metadata comparison.

So what are you supposed to do with supply chain and tax bill? First of all, you need to understand the sheer magnitude of this, right? And the idea here is simple. Is that 99% of the goat pace that are out there that have been scanned by not just us but other organizations, analysts and stuff, 75% of those contain at least one vulnerability. That’s actually kind of low because actually we’ve seen actually larger numbers here because the thing is, is that the sheer volume of this has increased. These potential threats and attacks have increased. 49% of the code bases had at least one high risk vulnerability and that means high or critical. When we’re getting into the category of these could be major catastrophic things. And the other part of this though, and this is something people really most of the time don’t think about, but most of those libraries that you’re using out, those third party transit dependencies, both the implicit, the direct and the indirect transit dependencies are old, outdated, they’ve been abandoned.

So we even, at J Frog have this concept called operational risk. So we could even defend your corporation and by looking at the buying, there’s third party transits that you’re using, and say, “Is it end of life? How old is the version you’re using? Is there new versions available?” And also too, what’s the health of the open source project? Is this still a viable actual entity? This is a real credible threat because if there’s an issue and it’s never going to be fixed, you should know.

So let’s go back and when we talk about this, the thing is, is that why do attacks happen? Why do you need to know this? Well, first of all, it’s low effort. It doesn’t take a lot of skill and strategy to do this. It really doesn’t. Let’s be honest. And the other thing too is, is that it also spreads very rapidly.

Now when I say it spreads very rapidly, think about this. The open source community is very… When I say open source, I mean FOSS, right? Free and open source software. Those third party transit dependencies you rely on. Newgate packages, Python, MPM, docker based level images, Terraform template. You name it. These are the things, but the thing is they are accepting and when they make addition and if you actually are a hacker of some sort… I say hacker loosely in this case. I have my feelings on all that, but the idea is that introducing a small library that could be potentially threatening into the supply, the actual supply chain of building that third party indirect transit dependency that comes along for the ride, is very fast, it’s very simple. And if you associate it to them a more highly used one, it doesn’t take a lot of time for somebody to go in and say, “What are the most downloaded libraries out there?”

Right? Because remember, it’s dependencies, have dependencies, have dependencies, have dependencies. The thing is, is that once it’s in that stream, it just kind of gets swept up with it. You do an MPM installer or PIP installer, n NEWGEN or anything like that, you’re suddenly bringing this into your organization. It’s like unwelcome guests. You’re bringing them in. And the problem is that this could abuse a trust relationship, not only with your customers if the vulnerability is found and exploit has been exploited, but also to inside your company. We’ve seen a lot of companies that when we talk to them, before they see what we can do as a platform, have this knee-jerk reaction to say, “You know what? We can’t control this. This is just uncontrollable. We’re just going to lock out the outside world and we’re going to go air gap.” And in my opinion, all you’re doing is slowing down your development and those processes and your competitors are going to take advantage of this.

And the thing is, is that when they do this, there’s a lot of times there’s a… Don’t get me wrong, I’m not even getting into the whole philosophical debate on paid exploits versus just wanting to get the kudos down to those anonymous ones that get out there, but they’re usually just some sort of malicious code or some sort of backdoor.
I mean, look at it and then it really depends on how it’s being exploited. So saying that though, keep in mind in 2021 there was a 650% increase in supply chain of tax. Like I said, the flood is happening. This happens all the time, and there was an increase in 2022. It just kept going up. It just seems like you’re constantly having to worry about this. This is now a credible threat with software, the software industry, and we’re there to help you. And the platform, we call ourselves now the software supply chain platform, I like to say actually we’re the secure software supply chain platform because we give you the ability to not only pre-vet binaries before they get in their hands, we also have tools like our ID plugins, we have our CLI tool, our inside of the Xray.

There’s ways to do this even more rapidly. And now we have our advanced security features that do things such as narrowing. Are you being affected by this? And we’ll talk about that. So when we look at what we offer as a platform, it’s very straightforward. You have artifacty, right? Which is our… That’s where the third party transit dependencies that your developers are working on, both direct and indirect, are being cashed. So if you have a thousand developers and developer zero brings down a library and all its transited friends, all 999 other developers will use it too. You know, you can do also two global sites and be able to replicate between them. So you provide consistency, non-dependent on where your developers are located, but it’s also a place to store your builds. If you’re not storing the build data in artifacty, you should really take a look at some of our talks on bills.

It applies accountability, because the thing is, is… Don’t get me wrong, there are products out there that can find CVEs fine, but how many are going to actually tell you how you’re being affected, where you’re being affected, are there any other projects being affected? And the thing is, is the way this happens is, is through our build information when you publish a build, because it allows us to actually create dependency graphs on where things are dependent on other things and not just the project you’re using but other projects that might use that same actual library too. So you can get a blast radius if you do get hit with some sort of critical CVE. Xray, like I said, it’s continuous and you can integrate it at any point. If you look here, if we went from left to right, on the left-hand side for shift left, like I said, we have the ID plugin.

I’m going to show you the CLI tool. I’m even going to show you how you could pre-evaluate those binaries before they even get into the developer’s hands. Why let them in if you can suddenly say at the gates, “Hey, by the way, you know if you’re bringing this in, you are a potentially critical issue that could hurt us.” And we extend our security offering by the way, and we’re not going to go through it today, but if you’re interested, we have plenty more talks on the consumption side. Our distribution side, we actually have the ability to scan these things called release bundles, which allow you to actually publish out things like helm charts and dock images together as an immutable release called a release bundle. It’s digitally signed for security, you can scan it one last time before it gets into your production. We have Jfr Connect, it’s our IOT platform and allows you to do device management, diagnostics.

We even have security around like the firewalling for alerts, also the ability to roll back and deploy automatically. Lots of cool stuff. And then of course we have our pipelines product. Now with our pipelines product too, one of the great features here is, is that it can be your CI, you can use it as a straight CI, you can use it as a CD to distribute your software where it needs to go. Or if you’re using more than one CI environment, you can use it as a way to orchestrate them. But really what it comes down to is what you’re looking at here is a platform engineering play. We actually have the full gamut of everything that you need as a development organization. I mean there’s a reason why over 7,000 customers have come to trust us with the things that we do.

And when we talk about automating security and what we’re going to go through today, you got to remember it’s got to be able to scan software. Let’s face it. From package types for third party trends of dependencies to base level docker images and containers, being able to support a majority of those things to make sure that those components that make up 85 to 90% of your software are safe and secure. Getting full visibility. So we offer things like software bill of materials. Everybody’s heard about this. I have a whole talk that’s basically about demystifying what software bill of materials is. Basically it’s just a list of ingredients that makes up your software.

We have amazing vulnerability data from our security team. You can do malicious package detection, you’re going to be able to… We have Zero Day. So since we’re continuous security, if a new CV comes out, you can be notified right away so you can address it and take care of it. The thing is, is that with the thing I’m going to show you today is fix what matters fast. So we have this thing called contextual analysis and we can also do contextual prioritization. I’m going to show you how you can use that information to quickly bang out through that, right? Then the other part of this that we have is also too being able to take all this information and deploy it across your entire org, from your developers to your CI to CD, and in the future we’ll have an announcements down the road even now to your runtime in Kubernetes.

It can integrate everywhere. So you can use our J frog CLI or API. We have plug-ins for all the various CICD tooling, the IGEs. Like I said, we’ll discuss those. And then lastly, you can use these same things I’m teaching you with our platform, whether you’re using our managed solution, which you know is our SaaS, I guess I like to say it’s managed because it’s much more than that because you choose your own cloud provider, your own region and all that. It could be in your own DC, it could be a combination to be across different cloud providers. We don’t care. We bring that same level of excellence no matter how you’re using us. And the thing is that some of the things we’ll talk about today is our advanced features, which we just introduced late last year, which is like if you’re using Terraform, infrastructure is code analysis.

So being able to go in and determine are you truly locking down everything when you’re doing, saying something with Terraform. Secret detection. Oh, my god, you would not believe inside of docker images, how many docker images I’ve scanned and found private API keys. I found just lots of secret information. And by the way, it’s usually not highly visible. Most of the time it actually shows up in the root history. Think about that. Somebody forgot to go ahead and actually remove the credentials. They removed it everywhere else. They just never cleared their history. Miller’s code detection. We’re actually going to go through and I’m going to show you some actual ways that we detect that.

We also can tell you, do you have any services or applications exposed in docker images? Perfect example, you know might have a service in the background that’s starting, that’s looking for some remote connection that you downloaded some base image off the internet and now you have suddenly have something like… I had one I downloaded, I started the image, I did a quick search on something, it was a popular download, I put a sniffer on it, I started the docker image and as soon as it started we detected that there was a service running in the background.

And when I went to monitor that service, it actually was sending a request somewhere externally. And when I sent it externally, the request back came back. It says, “Hey, thanks for connecting. Give me your log files.” Think about that. You’re deploying a service, suddenly you have a container start and it rings off somewhere, grabs all the log files with all the data and deploys them somewhere else. That’s terrifying, right? You have no control over that. We can help you find that. So since this is a webinar, basically a discussion about how to, I just wanted to give a background and now let’s go ahead and take a look. So let’s start off with the preventative portion first. So the first thing you want to do as an organization, always make sure that when you’re designing your repositories and you look at any repositories specifically, not only your local where you store your bills, I’m also making the assumption that you have some experience using us already, right?

This is not new, but our third party transit dependencies are proxy through remote repository. And then when you’re doing this, and it could be anything type of repository that you’re building. And when you go in, if you want our x-ray product to ensure that things that you’re doing are safe and secure, always go to the bottom and say enable indexing and x-ray. Once you’ve done this, this takes the meditated representation of those third party transit dependencies cash and makes it available to our x-ray product. Now in x-ray, the way you can also make sure that you actually have things that you want to make sure that you’re ensuring that there’s no vulnerabilities or things like that, we have on-demand scanning and stuff, is through watches and policies. When you define your watches and policies, an important thing to remember is, is that when you are defining… Here, let me close this. Sorry, I was actually… I need to cancel that out.

Let’s go ahead in here. Let’s go look at my watches and policies. So policies are the rules you create in the evaluation and then the actions you take and some of the tools that we have here are pretty substantial. So first of all, you know have different types of policies you can design. You have security, you have licensing and operational risk. Operational risk is the one that I told you about where we could tell you how old is the actual binary that you’re using. But let’s just look at security for a second or any of these rules, because the actions non-dependent on security, licensing or operational risk, the actions are the same, but you go in and you define your criteria on what you want to evaluate. It’s a vulnerability. It can be malicious package and exposure. In this case, I’m just going to show vulnerability and to see their low, medium or high or critical when all severities… By the way, remember I mentioned when CVEs are created, there’s a peer review and testing.

There’s all the standard stuff you would get with scientific method. Make sure you always have all severities. Maybe you don’t take an action but always have that because info and warnings, by the way, come out before CVE is released just so you’re aware. Just saying that it’s being an investigation or you determine what CVSs score is applicable anytime you do this. All right, we have all these little features here and if you look here, there’s one that says Skip CVE if it’s not applicable. This is our architectural analysis and I’m going to show you how you can actually enable that in a minute. But the big thing is, if you go down here, we have block download. Block download will answer that Zero Day question. If a new CVE comes out to a library, let’s say log for J you’ve been using forever and a new CVE comes out that’s critical and you’ve defined a rule that’s critical in terms of CVE evaluation, this will actually stop the consumption of that binary for download.

So this is a way to preventively prevent it from that moment, right? Because we’re constantly scanning. But what about, I mentioned the fact that if you want to go ahead and have those third party trends of dependencies, new ones that are being brought in and you want your developers to be able to do it, but you also want to ensure that they’re not bringing in something malicious. You say block unscanned artifacts. And what that does is block unscanned artifacts allows you to go ahead and say, “Request the binary.” So they go like say the package, they do an MPM install, blah. It goes out and gets blah and all its indirect transit of friends, probably three, 500, 7,000 other additional libraries that come I, it gets stored in artifacty as cash. It gets evaluated by x-ray and if it meets your criteria defined by you, it’s released to the developer tool.

If not, they’ll receive a message that the library they requested or one of the transit dependencies that they requested is potentially threatening. So this is one way for you to go in and make sure that you, before this, even before you have to even go in and try to resolve these CVEs, this is a way for you to stop it from coming in. When you’re talking about… When I was talking about contextual analysis, one of the key factors here is we have this idea, which is our advanced features, is that you can go into your index resources where index resources is letting end x-ray know what resources it needs to evaluate. It can be repositories. Also too, if you have any bills that you’re publishing in here, make sure that they’re being covered to go ahead and manage your bills. You just click on manage build, find the bills you want, and then you can write rules around that.

So every time a build is published into artifacty, you can be evaluated. But back under repositories. If I look at any of these like this Docker one, what’s great is, or any of these components here, is that if I go in, you can see where I can say, “Okay, for this repository I want to go in and I want to configure some of my advanced features, such as I want to make sure that I have contextual analysis or I want to detect secrets. I want to look at applications and services.” Now these features are only applicable in this case for Docker. And I’ll explain the reason why is Docker is pretty dangerous. Plus what also gives us the ability to go in and do full scans, but it’s not the only place that it’s available. But once you’ve actually enabled those features, let’s take a look and see what kind of results you get. And this is where it becomes super important.

Now I’m going to show you an example of a Docker image and we’re going to start there and then I’m going to show you some of the other tool sets that are available so you can be on top of this as fast as you can. Now Docker is super notorious. I love Docker. Now I also can tell you that one of the things, if you think about the complexity, and that’s why I started here, think about the complexity. You have an OS, you have a runtime, you have an application that you have in here. And if you haven’t watched some of our other things that we do with Docker, our docker registry in my opinion, is tenfold greater than anyone out there. The fact that you can identify the application layer, I give whole talks on this, but because of the amount of time that we have, I want to be able to show this.

So first of all, I have a docker build here. Now this docker build… Actually, you know what, I’m going to show you the docker build. Let’s take a step back. So here’s the docker build that I created right here. You can see this is actually… By the way, this is a Jenkins job. This is one of my favorite ones to show because I think it really exemplifies everything that we do. I mean, even as part of this, we have x-ray as a way to evaluate this before. You can actually build in your X-ray scan. So when you’re building this, you can even throw in an X-ray scan to say, “Hey, if you could fail the build based on this.” So this way you’re always on top of it, even in if you’re doing get-ups or an automated process. But the other thing too is that when we look at this, one of the other key factors of being able to remediate faster is that here’s your typical Docker registry.

If you follow our best practices, one of my favorite things I’d love to show people is, is the fact that if you follow our best practices, you could actually see what application is running in the application layer of your docker image. And from remediation standpoint, you could even diff that application layer at the top. But that’s just kind of to give you an idea of maybe some of the other parts of remediation with these CVEs. Like maybe you want to roll back, maybe you want to see if a previous version didn’t have that actual issue. But let’s go back to our scan list for that same docker image. Now, the reason why I’m going to the scan list is because I actually have a tremendous amount of information. So let’s go in. So I actually know that this one… And now I’m not going to go into the details on how I got, I just know this was in Docker prod local.

I actually looked at the build and it told me it was stored there, because I can actually see the SDLC history. There’s a whole nother webinar on using our promotion API and emulating your SDLC for better… Basically better build management. But here it is. Docker app, which is the name of my docker image. It’s number 1 51. This is the version I’m interested in. Immediately I know that’s 358 violations, that there are some malicious packages actually in this. You can see here that actually I have 275 vulnerabilities., 275 CVEs. That I’m going to get to next. I also can show you that we actually are exposing six levels of exposure. Think about this too. That means is I have six services somewhere in this container that could potentially hurt me. But let’s go inside and let’s look at this.

So first of all, we have the policy violations, right? Here you go. I have some security issues. I mentioned we are a CVE, right? So if I’m looking at this one, you could see here, you can actually see that it’s active, that the violation of United State is active. You can actually organize your binaries. There’s a whole thing on that too. You can see that it’s a critical issue. But you know what? Our security team actually said it was medium. You can see that it’s undetermined. Now, I’m going to go in and show you a better way to look at this in a minute with contextual analysis. But check this out too. If you look here, this actually is a pretty terrible CVE, right? There really doesn’t tell me much. It just says SQLA has an issue. Well, since we are a CVE, a CNA, we actually provide with more remediation data and we also tell some additional research data that we have there and also some reference materials and also to where is this impacting you?

We have our software bill of materials. I mentioned that. I mentioned earlier, that if you talk about things like software bill of materials, doesn’t have to be this insurmountable task. If your security team comes to you, your legal team, and says, “Hey, we need to start using software bill of materials for legal purposes, blah, blah, blah.” If you’re using us, here’s just software bill of materials. You can actually go ahead even export this information as SPDX, recycling DX. You also have the ability to create reports. I’m just going to address this now. I mean your security teams are going to ask you for reports. If you’re a developer and you’re watching this, this isn’t going to really be your thing. But here’s the thing. I usually ask people, whenever I show this to them, I said, I’ve got 275 vulnerabilities. Now think about this. I have to, as a team for security purposes, I need to investigate 275 vulnerabilities.

What is this going to do? Well, it’s going to cost me money. Don’t look at these as actually just besides issues, these are costing me things. Number one, it’s costing me the ability for me to develop new features and functionality because now I have to redirect my engineering team to work on this, right? You need to address these security issues. Secondly, it’s going to delay the release. This could impact your revenue stream, right? Because now the thing is that potentially these issues could delay new features that are coming out that might have you excel compared to your actual competitors. Also as part of this, well, you know what? How long have you been affected by this? But first of all, how do I go through and say to myself, “well, where do I start?” But what if I were to tell you, if you’re actually uploading these into artifacty and using our X-ray with our advanced features, I could tell you, when I just do a quick sort, that actually added this to 275, 70% of these actual CVEs are not applicable.

Not applicable, they’re bogus. You know why? So what we do is we take the context of the actual CVE, we look at what the actual issue is, we then break it down and say what is the nefarious component? We scan the binaries, in this case the build, right? So we scan the components and say, “Are you utilizing these pieces?” All right, is it… And if you look here, it says, you know what? This CVE is not applicable. You’re not employing a specific component. So you can basically say and ignore this because let’s face it, the thing is if you understand CVEs, is you could have a library with a hundred functions and one function is potentially threatening, maybe a critical threat. It’s labeled as critical. If you’re not using that function, do you need to be aware of it? Yes, but do you need to take action on it?

No. And we let you know that you’re not being affected. What if you start using it though? Remember, we’re continuous. We will change the actual positioning on that from applicable, not applicable in this case to, in this case, applicable. Here it is, right? So if I go in and I’m… Oh, sorry, I clicked on the wrong place. But the thing is that we actually can go in here and show you the components and say, “Yeah, these are applicable. Or you know what? Here’s some malicious packages.” We’re cutting and I don’t not really have any in this case, but you know what, if there’s secrets. Well, here you go. You know what? We just found a weak password and we show you exactly where it is. This is actually, once the build has been completed. We give you that contextual analysis ability to go in and look at the pieces that you’re doing and say, you know what?

Actually, here we go, right? Like I said, when we’re returning these values, these are not applicable. And then I have other ones in here that are applicable. And the best part is we actually show you where. Here you go. These are the two direct locations. I just cut down your remediation time. I told you which ones were applicable to you so you can go in and fix them. I told you that 70% of these are bogus. So now you’re down to about 30 ish, 35 ish vulnerabilities you need to look at. Well, that’s great, right? Here they are. They’re undetermined. We let you know. But that’s just one part of this, right? Understanding that, because remember, you can go in here at any time and look at the pieces that you have here and also determine whether or not you need to go investigate it or not.

And this usually doesn’t take… Essentially takes much less time because in some cases, like this one here, this just happens to be the actual jetty server. Yes, there is, in this case, there is a high CVSs score value associated to this. But are you utilizing it? And that’s for you to actually determine. In this case, this actually happens to be a dependency of jeti. And here’s those services like I talked about. These are the things. Engine X in this case is not supporting TLS. You might want to fix that. Or in this case, there’s another one I have here. Oh, this is a different one. But you know, get the idea. I can go in and see are these things here, but where are the other ways I can do this? Well, let’s go ahead and let’s go to the developer.

So I showed you how you could quickly remediate it inside of our art factory. Well, here’s an example. In my case of a package JSON for an MPM build that I’m doing. Well, take a look here. We actually have an ID plugin called JF frogg. And if you look, you can see there’s a little symbol here. And if I hover over this, you can see that we’re actually exposing the CVEs directly right here. We’re actually flagging the libraries where it matters most, the developer. Well, let’s go in and take a look. Well, here’s a CVE that I found. Well, you know what? This CVE is applicable. Look at that. As a developer, I don’t have to go to the UI. I’m actually, as I am coding in this, I am coding this and using dependencies. We’re letting you know where it’s available. Here’s the information.

Where’s it available? Well, right here, it’s an off jsun. And you know what? Hey, this one here, I’m going to take a look. I can go ahead and click on this and this is going to bring me directly to where this CVE in question is. Think about this. Normally you would get from your security teams a CVE report and said, “Okay, investigate this.” Or you get a notification. So in this case, I’m actually showing you in the file, we found in the file, we found the CVE. Here it is. And we actually even highlighted the actual potential threat cause right here. Here we go. This is the CVE that’s applicable. We’re cutting down the amount of time it takes somebody at the developer to do this. We even offer the same sort of information. If you’re using our J frog, CLI. I mean you can even audit any of the things that you’re doing and get the direct information right here.

We also provide that if you’re downloading something like a jar right here. I downloaded a jar that created and I did a quick scan before I used it. And we give you the ability to see it there and also see. Now this doesn’t allow you to go in and see some of the context, but context will be coming. And we even extend this information even to things like the Docker desktop. We actually even an extension there. So if you actually download any of the things that you’re doing, you can actually see, hey, I downloaded this. Is there… Even if it’s not an artifacty, is there anything potentially threatening or nefarious there? But understanding all those key concepts when you are doing this are important because understanding the value that comes when you know can detect early and detect often allows you to remediate faster. We literally, by using the ID plugin, the CLI, by giving you any sort of level information here about the things that you’re utilizing and being able to actually go ahead and delineate through any of these actual potential issues.

I mean, 275 vulnerabilities, any development team would look at this and go, “Oh my God, what do we do?” I mean, it’s going to hurt, but we actually provide you. I mean, wouldn’t it be nice to be able to get that information as a developer and be able to say, “Yeah, you know what, we got to fix this.” And auto, you’ll hear companies talk about automatic remediation of libraries always up to the latest. In a way that’s a bad idea, right? You’re going to want to test here. We actually tell you, here’s the fixed version. So we even take some of the guesswork out of the for you. Here we go. Yeah, it’s applicable. You know what? Actually, if you upgrade to version nine, O, that should fix it. And this allows you to go ahead and look at what public sources are there. We also let you know, in this case this was a direct transit of dependency, but I’ll tell you right now, we have other ones too that where we can go in and we can show you the different impact paths on these actual binaries, these CVEs.

So if I grab this one here and I show you this CVE. I can show you this is a third level transitive dependency and also lets me know I can go ahead and fix it. But in this case, because you’re not sure, it’s not known. So you’d have to do a little investigation. But we provide you with enough information in reference materials for you to do this more rapidly. Like I said, if you want the maximum ROI on any product, you’re always a security product. You’re always going to do it at the developer level. This is where it’s most important. So you have, remember recapping, we have our J frog CLI, we have our ID plugins. You can also, by the way, we have other methodologies too, I should actually touch upon quickly. We have integrations to things like Jira, so you can actually go ahead and actually get all this information as a Jira ticket that’s actionable.

And the best part is, by the way, if I click on this, this will actually bring me to the actual library in question, the package that I have here. So I know, and I can go ahead and look at its X-ray data. So here we go. These are all the vulnerabilities. I can actually select this and find out more information on what this vulnerability is, right directly from my Jira ticket, which I love. If you’re using something like MS Teams or in Slack, if you look here, you can actually use our Slack plugin that we have here where you can see there’s a whole bunch of things you can do with x-ray and artifacty and whatnot, but it also gives you a way to get constant alerts. Are there new threats and vulnerabilities that are happening? And in this case, I can go ahead and click on here and go to the actual demo instance I want or go look at another one.

So this is direct integration right here. And as I stated, you know, can be using any other tool or any other CI tool in this case, I’m actually, in this case using.. I have another build that I’m doing where I’m using something like Azure DevOps, which is taking a little second to load. But we even have for other products like that where I can go in and just show you that we have artifacty, everything built in here to evaluate binaries at any point in time while you’re doing your build. Understanding how to basically secure your platform and to have it still giving your developers the ability to remediate faster is really the key consideration here. And J Frogg really brings that to the table with contextual analysis, secret detection, being able to isolate those issues down to where you can fix them and attack them more quickly.

Remember, the biggest threat with this is not actually the threat itself, but the amount of time it’s going to detract the amount of money it’s going to cost your organization to fix this. Because like I said, these will help you actually fix them more rapidly, meaning that you can innovate more and remediate less. So the faster you can remediate, the better your off your organization is. Well, thank you guys so much for your time. I truly appreciate it. If you have any questions, please let me know. You can contact me on J Frog or on Twitter. I hope everybody has a wonderful day. Be safe out there. Protect your company, protect yourselves. Cheers everyone. Oh.