> If your method of auditing code is skipping all the strlcpy's because you assume it's being used correctly That is not at all what I have said, how did you c

> If your method of auditing code is skipping all the strlcpy's because you assume it's being used correctly That is not at all what I have said, how did you come up with that? I've been arguing that the idiomatic use of strlcpy is easier to audit than any use of strcpy. > I haven't needed to audit code professionally, but when I do it personally, I don't look for common pitfalls in function use - I look for general scenarios that are dangerous, like working with potentially tainted data. So when I talk about design security, I don't mean what function you use, I mean how it fits into the broader scheme of what the application is trying to do. What you're doing isn't wrong, but looking for common pitfalls is a very easy way to get a baseline assesment of code quality. You'd be surprised at the amount of problems you can find just by looking for arithmetic overflows near memory allocation, misuse of realloc, and the string handling functions. And if the search turns out lots of such problems, trying to understand the design and "broader scheme" is not very useful (at least for me, because at this point I would've decided the software in its current state is simply not good enough for me). There's another reason to look for common pitfalls: you have something very concrete to focus on. You can work mechanically. You can work with grep. It really does make a huge difference. And let's not forget: these common pitfalls are common. And commonly, they are exploitable. And they are the things many attackers would also initially look for. If you "just look" trying to find potential security issues in design or otherwise, but are not looking for anything very specific, you can't be anywhere near as focused, and it will take more time to usefully process the code. If it takes a lot of time, focus is going to get worse with the degrading attention span.. it'll be harder (at least for me) to be certain that the review has actually been thorough and has managed to flag things that need attention. Oh I do look at the broader design of software, but only after getting the low hanging fruit out of the way.