Name: Introducing WizOS: Making Secured Container Images Easy to Adopt
Uploaded: 2025-09-30T17:15:17.071Z
Duration: 39 min 52 s
Description: Introducing WizOS: Making Secured Container Images Easy to Adopt

Transcript for "Introducing WizOS: Making Secured Container Images Easy to Adopt": Hi, everyone. My name is Allison Jackson, and I'm really excited to chat with you today about Wiz OS, our new secured container images offering at Wiz. And, just a reminder during this webinar, you know, this is for you. Please feel free to chat with us, in the chat in the webinar. Also, ask questions in the q and a. We'll do our best to respond, both during the webinar and also, live at the end. So just a reminder, I'm Allison Jackson, director of product marketing at Wiz. And with me, I also have Daniel Velikanski, product manager at Wiz, and we are the Wiz OS team. And I'm really excited to chat with you about this today because I think this is something that, you know, a lot of folks in security, can can use and can relate to, as well as folks on the engineering side. So, you know, first, why did we build this? You know, why did we see this as a really important opportunity? Why do we think that the industry needs secured container images? And what it comes down to is that modern applications are built on untrusted and sometimes insecure foundations. When you think about what actually goes into a container, a lot of what's in there, so your container images, which are coming from Docker, from other open registries, and also your application dependencies are coming from open repositories, open libraries that don't have security or maintenance guarantees. And, you know, what that really leads to is inherited risk in your apps. You're getting inherited vulnerabilities coming from all of these third party components, and container images really are a major culprit for this. As I'm sure many of you have dealt with, you get these container images that contain a bunch of packages, and many of them aren't even necessary runtime in the running application, things like testing kits, other build tools. And what that does really is, you know, bloat your container image, ultimately bloat your application that's in runtime and expand your attack surface. And the problem with this is that all these vulnerabilities cause pain across your teams. You know, on the security side, it's really dealing with this vulnerability noise. All these vulnerabilities from container images that are often recurring if you're using the same image. You don't really know how to prioritize them. It's in application code that your development teams didn't write. Then on the DevOps and platform engineering side, it's really this endless cycle of patching. Like, how do we find and fix these critical vulnerabilities that are coming from the image layer? How do we, you know, update this? It can really be a lot of work, as we've heard from many of our customers. And then on the application developer side as well, you know, a lot of what teams have to deal with, there are these broken builds or slower releases as a result of these bloated images, as a result of critical vulnerabilities, you know, slowing down their CICD pipeline. So the result really is that, you know, we're using all of this, you know, know, open software container images, things off the shelf that are meant to make us go faster, but in many ways, end up slowing teams down. And this is why we were, you know, really excited to, you know, think about this problem in a new way. And I think that one thing with Wiz is, you know, we're a product that already has visibility across the entire container life cycle. So, from code all the way up through run time, because of the way that we're deployed, both we're via our agentless connectors as well as with the Wiz sensor, we see everything that goes on with containers. We have full visibility into all containers, into container images, into all of the layers in those container images, and we're scanning them at multiple stages. And this gave us really kind of unique visibility into the pain that, you know, a lot of folks are feeling, with these container image vulnerabilities. And our research team was actually able to go and, you know, take a look at the data and discover that, you know, across, you know, many of our customers, we're seeing that 39% of high and critical vulnerability findings on containers are coming from that base image layer. So and we saw this as a big problem and, you know, essentially, by enabling folks to start secure, you know, with a new foundation, this would be a huge opportunity to reduce the overall number of vulnerabilities you're seeing on containers in your environment. So that led us to build Wiz OS, which is, you know, the focus of the conversation here today, and something that we're really excited about. Wiz OS are is a repository of secured container images. Every Wiz OS image is built from source and maintained by Wiz at near zero CVEs. So, really reimagining how we think about building containers starting with a secure image. So, you know, not just scanning and discovering vulnerabilities that you have to fix layer later, but how can we actually start secure by default, with an image that is then, also designed to help you stay secure, because we're maintaining it under SLA at near zero CVEs. We also include a secure package repository, with all these images with dependencies that have been vetted by Wiz so that as you customize on top of your your containers, and build out those images more fully, you can also stay secure, and know that you're not, sacrificing any of the security from there. And then lastly, you know, because we are a complete container security platform, we also have all the application code that's written by your development team. And, you know, this is something that we're not starting site secured by default necessarily because you're writing it. But because we have WISCO, we're able to scan at multiple stages across the life cycle, and really just piece together a full container security story so that every component that you're using has been tested, checked, verified, and is secure. So let's talk a little bit more about the images themselves. These images are designed to really, you know, stop this cycle of vulnerabilities and endless patching that we talked about. You know, I already mentioned that these are built from source by Wiz, in a custom secured build pipeline. We wanna make sure that, you know, not only are these images low and vulnerabilities near zero, but also that you can trust and verify where they came from. So these are built by us. We include SBOMs and verifiable provenance with every release, and we are building the images daily. Our SLAs for CVE remediation are seven days for criticals, fourteen days for high and medium. And, you know, this is a really important piece of this, that I think truly differentiates these secured images from other minimal images that you can use as having this maintenance guarantee, this guarantee around CVE reduction that helps you stay secure and really just taking the burden of patching off of your teams, and that's something that Wiz now handles. We also really wanted these images to be easy for developers to use and adopt. So we know that rolling out new container images, secure container images is not something that only the security team works on. It's really a shared responsibility between the teams that own the infrastructure, between developers, and also between the security team that kind of cares about that outcome. So we wanted to make it really, really easy for developers to use. So when we constructed these images, we built them with GLIBC for broader compatibility. So it's really easy to port existing images over, and really easy to customize on top of it. And our images come with a package manager and shell included so that they're, you know, essentially batteries included, ready to use right away. And what that does is, you know, enable developers to get started immediately, and you can always remove, very easily the package manager and shell, with a simple script before deploying to production to keep that attack surface small. We also offer FIPS compliant and STIG hardened versions of these images. STIG is coming soon. FIPS is available today, to help any organizations that are working on FedRAMP, or have other compliance goals that they're working to accelerate. So now that I've talked a little bit about the images, you know, I wanna talk about, you know, what really makes, offering these as part of Wiz unique. And I think that once you get the concept of these images and, you know, migrating to images that will bring you to near zero vulnerabilities is is something that, you know, you're excited about. The next question, the natural question is, like, how do we actually start this? You know? You probably aren't starting from scratch today. You already have lots of containers running in your cloud. So, essentially, you know, this is a a project where you're gonna have to figure out, how can I migrate to these new security images? How can I encourage my development teams to adopt them? And you need to be able to answer questions like, what are the riskiest images that are in my environment today? Are these images gonna be compatible with my stack? And which images can I swap out for a new secured image? How can I actually scope and prioritize this migration? And then on the developer side too, it's like, are you gonna have to change any workflows? Will it be easy to customize the images? And with Wiz, you know, our superpower really is the visibility that we have across the entire container life cycle. So, really, we wanted to leverage the power of our platform to help make it really easy to operationalize these secured images at scale. And, right after this, Daniel is going to show you a demo so you can really see this, and make it real. But I think, you know, when we think about how you can actually operationalize these secured images, it first starts with visibility so that you can understand your existing container image inventory, understand the risk posture of those images, and really assess where your risks are. It then moves towards mitigating those risks. So how can you actually prioritize the images that you need to migrate first to get that vulnerability reduction? And one thing that Wiz OS does, which is really cool, is actually within your container image inventory, shows you all the swap opportunities where you could swap an existing image for a Wiz OS image, and replace those images with a secured image. And you actually can see, you know, how many vulnerabilities you would reduce with each replacement opportunity. We also really wanna empower developers to start secure, to educate developers, and to make it easy for them to choose these secure images when they're actually building. So one thing that we are building with Wiz OS is, one click image swaps right in the IDE and vulnerability context right in the IDE and in full requests for developers so that it's actually, you know, the easier thing to do to start secure with the Wiz OS image. And then lastly, enabling teams to really enforce guardrails. So, you know, once you've looked across your image landscape, started swapping the riskiest images, really encourage developers to start adopting these, you can then enforce guardrails in the CICD and with the Wiz admissions controller to ensure that only, these secured and compliant images make it to production, that you're not releasing new risky images into your environment. So really completing this life cycle from, you know, the initial migration of the riskiest images to empowering teams to build on the new images all the way through to, you know, really enforcing that you're using the most secure and trusted components, in your applications and in your containers. So with that, I'm really excited to hand it over to Daniel, to do a demo of Wiz OS for you guys. Thank you, Allison. Let me quickly share the screen. Okay. So this is the Wiz portal when you can see everything, which relates to your current risk and your environment. I mean, from toxic combination to specific issues that we identify and also vulnerabilities that we've already provide today as a full platform for your, cloud security. Now what we are going to focus today is about the new, two new pages that is related for the new Wiz asset product. I'm starting with the container image new page that we released and rebranded actually last month, which give you a full visibility about your container space in your environment. It gave you it gave you a a full visibility about images which is built on boot, store, deploy cloud in runtime. And, again, as Allison mentioned, this will give you a full visibility about what happens in your environment, whether it's in AWS or GCP or even Azure or other cloud providers. Now with this kind of visibility, now that we not only scan for visibility, but we also scan for risk, we can understand what is the risk or maybe the risk of the of the specific container or specific application across all my environment. Now how Wiz OS is actually relevant to this kind of of visibility? That is actually the start of how Wiz can provide you with a more actionable, actionability to actually mitigate and start using resources in your environment. We are not only supplying you with a secured image catalog. We're supplying you with a new different solution with a whole solution for container space from build to run time. So by that, I'm starting with going to a filter and filtering, for example, for which image available. This filter will give me all the images that could be transitioned to with a low effort with a low effort from the current solution. And for example, we can go to a specific image. We can see that this image comes from a specific solution, comes with also a solution that have an issue with 78 critical vulnerabilities. Now I can click on that to see how visibility about the current insight of the vulnerabilities, the OS, even the code to cloud pipeline when I set a code to a a code product and connect my code reporter to my Wiz. And this is again telling the story of how we see the bot. She's not only saying the visibility of what's running in your cloud. We know to trace that. But, again, how it's interesting to resolve is, again, the insight. When I know the vulnerability, I actually can go to the vulnerability side and see image vulnerabilities by layer. Understanding if the vulnerabilities come from the base image, maybe it comes from a middle middle layer such as some application or maybe this is a golden image that I've compiled in my organization. And then I have the actual application, whether it's copying some requirements or running some Python script. I can see a whole visibility on the vulnerability risk. Now further than that, we're actually going to raise raise insight when resource replaceable image available. For example, in this case, we know that the resource image will solve more than 72 critical vulnerabilities and also for 145 high vulnerabilities. And, again, this is all possible because the full visibility and the access we have in with also in the cloud, but also in the code, that we scan the disk itself for for different technology, whether it's application that is running or some base image, and that we know even to pause the image itself and scan it layer by layer. With that, you achieve a full visibility. You understand what you should tackle first because maybe this specific application is the most well which is spread across all your environment where you also understand how much it is easy maybe to actually mitigate. When we understand that we're pulling from Docker Hub, Python, the bullseye option, and we don't do anything special instead of just running my application, this is exactly the resource have an image available inside. Now further than that, we are not only the visibility scroll, but we also provide it with a whole security image catalog that we keep enhancing. We actually took a different approach in this model, and we primarily focused at fault in the when we launched the private preview, a quarter ago on the base images, on Python and on OpenJDK, and node and many more than that. But we're expanding more and more tiers of the case where the customer needs, whether it's nginx, all specific Kubernetes native application that we currently explore. But now I didn't stop on this specific page. This page is under inventory, the secured image catalog, but this is not your simple catalog page of secured images. You actually can understand what you should tackle falls as you've seen in the container image, but in more organized way towards the specific image. For example, in this specific case, I can say even with grouping to a specific project, whether I want to group on specific, specific application that is relevant to one department or the second, I can see the risk reduction and the swap opportunities of taking such as image into action. So for example, I can see that the node image actually has eight instance for swap opportunities and 314 critical vulnerability and risk reduction opportunity. So what I can do is go to the specific one and search for the swap opportunity, whether I want to go to a specific, specific image which already contained the vulnerability. And this will comes together with what we've seen in the container image page and see that we have the with the house and image available, but also more useful on how to use the image itself with the specific images that we provide today. We call contains also an s bone, but also a really a really straightforward package list with a specific license that comes with a specific image. For us on the telephone compliance way, we want to use a specific node or maybe engine an engine installation. Following that, you, of course, can even see an example on how you can use the, Node. Js image, how we recommend you to authenticate with the fact that your product so we can get a better control on what you allow your developers to actually, to actually install over it and not using only open source package repository and, of course, running your application and your specific program. Following than that, we also can provide any feedback or request any email that is relevant for your application, whether it's a specific image, technology, use case, or compliance needed, whether it's FIPS hosting. As we look forward, just a note to the future, this page is going to be even will be even better if understanding current risk and value. It will attract value over time when we see in actively what happens in your cloud and how the migration actually help you in that case, and also more integration to with our cloud product, but even even a specific tool that will help you migrate current Dockerfile without just insight, but more on what you actually should do in the in the specific space. Now with all that, if you're a Wiz customer or a prospect, all you need to do is to go to the settings and then to the go to the preview habit migration. Once you're there, you need to filter for Windows OS. And with a single button, you can enable the public preview of our new product. With that, passing to you again, Allison. Thanks, Daniel. And let me just share my screen again with you all. Great. So really excited, for the the next segment. Excited to talk a little bit about how we actually use Wiz OS at Wiz. So we are dogfooding this product. And here to talk a little bit more about that is John Elliott, who is our senior manager of product security at Wiz, and has a ton of experience, working with these WizOS images and rolling them out and is here to talk a little bit about that journey, with Daniel. Hi there. How's it going, John? Hi, John. John Elliott, senior, manager of product security here at Wiz. Our team is, responsible for security of the Wiz production environment and the Wiz product itself. We use Wiz as our primary security tool to to monitor Wiz, and we call that Wiz for Wiz. One of our main responsibilities on this team is vulnerability management in production, and we run a containerized microservices on managed Kubernetes, on across various cloud providers, AWS, GCP, Azure, AKS, EKS, and GKE. And, therefore, container image and supply chain security are high priorities for us, and it's something we spend a lot of time on. And so we've been running, with OS, like, in our production environment since, probably earlier this year. Mhmm. I think what's interesting to understand in this context is the way that we try to create a new product, which actually still can protect our own cloud environment and across all products. I think we had a challenge just also not about our only commercial, but also on the federal development. So I'm just wondering, we started the the BreezeOS deployment in Will a few months ago. I'm wondering how was your team managing the container image security, and what were some of the pain points before the Wiz OS, and how this actually solved this specific this specific pain point? Sure. Sure. So, in our prior to using Wiz OS, we sort of used a a variety of, container images that were sort of general purpose, like Ubuntu based, Debian based images, Alpine based. And, also, some of these are just images that are, available from the different managed Kubernetes providers that you can easily just sort of pull in your environment. And being that they're more general purpose, they contain everything you need because it's easier to get your service up and running. But the downside to that is that they also contain a lot of things that you don't need, a lot of packages and libraries and things that are irrelevant. As you know, like, on the vulnerability management side, the more packages and libraries you have and the more, surface area you have for vulnerabilities. So, larger images just mean larger attack services and more, CVEs for the security team to triage and manage and and have to work with engineering to remediate. So that was, one one issue. Also, just having to pull from a variety of registries. So it's sort of inconsistency with, like, different image sources, and we wanna be able to control and restrict what registries we're pulling images from. So, you know, the more sources, the more work that is to do as well. In our, CICD pipelines, we have policies that, you know, restrict looking you know, go through the pipeline based on CVEs and the images. So the more CVEs, the more broken builds because we stop stop pipelines when, you know, critical CVE is detected, for example, where a certain number of high CVEs is detected. So there was a higher number of bill broken bills. And then, like you mentioned, FedRAMP. So on the FedRAMP side, being able to we have to run FIPS validated, container images. The more variety of images there are, then the harder it is to sort of determine what the FIPS path is gonna be for those images. Mhmm. That sounds great. I'm wondering now when we decided to go to actually start the migration, how it actually went? It means that how you plan we have a large environment. We're talking we even don't talk about different realm. Even though cloud environment serves a lot of customers and a lot of services and different ones, how we prioritize which one we should do and how much it even do? Yeah. So so, we wanted to, obviously, prioritize, you know, based on risk, where possible, but we also had to sort of balance that with, the services that, we don't wanna, you know, break anything in production, so we have to go after sort of lower risk services that may have less impact if something were to go wrong during the migration. So using Wiz, we were able to sort of see, you know, what like you were showing earlier where we're able to see, here's the current images in the environment. This is their composition, the number of CVEs exist in them, and then, will be the level of effort to to migrate those to Wizz OS. So sort of identifying those first, and then, development and engineering teams, would do testing to sort of see, you know, if it's compatible and, like, either local or test environment, staging environments. And then depending on that, just sort of roll it out into production using kind of a phased approach gradually, and then kinda start trying to build momentum and kinda confidence that way and expand it out to to more of the back end services. Then we also prioritize what you know, these kind of Wiz provides various customer basing images for certain products, like the Wiz admission controller, the Wiz broker. We wanted to get those on the Wiz as soon as possible just so that we could have the near zero, CVE, numbers in those images as well. Mhmm. I wonder you mentioned that you work also with development to actually validate and maybe not test the new images. You mean that the the migration process was a bidirection. The security engineer took it as a program, but the developer staff to to implement that in the specific services. So how it went? The so the security was sort of identified. You know, these are the, you know, images we'd like to get migrated. And in some cases, you know, it was very little testing that needed to take place or depending on, what the existing service was running on as its base image. It may have required more. So for example, certain images that were running on Alpine that used Mucil, Wiz is glibc based, so there are certain packages that maybe they needed to request from the Wiz, development team to be built and made available in the registry, that we're g with c based. And, testing process would you know, whether, you know, developers would do it locally or just in our, test environments, in our staging environments to just sort of see if there was any changes to things like performance or, any just unexpected anomalies or anything like that. We would sort of monitor that, and if everything looks good, just kinda move forward and deploy it to production. Mhmm. And if we're talking about dynamic, what do we start with the the the specific the junior for placing to with OS, how much it took us for the most of the services? We we have a lot of services. We have a lot we have a lot of, you know, containerized microservices, but they're mostly go based services. They're generally the same. But, I wouldn't I would say that, maybe two to three months, to get everything. And that that that sort of involved, you know, the initial phase of, like, you know, being careful and going slower, and then once we kind of built on them, it sort of sped up. But then we were sort of monitoring it along the way to, you know, using Wiz because Wiz OS, appears as a a technology on the security graph, so we could sort of see the the ratio of, services have been converted versus things that need to be, you know, still waiting to be converted, and, sort of accelerated closer to the end. It was it was easier to you know, as we were going through it, just sort of move things over faster once, Teams, I think, got the hang of it. Mhmm. So you actually mentioned also that you use the security graph to monitor the adoption and looking for images that weren't actually, based yet on resource for finding yet if in new images that we should consider. I wonder, after you actually tracked the the vulnerability, maybe even did we see a vulnerability reduction? What is the impact when we actually transitioned to Wiz OS? Yeah. Yeah. I mean, we definitely, saw a huge, you know, reduction in vulnerabilities, especially, obviously, coming from base images. And, you know, the we're able to see, like, historical data from, like, vulnerability reporting that we run, you know, using Wiz OS. And then there's various vulnerability, management dashboards in Wiz OS that sort of tells the total count of, CVEs and base images, seeing those numbers go down. And then also, it had a big impact as well in our federal environment where we have to do what they call, ConMon, like monthly, plan vulnerability reporting. And the prior prior to moving with OS, we had a a, you know, variety of container images that would, appear with CVEs as line items in our POAM, and they have to be closed out based on federal, SLAs. And then you've got to once we're migrating to was the last the number of container image vulnerabilities in that month report was very low, in comparison. We've had we're kind of primarily focused on virtual machine image vulnerabilities now, where you don't really have really much to do on the container side anymore. Mhmm. When we're talking about the migration process, we I remember as well also as a previous developer in Wiz, if we had a multiple deployment, we had some Debian. We had some Alpine. We have some specific application or even Ubuntu. Does the migration seems okay from different operating system? Does it took any consideration when we decided to migrate such images? I would say that, you know, there's there's specific packages, obviously, on different operating systems or specific libraries that that need to be sort of, made available if they're required for that service. But, for the most part, I mean, they're generic generic enough across the platforms that it it wasn't a major issue. And I think the only things were just, that I mentioned earlier, packages that were maybe based on MUSIL before, needing to be using the GLMC, version of those packages. But but in general, it it wasn't a major issue to my knowledge. Mhmm. Sounds like a plan. And when you got this last question about further out, it was a different project, I guess, the different time, and then we needed to even have some kind of audit on the resource. How it went? Did we needed to do any different modification than the, the commercial one? Yeah. So I think that, for most of the images in in Windows today have have an equivalent FIPS version of that image. So, yes. We know that they're, you know, saying that their FIPs validated. There's still, our compliance teams on the FedRAMP side, you know, just needed to validate, that that, you know, FIPs components were there. They're whatever cryptographic modules need to be there were there. They met, like, FIPs requirements. So that was the only maybe difference is having having a second compliance team kinda validate that the the HIPPS, modules were enabled, and they met this the FedRAMP standards. But but other than that, it was pretty much the same product. We run basically the same, technology and commercial as we do in FedRAMP with the exception like those DIPs images. Mhmm. Cool. Thank you so much, John. It was interesting to hear your journey actually managing the adaption of Weavoice in our organization. I think that taking this as a project and actually to mitigate that or maybe to to make it as a as a real process in a real cloud environment, it's interesting to hear all this kind from migration to visibility, the action plan, and how we actually made it. Thank you, John. Absolutely. Thank you. Thanks so much, John, for joining us. And I know, we've been trying to answer a lot of the questions in the chat, but we have a little bit of time left here, to take some of the questions live. So I'll read a few of them out loud. Let me just go through here. Daniel, I think this would maybe be a good one, for you. How how do updates how should updates to Wiz based images be managed by application teams? So that depends if you mean the specific version or how you're actually planning the the upgrade itself. In general, if we're talking about using the image itself, we recommend customers to pull the images. Actually, they're only CL, CL. They can even mirror the specific images. Once they've done that, there's we have a specific tab for version. For example, when we have a go, you would have a go1.20four. Now when you do have a deployment, let's say that you have that weekly or biweekly stand, we recommend as soon as possible, but weekly is our SLAs for critical vulnerabilities, and this is probably the best case to actually update that. And then you actually can pull once a week this specific image to your own container register, and you will gain the SLA fixes with all the vulnerabilities in it. Top of next, next player. Thanks, Daniel. And then here's another one. How are vulnerabilities patched in your images? Do you back port fixes or update to the latest library versions? Mhmm. So that's a a good a really good question. So we do a few a few option of remediation. Of course, one is the obvious. If we have a fix, we're going to fail to, to operate to the specific fixed version of the specific vulnerability, but it's not only that. For example, we can take even a real life example. In the g l f c last version, in the last bug fix, we actually have a critical vulnerability. But I'm going just one big back fix down that maybe removes small functionality, takes the critical vulnerability, and remediated the action. But more than that, this is not just about package versioning. We're doing more than that as a research, for example, configuration change. And even if we can, we patch it manually. We have a world class name, security researchers that publish a lot of new vulnerabilities in this page, and we also take as as part of that, we also take the specific CVEs that we see on our images, and we even communicate to the open source and on our team a specific vulnerability features in our images. Does that make sense? Thanks, Daniel. And then we have one. Will pulling new images create any downtime? So it depends. Pulling new images won't take a downtime. In general, we also it may it depends on what do you mean downtime. But for example, if a port now is restarting, if we're talking about Kubernetes, it will take time to log, but the previous port still will be still alive. It depends on the configuration. Now pulling the say the port itself to your own ECR, if you copy that, won't create any downtime. And once the services are going to restart, whether it's a Wiki based or even just a manually, then it will use the new image. And Wiz ACR and ECR grade caching system, it it will just use the same image met without our being done yet and yet again. Thank you. And I I saw a few questions, about, documentation, and also a little bit about, licensing. So I want to mention, you know, again, that for for all, existing Wiz customers, this is currently in public preview. So if you go into your risk portal to the preview hub, you can enable this today. All of the documentation, is available when you enable the preview, for Wiz customers. And, from a licensing perspective, this will be covered as part of the WizCloud advanced unit. So it will be charged as billable units within WizCloud advanced. And there is some more information, in the docs, today, if you go into the WizCloud advanced, billable units documentation, to understand what the pricing might look like, for your environment. But also during the public preview period, it is free of charge, to use for now. So just want to to say that out loud, because I saw a few questions come in around that theme. Amazing. Well, I think we got to a lot of the questions here, and I know there's a few, that maybe we didn't touch on. We will follow-up on those additional questions, after the call. But really appreciate everyone joining. Definitely encourage you, if you haven't already to go enable the public preview, check this out. Let us know what you think. You can submit your feedback directly through our new preview hub, which is one option, but, of course, also to your account teams, and we're happy to chat and excited for you to be able to try this. And, please, if you have any new images that you want and we still don't support, you just have a one click in your website to ask you whatever you want. Thank you so much. Thank you.