CRV2 RiskBasedApproach

Development notes:

* 3? - Accept, Transfer, Avoid or Reduce
* 4 - integrate into repeatable CCPM
* DONE - mgmt will ultimately own the risk
* 3 - CIA of risk
* DONE - management of resources (machines, time, skills)
* 3 - what is high risk? Ease of exposure?  Value of loss?
* 3- analogy to car development/maintenance risk.  Subjective or regimented risk, regulartory controls are higher risk
* 1 - test everything or just high risk?
* 3 - risk analysis involves cost/benifits analysis
* 1 - sizing review would allow mgmt to know what resources are needed
* ? - redundancy and physical failure
* 4 - high risk issues/features are candidate for automated testing/review checks
* 4 - a lot of static analysis tools allow for modules/tests to be plugged in.  High risk could be candiate to be mitigated in this way.
* 3 - diff codelines for more sensitive code
* 3 - quantitive vs qualative risk
* 1 - risk could determine who reviews/how many people/# of signoffs etc
* 3 - risk is chance of something bad happening and damage if it occurs

1 Not all bugs are equal

A development house will have various degrees of code being reviewed, from simple one line bug fixes in backend scripts that run once a year, to large feature submissions in criticial business logic. Typically the intensity of the code review varies based on the perceived risk that the change presents, though typically the perception of this risk is informal and adhoc. It comes down to the management of resources (skilled persons, company time, machines, etc). It would not be common to bring in multiple security architects/experts for every code change occuring on a product, the bandwidth of those persons or those teams would not be large enough to handle every change. Therefore companies can make a call on which changes are important and need to be closely scrutenized, and which ones can be allowed through with minimal inspection. The process of deciding which changes need which level of code review is based on a Risk Analysis of the change being made.

2 Who makes the call on Code Review Risk?

So if we are going to vary our code review intensity based on the nature of the change being made, who should decide the level of risk? Eventually, company Management are responsible for the output of a company, and thus they are responsible for the risk associated with products sold by the company, therefore it is up to Management (or persons delegated to by Management) to create a reproducable measure or framework for deciding the risk associated with a code change.