I have heard of security firms who consult on the security of a clients systems. All of the people I know in this field are network engineers, but I know programmers get involved in security as well.  What do security programmers who perform audits/consulting actually do? Do they literally go through the codebase looking for every vulnerability in peoples legacy systems? I have always assumed that is what they did, but it seems like this would be highly unreliable and not do much more than providing a false sense of security. Note: Im not talking about programmers who write encryption algorithms or anything like that, only those concerned with software security audits/consulting.
What do programmers at security firms do?
security;freelancing
Frankly we try not to go through your codebase, we try to write tools to do that for us.First, the theory. Security is a requirement of a software system, so like other requirements (functionality, usability, accessibility, performance etc) it should be considered at every stage of the software engineering workflow from requirements gathering to deployment and maintenance. Indeed, this is possible, and guidance exists to help software project teams do that. Even though I mainly work with iOS developers, my favourite description of the secure development lifecycle is from Microsoft Press.In this model, application security begins when we're trying to elicit requirements from our users. We need to discover their security and privacy concerns, which is not easy because we are the experts, not the users, and where they do understand their security requirements they might find it hard to express them. We also need to discover what risks the software will be exposed to in deployment, and what level of risk is acceptable.We design our application with fulfilling those requirements in mind. We write the code with an eye to satisfying those requirements, and avoiding additional risks associated with code-level security mistakes. We test the software to ensure that our model of its security is consistent with what we really built, then we deploy the software in a fashion that matches the assumptions we made about the environment when we designed the thing. Finally, we provide support and maintenance that helps the user operate the software in a way consistent with their security requirements, and which allows them (and us) to react to novel changes in the risks presented.Ok, so much for theory. In practice, for reasons that are explained very well (albeit in a nontechnical fashion) in Geekonomics and which are mainly due to they way software companies are motivated, most of the above stuff doesn't happen. Instead, we get this. Developers will:hire a security guy or gal to be present when they're bidding for a contract, to show that they get security.write software.hire a security guy or gal to validate the software before release, fixing many problems that arose in step 2.patch everything else after deployment.So what most app security people are really doing is, as you say, finding bugs. This is really a glorified code review but it's a highly focussed code review carried out by people who are experts at the sorts of bugs this review is looking for, so there still is value in getting external help in doing that. That's a general rule of teting, of course: always get someone else to test who wasn't involved with making the thing.If we accept the above as true then it follows that people making purchasing decisions are likely to equate capable security guy with finds lots of bugs. Those who get computers to do the work for them will find more bugs than those who don't, so of course they rely heavily on static analysis tools and will aim to spend more time extending the tools than coding for specific issues for specific clients. Then we conclude that app security people are more likely to write tools to read code than to read code.** Warning: what remains is personal opinion and speculation **Reality is broken. You will notice that the theory of software security was all about identifying and responding to the risk of relying on a software system, while the practice was about finding as many bugs as possible. Sure, that will still reduce risk, but only as a side-effect. The point of the game has become less important than winning the game, so the rules are changed to make it easier to win.What can you as a software developer do about that? Play the game by its original rules. Find someone on your team (preferably actually on your team, rather than a contractor, so that they are motivated to provide long-term results rather than a quick win) who understands the importance of security and train the bejeezus out of them. Give that person the responsibility to direct the team in providing the end-to-end security described at the beginning of my answer.Also, give that person the authority to follow through. If a design doesn't express the security requirements, it must be revised. If the implementation does not meet the security requirements, it must not be released. Your security person can make the judgement call, but must be permitted to act on that judgement. I realise this might sound like the security guy saying OMFG security is the most important thing, but that's not what I mean. If your product doesn't meet the functionality, usability or performance requirements either, you also shouldn't release that thing.Why would you want to do that? It ought to be cheaper: we've all seen (and probably quoted for a cheap +10 rep) the Code Complete table where defects get more expensive the later you fix them, right? Well security defects are defects too. I the real-world rules of the game, most of them are problems in the requirements that are fixed in maintenance. Is that cheap?Ok, now what can I as a security gun for hire do about that? Well it turns out that I can refuse to play by the amended rules, too. I can tell developers that it's all about reducing risk, that this can be done at every stage, and then I can help them do that.