 Welcome everyone to our Tech Tuesday webinar. Today, we're going to be talking about digital transformation. But we're going to take a slightly different perspective on things. I think you'll find people talk a lot about modernizing your apps and more recent times, it's been about the collaboration and maybe the enterprise. But we're going to talk about AppSec and why, when you're considering going through a digital transformation that you should be considering making updates to your application security platform or strategy. Just to introduce ourselves a little bit, my name is Andrew Horrigan. I'm a technical PMM at Deep Factor. I've been here for almost six months now, it's rounding up, but been here for a little bit, learning all about AppSec and helping spread the message around Deep Factor. I'm joined today by Karen. Karen, I'll let you introduce yourself. Hey guys, I'm Karen Cummings. I'm the founder CEO of Deep Factor. Addicted entrepreneur, lots of experience in the Cloud Native and other areas I was at to school before and the bug bit me and I started another company. This is an area that we feel is going through a lot of changes. Organizations are creating Cloud Native containerized applications, Kubernetes applications, etc. It's important to identify security just in these applications during the course of development as opposed to late in the game when the apps get rolled out into production. Hence a modern take on an application security platform. Yeah, absolutely. Just a little bit about Deep Factor. We were founded in 2019. We've got people from all over the technical sphere from infrastructure and Cloud Native guys like myself, all the way to security experts from QALIS and Citrix, etc. We've got a good well-rounded team in our mission ultimately is to help developers ship secure and compliant applications. If we could deliver one thing, that's what we want to deliver. Moving forward a little bit, I want to give Kieran an opportunity to talk a little bit about the apps that challenges and trends that we're seeing shape up the environment here. Yeah. As many of you guys probably are following or have been following the space quite a bit, which is probably what led you to attend this webinar, digital transformation has been happening for the last few years now. Ever since Cloud Native applications started becoming the way you build modern applications. That has resulted in, there's a couple of, we're sitting in the intersection of a few interesting trends. Number one is every organization when they're building new applications, they're looking to now think about, should I build a new application using containers? In fact, that's become the norm for any high-scale application with Kubernetes or containers or at the minimum maybe some serverless functions being thrown there. So application modernization, if you're starting application building from scratch, then Cloud Native icing your application seems like the way to go these days. But if you're a larger organization that already has a bunch of applications in place and you want to try to transform those applications and modernize those applications and make them Cloud Native, then that's another threat of initiatives that is happening in pretty much every large company that we've been talking to. So basically apps are getting more granular, they're moving at a faster pace because you want to ship them faster, you're putting them through your DevOps pipeline. At the same time, the number of security-related breaches, both in terms of the size of breach as well as the number of breaches have increased quite rapidly over the last few years, and that number we only see is going to continue to grow because the number of the applications are increasing quite heavily. So if you think about the concerns around security, you see stats from Stack Rocks adoption survey and some of the Red Hat state of Kubernetes security reports, they indicate that pretty much every Kubernetes deployment, 94 percent of Kubernetes deployments have experienced security incidents, or they've experienced security-related delays where issues were caught, but they were caught late in the game, which resulted in releases getting delayed because somebody had to come back in, the engineering team had to context-switch and fix those security issues, etc. Several of those issues are obsturated, but there's also several of those issues that are application or development-related. If it's an obsturated issue, the fix is to protect your perimeter or get your cloud security posture configured right. But if it's the application, then the best way is to make sure that you create a secure application to begin with. I was just attending another talk with somebody from Zscaler and they basically were saying, do you want to be a coconut or an avocado? Coconut being secure outside, but soft inside without much security inside. That's important because you still need to have some kind of perimeter protection, etc. However, it's becoming more and more important these days as apps become more granular and there's a lot more e-switch traffic to be for your organization security strategy to be an avocado, which is make sure that your application is secure in the middle because once your app is secure, then the rest of the things start mattering a little less. Some other interesting stats here is in terms of the number of developers versus security professionals out there. The number today is 26 million. I think today we have about 26 million developers and that number is supposed to get to 45 million by 2030 and the mind-blowing stat that I heard is that there's going to be 500 million cloud native applications by 2023. Come to think of it, cloud native and Kubernetes just got started five, six years ago. So this is like a massive amount of growth and proliferation in terms of number of applications being designed with cloud native in mind. At the same time, if you look at the number of security related people, the talent pool is very small and look at three and a half million plus unfulfilled cybersecurity jobs. So it's important to make sure that you automate a lot of these cybersecurity functions during the course of your dev or CI pipeline or in production so that you can make sure that you create secure applications to begin with. So what is driving? Now that we've taken a look at the macro landscape, let's dig a little bit deeper. What is driving app sec modernization? We talked about app modernization, meaning containers and Kubernetes and server less and all of these things that are creating that are that are enabling people to create secure applications. Now, how does that affect application security? Application security in this case being defined as the ability to identify all of your security and compliance risks during the course of your development. We've talked to over a hundred enterprises over the course of the last year, year and a half, and we've broken it down into five themes where these companies kind of come to us and say, this is the problem we're trying to solve and therefore we need a better app sec solution. Number one of that is app modernization, where somebody is creating an application or transitioning from a monolithic application into Kubernetes or some kind of microservices based application and they want an app sec platform that understands Kubernetes that is designed for Kubernetes. So they view this as an opportunity to say, now that I'm modernizing my application, I don't want to take all of the baggage of the older app sec tooling into this new world because I had put together a hot spot of five different app sec tools as part of my legacy application. I don't want to carry the same things forward. Is there a cloud native centric application security solution? Number two is dev sec ops adoption. I want to make sure that I add security early on in my CICP pipeline so that we can identify the risks in the application before they're widely deployed into production or even cannery rolled out into a smaller group into your production. The third one is around alert fatigue that results in release velocity that affects release velocity. It's my current app sec tools are giving me too many alerts and I don't know which ones of those I need to start fixing first because of that either we're fixing too many things which is affecting release velocity or my developers are just losing interest in work or the confidence in that tool. The fourth one we see is you know I have tools tool fatigue when there's there's just too many tools to use and all of them are important because security at the end of the day is a layers game but you know I don't I as an organization don't have the people or the budget in my organization to kind of put a SAS a software composition analysis a container image scanning a Dast and an IS so there's just too many tools out there like how do you how do you simplify this and lastly is there you know given the the importance of of observing an application at runtime especially for cloud native applications because imagine your app which was basically one thing was broken down into like maybe you know 10 plus containers now and all of these microservices are being orchestrated up and down in in your you know Kubernetes or other environments and you need visibility the true security posture and risk of your application cannot just be assessed by scanning your code or scanning your artifact of containers but you have to actually observe what your application is doing at runtime because maybe it has some it's passing some clear text secrets and you know at runtime or maybe there's an environment variable that has a key in it lots of interesting things that show up only at runtime that you cannot just get by looking at your your static code or or even your container image scanning so these are the five reasons why people reach out to us and why there's a need to rethink app sec and create a next generation application security platform you know and and that's basically the course of this discussion today Yep and and one of the things that we like to do when we give this presentation is kind of ask the audience you know where or you know what are the driving factors for them you know obviously I think for each of you there's going to be an individual reason why this you know this webinar was of interest to you and so we're you know just what do you a quick poll I think Virginia is going to go ahead and launch that in the background so you should see a pop up but you know let's just take a quick second to answer this and just to you know understand where you guys are coming from are you you know like Karen said are you looking to modernize your application and you realize you know maybe this is the right opportunity to reevaluate my app sec tooling are you concerned about release velocity and being able to allow developers to secure more quickly but also ship at the same rate you know just take a quick second to off to to make a selection I believe you can select more than one so I'm just curious to see you know what what you guys are saying and Virginia I know you're you're on mute and off camera but I think you'll see the results if you could maybe you know let one of us know what what seems to be trending more popular than the others that would be absolutely so as of right now it looks like 75% app app sec modern application modernization with a second runner up being unified app sec great thank you and that that kind of drives with I think the conversations that we have right it's it's your you're going through this modernization you're realizing that you're kind of toe in all the stuff behind you a lot of legacy maybe more traditional ways of doing app sec and you realize this is an opportunity to maybe reevaluate it and then obviously while you're reevaluating I think a lot of vendors in this space have have kind of started to consolidate and unify and and really bring together a lot of legacy app sec platform so you can kind of get that best of breed approach and so that kind of jives I don't care if you want to add anything else but that that kind of makes sense I think from our perspective yeah totally yes I mean people are frustrated with with a lot of tools that they have to put together because they want a good security comprehensive coverage at the same time without having to use too many tools number two is a tool that understands your modern application so I think I'm kind of pleased to see that both those are the two number one number two exactly exactly so before we get into you know the next generation of of app sec tools so to speak what what we wanted to talk about a little bit was just kind of define the landscape as it stands today and so you know these categories aren't you know they're not the categories right if you go look at a Gartner MQ they're gonna maybe kind of realign it a little bit differently but you know we kind of want to paint a picture of the current app sec landscape and how we view you know where these tools kind of fit best and and this is kind of like a little bit of a 101 you know 202 type level for people who maybe are a little bit new to app sec in general so on the left hand side you've got your your static code scanners so these are things that are going to be looking at at your code as you're writing them you know one of the more recently announced sort of capabilities is is infrastructure's code the rise of Terraform and Pulumi have given the you know a rise to a need to secure your your infrastructure code you know assess the static application security testers can be looking at the code that you write right so you're going to define best practices for your developers for your organization you're going to ensure that code is written to the sort of spec and quality and sort of a framework that that you expect within your organization the other type of static code or static scanners that we have out there are SCA so software composition analysis and container image scanning so an SCA is going to be like a like a sneak it's going to be observing or not rather not observing scanning your container images in your artifact repository this is something that like a JFrog might do as well and it's going to kind of help you understand all the potential vulnerabilities that that specific image might be susceptible to right so it's going to do some correlation some of them use their own you know their own databases some of them use like the the publicly available in this CVEs right but the idea here is to understand as you start to pull in packages and dependencies which of those are have pre existing disclosed CVEs same thing with container image scanning so the idea here is that we're going to give you not only the vulnerabilities but kind of a readout of all your dependencies and all the different packages that make up your your application that will be deployed in the dynamic category we've got DAST so DAST is dynamic application security testing there's a couple different DAST school DAST tools out in the market you know we at defector really like a WASC ZAP but the idea here is that you are scanning all the APIs for your application and you're checking things like the OWASP top 10 so cross-site scripting SQL injections buffer overloads etc those are all things that we're going to be scanning with using a DAST and then finally we've got the runtime category so what you see in runtime is interactive AST so you'll see I asked you'll hear people say I asked a lot this is a fairly older I'll say within the last two decades sort of technology it uses an agent most most commonly to observe the application as it's actually running so the agents generally are a little bit some developers we call them intrusive because you do have to actually compile them into your code but they understand the language intimately right so you might have a Java agent that's going to actually understand all the different calls and packages loads that your Java library is doing container security scanning or sorry container security as a new category that's also in runtime you'll often find these in production so you can think of like an aqua or a twist lock right these are going to be side cars that sit right next to your application in runtime and they're going to be observing sort of the network traffic that's going in and out the cluster in between the pods and it might do some sort of security analysis on that traffic it might be able to isolate the pod it might be able to give you insights and so what the what the application is doing and when we talk to customers about the adoption of these various tools what we have found is that there's four very clear stages when it comes to sort of DevSecOps maturity so as you start to move left as you start to shift the responsibility security from the app sec you know silo the app sec be you with the organization and you start to move it onto the developers we're finding that various different enterprises are in different stages so the first app sec stage unfortunately is actually a stage we have had conversations I went to I went to lunch with a nonprofit in a nonprofit doesn't do any app sec right so they just release their code they do some functionality testing and they release it into the wild they're very early stage they've only got a couple of employees so they don't really have the resources of the bandwidth to do app sec right so they haven't implemented any tools more often than not what we find so a lot of customers aren't a sort of like reactive app sec stage where they are not really doing anything in the pipeline they're not really securing their apps there but what they are doing is once you know the app goes into production maybe once every month or once every quarter they do some sort of pen test right they they contract out to our organization that specializes in app sec and they go ahead and they do some you know some testing there now obviously the issue here is if you don't catch any of the security sort of you know risks in the application until you've already gotten a prod well so can the bad actors right the bad actors have an opportunity to interface with your app just as much as the pen tester does the other stage that we do see a lot of the larger enterprises for sure and are that that sort of proactive app sec so they realize that you can't just wait once a quarter to go ahead and do you know a pen test but what you can do is every time I build an image I'm going to do a container image scan every single time I you know maybe once a quarter once a month once a release I'm going to do a dash scan to check my API security right so it's it's proactive at a minimum it's I'm not going to wait until something goes wrong I'm not going to not do anything but I'm going to go ahead and do some of the stacks scannings I might have like a container security product in play so I might go into production and you know the ops team that the the SREs the DevOps team who are actually in charge of the environment they might actually be doing some of the app sec responsive abilities but you know not it's not really in the developer world yet so the stage three is kind of the very beginning stage where you think okay in order for me to actually mitigate this stuff getting further into the pipeline why don't I you know have my developers start securing and observing the application before it gets put into production and so that's what we call called cloud native app sex and the idea here is that your developers are you know as they're writing their code they're doing their functionality tests they're checking for security risks they're checking for runtime behavior they're doing their scans all as part of that development process so that you don't necessarily need to go through stages one two and three in order to secure your application and what we kind of advocate to customers is don't think that you have to go stage one stage two stage three stage four you know when I was having that conversation with the with a nonprofit you know I'm not going to advise that they slowly ramp up their app set capabilities I'm gonna say like no you should be looking at tools are going to get you immediately from stage one all the way to stage four right without having to go through those sort of baby steps to get into a you know a more secure posture so with that being said what I wanted to do again is ask a second poll and just kind of get a feel in a room for where people are in their app sec journey you know in their dev sec adoption journey you know are you someone who maybe doesn't take app sec very seriously today or are you doing some out of band tests do you have static scanners you know are you more in a stage three sort of category or do you really feel like you've gone the full mile and you're doing cloud native app sec and you've you've got dev sec ops you know ready to go so we'll take a couple seconds there and Virginia I'll ask you to speak up once again once once you get some good responses or stage one is definitely in the lead at 42 percent but stage three is coming up as a close second runner up so yeah stage one and stage three seem to be the most popular ones huh I think that's we've done this a couple of times I really feel like we usually get stage two and three stage one is surprising I want to say shame but that would be a little too judgmental for this audience but so thank you thank you Virginia so you know Karen I know you wanted to talk a little bit now about what is the ideal app sec tool yeah cool so you know we've established the fact you know over the last you know 20 minutes of this conversation we've we've talked about what the need for cloud native applications and a new breed of app sec tooling now let's talk about what is that next gen app sec tool looks like what is an ideal next gen app sec tool and I think given the context of cloud native applications the number one important thing is that this app sec tool should be easy to insert into your cloud native workloads and it should observe both your running containers as well as your static container artifacts so a cloud native first application security tool that is easy to drop into your cool environments or other environments it could even be like managed Kubernetes like it could be AWS Fargate or even your your own renter clusters for example or and it should be able to watch both the static aspect of your container images as well as the runtime aspect of your container images very easy number two is the number of alerts that you currently see with some of these legacy tools should be drastically reduced in order for your developers to take the output of these tools seriously and one of the important ways to reduce that is by correlating some of your findings with what your application is actually doing at runtime for example an example is if you if your application has you know a hundred vulnerable components that have CDs in them based on your software composition analysis or container image scan findings can you look at which of those are actually used by your application at runtime and by looking at that you know you can reduce the number of alerts because you only focus on the libraries of the dependencies that have been loaded and used by your application therefore your hundred might come down to 25 the other thing is lack of runtime visibility today is a problem and a an apps like platform that that understands not just the static artifact scanning aspect but also runtime like I talked about the third one is the unified part you know which you guys chosen the poll is one of the problems which is you know I don't want to be using too many tools this one you know or a handful of apps like tools should be very easy to kind of drop into my environment and it should get the various security insights in a simple pane of glass or integrated even better as part of my CI pipeline like if I'm using Jenkins you know I should just be able to go you know do my standard bills and at the end of the build it should show me you know all of the things that matter with respect to a bit of materials and the changes that have happened across releases all of the things that matter with respect to security posture of the application both static and runtime and compliance insights and if that can all happen as part of my CI pipeline that would be awesome so that would be in you know that is the definition of what a next generation ideal app sector should look like and there is an important aspect that of technology that is emerged over the last few years which is observability and that is that is basically enabled us to observe running cloud native applications very deeply so you know there are technologies like EVPF there's sidecar technologies there's also you know library loading technologies that allow you to get deep visibility into your application behavior and I want to make sure that we spend one slide talking about what observability is and how it is involved and why it is relevant to app sec and why it is important it's an important fabric of creating the next generation app sec platform so what is observability observability is the method of evaluating running applications so that you can reach meaningful conclusions about their health or performance or in our case application security so far all of these the first generation of observability products like honeycomb elastic and all of that they've focused quite a bit on using observability for logs metrics tracing like performance related insights but observability is just beginning to be used now to get application security insights and you know tools like aqua or sysdig or de-factor you know these are these are some of the companies that are using observability to observe application behavior and then correlate that into security related behavior so what is it why is it important for app sec because it allows you to watch an application or a cloud native application at runtime and then coordinate or correlate the behavior of the application with what is acceptable what is not like a simple example could be your developer brought in some third party code they did not know that the third party code was making an outbound connection to a certain geography that you didn't want but let's just for example say let's say Antarctica like it was making an outbound connection to Antarctica and you did not know and they did not know either because they thought it was a third party component that was already that didn't show any CVEs in the scan so many times runtime behaviors that bypass your scan your CVE list because it's just you know the it was not known vulnerability it's just bad runtime behavior those are things that I think need to be caught and there's several examples of what bad runtime behavior could be including not just network activity that I just gave an example of but it could be files that are being touched in slash 10 for libraries being loaded from some from unwanted folder structures in your in your operating system so on and so forth so risky behaviors can happen both in your code as well as you in your dependencies code like if your developers are bringing in third party OSS components into your code and they could be having risky behaviors and it's runtime observability is important for apps to not just to identify these risky behaviors runtime but also to correlate with the findings of your static scanners so that you can prioritize which of the findings of the static scanners are actually being observed by your application at runtime so that you can figure out which ones to fix fast so it'll help you reduce the alert volume as well as increased coverage of your application security faster now why is observability a must have for cloud native applications because cloud native applications increase the order of complexity quite a bit come to think of it the moment you've granularized your application and divided that into a bunch of microservices a lot of these microservices in many organizations and managed by different teams so they may have different base operating system images one could be using Alpine one could be using Ubuntu and Red Hat and so on and so forth the not only the base images but the languages used by these application for these each of these microservices might be different one could be written in Golang one could be written in Java or no JS so there's a larger surface area of risk and therefore you need to make sure that you observe each of these running containers while they're in action as opposed to just scanning your container image repository so just the quick scan of your reposes insufficient you need to make sure that you look at it at runtime so now that we've established what observability is and why it's an emerging technology trend let's talk about what observability can do to the list of APSEC findings that Andrew laid out before so this was a slide that Andrew laid out that basically says these are the tools that exist in the market today and there's probably one tool for each of these you know boxes that you might be using in your organization now the question is obviously we don't want to use all of that we want to make sure that we have a unified view and what is that unifies you know some of these things it's observability is a fantastic candidate to unify that so if you overly observability on top of these tools whether that's whether you use multiple tools or whether you use one tool like a deep factor that that incorporates observability along with some of these other modules so that you get that unified experience it's it's a way to augment both runtime dynamic and static finding so here's how here's what it can do for you on the runtime side observability will give you visibility into your application's behavior by looking inside the app while it is running there's several ways to incorporate observability if you use you know tools like you know sysdig it's an agent that you put on the host if you use a tool like aqua it's a sidecar that you install in your kubernetes environment if you use a tool like deep factor it's a library that you drop into using a kubernetes plugin so all of them have their own place and pluses and minuses and on the operator side tools like sysdig and aqua are probably the better fit if you are using production rollouts and you want your goal is to secure your production environment but on the development side tools like deepfactor are the better fit because you need your goal is to identify runtime behavior that's happening in every thread every process every container in every pod of your kubernetes deployment for example so you need something that watches each of these processes as opposed to a sidecar that is observing it from the outside so observability depending on how it's delivered can give you great visibility into runtime of the application but also make sure that you pick a tool that that condenses all of these insights into a small number of actionable items as opposed to just overwhelming you with a ton of telemetry because that's not what you what you want in is you don't want yet another tool that spits out that ton of alerts you want a tool that reduces and detects anomalies based on these alerts and reduces them into a handful of actionable items the second advantage that you get a second thing that a good observability platform can do for you is to augment your DAST a lot of the times DAST is kind of like a standalone thing that you run you know once a week or once a month or sometimes and mostly in pre prod sometimes even in prod to poke the application from the outside and then detect vulnerabilities like the OWASP top 10 type vulnerabilities and examples of DAST tools are OWASP ZAP which is what we use integrated entity factor but we also see a lot of the you know Burp Suite and Acunetics and Neuralegion and Stackhawk and all of these companies that are that that provide DAST tools the beauty of combining observability with DAST in fact I just gave a talk on Friday at the OWASP OWASP conference on specifically that topic is how do you enrich your DAST by combining it with observability using just to shorten it a bit the by by using the ability to observe an app from the inside you actually can get to detect things like hey my app was listening on web services XYZ and you can use that information to pass back along to your ZAP scanner so that your your DAST scanner can can therefore scan these new interfaces you can also identify which changes have happened between releases so that you know your DAST scanner is not now going and scanning every endpoint or crawling every API of your application and scanning it by going through your swagger document only scans the the list of changes which reduces the scan times for for DAST which is one of the biggest pain points that ZAP scans or DAST scans in general take a lot of time so lots of benefits by combining observability with a DAST product now let's come all the way to the left which is what can observability do in the context of your software composition analysis or your artifact scanners again I may have touched upon two slides ago which is the ability to prioritize your insights by that your SCA tools or your container and the scanning tools provide you by correlating it with runtime context is something that observability can do so in a nutshell there's so many different tools out there a good way to think about it is unify them but you can't just unification is not just throwing all these tools into one pane of glass it is actually combining it with a technology such as observability to give you deep insights and help you augment your existing tooling and reduce the number of things that your developers have to fix at the end of the day so we talked about the evolution of appsec apps into cloud native work cloud native workloads we talked about the that resulting in a the need for a modern appsec platform but let's take a step back and in a kind of unvendor related way talk about what is the right thing to do when you're planning for your appsec strategy so let's start with the first thing that you know we typically recommend you know any organization to do that's a marking upon this journey of hey I want to put appsec in place is understand your business driver you know is the need for my for my appsec journey a digital transformation is it application modernization or do I just want something in the CI pipeline or am I just trying to get some compliance boxes checked you know with Biden's executive order around the materials as well and so forth once you understand that then you understand you know what who is going to be using the tool I mean do we have resources a dedicated appsec team that is going to be doing this task in which case they will be doing the tool selection and embedding into the CI pipeline and then the developers are going to be consuming it or do I it doesn't have to be done as part of the engineering organization if so identify a resource some you know essentially you need a resource to put the tool in place you need a process and a resource for that for the alerts to be regularly triaged because without an understanding of the proper process that program is going to not be successful so you want to make sure that you give some thought to it then you figure out what you're before you pick the right tool you know understand what your technology requirements are if your app is a monolithic application that is written in .net you know you may want to use an older kind of I asked to a couple with maybe some DAST and maybe some code scanners but if you're building a modern cloud native application then consider a cloud native application security tool if you're building a mobile application then you need some you know a mobile you know security tools like Massacure and stuff like that are good for that and once you've done that then you understand you know what budgets and timelines you know make sense for you the beautiful thing about picking tools that offer more than one functionality into one unified experience is that you save a lot on money as well as the time it takes to set up these tools so pay attention to that as part of your budget and then make sure that you dedicate a certain amount of time there are certain tools that take a long time to to put in place it's not just the aspect of making the tool and it's it's the aspect of getting your engineering team to kind of work with your security person or the APSEC team to get the the triaging process kind of nail down completely so that takes a little bit of time to do maybe a trial trial run with a couple of your sprints and then you know get that incorporated in the long term as well. Great great great summary there Karen so so you know just as we go ahead and close out this webinar you know I wanted to bring you guys attention to some resources that you can follow up with if you want to learn a little bit more about observability and DevSec DevSec maturity we do have a couple of blogs that we've written I think Karen wrote maybe both of these actually so so they're a couple of good blogs about what is observability a little bit more on why it matters for APSEC and then a whole another blog on DevSec Ops maturity and what sort of decision points and sort of things that enterprises need to consider as they sort of make their way through that DevSec Ops maturity you know staged step ladder that we talked about earlier we also you know if you're interested in learning more about deep factor we do have some some case studies that have been done by some of our customers so feel free to visit our YouTube page and watch that it's pretty pretty helpful if anything not just for the deep factor angle it's it's actually kind of cool to see peers that are going through the same sort of challenges that you might be going through and and and their thought process to why they might have evaluated you know an alternative APSEC tool or or decided to do something versus you know another decision so that's always a great video to watch and then finally if you do want to see more about deep factor and you would like to see a demo please feel free to to reach out to us and and we would love to get on a call with you and and and kind of walk you through through the product so you know unless unless Karen you have anything else to add or Virginia we missed anything I think we're we're kind of at the top of the hour here and we maybe have one time for one question so this this seems like a good one so Karen could you touch a little bit more on on why existing APSEC tools might not work for a cloud native development I know we kind of talked about a little bit but it seems there's two questions in here that seems to be indicating like well I have all these tools I'm confused you know why I need another one yeah yeah no so the question is not needing another one the question is as you move from your traditional applications into this new world of cloud native now is actually you know it's a it's a problem to be solved but it's actually an opportunity to kind of rethink your tool set and so it's a good time for you to reimagine what your APSEC tools that should look like for this new world so instead of taking you have two choices I mean we have the choice number one is to take the existing APSEC tools that we've been using all along it's like four or five different tools and put them all in this new world or choice two is you know re you know leapfrog it and go pick a pick a tool that understands cloud native that is designed to understand both the runtime aspects of your containers as well as your static aspects of your containers therefore you can kill two birds with one shot yeah absolutely you know that was I think it's a great way to end I think I was ultimately what we were trying to advocate for when we started this presentation an hour ago so thank you Karen for your time thank you Virginia for helping facilitate and thank you to all of you for tuning in and listening to to us talk a little bit about abstract modernization