We need people reviewing the code of exchanges. We can't keep having Mt. Gox and Bitstamp incidents.

This is a component fallacy; you are begging the questions:

"would code reviews have prevented the fraud incidents at Mt. Gox and Bitstamp?" and

"would code reviews have prevented the fraud at Mt. Gox and Bitstamp in the most cost effective manner, or would other solution(s) have served more effectively?".

In fact both incidents, especially the former, may have been intentional acts carried out by insiders, potentially over a long period of time.

Assuming that code reviews would have prevented the two incidents:

1) creates mandatory code reviews by 3rd parties for 100% of exchanges

2) creates a false sense of security in that exchange operators now feel that they are "safer", when they need to be focusing on separation of duties and eliminating developers and executives from having any ability to commit code to production directly before a QA cycle.

You have now successfully introduced a) cost (code review) b) time (code review) and c) no real security improvement.

This is my point. This is exactly the type of bureaucratic thinking we need to avoid like the plague.

Some organizations may have processes already in place to test releases independently where a different employee or team releases code only after a QA cycle. Others may have really strong QA employees who also write and understand the code base. Still more may lack any controls and might benefit from code reviews or hiring test staff and setting up more formal procedures around changes or release of code that moves money or handles PII.

For example, I would argue that for gox and stamp, controlling your own private keys for your deposits until you wish to trade would have been a better solution. Also, removing the CEO of Gox's ability to commit code to production or update production data would have been ideal. Stamp could have used background checks on all employees and a full crypto/financial audit. That's my opinion, but again, I have no proof that these "solutions" would have prevented the incidents either. This is the danger of checklists when applied too broadly. They introduce cost and generalization that comes at the expense of specificity and customized security solutions. I would rather pay for a more talented and experienced consultant than a checklist anyday, frankly.

The standards meant to prevent fraud should be written with economic incentives that reward the author of the standards when fraud is prevented.

If this is not the case, standards are still necessary, but they should NOT be tied to for profit "seals of approval", mandatory compliance, or a private company.

The standards should be maintained in an open source manner. If security consultants want to use the standards to give consulting services, and companies feel they are worth the expense, companies will hire the consultants. I know we are planning to do exactly this with Novauri, and not because it's a requirement, but because it is a good idea and worth the investment.

Don't get me wrong, I think a crypto-security checklist is an awesome idea and sorely needed, but we cannot let this turn into BCI compliance. There are enough people already trying to wall off innovation around bitcoin and carve out a monopoly for themselves. Let's not aid and abet them, ok?