| Since code audits are mostly conducted as an art rather than science with rigorous methodologies, I assume most vulnerabilities locations are just derived from experience and "poking around" work. If you look at public penetration testing reports [3] seeing there mostly is no section about methodology, it's reasonable to assume that there are rather no true common standards or bodies of knowledge to find security vulnerabilities. For some application security fields like web application security there are at least some semi-rigorous catalogs [1,2] which can help you to conduct more comprehensive code audits or security tests/audits. As already mentioned there are already tools which can help you to conduct more professional and thorough code audits through static security source code analyzers or dynamic analysis tools (e. g. valgrind for memory related bugs or afl as an fuzzing tool example). These tools are focusing on implementation bugs, design weaknesses still have to be evaluated manually. In my opinion the discipline of software security assessments hasn't grown up yet, but there is definitely research going on to improve the situation, e. g. [4] for a research example on finding bugs statically. [1] OWASP Testing Guide v4: https://www.owasp.org/index.php/OWASP_Testing_Project [2] OWASP Application Security Verification Standard (ASVS): https://www.owasp.org/index.php/Category:OWASP_Application_S... [3] https://github.com/juliocesarfort/public-pentesting-reports [4] Modeling and Discovering Vulnerabilities
with Code Property Graphs: https://www.sec.cs.tu-bs.de/pubs/2014-ieeesp.pdf |