Touchpoint Process: Code Review
I am not a process person,
Figure 4-7 shows a very simple process for applying a static analysis. Note that this is only one of many processes that can be wrapped around a source code analysis tool. The process here is very much based on a software assurance perspective and is the kind of process that a software security type or an analyst would use. There are other use cases for developers (e.g., more closely aligned with IDE integration). This process is one of many.
Figure 4-7. A simple process diagram showing the use of a static analysis tool. This is a simplified version of the process used by Cigital.
Static code analysis can be carried out by any kind of technical resource. Background in software security and lots of knowledge about software security
The analyst can choose from any number of security tools (as shown in Figure 4-7), including, in some cases, use of research
Note that raw tool results are not always the most useful form of information that this process can provide. As an analyst pours over results, some possible problems will turn out to be non-issues. Other possible problems will
The simple process shown in Figure 4-7 results in code that has been fully diagnosed and a set of issues that need to be addressed. Fixing the code itself is not part of this process.
A much different approach can be taken by developers who can use a tool to spot potential problems and then fix them as they work. This is probably the most effective use of static analysis technology. Even so, widespread adoption of source code analysis tools by development
Use a Tool to Find Security
Chapter 5. Architectural Risk Analysis 
Design flaws account for 50% of security problems. You can't find design defects by staring at codea higher-level understanding is required. That's why architectural risk analysis plays an essential role in any solid software security program. By explicitly identifying risk, you can create a good general-purpose measure of software security,
The security community is unanimous in proclaiming the importance of a risk-based approach to security. "Security is risk management" is a mantra oft repeated and yet strangely not well
As I describe in Chapter 1, a continuous risk management process is a necessity. This chapter is not about continuous risk management, but it does assume that a base process like the RMF exists and is in place.  By teasing apart architectural risk analysis (the critical software security best practice described here) and an overall RMF, we can begin to make better sense of software security risk.