Chris Koehnecke - Minimum Viable Security for Cloud Native Stacks

all right everybody can you please give it up for Chris Kennedy we'll be giving a talk on minimum viable security all right good afternoon everybody uh what an awesome day here in Knoxville I'm super excited to be here I mean all these different talks uh all the different tracks we all love our technical tracks but you know there's a lot of you know career oriented tracks or soft skills you know building your um building up your resume um you know cyber security is such a broad field such a growing field um it's great to see all these talks and you know I'm super excited uh to talk today about a topic that's really important for me

um it's you know simple and and straightforward practices for securing Cloud applications uh and you know the way I like to start this talk is a bit of an analogy uh just just curious how many Beatles fans in the audience out here do we have not too many okay uh how many people know who the Beatles are ah much better okay um and uh if you know who the Beatles are maybe you saw this recently um you know a couple years ago uh Peter Jackson released uh this movie get back I was a documentary about the Beatles it's more of a Beatles nerd like I am quite frankly uh but I we all love Peter

Jackson for Lord of the Rings and all the you know awesome movies that he's done and what was really cool about the movie for me was that you got this really up close and personal view of how the Beatles write songs and if you you know if you know their songs you know the final product can be you know very complex all these orchestral pieces these you know different layers um you know they're works of art but how they started was in simple ideas um you know simple musical ideas and they built on that so starting small and iterating is an important step and really anything that you do but cyber security it's important to start with a

really good Baseline foundational understanding and it builds from there so that's you know that's one of the big things that I took from the uh to get back uh documentary uh a bit of background about me uh my last name's you know difficult to spell and say you can just call me Chris um so I'm with a an Israeli cyber security startup called jit so jit is an acronym for just in time I'll talk a little bit about that um but I did want to share just you know quick story about you know my history in cyber security um I was with KPMG and did Big Four Consulting in cyber security for 15 years um so I started as an associate level uh

near the beginning of my career worked my way up to uh to partner and I let our Cloud security compliance practice basically what that meant was that for any cloud service provider looking to get a certification whether it was something like sock 2 or ISO or also looking at some of the more complex certifications like fedramp that was really our specialty we take these products and these teams through these compliance processes um it was you know I know of the Consulting gig it's a lot of fun for those Consultants out there um you know you you get a lot of different varied experience um at the same time there was a common theme that I found is that we'd bring in

these security practices and processes and it would really stifle developer velocity like you know the developers you know in particular with the cloud companies you know they're very inventive uh you know all these new solutions that we're creating all the time and then all of a sudden now you've got the security process that doesn't make sense to a developer they have to start following that process so we'd oftentimes we'd achieve the goal from a compliance standpoint or the the outcome but the business would be her and the developers would be quite frankly would lead the company um so I got the opportunity opportunity to join jit and really looking to change the game you know Empower developers

with security um and and support developers with getting vulnerabilities and issues while they're developing and can fix things while they're developing and make it part of their regular routines just like a bug basically that's what we're all about so again it's uh or a startup called it's jit for just in time as an acronym uh based out of Israel I'm actually the first U.S employee so only 40 people 38 developers in Tel Aviv uh and then myself um and just a couple of things I could share is it um you know I I love you know I have your developer Tech and security um all the different pieces around technology love being a part of that

also with compliance and clearly I'm a big music fan I talk about the Beatles here a little bit we're talking about security all right so back a bit about the Beatles and those of you that have seen the documentary if you see Peter you know Peter Jackson's movies you know they get into the details there and you got to see like a really up close and personal view about how the Beatles wrote songs how they interacted with each other uh you get to see some of the drama too you got to see you know John and and uh and Paul fighting you know you got to see uh you know with their wives in the room they were no one's

getting along uh people quit the band it's you know some of the drama there is is kind of fun to watch um but at the same time you got to see again the origin of these songs and even the song like get back if you're familiar with it Paul just starts playing a very simple riff you know it's not complicated right just starts playing it something that you know just came to him as inspiration very simple but then you get to see the other band members pick up on that add their different pieces to it um and then also you've got a song out of nowhere right but again that's starting small and it writing was a huge

part of the Beatles success you got to see an up close and personal view of that in the get back documentary and like here's the like a few examples again of like how complex the music is uh you know not expecting you to read you know read sheet music here but there's a lot that's that are in these different songs all these different layers um but if you if you break it down again it's like three chords in the truth right I mean it really isn't that complicated from a foundational level and then you build from there so again just to start small and iterating is always a good practice as well as cyber security

all right so let's take that kind of starting spawn iterating and translate that over to Cloud environments and talk about some of the Baseline controls that really any Cloud environment should should have in place you know if you look at this you know first step you want to protect your perimeter right and how do you look at your perimeter there's a there's a few things here and again we're we're focusing on you know Cloud environments I'm curious just it's so hands how many people have you know cloud in your in your uh in your day-to-day activities pretty much everybody right every us gcp Azure what about in terms of uh like developing software like using GitHub

gitlab any kind of uh source code Management Systems like that pretty much everybody oh not everybody surprisingly um but you'll if you look at the you know kind of the modern tech stack if you will uh you know Cloud you know uh Cloud technology along with the appropriate source code Management Systems you're looking at your perimeter could be relatively straightforward right you've got those public resources your website your public IPS you want to protect uh you know you've got your CI CD pipeline whether that's a GitHub actions or using Jenkins to you know roll in uh you know updates and changes to your uh your your application of course you've got your user access and

it was a talk earlier and I agree with it that you know um that uh you know role-based access and identity is the new perimeter you know super important to lock down user access and then third parties of course I mean now it's using third parties and integrating with your Cloud environment every single day and making changes so you know kind of it helps again to look at just simple ways to have buckets of your of what you want to focus on and looking at the perimeter from that perspective so then we think about what are the controls that we want to implement for each one of those pieces of the of of your environment and your perimeter you

know first off for for cicd you know it's fantastic we can make updates to our Cloud application you know multiple updates per day uh constantly making changes improving user experience through feature do functionality we want to make sure that CI CD uh you know application Service as least privilege or to minimize the privilege uh looking at that those public resources you know you want to make sure that you've got your you're avoiding anything like you know Cloud misconfigurations you can run pen testing on your external applications you know web and API based scanning from an external perspective looking at those third parties you want to make sure that you've got MFA in place for any of the access to your

third-party applications and then you have the appropriate scope in terms of connectivity to your resources so evaluating those third-party applications appropriately and then looking down your users of course again MFA is super important and then you've got appropriate role-based access and least privilege so again a simple way to look at your Cloud environments and think about those core controls you want to make sure that you get right and you know again back to the Beatles you know if you look at um the Simplicity of how they started their songs you know it was this uh you know a simple thing like you know Paul's on the piano just playing a simple melody or a simple line John on the

acoustic guitar coming up with something you know again that's how they would start the process and build from there all right so we talked about the perimeter now what about inside your application and what are the some of the key things we want to make sure we protect against starting small and iterating of course we want to protect our traffic you know internal traffic that's uh you know being transmitted uh processed and stored inside of our environments uh you want to protect any of those Secrets out there your passwords your keys your tokens that's important you know any access to your micro Services you want to make sure you've got appropriate role-based access and permissions to your services you

want to make sure you have an incident investigation process right just again just a you know having a basic way to be able to respond to any potential issue uh event of event of interest uh you want to protect your software libraries you want to track your software software libraries of course there's been a lot of talk around uh supply chain so making sure those are appropriately attracted managed and protected and then also your backups right your Disaster Recovery uh you know being able to restore back from uh from an issue from an outage that's another important thing so again you know simple things here but you want to make sure you prioritize these is step

one as your Baseline of your of your security program so what are the controls that you want to put in place for those internal pieces of your application so for your traffic you know clearly encryption is a key control to make sure that you're properly encrypting and protecting that data you want to have some type of a secret manager in place that's protecting those you know tokens and hiding those tokens appropriately uh you know again least privileged and access to your services uh making sure you evaluate and look at that you know the various Privileges and and have our back in place role-based Access Control in place you know for your instant investigation you got to have the appropriate logs

right so making sure you have appropriate logging um you know set up enabled in your environment uh you know you know internal in your Cloud environment for your software libraries you're running it the dependency check so you're aware of any vulnerabilities that are in those software libraries and you know what's what's the criticality of those and then you're running appropriate backup so again a simple way to you know look at your environment and think am I doing all of these things is Baseline security is a minimum viable security approach um to help us build our security program and then we can build from there all right so here's just a you know a quick um you know a quick uh graph or chart

um that shows you know specifically some of the controls and how these fit into your perimeter as well as you know internally in your environment uh you know kind of starting from left to right and looking at you know your source code Management Systems um you know you've got you've got GitHub you know you're running the appropriate dependency check against those software libraries um and then for GitHub actions then you're gonna have the appropriate privileges uh whether it's gonna have actions Jenkins or another another CI CD platform you know you have the appropriate privileges set up uh you know you want to make sure your Public Access is properly locked down uh you know you're running things like

penetration testing from an external perspective web application testing uh web application security testing API scanning all those things are happening from an internal uh internal uh sorry external perspective and then you're looking at your third party Services you've got the the your apis right so which apis are using for your third party your third parties setting up those apis and the scope of those services so the access permissions are are set correctly and your apis are set correctly and then of course for your users again the MFA is in place for both administrators and for any of your regular users and your customers um so again just a you know a baseline security and something for you to go

back go back and look at your environments you know am I doing these Baseline security things appropriately uh am I missing some things because this is the most important stuff that you want to focus on all right so hopefully this helped us to kind of paint the picture of you know what is a minimum viable security approach look like and what are the minimum controls that we should focus on um but now you know looking at you know what are the types of uh you know vulnerabilities and risk and issues that we could potentially detect you know around these different areas uh from a minimum viable security perspective and how we utilize those tools all right so

one of the things we put together at jit is one things that we're doing all the time is we're evaluating tools and I think that's another important piece is that you know your your tools and your in your environment it's not always going to stay static you know you might make a technology change you might have a re-platforming um you know there could be a need for um you know kind of a tool reevaluation process tools get better and worse out there as well right so it's important that you're you know you have a regular process to evaluate your tool your security tools to make sure that they're the best fit for your environment um and you can make adjustments over

time as you need to once you have that process again here's a simple process that we've utilized to select which tools that we like to use at jit right first off we'll look at the various risks associated with our environment um we want to avoid things like SQL injection for an attack creating act you know level of access into our environment how do we uh you know potentially avoid that risk or mitigate that risk we want to validate the data input so we um you know from a security requirements standpoint and then we'll pick the appropriate tool so for example we like oauth zap to be able to help from an external perspective and we're

running external scans uh you know web application scans and API scanning to check for this risk and then we run those tests on you know tests and scans on a regular basis so here now we're going to walk through you know looking at some of the different security tools based off again that minimum viable approach um and you know what you know what tools that that we recommend that we utilize and why so again back to looking at your your code um you want to make sure you don't have vulnerabilities in your code so using tools like static code analysis scanners that's an important step there's a lot of static code analysis tools out there

one thing I'll say that a jet that we did is you know we evaluated um open source tools we evaluated you know proprietary tools you know you know uh you know tools that cost money um and we found that in a lot of cases the open source tools actually perform just as well if not better than some of those expensive tools out there so again that's an important step of your kind of tool selection process as you go through but looking at things like static code analysis um yeah we found a tool sub grab out there again open source free anybody can use it we found that you know semgrab found you know more you know to say

fewer false positives more exploitable vulnerabilities even in comparison to some more expensive tools out there like a sneak for example uh so we really like stem grab and there's other reasons why we like it too uh you know 2 000 rules there's a ton of rules out there you can utilize for stem crap supports oil many different languages across the board it could run everywhere so it was a developer it's easy to use uh super fast to run static analysis with subgrap it's extensible different output formats that you can utilize and it's it's easy to configure so this evaluation process we said hey Sim grab meets the needs for us it's a free tool out there anybody can use it it really

helped us to find you know more exportable vulnerabilities in our code that we could fix uh also around our code we want to make sure that again back to the secrets uh in Secrets manager is it making sure that we don't have hard-coded secrets in our code it happens all the time right it's one of the most common uh exploits out there is the inadvertent or malicious um you know um exposure of your of of your secrets so you want to have the appropriate scanner in place that's going to detect those things right uh your tokens your AWS keys and again evaluate different tools out there back to open source get leaks uh we thought

was a fantastic tool that found um you know found the most real Secrets out there the fewest false positives in our in our environment and so again it supports many different types of Secrets out there API Keys ABS credentials uh you know it supports in your git history so not just your current code sometimes you maybe you you fix something but you've got old secrets in your git history get leaks will find that you go back and fix it uh super customizable again to know for to ignore known false positives uh and Best in Class accuracy right so again an open source tool free for anybody to use uh but just just as good if not better than a lot of those

tools out there that cost a lot of money uh talking a bit about uh you know again software libraries and dependency checking uh again looking at your code but we want to track those third-party libraries and and understand what vulnerabilities are are uh you know potentially present in our software Library so we want to use a scanner to be able to detect those vulnerable vulnerable libraries um and this one is this one's a new one again I talked about changing tools all the time and you know all the time but you know you gotta you know your threat landscape you want to have that process in place to evaluate if your tool is the right fit and we really made a change

we're pretty excited about this one again open source tool but it's by Google so Google's been managing this uh osv open source vulnerability database for some time they recently released I think it was uh in January of this year so early this year a scanner that runs on top of the osv database um and uh and we love it uh you know for those reasons again it's free but managed by Google they're updating that osv database all the time so we have a lot of confidence that the latest software libraries out there are being detected uh or vulnerabilities with those libraries are being detected and being notified through the scanner um supports you know many different

languages so you're covered from a language perspective uh can run anywhere easy to use as a developer to be able to run these scans um you could you know against scan specific s-bomb and then you've got a software building materials and then multiple options and running the osv scanner as well now a bit about the infrastructure and infrastructure misconfiguration you know this again is a super important control again going back to that minimum viable security approach is that you want to be able to and again I don't know why this is the case with Cloud providers we love we love cloud makes our life you know you know a lot easier in a lot of ways but a

lot of those default settings out there you know why you know SC buckets are are publicly accessible you know why some of the you know different uh default settings are are you know making us more vulnerable it's a challenge maybe the cloud providers like it that way uh because they get more uh Professional Services we want to detect those uh infrastructure misconfigurations uh you know as they happen so we want to run a scan across our Cloud environment and detect those again we looked at an evaluation of different tools and we found another open source tool that there's a fantastic job of Finding Your Potential infrastructure misconfiguration operations in your environment it's a tool called Kicks

and if you know some of the facts here about kicks it's constantly being updated right so there's 2 000 queries out there that it's checking for so you know it's checking for a lot of different potential misconfigurations out there uh supporting many different Frameworks it's being updated all the time so this is there's this nightly build um and it has all these different built-in remediation recipes so not just finding some of the vulnerabilities but helping you to fix those as well so we like kicks a lot to help for that minimum viable approach from an infrastructure misconfiguration perspective all right now a bit you know pen testing I know you know pen testing can be

viewed you know different ways uh of course there's kind of the more classic you hire a pen tester um you know they're going to come in and you know perform different types of tests the best pen testers utilize different manual process to build detect vulnerabilities across the board but there's a lot of pen testers are using automated tools as part of their first step you could do a lot of that as well if a minimum viable security approach to detect to detect vulnerability so um you're looking at pen testing you want to simulate those attacks on your front end your publicly accessible uh environments you want to utilize appropriate uh you know web application scanners to be able to um to detect

those vulnerabilities and fix those um and for for again looking at open source um there's some you know there's some good tools out there burp suite's a great tool we like zap a lot um zap's been around for quite some time I'm sure many of you I've heard of Zap um you know it's it's supported by owasp uh helps detect those top 10 risks um it's got a ton of rules out there it's been around for a long time um it's supported by Simon Bennett's if you know Simon he's been you know leading the the uh zap project for a very long time so a lot of consistency there you could run zap pretty much

anywhere um and it's got all these different extensions so there's all these different kind of tests you could do with zap so all the different kind of flexibility was that uh we were like that and again it's free for anybody to use so you know that that's a really nice feature you know up next looking at your container images in your pipeline when you're building your container images you want to make sure there's no vulnerabilities in those base images so you want to run scan you know against your your Docker file images um and be able to detect vulnerabilities um in the environment so again we looked at you know different open source tools we also looked at some

proprietary tools we found that you know trivi again another open source tool does a fantastic job of finding vulnerabilities you know fewer false positives and more exploitable vulnerabilities um you know supports running you know a lot of different types of files so container images file systems uh you know trivia could do a lot it can also generate an s-bomb so it could do other things than just scan those base images super fast to set up it could run pretty much anywhere so we love that flexibility about trivia and then from a multi-factor authentication perspective you know looking at our third parties we want to make sure we have MFA set up and again looking at kind of a simplistic Tech

stack you know make sure we have MFA enabled on you know for GitHub uh AWS and Google and uh you know enabling uh MFA we have we've actually put some custom Tools in place to be able to check to make sure that we've got MFA on all our third parties so it's no open source tool that we're utilizing today but we've built some you know custom scripts in-house to build a check and make sure we've got MFA turned on for all our third-party access all right well I hope that was uh helpful to kind of go through some of the tools right and you know I think for maybe for a lot of you the minimum

viable security approach you're like yeah yeah I get it and hopefully you're doing that but maybe just a quick refresher on on things maybe you potentially missing something but then I think what's you know fantastic about this is all these open source tools that are free for anybody to use are out there for you to be able to detect vulnerabilities associated with that minimum viable security approach so you can detect these vulnerabilities you can fix them in your environment uh you could have some comfort that you've got those Baseline controls in place uh you know without spending you know a ton of money on all these proprietary tools um now I I kind of gave the the answers

to the test in terms of tools that we that we you know we picked uh that we're utilizing uh but again we went through an evaluation process and you know our Tech stack is you know we have AWS we utilize GitHub you know uh you know we have a set list of third parties that we utilize so we you know uh there's a there's a mentioned earlier earlier talked everybody's kind of a special snowflake a little bit so which is you know which is true um so the tools we picked maybe we got the best tools for your environment so how do you go through and pick which tools that you want to utilize uh you

know to help you kind of build your tool kit and change over time as well um so there's a few things that we look at to help pick the tools you know one is that result quality and I touched on this a lot is that uh you know one of the great things about a lot of these open source tools we did a lot of analysis and the you know the research part of our company we had analysis to make sure that we're reducing those false power minimizing the false positives and having a real exploitable vulnerabilities are being detected that's of course probably the most important thing on a tool because if you're chasing false positives you know

never fun for anybody the developer experience that's super important too you know again our mission is to empower developers with security that developer experience that utilizing tools it's got to be simple right you gotta be able to turn it on set it up run the scan you know if it's too complicated to be able to configure and and and utilize your developers aren't going to use it right plain and simple and don't they shouldn't use it quite frankly uh the maturity of the open source Tool uh and this is really more of a of an open source thing but you might have some concerns is to say Hey you know is that uh open source tool is it is it

going to be there for the long run you know maturity is an important point there to kind of evaluate if you're going to go the open source tool route and then customize customizability of the tool right you know could we uh based off our environment we have you know set up the tool the way we need to to again to avoid those false positives and find those real vulnerabilities that we can act on in our environment and reduce risk across the board uh so you know here's a double click on those those uh those different criteria and I think this can help as you think about your tool selection it might have I picked the right tools right or did

you know maybe a previous regime in your company picked the tools or someone else that didn't you know didn't have didn't know a lot about the environment with the tools maybe you had a good relationship with a vendor or there could be a lot of reasons why a tool was selected but kind of going back and checking this could be helpful to say hey if we picked the right tools the right way uh looking at that result quality again you know the false positives and false negatives uh you know running the tools on your code right and then vulnerable repos is the second option that's an important test there right and it's um you know running running some of

those tests yourself uh and then comparing those results uh between between tools so I get it not everybody has a research arm is part of your uh you know is part of part of your teams but if you could do some simple checks right to say Hey you know this tool works better or you could you know look at some of the leading practice uh thought leadership out there in terms of of tools that are right fit but look at that result quality right are we getting the best result if we're getting too many false positives is it time for us to you know think about changing the tools that we're using uh from a developer experience

perspective again you know talk about how important this is if you want to empower your developers with security they have to be able to use the tools right so they run everywhere the developers work fast easy to use the results are you know easy to understand human readable or machine consumable and run the tool yourself right make sure your developers like the tool they like the look and feel get their buy-in right I mean that's an important piece they'll just give them a tool it'd be like back in like KPMG days and be like here's the best of tool just go use it and the developers hate it right it's never a good situation so make sure you can the

developers run the tool themselves and they're comfortable with it uh and then that maturity piece um and again you know I'm focusing more on the open source tools but it's still you know relevant for some of the proprietary and paid tools is that you know is that tool popular right so you know from an open source perspective you can go you know look on GitHub you know see the stars the forks the Watchers you know it's like the restaurant reviews you know before you you know before you grab dinner tonight you're gonna go look at the Google reviews you know especially for an out of town or like me I live in Dallas I'm like where do I go

in Knoxville I'm gonna look at the restaurant reviews and and is that how I'm going to pick the restaurant ask them to you too where I should go um but it's an important input right so that kind of um you know kind of the general Public's view on that tool can help you say hey is this tool accepted out there is it is it utilized um you know is the tool uh owned and actively contributed to um like for example I talked about kicks earlier right and I said hey there's this nightly bills and all these two thousand checks you know that gave us Comfort it's being updated all the time right the tools owned it's an active

tool it's not you know out there you know orphaned or not being actively updated you want to be in particular with open source tools You'll Play pay close attention to that and then the other thing too open source tools you got to be careful is it okay do I get just a small piece of this tool and then I have to pay for the rest of what I really want and is that going to change over time from a licensing perspective so that's an important point there too and that that's something that you you know you could you should be aware of so it's good to have sometimes have you know a Backup Tool uh two or three right

to be able to uh to make that decision and the customizability piece right um You Know It took the reusability Paradox right the more generalized generalizable something is the less utility it has right but you still just want to make sure that you can fine tune that tool to account for how your code practices you know your languages the processes that you're you're you're utilizing that tool needs to be customizable enough you know to meet your developers needs all right so I hope this is all kind of coming together for everybody talking about you know Baseline uh you know security practices that minimum viable security approach hopefully that was again that was a lot of review for most

of you but if you're missing anything hopefully you say I'll go back and check that and then some of the tools that you can utilize to be able to again oh an open source tools for free tools you can utilize in the process to be able to pick those tools to to detect vulnerabilities your developers could run you know why you're developing uh is an important step and here's just a quick view of uh that minimum viable security plan right so you know within your code you know your code uh vulnerabilities Secrets appropriate logging you know those vulnerable libraries out there your infrastructure your Cloud misconfigurations loose privilege access your runtime again that you know pen testing API security web

application scans uh your pipeline your vulnerable containers least privileged access um your data appropriate data encryption secret storage uh you know third parties multi-factor authentication you know secured access in terms of scoping those third parties your people you know you've got you know password manager in place uh and then your operations that you've got appropriate auditing logging uh and backups uh again just some baseline things it's a good practice you know for any Progressive um you know any Progressive organization out there to make sure that you have in place from a security perspective you can maintain developer velocity uh your developers can own security and ultimately it can help your product go grow while you're still embedding

Securities part of your process so um I do want to share a bit um and and about our product at jet because one of the challenges that we had as we said okay this is this is great I understand my minimum viable security approach and I could build from there I'm going to pick certain tools to be able to you know and have my developers run those tools as part of their development process to take those vulnerabilities and they can fix those vulnerabilities but the challenge that you have still is you're maintaining those tools um you have to you have to run those scans on a regular basis you may have to create something in-house to be able to

manage all that in terms of from a security perspective that's what we build a jit right is it an orchestration platform to do all that for you automate all the scans run all the scans you know when you need to and again we're an acronym for just in time because we're going to detect those vulnerabilities is your detected sorry is your developing uh developers can see those vulnerabilities no context switching that's the other thing you don't want to log into some other tool get the vulnerability then go back to developing once you've done that how much time have you wasted and developers hate wasting time for good reason um so share those vulnerabilities with them in their native environments you

know in GitHub you know where uh where they're actually developing GitHub and gitlab and bitbucket where they're actually developing make those fixes you know while you're developing you know that's the way to do it so um that's what we have at jit but what's important to note is that you know we haven't necessarily championed any single tool right we I went through the process the tools that we like the evaluation that we went through with the tools that we picked you know we like them for our environment but again you may like different tools and I I'd encourage you to look at that with your vendors is that do you have the right Tools in place because we the word open

orchestration platform so you can bring any tool into our platform and you can orchestrate that it could be open source it could be a you know a paid tool for example but I think that's an important point is again your tools may change over time um and as they do you want to be able to make those changes quickly and having a platform that's extensible we can make those changes you know is a really important part of a security program it helps you to again maintain that developer velocity and detect risk and vulnerabilities at the same time which is what it's all about all right well that brings us to the end I hope everybody enjoyed the talk

um you know I love to take some quite we got some time here too uh before the next one so I'd love to take some questions but you know again back to the you know Peter Jackson thing he's got next the next steps on his journey you know I heard he's got like another Beatles ask documentary on some other lost footage he's gonna pull together which is kind of cool um you know we're doing the same thing right we're evaluating different tools all the time and looking to um you know add different tools um different capabilities from a security perspective you know it's by starting with that minimum viable security approach but growing all the

time and getting better and better and stronger and stronger uh so thanks everybody for your time I I do um I brought some uh eventually we're a startup from Israel uh I brought some jit swag which I uh I'd love to share with you just a little bit um but uh you don't know you'll have to ask a question to get it you're welcome to to grab something but if there's any questions out there um um let's take your questions now

any questions for Chris yeah well what distinction if any of you can be nearly testing software applications and software services apis and Microsoft yeah I think the key there is that uh it's a good question and the question was around uh the way I look at is securing your code and then some of the you know runtime checks that you're running right so you've got to do both right I mean obviously we want to shift left we want our developers to fix vulnerabilities as they're developing that's going to help us be more secure but uh but that doesn't mean there's there's still not going to be vulnerabilities why your applications running and runtime so you've got to do

both right so the way we handle that is we're running all all the uh like the code scanning checks constantly right so for every commit every pull request we're running our security scans detecting vulnerabilities and sharing those results with the developer so they can fix those vulnerabilities then then we'll run all like the runtime checks like I showed zap like over on zap daily right run zap every single day or if there's a major change we want to run it more in the daily we could daily is pretty good right but we'll run it on a scheduled basis and it detect those vulnerabilities in our environment and then from a runtime perspective sure um I think I asked is you know I

actually just I just had a conversation about that recently I think it's a it's a good practice um one thing we haven't figured out is kind of how to orchestrate an IAS tool in our kind of tool toolkit right so it's a kind of a separate thing um to be able to to but I think it's it's an interesting thing for we're evaluating it something we're looking into yep right any other questions out there from the group well if not again thanks everybody for your time this has been a blast to be here in Knoxville you know great group of people we got a few more talks so looking forward to talking with all you

uh later on foreign [Applause]