Video: Start Secure and Stay Secure with Wiz Code | Duration: 3448s | Summary: Start Secure and Stay Secure with Wiz Code

Transcript for "Start Secure and Stay Secure with Wiz Code": Alright. Welcome. Welcome, everyone. Welcome. Alright. We'll give folks a couple a minute or 2 to keep having keep those numbers of attendees coming up. But welcome. If you have any questions or at least thoughts in the chat and the Q and A, feel free to drop some thoughts in there. We will have all of our speakers joining us up here in just one second. Alright. Okay, everyone. Hi, everyone, and welcome to today's webinar. Start secure and stay secure with Wizcode. We're super excited to have you join us today and appreciate taking the time out of your busy schedule to hang out with us for a little bit. So a couple of housekeeping items, there are many different ways you can engage with us during today's webinar. You can type any and all of your questions into the q and a section in the right, your right module or throw them directly in the chat. We have a number of Wizz folks on standby to help answer questions in real time. We also have a related resources, section that's under docs next to chat and q and a. This includes a request for a custom demo as well as links to our launch announcement and some downloadable guides on best practices, that are relevant to this event. With that, housekeeping is all over. Let me get started here. First, I wanna introduce our panelists for the day. I'll start off first with Ziyad Galeb, product merge oh, excuse me. Product marketing manager at Wiz. You've introduced yourself for a moment. Hi, everyone. Ziyad here from, the team at Wiz. I've been working on Wizcode for the past 6 months or so, and very excited to show you what we have in store when it comes to developer and application security. Wonderful. Thank you. Next up, we have Arnon, a product manager at Wiz. Hi, everyone. So I'm Arnon. I'm a product manager here at Wiz, leading Wizcode on the product management side. Super excited to talk to you, and to have Danny with us here, to give all of his insights. Great segue. And last but certainly not least least, we have Danny Robinson, cybersecurity engineering manager at AppsFlyer. Thanks for joining, Danny. Can you share a little bit about yourself as well? Yeah. Definitely. So very excited to be here. Thank you for having me, first of all. So Danny from, AppsFlyer. I manage the security engineering team. Everything to do with securing our product from cloud infrastructure and AppSec. And here, of course, today, I'm putting my AppSec hat on, and we're talking about Wizcode. So very excited for that. Awesome. And with that, I will hand it off to Zia to share her screen and get the presentation going. And as I mentioned, feel free throughout put put your comments, put your thoughts, questions in the chat and q and a. We have some folks on standby to answer them, and we also will have some time at the end for a live q and a session. And with that, I pass it off to you, Zia. Perfect. Can you all see my screen? Yeah. Great. So let's kick this session off. We have a lot for you today. On the agenda, we'll talk about the challenges of securing cloud native development with lots of insights, from Danny and, Arnon, and all the knowledge they accumulated over time, while building wiz code. And we'll also introduce, wiz code and how it extends the, wiz cloud security platform before showing you wiz code in action, with a quick or, lightning demo, so to say. And then we'll have we'll leave some time for the end to take questions. So please feel free to engage with us and, ask questions. We'll pick these at at the end of the webinar, and, Danny or Arnon will will answer your questions. So Wix Code is a product we introduced a few couple of weeks ago now. It reached gen general availability after many months in in development and a preview that has been one of the most popular at Wiz, with 100 and 100 of customers trying it out, among which we have AppsFlyer and and Danny. And it brings us immense pleasure really to make this widely available to all of his customers, but also every single organization out there, that is looking to secure development and cloud native development, in general. I'll take it away, Ziyad. Thanks. So for the past 4 years or so, we've been helping security teams with, 1st, full visibility. Right? We gave we gave the security teams comprehensive visibility in multi cloud environments. Then we helped with a deeper risk assessment. So the platform, provides the deep the deep risk assessments correlating the critical issues and risks across multiple dimensions. And then we also provided ruthless prioritization. So we shifted the conversation from looking at an isolated security finding, to toxic combinations of risks, and then offering remediation guidance that no other, cloud security platform, can actually match. So you love this. Our customers love this, and they ask for much more from Wizz. So we we shifted we started shifting left with the Wizz CLI, but our customers wanted much, much more, and we heard them. So with Wiz code, we're opening a new chapter in secure cloud development, which helps, firstly, identify and remediate, root causes. So going from the cloud issues, to the code, so pinpointing the issues at the source and helping you remediate them effectively, but also billing securely from the start. So ensuring that the security team that the security is is ingrained from the very first line of code. So from throughout the the entire process from the IT to version control system, etcetera, which we'll show, during our presentation. And now with code combined with the cloud and the defend offerings, it forms a very strong, and powerful better together story, right, for security across the entire application life cycle. From code to cloud and run time, and, yeah, and we own it. Next, please. Now, which is the only solution that really applies, like, the same security scanners across the entire application, life cycle. The same scanners, the same policies, through so so from the software development life cycle through cloud and and run time. So for example, we have our secret scanner that runs holistically from code to cloud. We have our vulnerability scanner, which our problem our platform actually brings together the vulnerabilities that were detected both in the source code and those that are running in the workloads. Well, traditionally, those were, obviously, separate efforts. And it's not just about the technical advantage of having the the same policy and the same engine that runs at different stages. It's actually bringing people and teams together. So now teams that focused on on on code and teams that focused on the cloud infrastructure, they can look at the same, problem together. So yeah. Next, please. Yeah. And and to add to this, Arnaud, like, traditionally, we've seen cloud security with CSPM and cloud workload, protection platforms on one side. Right? And application security on on the other side with, SaaS, DaaS, and and whatnot. And both of these areas were were siloed and each addressing specific parts of the security problem without too much overlap or without giving teams the full the full picture. And what we're seeing is that applications are modernizing, new threats are emerging, and the app sec world has to keep up in a way. Right? So these new requirements, of looking at security issues from the code to cloud perspective are now emerging and becoming a, very important requirement for, for security teams. So we're trying to duplicate that effort, for them in in a one single, platform that addresses this in a in a holistic way, I would say. Definitely. Okay. So our belief is that Wizko will actually open the next chapter in in your cloud security program. So we started off with, helping our customers gain complete visibility. So ensuring that there's comprehensive visibility across all the cloud resources. Then we moved on to reducing and remediating the critical risks. So we're identifying and addressing those critical risks, in order of priority, establishing the KPIs, the workflows, the SLAs, for, basically, for the ongoing risk management. And now we're, we're shifting this even further into democratizing security across the board. So we're empowering all the teams, including the developers, to access security tools and information. Right? So fast which actually fosters a culture, where security is everyone's responsibility from the developer to the cloud infrastructure, engineering engineer. And we're also helping this by by building by helping the the developers build securely by design. So we're embedding security into the development from the start and helping the developers address those findings, those issues, with the cloud context early on as as they're actually, writing the code. Last but not least, we're also detecting and arresting the intrusion. So it's more the the runtime part, which ensuring you can detect and respond to threats in real time to prevent infusions, both from threats on cloud resources, but also threats, that that come from, from your SDLC infrastructure, which we've, recently released. For example, looking at GitHub, a hundred logs. Mhmm. And the outcomes are actually, like, merging again as we've spoken and as the ad said, merging them between the code and the cloud teams, fixing those issues as soon as they're being written, as soon as the developer writes the code, and the quicker meet median time to remediate, right, by leaving, which leaves ample time for the developers to actually write the code that they're supposed to, to build your your your applications, by having that context, that cloud and the code context together. Now let's let Danny chime in here. And, Danny, could you tell us, more about, like, AppsFlyer's, cloud security journey and how did it mature over time? Yeah. Definitely. So just to paint a very quick picture of AppsFlyer in terms of tech, we use many different, programming languages, from programming languages that are very well known, go lang to slightly perhaps less popular ones such as closure. And, also, we've been using Wiz as a platform for around the last 2 to 3 years just to give an idea of history with Wiz. So one of the things that I strongly connect with is sort of letting our teams work together within Wiz. So within Wiz cloud, we took this and we sort of joined how our security engineering teams that look at all of our different cloud standards and how our security operations team work together over one platform. And Wizcode is kind of providing the same, solutions for us in terms of combining not only our, SecOps and security engineering, but also the teams that mainly focus on application security and infrastructure security all under one hood. And so in terms of the the sort of journey that we've been on, it's also been a technical journey of, you know, crunching numbers and trying to solve what it sees different issues, but also at the same time joining teams, together and and sort of making everyone work with the same context in mind. It also kind of connects to, on what you were talking about with having one tool or one wiz tool, which is providing the same vulnerabilities across the full landscape of our tech stack and all of the different ways that we do security. Because that can be kind of tricky when you're using different tools. And we're really on a journey now today with Wizzcode of scanning our GitHub, all of our repositories, all of our GitLab repositories as well. We're starting to push those all the way in the CI pipeline to the developer, sort of dealing with this as early on as we can possibly do it. And in in terms of, outcomes and expectations, Danny, do you see this accelerating development and innovation with continuous improvement and having that security feedback, always on in a way? So yeah. I I think one of the really one of the nice sort of mottos that I quite like, which we've taken out of the r and d world is, fail fast, which is essentially when we're gonna fail something, when we're gonna block something, let's try and block it as soon as possible. And, you know, essentially, it was very, very difficult for us at the scale that we're at. We have something like 8,000 GitLab repositories to roll out the types of policies on our code that we were really looking for. And so Wiz really allowed us to sort of push forwards in prevention and, dealing with these types of issues and failing pipelines fast to make sure that developers aren't wasting their time on things that, you know, we would then catch later on. So in terms of productivity, in terms of making sure that our security standards are still being upheld, definitely, we see, like, a huge increase in that. Interesting. Thanks. Well, moving on to the next section, which is more about the challenges and what we've been seeing while building wiz code with our numerous partners and and customers. The number one thing, is our belief that, like, now more than ever, we can no longer have application and cloud security evolve in separate silos. And there are various challenges that we have detected or sort of identified when, talking to these different teams today, whether they're on the AppSec side, CloudSec side, or also engineering teams, we've had the chance to, work with. On when it comes to the challenges, the lack of context for prioritizing risks in code was the number one thing we heard. That without cloud context, it's very difficult to determine, which vulnerabilities will really pose the greatest risk in a way, which leaves team guessing out what issues to prioritize. And eventually, this is time wasted on low risk, vulnerabilities or issues, while the most critical ones are left unaddressed. Right? The the second piece is, the inability to trace issues in the cloud environment back to code and identify their root cause in a very, clear way. So and this this is a challenge that we haven't seen, any team really solve in a very elegant way because their tools are simply, siloed. They have something for CloudSec. They have something for AppSec, which makes it almost impossible to identify the origin in the code base itself, like the specific line of code that causes, this issue. And, again, the fact that we're having, like, duplicate scans running in in code and then in the cloud environment, this also leads to multiple and often, like, redundant alerts across, those two environments, which forces the team to correlate them manually, and spend time, managing a high volume of alerts since they're, duplicates in in a way. The next step is going to be disjointed remediation workflows. Like, once we have alerts coming from 2 different tools, we also have 2 different remediation processes. Right? So it's hard for these teams to have a unified remediation, strategy and aligning AppSec and CloudSec on a on a single, strategy for fixing issues, I would say. Last but not least is the ability to enforce consistent policies. So I want a single policy engine that runs from code to cloud to run time. And having a very heterogeneous, stack of security tools and scanners simply makes this impossible. And so this is also one of the challenges we've seen many teams, grapple with. Now when it comes to the opportunity, of tying together AppSec and and CloudSec, we believe that code to cloud visibility is the core tenets here. And this is what will help teams unlock so many different, advantages, I would say, and opportunities for their, security program. The first one is obviously, we're understanding risk posture, with this time complete attack paths that help them connect vulnerabilities between code and potential misconfigurations in their cloud environment. The second one is what I mentioned earlier, the ability of, enforcing and defining the policies once and then embedding them across the life cycle again, at once. So you don't have to do this across different tools and with the operational complexity that that comes with that. And from this, the consequence is going to be an easier remediation strategy, something that is consistent and aligned with the policies that you have in place. And another thing we all also you you mentioned this, Arnon, earlier is, looking at the delivery, the software development or delivery pipeline from start to finish. Right? From from code to cloud, and not just code itself, not just code scanning, but securing the pipeline and what's around the pipeline. We believe that's also important to build trust in the applications that are running in in our cloud environment. The last piece is, suppressing, I would say, alert fatigue when it comes to developers receiving a flood of alerts from uncoordinated tools. The the differentiate the difference here is that with cloud context, you can filter the alerts that you will send to your developers early in the development life cycle and only pick the ones that really have an impact on applications that are running in your production environments or, ones that, the risks and code that will have a significant impact on on those applications. So you can choose what to alert your developers to, and then, leave those other alerts for another time, to treat them once they they have more time on on their hand, I would say. Danny, can you tell us about your your experience, like your personal experience in in general in this world where AppSec and CloudSec were evolving separately? Yeah. So one one of the really big things that I I just really connect with is the lack of context in some of the AppSec tools that we've used in the past. And so what that essentially means is that, you know, we're scanning our applications. We're making sure that we're looking at our vulnerabilities, but we lack the ability to understand where that application is actually running. You know, is it exposed to the Internet? Is it now something that we need to deal with urgently because of the different posture of the application within our cloud? And so having that ability to connect between the two worlds of cloud and also application and understand the context is just hugely powerful for us. You know, we're able to then also understand, based on, one of the components, which is the runtime sensor within Wiz. You know, is this library or is this package actually running? Is it being used? Is it loaded to memory? Is it validated in the runtime? And and being able to then narrow down the issues that are actually very important for us to solve is something that I don't think many tools were doing before. And with taking this forward to now connecting between our world and the cloud in our supply and also our code is just a huge benefit for us in terms of being able to understand also from the account security team and from the AppSec team, you know, and start talking the same language of, you know, how does this vulnerability affect us? Is this exploitable? Is this something that we actually need to deal with? What type of priority are we talking about? And so it opens up a whole other door and a whole other way of looking at these these findings. So it's it's very, very exciting. Definitely something that is much better, and I think something that the industry really has been pushing forwards into in terms of context, and having it at our fingertips today with Wiz is is, yeah, very, very beneficial to us. This is something we that also, heavily resonates with, the the product team behind Wizzcode and and the way they they they conceived it. When we look at traditional SCA, for example, you you mentioned the, this example earlier, not having that that context and the real world impact of that vulnerability on applications that are running in our infrastructure. That's something that we wanted to really, bring once and for all and say, okay. It's the days were both were separate, and you had to go to different tools to get that context. Those days are gone now. That's that that was the objective I would say behind behind WISC code. Yeah. And you you took the example. We had this discussion before on on log 4 j and how the with sensor, helps also get that runtime visibility and understand if this is something that's reachable. If my container is exposing endpoints to to the Internet. This in a way helps you, right, identify that one CV encode that has to be upgraded today, or that should have been upgraded yesterday, actually, and, fix that CV before any other one before any other one, that you might have in in your findings. It's like getting that needle in the haystack, but very quickly. Yeah. 100%. So, I mean, if we jump forward into essentially in the SSTLC, the maintenance phase, you know, it could be that, there was an application that had log 4 j as part of the application, and it was pushed through the pipeline. It passed all the checks because, of course, the CV wasn't found. And then later on, when it's actually running in our production environment, all of a sudden, the CV comes out. It's a critical issue. It has to be fixed right away. Being able to identify exactly where that's running, which ones we need to prioritize, make sure that we can actually understand if that library is actually being used or not, by the application. Those are things that were just not possible for us before using Wiz. So, again, it just saves so much time. It really provides one way for the cloud security, infrastructure security, and application security team to work together and also discuss things with the SOC and the security operations team. So it definitely connects a lot of different, teams together and also provides the way to triage these issues in a way that is actually pragmatic and and not just blind. We'll go and do everything because we don't know. Right. And then and then there are different scenarios. Right, Danny? There's one scenario where, the CVE, you know, the library when it was, used initially was not vulnerable. Right? This is often the case. But then it becomes vulnerable and you have to prioritize it. But then there's also like this other case where the developers might select a vulnerable version of a library to start with. And there in in in that scenario, beyond, like, finding the CVE, beyond scanning code itself, you also want to make sure you have the right checks and balances on the code repository itself and on the branches themselves that are used to deploy applications in the cloud. And make sure that you have, like, the code reviews in place, make sure that, pull requests, will require, branches do require checks to pass before merging. So we're also in adding that context around, the VCS configuration itself and the branch configuration itself to make sure that these this does not happen to you in the future. Yeah. So 100%. I think, with everything now becoming very code based, not only our applications but also the infrastructure. The rules that we have around the different repositories, how we push into master, how we get things into production. All of that is critical for us to understand. And also in terms of security, to actually have our guardrails there in terms of how do we make sure that this is monitored, managed, and also in terms of posture, we're keeping to the security standards that we've defined for our organization. So, again, this is something that Wizz is hugely helping us with, especially our scale. Great. And this, I guess, Arnon will take us to, the next part where you will tell us more about what's in Wizz code. Yep. Great. Thanks, Liat. Thanks, Danny. So we've introduced wiz code at a at a high level. So let's dive in and and look at, what it includes and and how it works. So yeah. So first of all, the first thing that we're doing is that we're extending the security graph, our famous security graph that connects between the different, the different points, throughout your your application. We're extending it to the code, and we're helping with that extension. We're we're tracing cloud issues to source to to their source and and fixing, and helping you fix some code. And we're also having, predeployment impact analysis on cloud. I'm also calling them cloud aware scans, where we bring the cloud context as soon as the developer, writes the code. Next, please, Yead. So let's start off with this with our scanners. So we have, an SCA scanner, looking for vulnerabilities on 3rd party dependencies, an IAC scanner, secret scanner, and a sensitive data scanner, as well as a malware scanner, which looks for, in in which works in 2 ways, both with, hash based, and we also have Yara rules. And we also have s palms. S palms can be can be generated from code repositories and from your workloads. We also have our inventory s palm page, which combines all the software components across your entire life cycle. So both in the repositories and the workloads, where for any software component, for example, you can look, where it exists throughout your application. So those are the scanners. Then we have the security posture, whereas Yad and and Danny talked about, a couple minutes ago, we're looking for, for misconfigurations on the infrastructure where the code is being written, where it's being, built, where it's being stored, to identify, again, other attack paths attack paths that potentially target your software development life cycle. And we also have compliance frameworks against which you can measure, the security posture of that infrastructure. We also have a stand where, we allow you to ingest findings from, third party tools. We have right now a native integration, with check marks, And we also allow you to ingest findings, with bring your own SAST, capability, to ingest them into wiz and still maintain all of that wiz context. Right? So the the finding is on is connected to the repository, but still, you can still see the context of where that repository, what the repository builds and the cloud context of where, of where what it builds, where where it's running. So that's regarding that part. Now all the code scanners and see how next, please. All the code scanners are running on each and every step that you can see here. So we have the ID. Right now we're supporting a Visual Studio Code with IntelliJ coming soon. We have within the VCS, we have scheduled scans and PR checks as well as, pull requests that you can create from the findings in the portal, and I'll show this, in in our upcoming demo. And you can also run our CLI, which which has been, has been in place for for a while now. Our our CLI running with you can run it in the CI, to, again, our layered approach to to have at every single point, the ability to check against those policies that are, that are heterogeneous across across your entire application. So both in in the ID and the version control system, with the pull request and the scheduled scans and then in the CI. So, again, those checks and balances and that layered approach across the entire software development life cycle. And, yeah. Now I have do have a question for Danny. How did your team first get involved with code? What drew drew you to actually use, all of those codes as opposed to as opposed to to the tools that you were using, previously? So I think it's a number of different, reasons. One of the things that I really connect with is I don't want our developers to have one set of findings by tool a. So for example, apps like tool a, and then it gets deployed into production. And then all of a sudden, there's another bunch of findings that tool b finds. And then we have this sort of wait. Hold on one second. Why didn't the first tool find it? And, obviously, you know, we have seen this across many different open source tools, and also, you know, paid tools as well where the engines run differently, the detection systems run differently. And so I think one of the main, reasons is I want one holistic tool that can do security for us in terms of code. I want to be able to provide our developers with a really good experience of what does securing their application mean. The other thing and and the other main reason, and we sort of also touched on this before was I really wanna be able to provide a good understanding of what are the dangers of this code or this application when it's deployed in terms of its context in the cloud. So being able to push this application into our Kubernetes clusters, having a runtime sensor from Wizz that also understands and looks at how things are running in terms of the application and what's important for our side is is a huge benefit. So what was really important was sort of making sure that we don't now all of a sudden have a jungle of tools that we're using, and also that we provide the ability to understand to our security teams in one way what is the security impact of this, vulnerability on our company, on our organization. So those were the main two reasons that I would say. Awesome. Thanks. One thing I don't know, I wanna say it's it's called wiz code, but the with the wiz CLI, you can go beyond code actually. Right? And when you have it running in your CICD pipelines, you can also scan container images that you will build, from your repositories, but you can also scan virtual machine images, and whatnot. So these are the artifacts that will be ready to be, pushed to your registries, once the build step, ends. And, you can also extend that WIS codes layer of defense to these artifacts that will be, ready to be deployed or about to be deployed in in your cloud environment. And then from there, of course, with cloud and with defend, we'll we'll take it from there, to ensure the security of these resources and and the workloads that are, once once they're deployed. Now moving on and we'll, get to see wiz code in action now. I'm seeing a lot of interesting, questions in in the chat. We'll get back to these, later. But quickly before we jump into, the demo, we wanted to also, take a specific use case, I would say, from, in a security incident, that many of us have heard about earlier, this year back in back in April. So our example for the demo is going to be inspired from a real world, threat or attack scenario. So back in April 24, CISA had issued, a warning to many security teams around the world, about a significant breach at a business intelligence, company. And, there was this was quite the the blast radius really. And it's this case also goes to show how the attackers, mindsets and modus operandi has started to change in a way because they're now looking at the developer environment as a target in and of itself. So we're talking about developer identities, code, and the build system, in itself. This was an interesting case where, attackers gained access to, the, self hosted, Git instance. So a, version control system that was self hosted. And once they found their way in, they scanned the repositories in there and found hard coded secrets, so AWS keys, which led them to the cloud environment, which led them to crown jewels to exfiltrating data from s three buckets in the cloud. So it's a very interesting, threat scenario where we can see how code and cloud, come together and and how attackers, see one as an entry point to get to the other. So I'll leave it to you here, Arnon, to show us the magic of of WISCO. Thanks. Let me stop sharing. Just a quick second. Okay. Perfect. Can you all see my screen now? Perfect. Okay. So the first thing that happens, once you connect with to your version control system is that you get an inventory. An inventory of all your code repositories, regardless of their type with which version control system you're using. As you can see here, we have a number of them. You can set settings, scan settings on each and every one of the of them, at each and every layer. So because you got the inventory, you're able to set the the scan settings, at every level. You also have an an inventory of all of your developers, all the developers, that was found, when connecting to, your version control system. But you also have this, magic. So this is the representation of all of the capabilities that we showed in the slide that gave that overview of all of the, of of the different scanners and where they're running. So what you can see here is, at the top of the the first row, represents the issues, the code and CICD issues. So those are the toxic combinations that take into account the code. So our findings that, that resurface from scanning the code, but also bringing bringing the cloud context. So we're marrying again those code the code context and the cloud context together, to give you, more insights. You can also see here compliance scores that we've talked about, the posture issues, SCA vulnerabilities. We even have, licensing, so open source licenses. We can show you whether they're not you're using some non permissive, software components. Software components, they're using non permissive licenses, secrets, data findings, all of it here, together, and we even have talks and combinations that involve the SAST. So even if they're, from a third party tool or they're ingested from, from an external source, we still take those into account when building talks combinations, and bring that color context, together with, those findings. Now let's dive into the example that, Ziad showed, in the slides. So here, what we have is a public version control system repository that has clear text cloud keys, that grants access to sensitive data. So what we can see here in our attack path visualization is that we have a repository that we see as public, so it's connected, to the Internet. And while we scanned it, we found an AWS access key. Now because we have the cloud context, we know that this access key gives access to a a certain user. This user has access to all of this sensitive data, and this is and having that toxic combination, we we have that only because we have the context of both the code and the cloud. So taking our cloud context, when we're scanning, when we're scanning the code environment and the source code itself. Now this is an example of, again, bringing the cloud context to the code. Now for for the customers that have already been using with cloud, we've already been showing them, toxic combinations, that take into account, the cloud environment. Now if we go into, one of these issues, for example, that involve log4shell, a famous example that everybody can, can relate to. So here we have just like any other, issue. We see the attack path. It's an unprivileged container that uses an image that's vulnerable to log for shell. We can see the attack path. We can see how it how it can potentially, be reached. But now with wiz code, we're introducing the code context, and and this is the cloud to code, remediation that we're talking about. So this is the code to cloud pipeline. What you can see here is basically a lineage from the container image that's vulnerable that were that's actually the target resource of this, issue back to the source code, back to the the the code repository. And you can see at every single step, you can see information on it. Here you can see that the Docker file actually was scanned and didn't pass the policy, that was assigned to it. It just wasn't, set on a blocking action. And now if I go into the vulnerabilities, here I can see that I have log 4 j core. So I do see that there's a vulnerability, which is at the origin of that, toxic combination that's in the cloud. So we're gonna bring that cloud context and the code context together, for easier, for easier remediation. And when I click on this, here I can see all of the vulnerabilities, all of the, this specific vulnerability. And as soon as I click on one click remediation, I can open a pull request, which will open it in the developer's environment, open the pull request. Developer just needs to take a look at the pull request, make sure that it matches, matches, what they were looking for, and merge the code. And then the next time that the image is being built or that the code is being, built into an image, the vulnerability will no longer be there. I am that cloud to code context, giving that power, and and bringing that context together, is super powerful, at least, in in this in these cases. And then going back to the security development dashboard again. Here, this is, like, the the the summary of all of these capabilities in in one dashboard. Gives you an overview of how well you're doing, in the developer in the development, environment. And, yeah, back to you, Ziyad. Unless you have anything to add, Ziyad Danny, to what I showed so far. I was going to mention, Arnon, like, the repository where you found the, vulnerability itself. Can you show us some additional context around, how it's configured? Maybe any findings on the branches in in particular, or how do we elevate, like, that, vulnerability in in the context of what we see in the repository in general? Sure. Let's go back here. And then, I think because of the, let me just click on this. Oh, sorry. Just a quick second. It's because I'm hiding the data. It's, it's a little bit difficult to to show, to show everything. But yeah. So here what you can see first of all, I can see on this on this, repository. You can see all of its vulnerabilities. You can also see its configuration. So this is the what we talked about about the posture of the of the repository branches of the repositories and the repository branches. So, this is one of these examples where you can see all of these misconfigurations. For example, the default branch does not require branches to be updated before merging or, it doesn't require checks to pass before merge. So if, if with code and and the PR checks were turned on, for this repository, even though it was turned on because this, this configuration wasn't set, the the the code was would would still be able to be built. So this is an additional information that the security team can come in and look. Oh, like, even the this can potentially happen again, because we don't have the configuration set, to to stop that from happening the next time. So, yeah, anything else you want to see, Ziad or Danny? Perfect. So that's that for a quick, for a quick demo. What do we have next to you? Let me take over. Oh, perfect. Well, thank you for the demo, Arnon. And, we saw together here, like, the power of of Wisco, really, when it comes to identifying, like, the root cause, right, in in code for those vulnerabilities that you see in in your workloads, in your cloud environment. So the idea behind WISCOODE, is also to help security teams and development teams resolve much more issues much faster. So, multiplying, remediation efforts. And on the other, on the other way back, right, you want to limit the number of net new risks or issues that make it to your applications and and resources in the cloud. So all the preventive, checks, that you mentioned earlier, whether they're implemented and embedded in the IDE or in the version control system with full request scans or in the CICD pipeline, with the wind CLI. The idea behind all of those is to give developers, guardrails that will set them on a path where they're building securely by default and, stopping the bleeding in a way and preventing those new issues from making it to their cloud environment. So not only you improve your security posture and your risk posture across code and cloud, but you also get to maintain it over time. And that's, going back to, our conversation earlier, Danny. The, the infinity loop where, it's all about continuous improvement and, the effects do compound over time, with the with the combination of WIS Cloud and and WIScode. Yeah. Definitely. And I I had to, end it with with a quote from you, Danny, on on how WIScode is helping, AppsFlyer unify cloud and AppSec. You've already, shared many insights with us, but I I I love this, bit of the conversation we had, a while ago. Again, this ability to map code level vulnerabilities directly to cloud infrastructure risks. Right? That's, that's a premier, I would say, or something that profoundly changes, the app sec, program and and experience in general. Right? Now now that you've been using and and trying with code for, some time, how do you see your security program evolve, with it? And what do you think would be the next steps for, for AppsFlyer in a way? So I think that we've gone to a place that we haven't managed to previously, which is already really exciting in terms of being able to join the teams together. And, you know, even just from the small demo that Alon showed up now in terms of being able to pinpoint, this specific container that's running in this pod, in this cluster, on this AWS account, has got this vulnerability, and, also, it's exposed to the Internet through this, CDN or through this, Internet facing load balancer. That's already pushed us to a place where we weren't we weren't there previously. Looking forward, some of the more exciting things that we're looking at is sort of how do we get now, our developers more engaged on the platform itself. That is really, really exciting. In terms of I I truly believe that security shouldn't be something that just the security team deals with. This is something that largely developers need to deal with. And so when we talk about shifting left, that's great. But we also need to provide the right tools and the right knowledge and the right training for our developers in order to be able to do that successfully. I think Wiz helps with that a lot building sort of processes and procedures automatically into their into the tools that they use today. So for example, we use GitLab, and so meeting them at, the merge request or in GitHub PRs for pull requests that is already meeting them where they are currently working. And, you know, using the same tool across all of the different life cycle that that they go through in terms of their development, in terms of also scanning our container images. That's also providing them, in my opinion, one security suite, one security tool that is gonna provide a holistic overall picture of what does security look like for my application or for my you know, we also have a set of applications which may you know, everyone has their own terminology, but we call it a system. So what does my system look like in terms of vulnerabilities? What do I need to deal with? So those are the more exciting things that we're looking forward to in terms of, you know, basically making it even more. I think it was it was mentioned in the previous slide, democratizing everything to do with code security. And so looking at that and putting it even more into the hands of developers, I think is, our next steps. Love it. Making developers and empowering them to really own risk in their own applications and code. And right? Developers are have a sense of pride when it comes to what they produce and the output of, their their their daily efforts. And, beautiful code is is also going to be, has to be secure code in a way, for for them to be, proud of it. And, we'll we'll be there for developer enablement at AppsFlyer and looking forward, to have as many lunch and learn sessions with with your folks, and seeing what, else we can help with and what we can build for AppsFlyer and every other Wizzcode user and and customer today. And with that, thank you, Danny. Thank you for sharing all these insights with us today. Thank you, Arnon, for opening a window into your mind on how we built with code, and showing us the the product in action with the lightning demo. This leaves us with about 10 minutes, which is perfect to take, questions and answers. So, well, to take questions and for us to answer them. So I'll open the floor, for q and a now. Awesome. I will help take over here. I've got a couple of questions. Thanks to our team behind the scenes. They're literally all backstage or Brian, Karen, and Isaac who are helping answer all of your questions, but keep them coming. We do have a few minutes. A couple of questions for the group though that have come through. First off, question for Arnon. What do you mean when you say democratizing security? So by democratizing security, we mean bringing the, the the the security, the the context, the wiz context to into their hands. So we want them to be able, every single person throughout the application persona throughout the application life cycle, to be involved in security. It doesn't have to be to hinder on their efficiency. We're here to to provide the guardrails and and to help them, to help the developers throughout their development, life cycle. But we're democratizing it by the fact that we're actually bringing that security, to everyone throughout throughout the application, life cycle. Again, like, bringing also those cloud issues without, to the developers, to their development environment, brings brings that super powerful, capability, to life so that everyone is involved, in there. I don't know, Ziyad or Dani, if you if you have anything to add on there. Yeah. I would say it's also about, breaking down your environment into, smaller chunks or territories. Right? By application or by service and regrouping those resources that form an application or a service, whether they're in the developer environment, like code repositories, CI, jobs or, like, CICD pipelines in general, or cloud resources and workloads. Right? Getting those 2 together, forming, an an abstraction that could be like a a project, for example, and then, giving access to the owners of of these project, of these projects. Right? So that they can get full ownership of the risk within, their applications, and empower them to resolve those those risks directly, by giving them remediation guidance and whatnot, helping them throughout the process, and giving them also the power to resolve those those issues. Right? I would say democratizing in a way is giving everyone the ability to see what's in their apps, and then also the ability to to resolve them in in a way. Awesome. How do you see wizcloud and wizcode is different from Defender 4 Cloud with GitHub Advanced Security Integration? That's an interesting one. I would say that GitHub comes from, the developer world. Right? It's a it's a DevOps platform. It was mainly built for developers to collaborate, around code, ship code, review code before, it's it's merged. There's also a community around GitHub. Right? It's the whole, world that comes to to build on GitHub. It, propelled open source to to new heights. I would see GitHub as a solution for, developers, but if I were on a security team, I would choose something that, caters to both security engineers and developers at at the same time. I'm I'm not sure, how well, with, we have lots of, obviously, respect for for GitHub and every other solution out there in the market, But I'm not sure GitHub, really, serves the security teams today like Wiz intends to. And I don't know, Danny, if you have any, thoughts on developer security tools or security tools for developers. It's it's one way or or the other. Yeah. So, I'll be honest. I don't know the GitHub, whatever it's called, the advanced special package that well. I will just say one of the things that possibly just needs to be looked into from, the person who asked it is, does it go into detail in terms of your actual cloud assets around, actually scanning your volumes, having a runtime sensor on your, pods, being able to essentially understand what is in production and what is publicly available. Those are the sort of things that Wiz and, in in my opinion, the power of Wiz code and Wiz cloud together provide. The the joint ability to look at your application and to have a full picture of what this looks like in production is, in my opinion, something that other other offerings don't really provide, or at least not to, the same type of standard. I will take it to a world possibly that I know a bit better, within the world of GitLab. You know, there are sorts of all different types of, packages that you can buy, within GitLab, which allow you to scan code, you know, for SaaS, SCA, all of those sorts of things. But, again, one of the things that that type of offering will miss is what does this mean in terms of the context of my cloud? What does this mean in terms of the context of deploying it into my production? What does that look like? So that that is where this offering really, in my opinion, provides the biggest amount of benefit and the biggest different from other competitors that you may have worked with or possibly be working with. Yep. And going back to the question now, I I I read it better. With with wiz code and cloud, you get all of these findings on a single on a unified data layer. Like you mentioned, Danny, that is the security graph. That's like the the single backbone of the wiz platform. With defender for cloud and combining it with GitHub advanced security, Let's say you get the same coverage in terms of risk source cans, but these are still 2 separate tools with 2 different back ends, 2 different separate layers. So you have to do that work of correlating these findings across those two environments. Right? Yeah. I I will just say just one last sentence on it. I really strongly believe that we're going to place, especially in terms of security, that we want one holistic view to what does security look like in my organization. And we want our developers on the other hands to have also one holistic view in terms of managers and sort of VP levels and executives. And then the the people who actually are working on the code, our developers are actually running it. You know, those sort of processes in terms of security should just work for them in their systems. So that is, in my opinion, what Wiz is providing us. That that's really the the strong point. Awesome. Perfect. Thank you, Danny. Thank you, Zia, Arnon, Danny, and, again, all the folks on the backside for this walk through of Wiz code. We as a reminder, in the q and a and by the q and a, excuse me, in the doc section, we've got a couple more resources there. If you wanna check those out or if you wanna schedule a custom demo, you can do it all through that link. Again, thank you for taking the time to connect with us and spend some time with us today. Super appreciate it. Have a great day. And we will be sending out an on demand version of this recording probably tomorrow or later this week. So thank you all. Have a great morning, afternoon, evening, wherever you are. Thanks. Thank you. Thank you. Thank you, Danny. Thanks, Rynon. And thanks everyone for attending.