JFrog Advanced Security Features Overview

JFrog Advanced Security is supported by Enterprise X and Enterprise+ subscriptions and is available as SaaS and self-hosted. You can find the pricing information on the JFrog pricing page.

Does Container Contextual analysis save my developers remediation time?

Yes and our security experts’ research suggest this can be as much as a 75% reduction in the number of applicable CVEs to fix. Essentially this feature helps you eliminate any false positives!

Does Xray scan container images for known vulnerabilities like an SCA tool or do I need to get Advanced Security to do that?

Yes, Xray is an enhanced SCA tool which can scan your container images for known CVEs in your open-source packages or dependencies. It utilizes our premium vulnerability database from Risk Based Security and other public and private sources – PLUS it is enhanced and updated on a daily basis by our security research team.

Do you support other container and IaC technologies with Advanced Security?

Today we support Docker Containers and Terraform IaC files… but we are already working on supporting other IaC and package technologies with these new features and will be making releases with more support soon.

What package types support password detection?

Password detection feature is for Docker images to start with.

How do you find dependencies not listed in the SBOM?

JFrog Xray does not depend on SBOM to identify the dependencies. Yes, it does use the build info from artifactory and the meta data associated with the artifacts. However, based on the package type it can automatically identify the direct and indirect dependencies and scan them. For more information please refer: https://www.jfrog.com/confluence/display/JFROG/Xray+Dependencies+Scan

JAS available in which version of Artifactory?

7.39.4 and above.

Does it use self reported package version number to ID vulnerabilities or does it use VDOO technology and support scanning binary directly

Xray uses a variety of techniques to identify a given package including versions, checksum, fuzzy hash, buildinfo.json and direct/ indirect dependencies and so on.

Do you have more information about integration Artifactory and MS Code integration ?

Please refer this https://www.jfrog.com/confluence/display/JFROG/JFrog+Visual+Studio+Extension for step by step instructions on how to install and use the JFrog extension on MS Code. Note there is a video demo of the extension as well on the same page.

Does the scanner support raw linux image scanning, binary file scanning and zipped package scanning

I am assuming you are asking about being able to scan raw linux images in “img” format. Right now this is not supported. Please refer this link for the support package types: https://www.jfrog.com/confluence/display/JFROG/JFrog+Xray

Could you share Advanced Security roll out date to Artifactory cloud?

The advanced security product is already GA and is being rolled out. Please note that you need a subscription to enable the capabilities.

What’s the difference between configuration issues found in services versus Applications?

Service Exposures are config issues in popular OSS like Envoy Proxy, Etcd, Prometheous etc. Application exposures are related to your usage of OSS libraries. Give an example for each.

Do we categorize JFrog Xray as SCA or SAST tool?

Xray is primarily a SCA solution. The Advance Security Features are in addition to help developers to build and deploy secure applications.

Could you explain the terraform repository scanning in more detail?

Please refer our documentation: https://www.jfrog.com/confluence/display/JFROG/Exposures+Scanning+Categories

Does this come with the next Xray release?

Yes, 3.59.4 release.  Please note that you need a subscription for JFrog Advanced Security to enable these capabilities.

What sort of trajectory to you see in terms of intensity of attacks against MSSPs going into 2023?

Forrester Research: The State of Application Security 2022

How can we implement a secure shift left process to mitigate malicious packages don´t get used in production, like npm, pypi, etc, without using gates to scan those dependencies?

JFrog Xray already protects against malicious packages.

How can jfrog monitor dependencies not listed in the SBOM?

JFrog Xray does not depend on SBOM to identify the dependencies. Yes, it does use the build info from artifactory and the meta data associated with the artifacts. However, based on the package type it can automatically identify the direct and indirect dependencies and scan them. For more information please refer to this page: https://www.jfrog.com/confluence/display/JFROG/Xray+Dependencies+Scan

Is it included in plugins (for instance for Jenkins, Intellij IDEA, VS Code etc.)?

The contextual analysis is going to be part of the IDE plugin.

Do the security updates expand your reach in terms of which customers will be attracted to this offering or should they be viewed as providing more depth of coverage to the existing base?

Yes, we do expect ops and security to be attracted to this offering. The new advanced security solution unifies developers, operations, and security teams to safeguard the software supply chain in a holistic, hybrid, multi-cloud platform.

Transcript

Hi everybody. Welcome and thank you for joining our webinar about JFrog Advanced Security. Today we’re going to talk a little bit about supply chain security, the current problems that plague us with resolving them, and then introduce a new security suite by JFrog and aimed at solving this supply chain security issues in a holistic manner. Regarding Q&A, please feel free to write your questions in the chat box and we’re going to address all the questions at the end of the presentation.

All right, so just to introduce myself a bit, my name is Shachar Menashe. I’m senior director of Security Research at JFrog. I manage all the security research teams, so we’re doing things like CVE analysis, malware research, zero days analysis and research, and basically supplying a lot of the research information that gets fed into JFrog advance security and JFrog Xray and fuels those features.

All right, so I want to start a little bit about talking about supply chain security attacks, really short intro and why they’re actually on the rise and what do we want to do about it. So why do attackers actually prefer supply chain attacks versus, for example, a targeted zero day attack? First of all, it’s a very low effort attack, a supply chain attack, like writing a malicious package and publishing it to NPM or PPI is extremely low effort. Writing an exploit to a third party vulnerability, which is already public is a medium effort I would say, but still not high effort as finding a brand new zero day vulnerability and exploiting it. So this is an advantage to the supply chain security part.

Also, with a lot of these techniques, there’s low technical skills required. So when you’re writing a malicious package, you don’t need to reverse engineer, you don’t need to be proficient in exploit development. You can just write a simple package and publish it to open source repository and it will also cause a very high spread. In a targeted zero day attack, you’re really targeting one system usually, or one network. But if you write a malicious package or you exploit vulnerability in like a popular third party library, it becomes a very high spread attack. You can attack tens of thousands or hundreds of thousands of machines or sometimes even more.

And the last thing which we could actually see from the SolarWinds attack as well, is that in supply chain there’s an inherent trust relationship between the vendor and the customer. So for example, in SolarWinds where they supplied an IT product and everybody trusted that product, but when it had a back door, it caused massive effect because nobody was expecting to be hit from that way. So that’s also something that’s very easier to do with a supply chain security attack and versus a targeted zero day attack. So basically we want to solve the supply chain security data attack, and they’re coming from multiple categories, not just CVEs, it’s also malicious packages, configuration, et cetera. And that’s why today we’re very proud to announce that we’re introducing JFrog Advanced Security as an additional product in our JFrog platform, which works in tandem with Artifactory and Xray.

We’re positioning JFrog Xray as a one stop shop basically for software lifecycle management. JFrog Xray was until now mostly focused on software composition analysis, but now with advanced security, we’re going holistic. We’re actually merging multiple security tools into one tool which would solve the problem holistically. We want to eliminate security blind spots in multiple categories. So if we’re focused on software composition analysis and CVEs, now we also want to solve exposed secrets. Any misconfigurations, misuses of popular third party libraries, scanning infrastructure as code and even more, it’s very important to have all these things in one platform.

It works beautifully with Jfrog Artifactory and of course with Xray. Every artifact that you upload can be scanned by advanced security. You can have actions from advanced security that, for example, alert you or deny downloading certain artifacts from Artifactory. So everything is seamless, both in the detection and the actions that you can take, which is very important for us for the CICD pipeline.

Everything here that we’re going to show is research powered. For example, our context to where CVE reports can severely reduce the amount of false positives you get from CVEs. We’re going to publish a research that we saw where in common use cases it reduced more than 75% of false positives on CVEs just because you have that context to aware reporting and not just reporting a CVE because the package is installed. And throughout the advanced security, it’s very important for us to not just show you the issues but also show you how to solve the issues. So it’s not just a detection platform, it’s definitely a remediation platform as well.

These are the features that we’re rolling out with advanced security. We’ll explain very shortly about each and every one of them, but our main highlight today is the demo where we’ll really dive into each feature. Of course, feel free to ask questions about each and every one of those and we’ll be happy to elaborate on them. So with contextual analysis, we’re scanning containers. We’re trying to find open source software vulnerabilities, CVEs, et cetera. But instead of just reporting them, whether the packages are present in the artifact that you’re scanning, we’re also looking at if the vulnerability is actually exploitable in the context of the image that you’re scanning.

So it could be that there’s a vulnerability in a library, but it’s only exploitable if you’re using a specific API. Contextual analysis will look if you’re using that API, whether you’re passing arguments that make the exploitation vulnerable, and basically everything around in the configuration and the code that determines whether the CVE is actually exploitable or whether it’s just a false positive.

With secrets detection, we’re detecting any secrets that are left exposed in the container, the containers that are stored in Artifactory. We want to prevent accidental leaks of internal tokens, credentials, private keys, et cetera. We’ve also, as part of the development of this feature, made a very extensive research and found that this is a very much a real world problem. We found thousands of active access tokens, which we’ve later of course disclosed to have these keys revoked. Both of the next features are related to each other, the application libraries misuse, and the services configuration security.

Basically what we are able to detect with these features is whether common open source libraries and services are used or configured insecurely, which may lead to attacks. For example, if you’re using a crypto library but you’re using a non-secure API or passing bad arguments, or you’re running some services with a open admin port or as route, which you shouldn’t do, and it leads to a security impact. We detect it and we show you how to solve it.

Last, but not least, we have infrastructure is code security analysis. So basically every IAC file that’s stored in JFrog Artifactory, which currently supports terraform, we go over that module and JFrog advanced security automatically finds security issues in the configuration of that module, how the IAC module is deployed. And for each of issues, of course we show you the issue where it is in the Terraform module and how to solve it in a copy based manner, which is very important.

Of course, all of these build on Xray’s great software composition analysis capabilities. We’re retaining our SBOM vulnerability finding licenses and policy violation on licenses and operational risk, which is fueled by package metadata, like showing which packages maybe are not preferred to use because of their commits and health, et cetera. Also with malicious packages, which is a fairly new feature that is of course we’re retaining and upgrading with this release, which relies on our curated database, contains more than 17,000 malicious packages right now from NPM and PyPi, which have the most prevalent amount of malware currently, and allows you to detect whether malicious packages are in your direct or indirect dependencies very easily.

All right, so let’s see how all of these works in tandem with the JFrog platform and let’s see these features in runtime. All right, so now I’m switched to the JFrog platform. We have a new UI here, the scans list, which instead of going through Artifactory, you can go directly through a Xray and see all of the scanned artifacts. Going to go into docker type artifact, sorry, docker type repository. And I’m going to go into just basically the latest artifact and I’m going to start with vulnerabilities view.

So what’s great with our vulnerability reporting, first of all is the contextual analysis that you can see here and our JFrog research extended information, anything that has green beaker icon, you can see there’s quite a lot. These are vulnerabilities that contain our curated research data. So let’s jump into one of them. For example, so this is a YAML vulnerability.

The issue is a very high severity issue code injection. So leads to remote code execution. Basically, if you’re using YAML and you’re calling a specific API and passing user input to it, then you’re susceptible to remote code execution. So let’s see how this vulnerability would look when you look at it through NVD. So this is the public data. It’s not formatted, you can see it doesn’t contain that information, but when you look at it with the extended JFrog research information, first of all, you get much more details. You get code snippets of when this vulnerability is actually exploitable. You get a remediation either through configuration or code changes, how we can fix this vulnerability without having to upgrade to the fixed version. Sometimes you can’t upgrade or temporarily you can’t upgrade. So we supply a copy paste solution and how to solve the issue without upgrading the version.

And we give our own JFrog severity. Usually the severity is lower than the public, for example, NVD severity, which tends to be very high. So usually our severity is lower, but of course it depends on the vulnerability. Sometimes it’s even higher than NVD or other publications such as Red Hat, et cetera. But very importantly, when we give a severity, we always tell you why we gave that severity. So for example, in this case, it’s a critical severity because it leads to very severe impact. And the prerequisites for exploiting these issues are actually very common. It’s very common to pass actually untrusted YAML data. So that’s why it’s a critical severity issue.

Here, it’s very important to see the contextual analysis. So this actually shows whether this scans the first party vendor code in the image and shows whether the vulnerability is actually exploitable in this image.

So what we have in the contextual analysis is first of all, for each and every one of these, we tell you what the scanner actually looks for. So for example, here the scanner checks whether a vulnerable function, full load, it’s called, or whether a vulnerable class full loader is initiated and untrusted input is sent to it. So only if these conditions apply, then the vulnerability will be marked as applicable or non-applicable. In this case, it’s applicable. We show you the file path where it happens and the code line or lines where this issue appears.

We can also see this in the ID plugin. So this is part of our shift left efforts. We have the same capabilities both in as part as the JFrog platform and integrated in the JFrog’s ID plugin. For example here as you write the code, if you’re using the vulnerable function, and it’s a vulnerable version of this dependency, this is different CVE, but it shows you exactly where you are using the vulnerable functions and what’s the description of the vulnerability itself. So this can help you manage and not be exposed to vulnerabilities as you write the code.

All right, so this is an example of applicable vulnerability, but we can also see non-applicable vulnerability here. In this case, you also have all of the research data, but in the contextual analysis, we tell you that for example, in this case, it’s not applicable because a vulnerable function is never called with external input. And again, we always tell you exactly what the scanner does, what it looks for, so it will be 100% clear why it’s said whether it’s applicable or not.

This also integrates into our policy engine. So for example, you can have a policy that says, “Okay, I want to alert on every critical vulnerability or high severity vulnerability or via CVEs score, but actually if the vulnerability is not applicable, then I don’t want to be alerted on it.” So this actually allows you to get much less alerts on things that cannot exploit you right now. So actually in the recent research that we did on the top 200 containers in Docker Hub, we got a 78% reduction in false positive CVEs. So this feature can actually save that much time of engineering work, and we’re very proud to roll it out as part of advanced security.

All right, so these are the new things in the vulnerabilities view and jumping to malicious packages. Like I said, this is part of our software composition analysis. Our main differentiator here is the amount of data that we have on the packages and the amount of packages that we curate. It’s something that the research team does on it on its own. So we have our own custom database of malicious packages, very high rate of true positives because the packages our matched uniquely, so there isn’t any false positives in disregard and just helps to make sure that you’re not using any malicious package either directly or indirectly. Moving forward to the secrets. So for example, let’s go into one of the findings here.

So in this finding, we can see that there was a configuration file left on the image and it had an AWS access ID, or access key. Currently on general availability, we support more than 250 credential types, which were very highly curated to remove any false positives patterns. And really for each pattern type, we have a specific pattern or token, so no generic findings, which really helped us reduce the amount of false positive. This was tested, again, 8 million artifacts actually. Also, we’re going to publish research on our blog, which helps find thousands of active tokens with this feature. So very high level of testing. And as always, we show you how to revoke, for example, if it’s an AWS key, how to revoke the key so that you can remain safe after the key is found.

Moving on to services, as I mentioned here, X-ray, detect misconfigurations and misuses of popular third party services, demons, anything that could lead to security issues. So let’s look at one of the findings where the [inaudible 00:19:02] proxy is used in the image, but the admin interface is externally exposed. So again, as you can see here, we got the evidence of the findings, exact file path, the line of the evidence, both number and content. And very importantly, we show you in plain English what this issue is all about, a detailed description, what kind of impact you’re liable to if you’re not fixing this issue. And very importantly, just a copy paste solution like, “Go to this file, remove the key or copy, paste these lines and you’ll be good.” It’s very important to us to show how to solve the issue and not just show that there’s an issue and there’s a copy paste solution for 100% of the issues that JFrog Xray detects.

In the applications view, we can see another example. Let’s look at a code example this time as opposed to a configuration example. So here, JFrog Xray did static analysis on Python code and found that it’s trying to get an HTTPS URL, but it’s disabling SSL verification. And of course that means that you may be susceptible to SSL man in the middle attack, and this is detailed here along with the exact impact. So even if you’re not familiar with these kinds of attacks, this is all detailed here, exactly what it causes and what’s the impact. And as we shown previously copy paste solution to solve this issue.

So last but not least, let’s look at the infrastructure is code scanning. Here we have a scanning of multiple Terraform modules. So let’s look at one of the findings. For example, we can see that one of the modules contained a deployment of AWS, API gateway. And here in the module, it was found that authorization was disabled for this API gateway method for several API gateway methods. Again, we show you exactly what that means. What happens in this case where public attackers can probably abuse this API, try to hack it, try to brute force it, which wouldn’t happen if this API had authorization. And for each and every one of these, we show how to solve it in both a vulnerable example and a secure example of this specific feature.

All right, so we can get back to the slides. So very excited to roll out this feature JFrog Advanced Security. I’m very happy to announce that you can try it out today for free. Just go to this URL, jfrog.com/startfree. And you’ll be able to experience this feature all on your own, upload your own images and see what kind of vulnerabilities are found there and see the improvement in the false positive rate, see all the secrets that may be leaking, and all of our new and exciting features. So very much excited to show this and feel free to go over start a free trial, and I’ll be happy to answer any questions from the chat box. Let’s see if we have anything, or feel free to write any questions right now. I’ll be happy to clarify about any of these features or answer any related questions of that. So thank you very much and let’s see those questions.

Thank you Shachar so much for your presentation and demo. Today we have our JFrog Xray team here to answer your questions. As a friendly reminder, please add your questions into the Q&A section so we can address them. Let’s get started. What are the pricing options for advanced security?

So that’s a very good question. So the first thing that I’m going to mention here is that what we are launching JFrog Advanced Security is only for our task customers for now. Our Salesforce customers will be able to get this capability in the future. But for now, if you want details about what are the pricing options for advanced security, the best resource is to basically go to jfrog.com/pricing, and you should be able to get all the information from that.

Great, thank you. Next question, does container contextual analysis save my developers remediation time?

Absolutely, yes. Lot of times what happens is many of the SDA tools or the softer composition analysis tools look at the version number and identify all the vulnerabilities associated with that. However, what Xray does is it takes the vulnerability detection and it actually tries to identify if it is really vulnerable, if your application is really vulnerable, and then it’ll allow you to prioritize which are the ones that are actually applicable in your case, how the way that you are using the open source libraries and you’ll be able to decide which ones to fix and which one not to, or defer. So based on some stats that we have read, 75% of the application Wonder is basically may not even be exportable. So it actually helps the developers to figure out and prioritize which wonder data should be fixing.

Wow, that’s great to know. Does Xray scan container images for known vulnerabilities like an SDA tool, or do I need to get advanced security to do that?

So Xray is and enhanced SDA tool or software composition analysis tool. So what we do today is obviously as a software composition and analysis tool, we are scanning for open source vulnerabilities, open source license risk, operational risk associated with using open source as well. However, with the advanced security, what we are allowing you to do is not only secure development, we want to make sure that you are deploying the application as well. Hence, what XR does today with our advance security capabilities, much more than any SDA tool can do.

Great. Do you support other container and IEC technologies with advanced security?

It’s a very good question. So we are starting off with Docker containers and in terms of our IAC technology, Terraform, especially with providers, AWS, Azure and GCP. So that pretty much covers majority of what our customers are using today in their technology stack. We do plan on expanding it to, for example, AWS cloud formation or as a resource manager in the future, but for now it’s Terraform with AWS, Azure and GCP providers.

What package types support password detection?

So the secret scanning capability, I’m assuming that’s what the question is about. The secret scanning capability we have in the product today is for Docker containers. So as we all know, we all make mistakes and developers sometimes leave SSH keys, API keys, and so on in Docker images and we want to make sure that if any of your code or files have any secret information, we want to flag those.

How do you find dependencies not listed in the SBOM?

Oh, well that’s a very good question. So JFrog just does not depend only on the SBOM to identify other dependencies. Yes, it does use the building from Artifactory and the metadata that is associated with the artifacts. However, based on the packages that we scan, it can automatically identify the direct and indirect dependencies and scan them. You can look it up on our documentation as well. If it’s just a Google for Xray dependency scan, you can identify how actually Xray’s scans dependencies that may or may not be identified by SBOM.

Great. Is JFrog Advance Security available in which version of Artifactory?

The base version is 7.39.4. So anything about 7.39.4, you should be able to enable these capabilities.

Thank you. Does it use self-reported package version number to ID vulnerabilities or does it use BD technology and support scanning binaries directly?

So Xray uses a variety of techniques to identify a given package. This could just be versions, fuzzy hash, check sums, [inaudible 00:28:43] direct and indirect dependencies and so on. So there are a lot of techniques Xray uses internally to identify the package and the version number associated with the package.

Do you have more information about integration of Artifactory MS code?

The simplest thing that you can do is basically look up JFrog ID integrations and you will see the documentation and all the information about how to enable. And also there are YouTube videos as well that you can look up on how to install the extensions, how to use them and so on. So I would highly recommend you to just go to JFrog documentation page and search for like visual studio extension or IDE extensions.

Does the scanner support RAW Linux image scanning, binary file scanning, and zip package scanning?

The short answer is yes. However, do keep in mind that we are already able to extract most of the archive types, but if you are thinking about RAW Linux image in IMG format, we don’t support that. We don’t support like ISO format for example. However, there is a exhaustive list of packages that Xray supports. You can just look it up on the Jrog Xray documentation. There are more than 22 or 25 packages that we support today and there’s a big list of those that Xray can scan.

Thank you. Could you share advanced security rollout dates to Artifactory cloud?

So as of October 18th, the advanced security is a generally available feature. It’s currently being rolled out to our customers. Please do note that you do require a subscription. Just because you get [inaudible 00:30:48] of JFrog Xray does not mean that you will be able to see these capabilities. You do need a subscription to enable these capabilities in the product.

Great. What’s the difference between configuration issues found in services versus applications?

That’s a very good question. So service exposures are mainly configuration scans for most popular open source projects that typically used in microservice architecture. For example, Envoy Proxy, etcd, Prometheus, which is used for monitoring. So these are the common applications. We look at their configurations to see if you know are haven’t configured according to the best practices for these open source services, we’ll be able to flag those. So that is service exposures.

On the application exposure site, we are basically looking at how you are using open source libraries in your code, in your first party code. For example, let’s say you have a Python code and somebody is opening a shell in the Python code for whatever reason, we’ll flag that and say, “Hey, this is against the best practice, and we’ll give you some examples on how to fix those itself.

Do you categorize JFrog Xray as an SCA or SaaS tool?

Excuse me. Xray is definitely not a SaaS tool, but we do have several SaaS capabilities. For example, we do advocate for secure coding practices and the if we see any code that is against best practices, we’ll actually flag them as well. So Xray does much more than what a typical SaaS tool can do. However, we typically consider Xray as a software composition analysis tool. It is used to detect 100 days, license risks, and operational risk of using open source software. As well as with the advanced security features, we are trying to help developers to build and deploy secure applications as well.

Could you explain the Terraform repository scanning in more detail?

So I think the best thing that I can suggest here is to just look at our documentation and you can just look up on our websites about exposure scanning categories or you can just look up our release notes that has a lot of good amount of documentation around how Xray can actually scan Terraform state files and flag issues with the way that you are defining infrastructure in your Terraform files.

Does advanced security come with the next XRay release?

So again, we just have to be very clear that advanced security features are additional subscription. So just because you get to the latest version of Xray does not mean that you will be able to use all the capabilities of this new release. You still need to request a license if you want to be able to utilize the advanced security features.

Thank you. What sort of trajectory do you see in terms of intensity of attacks against MSSPs going into 2023?

GFR research team actually has a lot of good content on this, so I would refer you to research.JFrog.com. Also, another resource that I would point you to is Forester Research has done a very good analysis on this and they have a report called the State of Application Security for 2022. You might want to just look it up and it does give you a lot of data on the trajectory of attacks and things like that.

How can we implement a secure shift left process to mitigate malicious packages that don’t get used in production like NPM, iBUY, et cetera, without using Gates to scan those dependencies?

Without using Gates to scan those dependencies. So I think obviously JFrog Xray today already detects malicious packages and we are able to fail builds and take action, things like that as part of the Xray scan. So without really scanning, I’m really not sure how you’ll be able to detect malicious packages, but if you are using Xray, we are already helping you detect these.

How can JFrog monitor dependencies not listed in the SBOM?

I think this is a similar question, Rebecca, that we had before. So Xray not only depends on SBOM to identify the dependencies, it does look into build-in form from Artifactory, the metadata associated with artifacts. It can automatically identify and the direct and indirect dependencies associated with each component. The best thing that I can tell here is just look up how Xray does dependency scan. So if you just go to JFrog documentation site and search for dependency scan, you’ll get more information on how we are able to identify things that may or may not be listed in this one.

Is JFrog Advanced Security included in plugins, for instance, for Jenkins or VS code?

So to start with, we are implementing the contextual analysis capability in the id. So if you’re using an ID plugin, you define a dependency and the contextual analysis will identify the vulnerability associated with the dependency as you are coding. And it’ll tell you this is a CV that is associated with this particular component you just defined. Not only that, it’ll tell you the way you are using, or if you are using a function or method that is impacted, it’ll say, “Hey, this is not the way to use it and you know, will make it vulnerable if you use it this way.” So we do have integration for contextual analysis. For rest of the capabilities, for IAC scanning as part of the ID plugin will come in the future.

Thank you for our last question today. Do the security updates expand your reach in terms of which customers will be attracted to this offering or should they be viewed as providing more depth of coverage to the existing base?

I think we are targeting these capabilities for three personas, right? And number one, obviously the developer. We are being busy putting all the responsibilities to developers like you have. Infrastructure has code now. Developers are defining the code as well. So we are targeting developers. We are also targeting security operations as well. So the security teams now are able to look at the infrastructure defined by a developer and they can say, “Hey, you are exposing these [inaudible 00:38:22] to the outside world, or these internal services are being exposed to the outside world,” and things like that. And so we are targeting developers, we are targeting security teams, we are targeting operations or DevOps teams as well to make sure that a application is securely developed, is securely deployed and also operationally secure.

Great. Well thank you so much, Sharan. Thank you, Shachar and the Xray security team. We’re very excited to have presented these new capabilities to all of you who have attended. Please note we have upcoming demos if you wanted to join. And if you wanted to speak to a JFrog account executive, feel free to book a demo at jfrog.com/advance-security. Thank you all, Have a great day.