That's like asking how web development happens. Standards are sort of a double edged sword in infosec, because: * if I can just run a scripted audit and go ho

That's like asking how web development happens. Standards are sort of a double edged sword in infosec, because: * if I can just run a scripted audit and go home, then any dipshit can do that and security professionals won't have jobs. Or fewer ones will. Which means less infosec software gets produced. * if an attacker has access to that script, it's more or less a matter of time until they develop an exploit to circumvent it, slightly dependent on their skill. Eg, industrial software might be in less danger here because the exploit surface is limited to in-facility, if their network stack is good. So, patterns in general are a smell worth investigating. If something works, I try and find out if my PM will gift me some time to automate and smoke test what I come up with. If something never works, I learn, but I also automate that too, and generally just try it anyways. Tooling is more or less standard, kali linux, unix tools, and then whatever they've found to work. Maybe eighty percent of what I use is basic kali toolbox stuff w/ whatever extensions I've collected, and the rest is tools I wrote for mapping, measuring, and muscling my way to success. Lots of old python, some new python, tons of C, I've got perl scripts laying around, I've got afl installed somewhere, I use lua for some things. Memory errors are common security issues. There's tools like valgrind to help find those. I don't really know how data race stressing is done, but I'm sure that's a common route in finding network stack bugs. Afl-fuzz finds a lot of data processing bugs, off by ones, pointer/deref issues, etc. They've found some pretty big ones, too. When I am handed code to audit, I'm looking for areas where I can tell the author was rushed, or where he was copying code from somewhere. The more the better, I want to know what he thinks like, how he writes, and that helps me find something that would be difficult for him to implement. Sometimes you get a big obfuscated mess and you gotta try and make a rough 50,000ft map of it and start profiling, even stepping through with qemu if that's what it takes to get a clue. Infosec is one of those devilish details kind of fields. Once you get the feel for how things break, then it's mostly rote work. Sometimes you just gotta trust that if you read enough code you'll find a piece that sucks enough for you to break something. Sometimes you don't find anything. But I'm not a researcher, so I'd then move on to other pastures, whereas the research auditor presumably has to write a report or talk to his peers? That's a bit over my head, tbqh.