Some kinds of security problems are mechanical: a computer program can spot them in your code. So use one...
Once you’ve made sure of your components, what can you do to improve the team’s own code? In these days of automation, we want to do as much as possible to help the team get things right.
So, consider using an automated code checker. These do not provide code security – far from it. However, they certainly can help removing some types of security error.
Automated code checkers review the code to look for possible security flaws. Such tools are sometimes called ‘lint’ checkers, after a UNIX tool that does extra checking for C code. There are now many such tools, some produced by commercial companies, supporting different languages and purposes:
One of the most common things… for anything using C or C++ is to look for potential buffer overruns. And anything that has SQL Injections that do the same sorts of things: anything that can go outside of the expected bounds, that aren't being checked. And there are a number of Lint checkers that will pick up on that sort of thing. Use them! (Developer, Security-oriented phone manufacturer)
Probably the most important feature you want from an automated code checker is the ability to suppress errors on subsequent runs. Most will provide a host of warnings: wading through them takes a while, and no programmer would want to do that twice. Yet you will want to run the tool regularly on the code as it changes.
It may be possible to incorporate the tool into the project toolchain. This is worth doing only if the team regularly look at the errors generated during the compilation process; many do not.
Most tools support configuration to suit specific systems; this too is worth considering, though it is expensive in time.
Certain tools are very good with custom rules; they are very easy to tweak to try the custom rules. If someone is doing something different from a web application, I contend that they need to find an Automated Static Analysis tool where they can write the rules easily, because they are not going to have cross site scripting, they are not going to have the standard thing that the tool looks for. (Consultant trainer, Security specialist)
Please ensure, however, that developers do not get the idea that using a tool on its own will achieve security.
Are they useful? To a degree, yes, they are useful. … Obviously finding potential issues in your code, that you have to then look at and say, “actually I meant to do that and that is okay”, or “oh dear, I’ve missed that, I’ll …”, that’s great. But the danger with them is that you think that is making your code secure, and it is not. It is just finding a certain class of problems in it. (Security consultant)
There’s plenty more do to, and we’ll be looking at that soon...