Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Secure Development Rule #4: Code Reviews
Over the six months of reviews, rewrites, and fixes, Mike's company learned that among other quality-assurance measures, doing code reviews provided a way to prevent some of these problems. As he was glowing over the concept, I reminded him that code reviews were always part of the government's review of software used in a national security environment.
In the succeeding months, Mike wrestled with creating the procedures to do code reviews. We had several discussions that ranged from the ideal, academic theories to what we have seen as industry standards, which we both agreed were lacking. In fact, the only experience with code reviews between us was one project I was involved with a few years prior for the U.S. Department of Defense.
After a lot of research, we outlined what made their recent reviews a success. First, we realized that the reviewers had never been involved with the development of that part of the product. For example, the server source code was reviewed by a group of programmers who wrote the desktop applications, while the source code for the desktop applications was reviewed by web programmers. Although all the programmers were involved with developing the overall product, we found that it did not taint their objectivity, while taking advantage of their experience. These reviewers were able to bring a new perspective to the programs they reviewed.
One problem with this exercise was that after devising a plan, Mike discovered that his company did not have the resources to do this type of code review on a regular basis. During the previous review, his resources were focused on these reviews and fixing the problems. When it came to reviewing the security mechanisms used by their software, this review was limited in both scope and resources while the rest of the development staff worked on new releases.
My first three rules are items that can be enforced during the software development cycle. Programmers can be trained, even cajoled into following these guidelines. Software tools exist to help find bad programming practices and to enforce the rules. But code reviews are usually not part of the software development cycle. They require additional resources, additional planning, additional monies, and additional time to market, and both money and time affect the amount of resources available for this effort.
Market and resource concerns overshadowed Mike's effort. However, he did have the recent successes to use as his support. After some negotiations among the internal customers that would be affected by this decision, including marketing, a plan was created to move the code reviews from the development staff to the quality assurance (QA) environment. Making this process part of QA ensures independence of the process, which is something that the marketing people can use to show the company's advantage over their competitors. When the software is in the QA cycle, it is removed from the development environment and can be reviewed without the requirement to hurry up and finish so that the next great feature can be programmed. It also puts the control over resources in the QA department.
One caveat to doing this is that your organization has to fully support a complete QA department. The QA department can borrow resources from other parts of the organization, but it needs to be empowered to hire its own staff, including programmers who can perform this review. If your organization is small, you may not have the resources to support this type of QA. This is not a problem if your organization has QA procedures in place. However, even without a large organization, the smaller group can include code review as part of its testing and QA cycles as part of the overall plan.