安全なスマートコントラクト開発の手引きとなる「ソフトウェア開発ライフサイクル」とは｜Hi-Con 2018注目内容取材
今回はこの記事を取り上げてみようと思います。
コード監査を含むスマコンに必要な管理・監査は
「スマートコントラクトに必要なもの」に書いたのでそちらに譲るとして、ここでは
Deploy
一通りテストが終わったら、テストネット（テスト環境）などにDappsを展開する。
そこで実際の動きを確認し、改善点を洗い出していく。
大抵のDappsでは、この段階でバグバウンティ（賞金付きのバグ発見イベント）が実施される。
ここの部分について考えていきます。
バグバウンティ自体の説明は
脆弱性報奨金制度「バグバウンティ」とは｜導入している企業15選｜フリエン
こちらをご覧ください。
CVSSは興味がある方だけが調べれば大丈夫です。大方の予想通り、深刻なバグを見つければより大金を獲得できます。
最近ではバグと言えば
EOS、メインネットのローンチ２日後に「フリーズ」 | Cointelegraph
こちら、EOSがメインネットをローンチした後二日で止まった事件を思い起こします。
その最中に起こったのがこちら
ホワイトハッカーが1週間でEOSの脆弱性を12か所発見｜報奨金約1320万円獲得か
バグを発見し、それに対して報奨金が出たという話です。
既にこのブログでは何回か書いているのですが、この懸賞金の額とバグの性質が問題だと思うのです。
説明します。
バグを見つけた、その重大性に見合った懸賞金を払う。そこまでは何の問題もありませんよね？
じゃぁ、そのバグによって行える不正行為が、プロジェクト組織が払える限度額を超えていた場合はどうなりますでしょうか？
扱う金額が大きい、もしくは相当量のトランザクションが予想されるよく使われるものである場合、不正により得られる利得は大きいと考えます。
それは、プロジェクト組織が払える限度額を超えるかもしれません。
その場合、正直に報告してくれる人がどれだけいるでしょう？
たいていは、その不正行為を行うか、誰かに情報を売りつける側に回るか（バグを使ってこういう事ができるよ、と）だと思うのですね。
だから、バグバウンティはその前に大きなバグ・深刻なバグがないという状態をもってお小遣い稼ぎのためになされるのだと思います。
逆に言えば、まともなプロジェクトでバグバウンティによる大金稼ぎはできなさそうで、そうあるべきだと思います。
大金が動くシステムで、もしくは広く頻繁に使われるシステムで見つかりずらいバグがあった場合、それにバグバウンティは機能しないように思います。
?
