3. Code review

Code isn't written all in one go, and then put aside. At every step of the process, good programmers will hand off what they've written to be checked for errors. This way, a mistake early in the course of the project won't compound itself to becoming unfixable, as it's caught before it's built upon.

There are three audiences to bear in mind for code reviews:

Reviews by another programmer. Some programming strategies, such as paired programming, involve programmers checking each other's work. Other times, outside eyes are brought in to check for things that might have been missed by a group too close to the project. This kind of code review is expensive, both in time and money, so it is often restricted to the most critical parts of a program.

Automated code reviews. Some flaws are common enough or so easily recognised that they can be automated. Logical or syntax errors can be flagged by compilers, bad programming practices can be highlighted, and common flaws in the programming language itself can be brought to the attention of the programmer. Automated code reviews are cheaper than hiring a human to do it, but are limited in what they can pick up.

Audit trails. These are a chronological log of changes made to a program, often including whole copies of earlier versions of the software. Audit trails allow reviewers to look back on the entire process of software development and identify where exactly potential security issues were introduced, and by whom. This makes the process of fixing the issue much faster and more thorough, as it's clearer where the problems stem from and where they might have propagated to.