The Clutter That's Choking AppSec

okay

okay so i think we can give you a um a star on your presentation so first of all thanks for being here didn't you participate in the besides barcelona it's always good you know to see presentations around absec so yeah the the floor is yours all the best thank you so much thanks for having me here it's the first time i'm glad that you'll be part of this uh presentation this time so uh welcome everybody to who is listening online live now or later on at the live streams recording through the presentation um the clutter that's shocking upset uh before we get started a little bit about myself my name is one of the co-founders of p45 um we are

an application security company essentially kind of helping um product teams across the world in terms of implementing and scaling application security uh programs um personally uh things that keep me at night keep me excited uh in the aztec world i think around up against security automation more recently express modeling and the way it's just modeling kind of changes integrates with security testing and other aspects um also a lot in terms of vulnerability correlation vulnerability management things like that so uh for all the enthusiasts who share a common interest in any of these things that you see on screen happy to connect offline and have to reject more of these topics um so a little bit about this presentation

so i made this presentation first in uh i started working on this presentation way back in november 2019 and ever since i've presented this in at least 15 different venues across the world and every time i make this presentation the impact that it has on people are very different um when i made this the first time around each person i used to obviously kind of get a lot a lot of uh feedback in terms of people who had multiple questions and people uh who couldn't really kind of associate it with it um differently but since we're doing this virtually the last two years or so things have been a little bit different but yet um for those who are on the

program right now um so my intention here is that even if you are in any part of the product engineering you're a developer you're an architect you're a devops engineer you're a social engineer my hope and aspiration is that there's something in this in this presentation that you can personally kind of take back uh from an implementation perspective so having said that let's get started so i can start off uh really having a look at how product engineering has kind of moved on or has evolved over the last couple of years and some of these things are not uh something that's uh you know uh really brainstormingly new or something like that but still there are some

very interesting developments that have happened um obviously tvs are going a lot more in terms of agile than waterfall and i always joke that there's always going to be a group that is agile fall which is between waterfall and adults and we're also seeing a lot of accelerated deployments in terms of fabrics that are enabling teams to take applications uh to the cloud especially with the identity of the rocks so i'm talking about things like uh both cia both on the ci front and the ca front so you're talking about more uh github actions based integrations of the ta perspective and also seeking a lot more calculus helping us deployments like things like chest and puppet and ansible

uh that are being more seen in terms of content deployments in terms of share the the architecture of apps itself is that obviously we're not looking at a lot of monolith apps anymore we're seeing a lot of more of multi-tiered approach to application architecture which includes a lot of micro services and serverless stacks that we've seen as opposed to really large chunks of apps that we used to say a couple of years ago and then they've also seen an increase in terms of third-party libraries and that's quite evident with the advent of more fca platforms that have become that have become very relevant over the last couple of um to you guys as well so all this from a testing perspective

uh has also led to a more automation um when it comes to not just functional performance but actually i see from a security perspective as well you know a lot more in terms of um testing and automation that we've seen um in terms of just the application delivery landscape we actually see two distinct kind of um ecosystems so i typically consider i usually when i make these presentations in the u.s i usually compare it to the west and the east coast of the u.s right for example let's take a typical silicon valley company in the bay area somebody who's 200 employees somebody was working on a product they have multiple deployments in a particular way they probably have

lesser number of applications they're probably working on four or five or ten core applications but you see continuous changes having uh do those 10 applications so you're seeing multiple deployments in a day and therefore multiple deliveries so that's one view of the world now consider a large enterprise let's say a bank or a financial institution or a large retail organization they might have hundreds of apps that probably even have 500 apps but those apps don't necessarily undergo the same kind of deployments as the other example that we saw so you're probably looking at one or two deployments in a quarter or something like that so even if you consider both these views of the world one thing that's common is

that the number of deliveries are more for example this year you have 10 applications with a daily delivery but there you have 500 applications it's probably one terribly a month so either way the application delivery model has kind of really kind of uh moved very further and this we're talking about it at a time period now but when i remember when amazon moved to aws uh a long time ago they used to develop and deploy applications once at 11.7 seconds uh and i'm sure that's something that's gone further as we speak uh right now there's a third kind of uh uh groups that fall in between both these views right so you could there are there are

usually companies who are product companies who actually say that they probably have like a 150 applications uh in their portfolio um and with the advent of devops and with the advent of um application security automation they actually are in both of these worlds right so they have massive releases and with these masterpieces comes a lot of challenges now obviously this is a this is a a an image that a lot of us are familiar with with a lot many conferences this is obviously the partners in finite loop um of devops and designs now i'm not really sure about the rest of the folks during the call but me personally and there's not even a week 45 opinion but this is

the personal rahul's opinion is that i find this image be really really confusing and i don't think it really is as relevant to the current way in which we see african security so what i've done is i've kind of tried to give a different representation of what devops and that's the culture and this is what i would call uh the true definite cosplay device model so what you see on the top of this image are the typical application uh product engineering process that you essentially plan code with test release deploy and monitor and what you see on the bottom are the typical phases of security so what you see in the process product engineering what is your

department security engineering which is actually threat modeling analysis data analysis infrastructure as code and finding security uh monitoring and impact detection now what i'd like to do is i'd like to really kind of give a color code of where we see the security engineering process to kind of fit with the appropriate product engineering process for example thresh modeling usually started off as an activity that was performed in the planned phase in in the place where people would probably do a design or an architectural review architecture really come up and say let's look at the blueprints that probably

so that used to be threat modeling purely in the plan phase but as they keep moving with it with security as a code we are now in a space where you could do strict modeling as code and that's a different presentation that i do i would love to talk about that on other days but with the advent of things like modeling this code and things like marketing more towards the developers community we're actually seeing threat modeling moving from the plan phase moving to a little bit into the core phases and that's where you see a little bit of orange uh in that code uh fast and that's predominantly a code builder test therefore you see that

completely uh taking over to test and and so on and so forth uh i don't want to go through the entire image here but you guys you i'm sure you get the idea in terms of how the security process is kind of finding its right way in terms of the proximity process and the reason i like this particular diagrammatic representation is the fact that every time i do a presentation the color code changes because at that point in time in 2020 this color code looked really different and therefore the whole ship flip model was very different than in 2021 where you have a lot more advancements and a lot more experiments that have been done

in terms of taking code closer to security so therefore you see the fact that a lot of these color codes will keep changing as the years move by depending upon the kind of advantages that we make so therefore the current state uh the devops in the left half movement is really picked up right so businesses across the plane want to move faster they want to go to the market faster and therefore their pickups amongst other things on the screen that you see here has led to a lot more in terms of tooling it's it's seen an increase in ci toning it's been an increase in test management build management deploys voice deploys and so on and so forth uh and therefore

security too has kind what we used to call it as a gatekeeper function uh today much more uh relevant and being able to kind of embed itself in terms of different parts uh within the project engineering landscape and people talk about the security champions program which really is that it's the up and spoke model where you have a centralized team and it has satellite squads uh off the center security team who kind of embed themselves with the various uh members with the adulting but all this means that we're moving between using more tools than what we're using uh when security was a siloed activity and this also means that there are a lot more integration

between tools and also between one unit and another and so these are some reports from the 2016 2017 year and they eventually kept that uh quite dated because i wanted to see the contrast right for example uh if you look at here like mature does check out shop run almost 300 scans a year and this was way back in 2017 and back then you had 3 000 vulnerabilities that were disclosed but if you look at the kind of time that it takes for people to kind of fix those issues on an average it's 34 days and that's really the problem because the more number of vulnerabilities that you find it's going to overwhelm the system in

terms of being able to take corrective actions to fix those vulnerabilities and that's that's a problem statement that i just want to leave it there for a moment i'll come back to this a little later but i just wanted to kind of give you some context in terms of the downside of potentially kind of increasing tooling and just focusing our attention a lot in terms of just finding issues as much as it is about fixing those issues and in terms of diversity and and scale also we've kind of really kind of seen a lot more changes today you're testing servers you're testing containers you're getting applications you're testing api services databases orchestration services cloud services and then you

have third-party libraries and all of this really means that with more tools uh there is a lot in terms of information overload that security engineers are having to deal with right it is not like the days old where you just had one map and you probably had four or five components that need to test the process uh right now with with the architecture kind of changing as much and with so many testing being done there's really a lot more that you need to kind of uh assess and therefore look at and therefore with that information overload we have some challenges we look at some of them in more detail but application security teams themselves have some serious security

have some serious constraints in terms of availability right in terms of time that they spend in terms of triaging issues sorting issues and so on and so forth and there are concerns in terms of tools like we can see further as well there's some major inconsistencies in terms of the results that some of these students give a lot of us in security engineering still don't know how the best we can integrate ourselves in terms of engineering workflows so there's a big business there's a big gap in terms of security engineering and product engineering in terms of technological uh integration and finally you have an issue in terms of managing vulnerabilities and remediating fundamentalists themselves in terms

of the sheer one of the biggest issues still considers to be bandwidth right within the african security that's quite evident in terms of the number of job posts that we see on a daily basis people calling affiliate security engineers to come and join their team and even today the business is moving higher they're hiding more deaths they're hiring more agile project managers more office folks more cloud engineers but no one no one almost from an exclusive security standpoint uh and and something that you've noticed in a lot of forums like these uh i mean not just here let's say even if you're doing meetup groups and things like that people really have a lot of job openings

for our video engineers which is great but then the reality is that when they actually go and start working their expectations and what they're supposed to be working on are quite different and just to talk about that i just have i just want to take an example of a small story here in terms of how a typical security nurse talent is spent so let's say for example this is someone called jason um and just obviously a fictitious person let's say that he's joined this new uh digital product company let's say in the banking space as a as a security engineer um and and let's consider what somebody an african security a day in a typical week would be like a couple of

months down the road so couple of months down the road this jason is asked to take care of security assessments which is okay then you're supposed to kind of help your developers remediate those fine things which is fine but you're in the backing and industry sometimes you get called down to the ciso and you're kind of asked to help in terms of compliance orders from the security perspective um you're also you're also involved in drafting security reports then you're asked to onboard tools you're being fixed modeling you're automating tools in ci cd validating for those fixings reviewing those fixing and you're doing so many things almost with no time that you have to focus on your core domain

which is that of security research and with all of these things in place we still ask and we still told that we need to continuously test for security right and now jason the gesture is not happening so it's not the same json that we saw earlier right because now he's disturbed uh and that's really what happens when this new world of update security uh with all with all of this automation and things like that coming into perspective it kind of changes the actual uh reason or the actual course objective of a security engineer right and but today we're not going to be looking at all of these things right we're essentially going to be looking at

one major issue which really is that of managing vulnerabilities and that really is the crux of my talk which is the cluster and the clutter um in application security which is that of managing possibilities and i often say that an applicant's security program is only as efficient as managing the vulnerabilities that come out of it um and i i mean what really is the point of having all these amazing tools and platforms and teams the processes if software vulnerabilities cannot be efficiently generated they can't be categorized they can't be shared they can't be remediated or even worse finally prevented from getting back upstream into accordingly right and this clutter is probably the most significant reasons

that prevent uh products and security gains in not being able to bridge that proverbial gap uh between the ideal and the practical of uh of right um and we'll be able to kind of increase what we like to call the secular product through throughput uh so let's leave this a little further uh into this clutter but before we do that it's essential that we understand what really is the anatomy

have been in the security world for a while but trust me it is really important that we understand the difference between these three concepts because the number of times i've had people confuse these three things these concepts is quite significant so before we start looking at uh what uh the cwe the stuff what the vulnerabilities are let's take a look at what cwd cde and cdss are because i think this is very important for us to kind of move further and also take an example that you know these three things are something like recorded groups right we all know that they're important but you don't know who is what child especially if you remove alex

equation so with these remaining three brothers you really don't know who's uh what so let's do a quick 101 in terms of uh these three concepts so the cwe is the common weakness enumeration right and this really is a system for categorizing software vulnerabilities it has over 600 categories uh including specific categories for buffer overflows parts directory traversals race conditions such as 15 hard-coded passwords uh insecure random numbers and so on and so forth so every time you find the vulnerability that vulnerability be categorized under a particular bucket and that bucket is the cwe now the cvss which essentially is the common vulnerability scoring system that is really a way for you to categorize the security

of one property right it is a free and open source open industry standard uh which kind of helps you assess the security of a computer of a security vulnerability and cvss really kind of attempts to kind of assign security scores to each of these vulnerabilities so that you can you can understand which needs to be remediated first which we should be prioritized first which gives you that second and third so that's the seriousness and the cde is the common vulnerabilities and exposures which really is a dictionary type list of standardized vulnerabilities and things every time there's a new zero-day attack that comes in it will find an entry in the cve and then it would find

an entry potentially once this if it's a web application attack could essentially find uh usually find a space in the cpu under one of those categories as well so this is really what the cwe and cbss and the cvtv and like i told you this understanding is really important for some of the next slides that they're going to look at so we talked about the issue of tools right tools are great we've got a lot of tools in african security they're great they make our life easy they're able to find flaws and ways and approaches and generate the data required to find these things that manual testing might not be but there are some inconsistencies

a lot of them both open source and commercial have a lot of inconsistencies in the name the way that they produce the data for example two tools could provide the same vulnerability but different names they call it differently they have different verbiages most tools kind of accomplish these results based on the cwp but a lot of crews don't even give you cwc example open source tools they expand it with embracement uh these are tools that don't give you results that have a cwp uh number there so how do you kind of correlate this information there's no way for you to kind of backtrack the vulnerabilities from from uh from these tools and with the nomination

and some of them don't even give you the taxonomy for example you don't know whether a particular issue relates to an oas vulnerability relates to a fan structure where there will be there's some kind of taxonomy to these vulnerabilities as well and let's see some examples so let's say for example that you're running a staff and sca and adapts and let's say that you find something like a sql injection now there's a good possibility that each of these type of tools would cause equal injection in three different ways for example a lab or a verb might call it a blinding sql injection a class you might call it a time-based sql injection and then you would find probably have other

kind of massive inconsistencies because really when i say this they literally tried doing this for almost a year when they're building our own intelligent correlation system which is orchestra um and we tried really every combination of the book right you've you've tried streaming matches they're trying intervention distinct algorithms we've tried ml algorithms and all of these provide a lot of these inconsistencies and what's worse is within web application scanners let's say you put an infrastructure or a network security camera like a national uh or something like that now nessus will give you three ease they don't even give you cds and then

now this is the result between acunetix and check marks the one on the top um is kinetics and the one on the bottom is a result from check mark that's obviously from a uh from an intentionally vulnerable app so don't worry if you see some code on the screen now i just want to focus your attention to see the e79 both these ones both these tools are on the same issue cw 79 is called by the academics as vulnerable javascript library but in check marks the same line of code the same cwe is being called as respected crossfit so the same line of code same cwe but called differently by two different tools this is cwe 693 the result on the top is

the app scan and the result on the bottom is our standard good old friend birth now appscan causes vulnerability insecure cross-frame scripting and work causing protection mechanical failure now imagine you give this result to a developer ask them to fix it they would look at this wonderful two different tools and they would have nothing to say that they had the same issue they would think that both of these are two different issues let's find another example now between two fact platforms the one on the top is function bugs which is an open source platform and the one on the bottom is very cool right uh we're talking about the cwe89 it's called sequential it's a secret

injection vulnerability but look at what they call i mean findtech books calls it non non-constant string pass to execute blah blah blah and then paracord calls it neutralization of special elements using that skill command right and finally we have an example where you don't even get a cwd right this is from node.js from the top and zap on the bottom uh that tells you that it's the sequel injection vulnerability it gives you that cwee 89 which all of us know but no js doesn't tell you anything it doesn't even tell you what that vulnerability is so how would a security engineer or how would a developer especially when you use so many tools in automation how do you try and get that

centralized view is that really the problem that you're kind of dealing with and the worst is when you run this in scale let's say you have a nicely built or a daily build and there is and let's say that this is a very simple kind of an architecture you just put you're just going to give people then you have a band-aid an sda as a app but this is a very simplistic view of the world usually you would have a much more complicated kind of a genetically fight um and then let's say if we daily build your nightstands and the kind of data that would get generated is just phenomenon and imagine you have to go through that

data on a daily basis just to kind of find out what those issues are it's not a simple task right let's also talk about some contributors that make this even more difficult first is the issue of false qualities right you cannot eliminate the soft hormones possible that's something that they want to talk about or actually you want to stress i mean if somebody's saying that they can eliminate false positives in african security you can't all you could do is you can reduce the effect of past positives right and therefore if there's a way for you to kind of de-clutter the results by showing false positives separately that crystal makes a lot of score for example burp gives

you something called a scanner confidence index uh i don't know whether other tools do it but i know for a fact that birthdays is every time you find an issue in birth next to the issue is give you a confidence index so based on this conference index you will know how uh impact or how true that particular uh vulnerability is so first part is again is a big issue the second issue is in terms of prioritization or security right different tools give you different prioritizations in terms of how severe a particular vulnerability is and especially you need to look at security in context your application in your particular organization so because i can't take two

applications and call sql injection of both these applications in the same priority in one place could be a critical girl in another place it would cause even medium depending upon what the impact of that vulnerability is and finally the issue of remediation strategy right in terms of how do you eliminate that vulnerability most tools will give you a very standard cookie cutter appropriate approaches to remediating vulnerabilities but again we all know that that doesn't work quite well because developers need to really kind of have more than one option to find and fix those issues it doesn't make sense if you just keep them sometimes remediation could be incorrect or sometimes remediation strategies could be insufficient which means that

you need to give them um an alternative view or an alternative idea in terms of your vulnerability so that could also be an issue that comes across so with all these things we've talked about problems all this while now let's talk about a solution to this how do we potentially declutter this now obviously there's no magic pill approach application security is not a one-state fix all so therefore the solutions to update security is not also one-size-fits-all it really depends on the context but i do have some ideas that i want to float around around the room and see what uh which of these things work right the first thing uh is simply the issue of

i'll be able to do two things very clearly five bucks early and six bucks early this is really the motto this is the mantra that secured engineering teams who need to follow uh for a more uh uh you know well-washed well-oiled missionary for the journey if we can kind of focus our attention towards just anything that we do with it needs to fall under one of these two buckets it either helps security engineers find bugs early or it helps developers fix those bugs right right uh if you can kind of have this outlook to kind of help us in terms of what we're talking about i'm sorry the first thing that i want to talk about is vulnerability correlation

or most automated contribution uh now going back to a previous discussion let's say that you have a string of tools eta that runs on a nike across all of these tools uh now correlation platforms essentially kind of help secure the engineers issues uh without them personally needing to say okay so here is an issue from that this state is equal like i have something else from that it seems like it's equal i want to put these both together to see the same button so coordination tools do that uh they are able to identify results that come from multiple tools that they're able to kind of correlate those results and there are some uh there are

some examples of those i'm not going to name those two because i don't want to make it sound like this is commercial but you can actually go ahead and look at a lot of open source and commercial tools out there that helps you correlate the responsibilities right uh because if you remember the previous slide that we saw uh we saw as to how different tools provide different uh different profiles right for example um let's say you have a source composition analysis run finding a particular tool they are right they are widely different in the way that the staff would find that issue for example an saa would say that it found a particular issue with the nested

dependency in a library level down for example say an encryption library uh that users say a triple test has a particular issue with the basic 64 implementation in that library and something like that so that would be the world of review that an asda would give but a sash will give you a completely different view of the world give you a line number where an issue exists so combination tools essentially kind of helps you put these various data sources together in terms of um the other thing i want to talk about is security as a code uh now we've always talked about the fact in all security conferences and talks we've always said developers need to

understand security and this is something that we've been talking about in the last 10 years in african security now i want to change this statement we're talking enough about the fact that developers need to understand security but i think we need to now ask security teams to understand code and that's the fundamental change that needs to come abroad yes developers have been trained to understand security they've done security courses they've done all of these things but how many security engineers actually understand code how much of how many of them still write code or read code at a fundamental level right because if security is able to understand core a lot of these problems get solved for

example they can write explicit scripts and expired scripts actually help you take a particular security business logic flaw in an application security clause and then be able to kind of write the selenium script around it or to kubernetes around it and add it back to a security regression that is possible uh with reset which means that just like how functional testing has functional testing suites security testing can also help the journey distance that's the possibility if you're able to kind of write code uh you're also able to give very very focused remediations or alternative limitations therefore being able to you know be more empathetic towards developers be able to kind of talk to them with the same language

as they do and therefore you're able to kind of get into that community a little bit as well so that's another advantage of of having to go uh the third thing that i want to talk about is that of cross training right uh and what i mean by cross training is uh the fact that we talk about security and engineering in two different silos and things like that we are doing a lot of work in terms of bridging that gap from a technology perspective i think there's also a lot of bridging that needs to be done from a cultural standpoint and part of that is being able to kind of train so when we talk about training

i just don't mean training as a point in time activity especially in terms of product teams you have a lot of people let's say that a typical product team would have a developer group they would have a qa group they would have a automation or a devops group and they would have a security group now there is a lot of skills that are transferable amongst these people so there's a lot that security can learn from qa there's a lot that devops can learn from development there's a lot from things there's a lot that qa can learn from security there is a lot of need for cross-functional training and this training would kind of help build a lot

of efficiencies within the existing client organizations itself so you are able to kind of not just look at vendors for all things but you're also being able to develop internal capabilities for us to tackle a lot of application problems and that's something that we've been talking about for a lot so so training should be more of a reference right and

they would go ahead and refer to case files they would go ahead and refer to previous such instances that have happened so training needs to be like that training program needs to be something that developers or private engineers are able to refer to and not something that they just get certified against or just something like uh something that they need to do right so i often say know what you need and not what you need to know right if it's always important that you need to have some skill at a point in time that is relevant to the kind of work that you're doing i've also seen a security champions program be very effective and we talked about that a

little bit earlier as well where you said that you could have a centralized security team and you could create the squads of security champions who are essentially developers turned security professionals who are able to kind of take the message of security programs across to various teams so therefore you're not having to kind of have the entire burden of security of the security of an app stick program on a few security people but you're actually being able to have them split across so these are some of the things that we could do from a training initiative i know we've got another 10 more minutes i want to just keep some time for q a but in summary um i'd like to leave you with

this topic from a core vulnerability management standpoint um i think the focus should be beyond just traffic light indicators of how many vulnerabilities are high medium or low uh or just the sheer number of issues that the teams have found um because there is an actual value in the metadata that these foundability statistics provide for example if i see more issues propping up in a certain class of vulnerabilities that are more design oriented for example perhaps the focus needs to be around threat modeling and not so much around electing static code tools and it is also about using the right set of tools organizations would need to kind of look at procuring platforms but not just keep constant mind body but

things like allies benefit how well do they integrate by other students how well do i integrate with existing workflows and how what kind of quality of metrics do they give right and things like that now while this slide summarizes what we've discussed in a nutshell the larger role that we as a security community have to play in this decade and i always say that the last decade the end that in 2020 was a decade that kind of gave application security the prime time slot inside of the engine which is great because today when you say appsec people stand up and people look at you people have to know what you know what you have to say so that is done the last decade

gave up this part but going forward i think the focus for us uh really needs to be being able to make the best use of it right so so when this decade was actually about realizing the various possibilities that automation and the scale of abstract could bring to priority um so i think that really needs to be the focus for us as security engineers as we move forward so with that um i'd like to say thank you to the besides barcelona for inviting me and accepting me for this presentation so with that having said that i'd be happy to take any questions that anybody might have

thank you raul it was a very interesting presentation on this new paradigm is there any question i don't see any question in the zoom

let's check also slack i think there isn't anything specific so first of all you know thanks for your presentation that was pretty interesting so i got a question actually so i mean the um we're saying that security thieves you know in some of the cases you know let's say i would be overloaded you know we're talking about you know probabilities right like we count them by the numbers so i wonder if you have any maybe some ideas or concepts about maybe protesting in a different way so i've seen things like this i'm moving more into you know trying to analyze the um the risk to the organization versus you know to the specific you know they say um

vulnerability risk call you know that might not be you know the uh exactly the same so i wonder if you have any ideas as well about you know that prioritization of vulnerabilities to be more let's say pragmatic you know in the way that we do yeah so so i think uh the idea here really in terms of the role that the regard engineering plays as well but really i wanted to kind of bring about that in terms of the presentation as well so i think the way that the description of the application is defined today is is quite confusing because people always think of an aspect engineer is almost like a superhero he needs to understand

so i think the focus of the presentation also was to say that try and understand what skills are core for an african security engineer so therefore you give him or her enough time and enough space for more research and more uh you know things that can be more intuitive and many hours trying to be more pragmatic because today the problem really is that people are overwhelmed and overloaded with work that are not really course acceptable uh a lot of things that could be automated are not automated and a lot of things that should not be automated is what is automated so i think there needs to be a step back and we need to kind of think

about what are the core skills of an aspect engineer and therefore look at it from that viewpoint that makes raul i sense a question for you do you think if an organization is a mature enough a back bounty program can help with the overload of information that the security teams have what's your point of view on a bug bounty program so i think a bug body program is very very useful i think it is one of uh i mean if done correctly it is it is a great source of additional uh vulnerabilities that a program management can get because today you have different source of uh getting issues you get you get issues from tools

you get issues from internal event testers you get your issues from your customers now a bug bounty program is just a way for you to get any kind of issues that all these sources have missed uh from an external uh from an external party uh because a pentester is a pentester whether there is internal or external so i have seen organizations where they run bug body programs to to get a very valuable source of information for potential security issues that neither tools have found or internal penetrators are found on external appendages so therefore sometimes uh bug hunters might find that one or two just one or two very specific critical issues which could be great and

once you find those issues you also have an opportunity for you to to kind of take those issues and loop them back into your pipeline for you to create correct models that mimic those issues so more functionalities also gives you an opportunity to create more uh innovative security test cases that you might not have thought

thanks so much for for your time today i really appreciate it [Music] i hope to see you again at future conferences sure thank you so much