Source Code Security Audit Speed Run

alright thanks for having me back it's great to be here another year and besides Canberra so I was going to make a joke about you trying to compete with the Kiba cotton pyrotechnics but that's fine well we'll try to get on with it I basically hate that I had to talk about source code auditing really doing it I guess quickly and efficiently and so yeah we'll start some introduction a little bit about me a little bit about source code auditing talk about it the theory talk a bit about vulnerabilities and eventually we get on to actually auditing so we've sort of encompassing I guess three things here first being the traditional code review which is looking

at the code identifying what it does make sure it meets the required standard source code a review is the same thing but looking for vulnerabilities and then for some reason I decided that trying to do too fast would be good that's that sort of the three definitions but essentially looking at a way to transfer some knowledge to you guys on how you can identify vulnerabilities in source code fast right and there is one thing I want you guys to take away and I'm pretty sure this lapin you should all learn at least one trick that will let you go home and get a CBE at the end of this talk yeah it's pretty easy all

right a little bit about myself I'm a security researcher with Senate labs which is the testing validation of dark matter I'm a former developer moved into sysadmin moved into pen testing now do security research and about a little bit over ten years ago I found myself as a sysadmin having to do some code review for a disproportionate amount of developers and I kind of decided I needed to automate this and try to find a way to at least spot like the really bad stuff quickly and sort of try to pull this stuff in so I created this sort of hot spot checking to all based on grep and in June 2009 I made the first public

release so that's officially almost 10 years unofficially a bit over 10 years and it's one of the primary tools I use whenever I do source code analysis because it's it's just I find it very versatile and I'm I'm very familiar with it because I wrote it so there might be a slight bias but yeah so the amok that percent is morning part of a great book called the art of software security assessment and it's what it what key takeaway when they talk about source code over you is that it's essentially a skill right you practice it you get better at it and as a skill it's made up of a lot of things so some people think

that code review is you got to know the language you got to be good at language and then you can just sort of really review decode but there is a lot more to it than just that you need to understand the systems that the codes are running on source of like vulnerabilities in PHP on Windows versus Linux can be different things like memory allocation size registry size you know I said 32-bit 64-bit all of this sort of place into it you also need to understand vulnerabilities because you know code reviews the developer tends to be more about you know correctness of the code function of the code but you might not specifically be familiar with a different vulnerability

classes that might be in the code and on top of that you also need to be creative because sometimes you know the vulnerability class hasn't been defined all right at some stage somebody had to be the first guide that went from a buffer overflow to actual code execution right to pivot and that correct take some creativity so you put all that together you know and you do security code review it's also important to remember that we generally don't try to consume the entire code base you know you might be handling this very big and if you're gonna read it all a it's very slow and be it's cumbersome and takes time so it's a bit like reverse

engineering in that imagine that you're always looking at the code through like a you're only seeing a small portion of the code at any given time and what we really care about is being able to find a path through this sort of tube into code execution that's a pen tester but just basically find the shortest path to the vulnerability you don't have to understand the entire code base there's also some considerations to taking to account it's not just the code itself like we said the system matters for example in in PHP the configuration can be changed things like race conditions writable directories compiler optimization can introduce vulnerabilities and I'll talk a little bit about that later as well so all

those things can impact the code base that you're looking at without necessarily the being a specific thing in the code itself it's just affected by external factors you know such as you know reading a fall isn't necessarily bad in the source code but you know you if you can introduce a race condition then it might be bad limitations for static source code analysis obviously dynamic evaluation any code that only executes at runtime and may not even be defined at the static time it's not something you can analyze by reading it because it's not there also often code that's written with a lot of callbacks or inside out objects can be really gnarly to to navigate your way through

and also a lot of times if you find I'm generally say enterprises sort of applications where maybe they take a directory structure of xml files and apply some transforms and then write something out and then performs two other operations on that if you don't have the XML files it can be very hard to actually know what is happening so so when we're looking at code through this tube we can't want to maybe consider the flow of the application okay so I'm not sure which part I'm standing in front of understanding this side for a bit so basically flow is how execution of code navigates the code we care about the execution flow and we also care about the data flow where does

the data come from where does it then end up and one of the other things that we generally find that developers don't think about and often researchers don't think about it sinks that interrupts interruptions to flow so let's say that you have an application and suddenly get an unexpected halt execution and it throws an exception and you know writes a bunch of sensitive data to log or to the exception or it's created a temporary file with some sensitive data in it like a private key that is trying to swap out and then execution halts at that very second that file remains on the file system it's very common to see in terms of file uploads and web

applications you'll see that the file upload occurs gets put in the temporary or maybe even a web-accessible directory and then the script goes hey this isn't a valid gif file and then just leaves your web shop rotten file system so interruptions to flow it's also something that's important to consider so when you're looking at flow it can be helpful to have this kind of like nice visualization tools it's something I would generally recommend if you're if you're in depth analyzing large code base they're very handy if it's a small codebase I'd recommend just reading the code listing here the guy just took down is is git repo because he's working on a licensing issue but it's it looks really

nice oh I haven't had a test spin myself so all right so there's a couple of things in terms of flow we care about basically data flow from source to sink and source is wherever the data enters the flow of the application typically we want to track user supplied data because static content is usually not manipulatable and doesn't tend to result in in vulnerabilities and and the sink is obviously the function where the code ends up that we care about so say that you take user input from the URL you put it in a system call that thus you know execute the ping utility and you don't filter that data then you know yeah we

have a problem now it can be very hard to identify where user user input comes from if you look at things like second-order SQL injection with data is read out of a database and then use directly in an SQL statement again and you might be doing proper power optimization on the insert statement but then the subsequent select statement is insecure also developers tend to miss things like environment variables or you know browser headers those type of things other things to consider when you're reviewing code is trust boundaries you know that's the flow past the trust boundary and also just a flow induce a state change so that you know has the user logged in has to user logged out

these are good areas of the application to audit taking it a bit beyond you know just using grep for full keywords or a reading code paint analysis is possible from a static perspective without executing code and it basically the notion of tent analysis for those who don't know is that a variable carries an additional flag that the compiler or the interpreter keeps track of and whenever data is assigned into that variable that comes from outside of the application it's not a constant or anything then this flag gets marked and and the variable is considered tainted and then eventually if a tainted variable ends up in a sink that you care about such as you know an executable function string

copy etc then you throw a flag issue found that he's untrusted data going all the way down to a sink that's important so essentially this is this is the flow it would follow it go from hello into hello then n gets so the taint flag copies any tank that variable they gets us onto and untainted variable the tank flag carries over and we see in the end we end up at the string copy right so having sort of thought about the the different I guess tools and techniques required skills there's a bunch of different approaches so there's like what hotspot checking which is basically using grep for a keyword and then sort of based on

whatever you find there you start working your way up or down to code this control flow sensitive where it's basically you're you're following certain functions and you only say you can either follow every function into the function and then back out and you you know you read the code the way would execute and you can maybe optimize that by only following the functions that they were use is applied data there's also data flow sensitive so rather than worrying about the code where it executes it's tracking the data so say you know this page insert saying in the database this page extracts it out of the database and then you sit in a query again and the flow of those new pages

are separate but if you track the user data in and out of the database you'll find a potential second order SQL injection so focus oriented tends to be just looking at the application and you go I'm gonna look at like this library and I'm only gonna worry about any function calls to this library I'm gonna read the library top to bottom bottom to top whatever and I'm only going to worry about that so typical examples where we see that it seems like authentication authorization frameworks you know they're good targets you get a brand new application like the first thing I'm looking at I'm gonna look at authorization authentication password reset all those things forward and

backward tracing is basically what it says you start at a certain point in the code and you read it down or in the case of hot spot checking typically you'll you'll find a random line of code in a file and you start going to work your way backwards like where did the data come from to into this this line of code that we're concerned so that's reading the code and of course we said we have to know about vulnerabilities so essentially we say that a vulnerability is a weakness that can lead to unexpected undesirable event compromising the security of the system network bla bla bla it's a bit like quality we know it when we see it so

this a couple of I guess main schools of vulnerability classifications there are others but hopefully you all know these ones always picked up ten they're sort of siloed there's like top ten for mobile top ten for web top ten for whatever and then the cwe they they more try to index the entire thing neither of them are completely complete coverage neither of them have necessarily you know always up-to-date definitions there there's a bunch of other ones if you want to learn about vulnerabilities these aren't a bad place to start read you know CW have examples for most of the ones they've classified but also you know go to conferences I mean you're all here white papers a good advisory

will often showcase the flow of the code through the application and and you know what led to the vulnerability so yep so how do you go about identifying a weakness in a new product or a sort of source code if you come through documentation that's a great place to start a lot of time I find specifically designed weaknesses I'll read the documentation I go like that doesn't add up you know like you're trusting the user to supply the the amount that they're paying for the thing that they're buying now that's that's not okay obviously recognizing weakness patterns and source code you know like user supplied input being concatenated in an SQL statement that one's pretty

obvious but you know you sort of once you read a lot of code I guess you you you'll learn a lot of bad habits that developers tend to have same thing if you're looking at API you can even look look at the swagger Falls then you might be able to spot like a pattern you know direct object reference this is often come to mind there's a function that returns some sensitive data and it takes a number and you're looking yeah I think I think that might be you think anticipate poor decision-making that ones sometimes easy sometimes and if whenever you come across something that you don't know say you're reading a language you're not super familiar with like Java when

you're a PHP dev or you know vice versa just write a short script and you're saying well if this value was that this value is that and they're calling the function this way can I write like a two-three line script and see whether or not my assumption about that being correct should have lived a vulnerability is it going to do the unexpected thing or it said actually handling it correctly on the on the function call so and also a peg breaks from complex or difficult code you know go have a shower if you Travis or Mandi it seems to work pretty well so I generally classify problems in source code as one out of two core problems

it's either the presence of something so you've written in insecure things you've added you know hard-coded credentials things that generally shouldn't be there you know a double free format string and then there's the other part which is the absence of something right there's an absence of a negation or authorization check at this function there is lack of encoding use of supplied output and a lot of people might say don't know but exercise is also you know validating input but not so much it's mostly encoding output particularly once you get to the stage where you're dealing with unicode strings at the moment I'm working in the Middle East so we always have to validate at least two languages

English and Arabic and you know it's a lot easier to just handily handle encoding securely at the time that you need to be encoded you know input validation it's nice to have you know if you can do both do both but but I consider that the absence of something rather than you know you're not encoding you could argue that one way or the other but yeah all right so now that we know a bit about vulnerabilities you know we know how to read some source code you know how do we actually go about auditing yeah it basically is a three-step process right it's kind like how you draw the old owl you know draw a circle draw the rest of

the out let's see see so you'd enter by weakness however you do that through source code reading documentation whatever I tend to prioritize high vulnerability or high impact vulnerable its first always look for you know remote code execution authentication bypass ideally together and then once you're there you get a check exploitability because a lot of times you might jump conclusion and think that ah this thing you know this particular function doesn't encode this correctly and then turns out yeah you're a bit premature so always check that you can actually exploit it before you you go and shut about your your latest vulnerability now so beyond reading the code manually static source code analysis tool there's a bunch of them

they all function mostly the same it's paint analysis abstract syntax notation you know keywords like grep honestly a lot of you guys here would have seen sílvio livestream you know it's it's been it's crap and a UNIX shell and very much the same but we ordered different different parts of the infinite ecosystem but yeah I really rely on grep for everything because it's it's fast it's very versatile you know let's research things and once you get familiar with the tool you can do a lot with it it's also important to remember the tools can't find some types of vulnerabilities such as usually the absence of things is very hard for tool to identify you know the absence of an

authentication check you know or in the case of default insecurity fault values being assigned to say an integer or a string or anything like that the tools generally won't find human analysis is always required for every type of source code review so if you don't like grep you know say you're on Windows you know Windows Linux subsets then we'll get you grep but some people like a core some people like a G Silver Surfer because it doesn't scan things like subversion directories to get directories once you're familiar with grep you can tell grep not to do those things as well so but each through the wrong there's more than one way to do things right but let me just tell you

a bit more about grep because I really like crap alright the benefit is a lot of the static source code analysis tool requires the ability to compile the code before they will analyze it so they operate on the bytecode intermediate language rather than the source code itself so if you're given incomplete code if you're you know reviewing just the partial patch or add if those tools won't work but grep will work on anything that a human can read so that's good it works across platform you know Linux UNIX PSD Windows it's all there and you know most programming languages are based on text sort of English word your language like syntax and then grep is very good at matching

text so that's that's a benefit which means that you can very quickly like add a whole set of syntax support for custom languages like smarty templates if you wanted to write a hold as a rule set for reviewing smarty templates you want for necessarily fund a static tool that does it but grep can do it and it will probably take you half an hour an hour to just sit down and go through the syntax tree write out a whole bunch of keywords and now you can audit smarter templates it's really quick really easy and then of course that's a starting point and you build on it from there whichever way you go but and it usually

and this is important to me it may not be important to you but I always find that I want to see the source code that grep thinks is that font something important on and I want to see the line surrounded I want to give it some context I don't want to report where they don't have to open and read and then go searching for the fall and then fund the line and then read the code I'd rather just get the code use to it straight away so yep that's a bit about grep so here's an example mem said it's a type of under ability that's being introduced by compiler options basically you're trying to zero out a

region of memory and if you're if you're running this with the right compiler options the compiler basically goes this is a null rewrite I'll just optimize that out no need so if you're trying to unset some sensitive memory but might contain a password or a private key and you're trying to use their just straight-up memset zero there's a good chance that it does not actually get zeroed out of memory and that the sensitive details are still there so here's two very simple regular expressions that find it but it's not guaranteed to be exploitable even though you you know a lots of fun memory initialization and a lot of the mem sets that try to see

right data it's not dealing with sensitive data at all so you probably have to wade through a lot of options or a lot of lines of code for this but you know it's really simple it's like he's two regular expressions and now we can go and audit this code base for a specific table vulnerability let's say that you want to audit a whole bunch of WordPress plugins similar thing you go through your CI here's all the function calls you see we started the top ones are really simple and then I've sort of 12 in two more optimized regular expressions because I can't help myself I really don't want to get all the false positives so if we can sort of shave

that down a bit that's really beneficial so of course what I use to shave this down is regular expressions um I'm a I'm an old-school Perl programmer so I really love regular expressions I guess you know there's certainly useful you got a year to know their limitations you know don't parse HTML with regular expressions ever but the way sort of grep rule sets work is at the simplest form you just write a list in it editor of keywords like require now okay that's gonna find every require statement and most of those are hard-coded fall parts that's not very useful so why don't we do any require that deals with you know a variable and we do that by sticking the dollar sign

in there now that's better but again a lot of the variables are static we don't want that either also this this other function require once we want to check not just for require we one both so we can combine them and then at the end we have limited down to be synthetics ambiguous you know a developer might put a space between the require and the the parentheses I mean some do that and then we also make sure that the only variables we care about is the use of supplied ones that come in through get post repress the environment cookie etc there might be attacking controllable or influenceable and and at that point we've eliminated a lot of the false

positives well literally if you find anything with that like last rule that should literally be exploitable you know to straight-up local or remote file include ninety-nine percent of the time so but you know that's just that's just like hotspot checking that's not very cool what about like taint analysis right you can trace through the code that's fine we can use script to do that we take the output of grep and then we message it's for Perl and regular expressions and then we feed it back into grep as a rule set so it's great to grab two more and you know you you actually get tenth analysis this one's been public for a while but it's just this is a very basic example

but you know it's it's almost the almost entire script is its comments and version and user friendliness and then at the bottom there is four lines of code that actually does all the work and now it could obviously be written as a single line so trying to keep it you know readable but let's say you also wanted something that you haven't found anything else for let's say that you were doing research on D civilization vulnerabilities in PHP and you wanted a quick way to see all the classes that can be deserialized through a wake-up of the instructor and an auto load function now you can add to this right this the two string and whatever you can just expand on it but I

generally find that these three are the ones I care about and then I do this magic trick where I actually parameter inject past grodan into graph itself on the third line there to make sure that I want to see the next 20 line so after every every function definition and then I pipe that back into Gaudet to look for potential PHP functions that we might care about so you know it's going to give you a lot of information but it's going to highlight the bits that are important so any like wake up destructor autoload that tries to load a file email a file do a system call anything like that it'll show up so you know yeah you

whip this up in two minutes and then you're off to the races so this is why I love grep it's just it's really simple to just go I should have something to automate this and then five minutes later I have and it might be noisy but when you only use it ever so often that that noise trade office is usually manageable so alright don't know how we're doing for time hopefully I think we're gonna finish pretty early all right so so what I did for this I went and I downloaded eighty repositories of github this is 1.3 gigabyte of source code and you might think that might take a little bit of time to scan right

granted it's on this laptop here it's an SSD it's not that much Ram I can't estimate if five to ten minutes code time but it actually ran in six seconds right so that's that's grep running about 50 I think regular expression rules an entire code base a text six seconds not tagged analysis it's a little bit more cost intensive they took 15 seconds to paint analysis string copy only string copy calls throughout the entire code base for any file ending in the dot C extension so it's really quick in fact usually I pipe it through more and I started reading it and even if it was a significantly slower even if it took ten minutes it'll still execute

faster than I can read the code so it's pretty easy so I'm actually the bottleneck here you know improving processing time for humans first of all we want to avoid false positives and I've sort of explained I do this by limiting the regular expressions to like the very stupid vulnerabilities when someone takes direct user input puts it directly in a require statement directly in an SQL statement you know the really really simple should not occur from any developer kind of mistakes they're the one we're gonna catch and then we might miss some where you know the user input gets supplied to another variable and then that gets used in the SQL statement all right that's one we can come back

and do the tanked analysis on the second run first we just want to get like a couple of starting points start reading the code get familiar with the code base so it's okay if ayran Ischl you know just stumbling through it it's rough and quick because I don't expect you to only do this one step if you remember back to when I spoke about the approaches you had hot spot hot spot checking forward backwards tracing focus ideally you should apply multiple of those whenever you're reviewing a code base because they're all good at identifying different problems if you want to find deep vulnerabilities in in a code base the stuff that might have lived there

for fourteen to twenty years you have to read the code you have to get very familiar with the code you have to understand it and you have to look in sort of the the weed nooks and crannies or often how things integrate together you're not going to find that stuff would grep and so all right and I also only look for certain vulnerability classes like I'm here if you order it 1.3 gigabytes of PHP scripts you're gonna drown in XSS if you allow any type of exercise to show up in your results you'll be there for a long time so I basically narrowed down to sort of remote code execution or higher critical vulnerabilities so code

execution SQL injection and then just run that through and then of course I can come back and only look for xsf if I want and of course you know the text rules and if I find that this one framework and the one app I'm looking at rather than using the standard database query interface they've written a custom one I can just go into my text files update the function name or add an additional function name and then I'll try to rerun it and I'll trap all of the the custom developer bad habits so it comes back to I like it it's versatile it's fast so when I'm running broad it there's usually a couple of things that

I gotta look at to try to help me make a decision as to whether or not I should stop reading the hotspot checking and start looking at the code and go reading the code or if I should just make a note of it and come back later so the first one is obviously the file name you know it's a sensitive filename or something that I think you know should be a publicly accessible index.php that's something that's usually publicly accessible and I might not have to find an authentication bypass to prove that there's a remote color code execution here the other thing I look at is the line the line number so you generally find that the higher up in a farm a

vulnerability of course the easier it is for your exploit or your for something to reach that code path if it's on line 8,000 something of something that is in the class file there is probably a lot of if statements before you get to that point and you know a lot of those statements may neutralize the potential vulnerability and then of course I look at the entire length and I say you know how many vulnerabilities or potential vulnerabilities am i seeing in this one file so if there's one file like a library that appears very full of owner abilities that's probably a very good starting point and then of course the last one but it's probably the

I actually check first it's the actual code view now you can see it's highlighted and this one man fortunately this one has to cross that scripting in there but obviously the one that my eye is drawn to is the potential disasterous remote fall include there and I can't say that this particular bug was patched a while back but so he's won this one everyone here everyone everyone here can take this one go home run a single correct over any PHP base code base if you don't use PHP you can change the the curl options to something else but this basically looks for any deliberate disabling of certificate validation within the source code and that's something you can get a severe

for it's not a very exciting bug but it'll get you see ve hey you don't even have to use UNIX and grep you can just go and github and search alright there's a couple of couple sitting right there and then of course I ran on my code base and sure enough there are plenty of them here some of these are like PayPal shopping carts and stuff that should absolutely not ignore SSL validation but you know turns out there's actually good reason the historical reason for this and goes back to I think it's 2003 where PHP on Windows would crash if you tried to do certificate validation so all the old or none of those crashes just fail the

validation regardless so all the old-school PHP developers have learned this habit of automatically disabling it because that way the code will run yeah ship it worried about security later all right SQL injection again very simple if you're not regular expressions a little bit you should be able to read this you can probably read it anyway so looking for a query with anything that's used is applied looking for the key words select with anything that's use of supplied followed by from or select from followed by use is applied or being used in the matching the right hand matching portion of a wet cloth and then the that and and or statement there it's a little bit noisy so I had to add the quote

single or double quotes in front because it's meant to match it's meant to match multi-line statements and so if I run that across a card base there's a bunch of ceará decidir I'll hopefully you can read that at the back this one is in a yeah clicky CMS here's a bunch more GLP I that's inventory and the ITIL style management software there might be some users here sentry on it's another inventory management system for you know taking care of you Nagios config in your systems this thing is very full of it at least the last two they're all authenticated injections so it's a little bit less important but alright cross-site scripting any output that directly echoes back used uh

supplied input or in the case of PHP self and PHP self is a tricky one because the webserver would have to be configured with as a query in query get options query I don't remember there there's a there's a toggle in web service that allows you to append data in sort of a folder format after the index.php script and if you have that enabled then PHP self is vulnerable to cross-site scripting by default so here this one's nag Yoast dashboard it's got a vulnerability and mumble server for like the there's like a teamspeak thing again the mumble server that one is dependent obviously on the config the other one is straight-up cookie value here's a bunch in Libre NMS we see that

these guys I think this one's one of us I don't know what was going on here so there's a there's a couple of cases where it's just like straight up just going out user-supplied it data that's not very good but in the same files it's also HTML encoding some of the data and then directly under the HTML encoded that I ghost we've got a MySQL real escape this starter which is obviously that's good if you put it in a database but it's not so great when you're doing HTML output so you kind of think that whoever added that initial HTML special characters should have fixed all of them but I don't know and I see that a lot

where it's like I we fixed it in two out of three places unsafe to civilization again this one is a little bit sort of tricky nothing go back same thing looking for the really silly stuff stuff just an serialize with user supplied data ran that over found a bunch of them but of course not all of these are yes all of these are doing unsafety civilization but not all of them will lead to code execution you generally require a library that you can leverage so if we go back to slide 37 I had a quick script to look for these these ones and we'll find that for the PHP ipam one that was actually in the in the

pair next to DNS client the the caching component will let you write arbitrary contents to arbitrary files so that that's very handy the other ones that's not a direct digital accession so you'd have to rely on a global PHP thing like a fire filed a civil accession or standard library deserialization but again the file where you're finding the unsafe to civilization it would actually have to have it would have to consume the the library that you're trying to inject through you can of course also attempt things like memory corruption through this realization so overall it shouldn't be there but exploitation is a little less straightforward and finally we're gonna talk about buffer overflows and I would generally say that

greatests not so great at finding vulnerabilities and see very fast it's much better at languages that have variable sigils so like PHP the variables are the cleared with a with the dollar sign in front you'll find that in some languages and crap is very very good for those because you can just add that dollar sign in your regular expressions to make sure that we only care about information that deals with variables we don't you know where it's in C it's hard to tell a custom function name from a variable name when you just searching it with text search so this is a variation on that tank analysis that we had for for PHP but this one

basically just goes float through and look for a string catch drink coffee and s printf as well as a character definition of a buffer so you put all of that together and in the code base I have here this is open Lightspeed web server I got a couple of couple of vulnerabilities here I'll lock this one in particular the top lines there the developer has an assert that makes sure that the max length being supplied is more than 255 when it puts it in a buffer that's defined as 256 and then and then it doesn't actually utilize the max length variable at all it just starts copying the data into the buffer very handy I don't know

what was going on there similarly they have this other section of the code where again there's a comment right above there that says nah we should we should check the length of the path but then that's just been commented out and like the line below I guess we'll take that comment we'll take that path out of the configure we just slap it in the buffer it'll be fine yeah and don't worry particularly you can say that maybe in this case the developer has my mistake because they think that you know maybe you'd want to be a fall name and unless you custom can partly a Linux kernel the files should only be that length so it should be safe but things

like siblings can exceed that that variable length so yeah you need to have that systems knowledge to go with it so that's that's all the all the demos all the O'Day hopefully I'll have time to report it to the vendor before somebody else takes credit and so in conclusion you know bond durability discovery doesn't have to be advanced you can just go out search github for curl verify SSL and and you're gonna find some under abilities sometimes the vulnerabilities are very hard to identify I mean we've seen that time and time again they live in the code base for a decade and nobody finds them again source code review if you have a very dynamic application

source code review might not be the best approach and of course finding a be so vulnerable code it's only the start of the journey you don't have to prove that it is vulnerable you don't have to deal with the vendor you know release an adversary get a patch out and you know hopefully everyone stays safe and secure so that's it any questions

we can take a couple of questions if there any in the audience now this is someone that their whereabout max fitness Thais here we've got a runner coming over I should probably rub myself yeah I just want to say thanks for making Gaea order I use a nearly daily and it helps me speed up my workflow insane we like it speeds me up so taking two three hours look through some things it takes 5-10 minutes to get some quick wins so just once a thanks thank you for myself and if anyone else gets use out of it that's great [Music] there's people questions any other questions no one here one in the front that's it definitely baby you come

anyway so about that so what happens if a vendor isn't as responsive or what interested in fixing something well if the vendor doesn't fix it I mean everyone I generally say that whoever finds the bug can't ask the right to choose how they want to disclose it not disclose it whatever if your company has a disclosure policy you should probably follow that and that should probably define what you do when a vendor isn't responsive but overall the standard industry practice seems to be try to notify them a second maybe a third time and then just release it for the Internet to deal with okay let's think I'll go one more time for a great talk

you