Name: From Theory to Threat: SAST powered by cloud context
Uploaded: 2026-02-05T17:50:43.141Z
Duration: 26 min 24 s
Description: From Theory to Threat: SAST powered by cloud context

Transcript for "From Theory to Threat: SAST powered by cloud context": Hello, everyone. Good morning. Good afternoon. Welcome to today's fifteen minute live demo on how static application security testing works with Sal and Amit. We are so excited to have you guys join us, and we appreciate you guys taking your time from your busy schedule. There are many ways for you guys to engage with us during today's webinar. If you have any questions, please feel free to throw them in the q and a tab, and we will address them at the end. And we also have some related resources in the docs section for you to download at your leisure. And with that, I will now pass it on to my colleague, Sal, to kick us off. Sal, all you. Amazing. Thanks so much, Alex. And once again, thanks everyone for tuning into this webinar. My name is Salman Lada, and I'm one of the product marketers here at Wizz focused on WizzCode, which is our ASPM solution. And I always like to start with a fun fact, and I think my background is pretty telling, but I'm a huge Marvel and Star Wars fan. And I'm joined by, one of my favorite people, Amit Haffrey, who is on the product management team. Amit, you wanna jump in and say hi? Yep. So hi, everyone. I'm Amit Hofrey. I'm a product manager here at Wizz, and I lead everything code analysis and SAST in particular. Glad to be Amazing. So in this webinar, we're gonna go over a high level market overview, talk about the solution, and I think the real magic is in, seeing the solution, and I'll hand it over to Amit for a demo. So let's dive in by setting some important market context. And I think for many of us in the industry, especially those of you in application security or product security, you know this to be true. And when we talk to our customers, their development teams are using AI generating, coding assistance, which has fundamentally changed the SDLC. Right? We are producing more code faster than ever. I think the interesting thing there is it's not just development teams that are using these solutions. It's also traditionally nontechnical roles. Right? Folks like Amit, who's who's a product manager, although he does have a technical background. But perhaps some nontechnical folks in in your organizations are also using AI generated assisting, coding tools to create applications at record pace. Now this is quite interesting because not only does it mean perhaps the depth of understanding on the code being generated is limited, but it also introduces a lot of risk. Right? More code generally means a wider attack surface area and more more risk. And I know there's quite a bit of studies out there that show that AI generated code is often insecure going against common basic secure coding practices. Now our stance here is pretty simple. Right? This volume of cogeneration, it means that static application security testing is more important than ever before. It still remains a cornerstone of most AppSec programs, and the proof is in the pudding. When we look at industry validation from folks like OWASP, who recently released their top 10 for 2025, I think what's really interesting here is perhaps not what it hasn't changed, but what's largely stayed the same. So we see things like common flaws around broken access control, injections, cryptographic failures. All of these are still top concerns confirmed by the broader application security community, which can be partially or fully addressed with SaaS solutions. So the punch line here is even in an era of AI assisted development and vibe coding, SaaS stays a foundational pillar of modern abstract programs. But and, of course, there's a but here. What we're seeing is that traditional approaches are really never designed to address this level of code velocity and cloud complexity. So when we talk to customers, particularly in AppSec and having been in this industry for for a few years now, after a scan runs, what are teams met with? Right? A long laundry list of CWEs that require an abstract or security engineers time and effort to manually prioritize and triage these findings. The reason it's so difficult is because in the absence of cloud context or visibility into how a potential CWE will impact a running application, it's really difficult to gauge the true exploitability of an issue even with advanced methodologies. And so we're really stuck trying to parse out theoretical risk from a genuine threat. Now from the developer's perspective, I mean, I'm sure we all know how this story unfolds. They're constantly hit up with low fidelity signals that end up frustrating them because their PRs might get blocked or they need a context switch out of IDEs. And finally, on the remediation front, you know, we hear this all the time from devs. They wanna focus on building great software. They're not necessarily security experts. And so how do we empower them with built in remediation guidance so that we can keep them focused on what matters most for them? Now it's for these main reasons that we launched very recently our own SaaS solution in public preview. Now it is designed to help AppSec teams identify weaknesses in their first party code by combining the unique cloud and runtime context Wizz has from the broader Wizz platform to help them prioritize findings based on their actual exploitability. So let's unpack what this means in terms of value. So first and foremost, we use the same policy engine from code to cloud. And this is a critical part of the platform because it really brings cloud and application security teams under a single policy framework where they can define guardrails once and enforce them consistently across the entire SDLC. Secondly, we're providing teams with deep context for effective prioritization all built on the Wizz security graph. This is fundamental to Wizz and everything we do, and Amit will dive into this in detail with the demo. But we're able to link CWE findings from a source repository and the code owner to the cloud resource it will be deployed on to identify genuine attack path. So instead of saying, you know, this function is vulnerable, we can actually say this code is deployed, Internet exposed, connected to sensitive data, and reachable through an actual attack path. Right? That level of code to cloud visibility is incredibly powerful for AppSec teams. And last but not least, we're really trying to be intentional about the developer experience. Right? AppSec program success hinges on developer adoption. So how can we be intentional of bringing remediation workflows directly into existing developer environments to empower our devs to focus on shipping code and not focused on fixing security issues? And this is where we can provide them with things like AI powered remediation suggestions. But I think I'll stop talking here because Amit's got a lot to show in the demo, and we're gonna unpack even more value. So, Amit, I'm gonna stop sharing and hand it over to you. Perfect. Thanks, Alan. So I'll go ahead here. Okay. So I'll be doing a short tour of how you can experience with SAS today and the voice platform and a bit outside it. I do like to start these demonstrations with talking a bit about Mica AI, actually. And the reason I do this is because everything we do, we like to make streamlined as possible and accessible to our users. And one of the best ways to experience that is just by asking Mika a question. So I can ask something like, what are my top SaaS risks in my environment? And then I can have Mika inspect my environment, query the different API endpoints inside Wizz, and get a clear answer on what they should be looking at. I'll give that another second so I can see examples of different things, different vulnerabilities, and this is all based off of the data that comes in from West Coast SaaS. And I can ask follow-up questions and get detailed instructions and so on. So starting with that, but moving into a more traditional view, we have the secure development dashboard, which is a good place to start for just getting an instant view of all my code security risks. And we can scroll down a bit here to see what is my state with SAS today. So I can see my repository is with the most SAST findings, my top weaknesses or CWEs in my code, as well as what posture is issues I have open. This is something I'll touch on a bit later in this demo, but it's very useful to see from a bird's eye view here as well. Now I'll move now to show an example of a WIS issue involving SAST. So we'll pick this one. And this is a great place to show an example of what we like to call a toxic combination of risk and WIS, essentially leveraging the full extent of our visibility into your environment to give you a very informed level of risk based on all the different components within it. So here we have a code repository with code injection application of vulnerabilities that builds a container image serving publicly exposed containers with lateral movement findings. It's a bit of a mouthful, but let's take it apart here. We can see that WIS code SAST surfaces its findings on the WIS security graph. It places them alongside all the other insights gathered by WIS, And we can see each finding is connected in turn to its weakness or CWE object, which helps us categorize them and and focus the view on the type of vulnerabilities that matter for this scenario. Now from this repository branch, we can see using our code to cloud correlation technology that it builds an ECR image or a container image that is in turn deployed as a Kubernetes container. Now what is nice is from this point, I can gather all of the insights from with cloud and connect them to this risk. So I can see the application endpoint, which means this application is exposed to the Internet, and here's even an example of what that looks like. And I can see it has a lateral movement finding associated with it, meaning we've analyzed this container's permissions, and we see that there's this risk associated with the level of permissions that have been given to it. Now if we connect all of these dots together, we can now tell a very complete compromise story. So if an attacker were to compromise this container, he could exploit this code injection vulnerability. They would land on this Kubernetes container, and then they would use the lateral movement finding to laterally move and continue to compromise my environment and my organization. So in a sense, we've changed the perspective here from looking at a specific code flow to looking at a scenario or how an attacker would look at this. Now let's view the actual finding in a bit more detail here. I'll double click on it, and we can see the different metadata gathered by West Coast SaaS. So we can see description of what this detection is about. We can see it mapped to different compliance frameworks such as OS top 10 or the science top 25. We can see a snippet of where did they took care in my code, and we can see, as mentioned earlier, part of the ownership and and attributed author of this specific finding. And we do this using our connection with the version control system to analyze this automatically based on both code owner's file as well as Git blame history, all to surface who could be the potential owner for this issue so we can attribute the fix or just consult with them directly. Now I will move actually, I will mention this quickly. And one of the most exciting features we have in WISCodeSAST is the WIS AI triage agent. So what the triage agent does essentially is analyze the findings detected by WIS code SAAST, and it does this by examining the specific detection as well as the the source code evidence to then give a very clear verdict on what do we think actually occurred here. So we can see this marked in here. And then finally, I'll move on this time to the remediation tab to show an example of how we can also leverage AI to generate very clear remediation instructions. These remediation instructions are generated by both static instructions that were written by our research and analyst teams and take into consideration the actual code snippet and how we should think you should fix this specific vulnerability. Now this is a remediation view that's very much tailored towards security personnel, especially being inside the West platform. A lot of West code is about approaching developers where it's most comfortable for them. So as an example, we can look now at the pull request experience. This is an example of a pull request in GitHub where Wizzcode is hooked up. So we can see how we leverage findings directly as a comment on the specific code change. We can see all of the relevant details directly in the pull request, and I can even go further to ask for specific remediation instructions inside the pull request, this time as a developer. In here, what's nice is I could go ahead and, if I were to have the permissions, click here and apply the fix directly from the suggestion that Wizcode gave directly to commit to the actual code. I would like actually to also show another example of how a developer can leverage Whisko very very effectively. And I'll go back here, and I'll just copy the specific finding here. And then I'll show an example. And here, I've I have this specific piece of code checked out checked out in my environment through Git, and I've entered the session with Cloud Code. So what I could do now is try to do something like help me fix this with fast track, and then paste the link that I got just now from the Wiz platform, click enter, and then very quickly, Claude can spin up a solution for me. And this is powered by the WIS MCP integration, which exposes almost all of the information that's available in the actual WIS platform. And we find a lot of our customers and users have been able to leverage it really effectively, even developers to be able to hook very effectively into the Wiz ecosystem. So here we can see how the agent picks up the finding from the Wizz API through the MCP server. It can see the specific vulnerable piece of code and suggest a fix. And this could be fed with all of my organizational context using CloudMD or AgentsMD or whatever rules file that I have available and just fit very effectively and neatly into my natural development cycle. Going back into the WES platform here, this is a great example to talk about what's driving the pull request experience here. So it's a good example to talk about policy in WIS code. So all of the policy in WIS code is customizable. We can see the default SaaS policy which caused this specific finding common to pop up is here. We can, for example, edit it to change different configurations about it, like, would I like to block pull request failing the SaaS policy, or would I like to fail builds? And this is based on CICD integration using the WIS CLI. Or I can actually customize the thresholds or different aspects of the policy itself to make sure my developers only encounter what they really want them to encounter as a block or as an informational vulnerability that they should address. So this is the main tool security leaders can use to drive the policy across the organizations using WIS code very effectively. And the second piece of that is how we can use a policy to define what they want to do with not new risk, but the existing risk environment. And we've introduced posture policies as a new tool to do that. What we can do with posture policy is essentially drive queries on top of findings of different types, so in this case, SAS findings. And then we can both filter them as well as group them together. So for example, I could have all the findings in a specific code repository create one posture issue. What's nice about this is then I could have very simple automations built on top of this, such as create a Jira ticket or send this into Slack or whatever makes sense for my organization. And we've created a few recommended posture policies out of the box, but we invite all our users and customers to customize these so they can make sense to how they want to manage their backlog for SaaS. I'll finish up where I started back in the dashboard here. Circle back again and showing the posture issues view, again, giving me a really good summary over both what are my top items of risk and what does my backlog look like. Is it getting bigger over time? Is it getting smaller over time? And so on. Okay. So moving here. Hamid, let's go off script for a second because we can stay on this slide, but I actually think that the demo view is probably appropriate because, you know, the main thing that we just wanna convey to to all of you in the audience today is we've talked extensively about SaaS. Right? But it is just part of a broader ASPM solution that Wiz is bringing to help our customers unify signals from code, cloud, and runtime into an actionable security platform. And so here, you're not only seeing SaaS posture issues, but we've also got things like software composition analysis, secrets detection. If you scroll a little bit down, you'll also see infrastructure as code misconfigurations. There they are. Right? These are all coming from Wizz's native proprietary scanners, but we can also ingest findings from third party apps like solutions and enrich them on the Wizz security graph, provide the code to cloud correlation to help you prioritize genuine risks. And, of course, as Amit highlighted in the demo, we're also really keen on meeting developers where they are. Right? Whether it's in their IDEs and coding assistant tools like Cloud Code, as well as things like GitHub and GitLab. So it's really this comprehensive solution, not just a SaaS offering that we have. Now we can go back to the slide where I just end on the final slide, then we can jump into q and a. Because for me, I think that the real proof not only is in the technology, but also in what we're hearing from our customers. And I really love this quote from Simon Goldsmith. He's the CISO at OVO, which is one of the largest energy retailers in The UK. And it really does capture the essence of the problem that we're focused on solving for our customers. So believe this on the screen here, and we'll end there. If there are questions, Amit and I are here, and we're happy to answer them. If you have any, so feel free to drop them in the chat or the q and a tab. I don't see any. Oh, there we go. So does this is coming from Anthony. Does ingesting third party information require a WizDefend license? So, I mean, I can take an initial crack at this one. And then if if I'm going in the wrong direction, please jump in. But so it I think I understand the crux of the question here, Anthony, but let me clarify. For third party ingestion for the ASPM solution, we're talking about things like Snyk as well as check marks. And in that situation, no, you do not need a WizDefend license. That would be part of Wizcode. So if you're a Wizcode customer, we would allow the ingestation of third party findings from other application security testing solutions. Alright. What's the there's another question. So from Simon, what are the supported programming languages today supported by Wizcode? Assuming this is specific to the SaaS offering, Amit, you probably have the Rolodex of this much faster than I do. So I'll hand it over to. you. So we've started by rolling out support for the top seven most popular cloud programming languages as as we see them through our customer base. These would be Python, c sharp, PHP, Java, JavaScript, TypeScript, and Go. Since then, we've also released some support for preview languages, which which would be the next wave of supported languages with mobile support mobile programming languages, Swift and Kotlin, as well as Ruby support. But in general, this is something that we constantly improve on, and part of our backlog is adding support for additional programming languages over time, just adding and expanding our coverage. Cool. Let's move on to the next question I'm seeing. This is from, Nick Jantz. What's the best way to tie findings from non Wizz tools into the Wizz ASPM? I feel like, seeing this one is probably the best way to showcase it. Amit, are you able to pull up the demo again? Yep. Sorry to put you on the spot. That's perfect. So I'll I'll I'll kick us off. So the best way to do this is by using the Wizz integration network. So if we go to you know where I'm suggesting we go. Yep. Yep. Deployments. Deployments. We should see integrations and yep. And addend. if we wanna add one perfect. There we go. So if we just do a quick search on, say, application security That's we'll the fault list. vendor name, There. you go. Take it away. Yep. So you can see, like, you can easily connect to Snyk. We have documentation on this. We can configure the the specific, like, findings that we want to ingest, and it's usually done through an API token. And this is available for several application security solutions. Snyk is one example. I believe CheckMarks is also on the list. We also welcome integration from other vendors like Cycode, Invicti, as well as there's the there's one of the, there's the view. As well as, additional, like, CICD platforms, version control systems like GitLab and GitHub who have their own, AST offerings. We can integrate their findings into our platform, but it's fairly straightforward in in connecting these into the Wiz platform. I'm not seeing any more questions. What's the best way of time? Going once, going twice, and that's it. So, hey, everyone. Thanks again for for tuning into this webinar. If you're interested in learning more, feel free to reach out to our team. As I mentioned, with SaaS, it's still in public preview, and we're really excited about it. Would love for for you to to try to try using it as well as providing myself and Amit some feedback. But we're really excited about it. Thanks again. And if you have any other questions, you know where to find us. Enjoy the rest of your days.