Secure Coding: Principles and Practices

6.3. Good Practices Through the Lifecycle

In the following sections, we broadly divide tools and testing methods into several categories: design-time, implementation-time, and operations-time. These broad categories should easily fit into just about any development methodology you decide to use.

6.3.1. At Design Time

Because design flaws in software can be so costly and time-consuming to repair, taking the extra effort to review software designs for security flaws is time well spent. That's the good news. The bad news is that there aren't a lot of tools and methodologies you can use to automate or streamline the process. As a result, most of the recommendations we make in this section are procedural in nature. What's more, the ones that involve automated tools and languages (e.g., formal methods analysis) can take a great deal of extra time, effort, and money. For this reason, we recommend the use of such tools and languages only for the most critical niche of software design projects—for example, those that can impact public safety.

In reviewing software designs for security flaws, your chief weapons are knowledge and experience. The following recommendations are primarily intended to best exploit the aggregated experiences of the design team, their peers, and others in the design review process.

Perform a design review

Regardless of how formal or informal your software development process is, we hope that at a bare minimum, you document your application's design before proceeding ...