「セキュア・バイ・デザイン」を読んでいる（２） #デッドライン読書会

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第40回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。ここ最近はこんな本を読んでいる。

さて、今回のお題は前回に引き続き「セキュア・バイ・デザイン」である。

けっこうな分量があるので、３回に分けて読んでいる。この記事は２回目で、「第6章: 状態の完全性（integrity）の保証～第11章: ちょっと休憩: 保険料の支払いなしに成立してしまった保険契約」までを読んでの感想になっている。

中盤を読んでの感想

とりあえず「設計」と「実装」を別の作業者で切り分けるようなトラディショナルなエスアイアーさん向けの本ではない
DDD章（7章まで）では設計をミスると、どんなひどい目に合うかという事例が豊富で学びは深い
8章以降は別の観点で開発プロセスとセキュリティ（というかシステム脆弱性）の観点に関する様々な知見が取り込まれていて刺激的だ

中盤まで読んだところで、改めて著者の以下の主張である「セキュリティを機能（feauture）ではなく心配事（concern）として捉える必要性」が重要であるということがずっしりと腹落ちしてくる。ここまでに列挙されるあんなことや、そんなことは、はっきりいってテストで見つけるのは無理だ。セキュリティテストを最後にやってOKという判断は現実的ではないということがわかる。

しかし一方で、本書に書かれているような「セキュア・バイ・デザイン」を実際に実行することもなかなか難しそうだ。チーム単位で本書（および本書の前提となるいくつかのDDD本）の勉強会を継続的に開催するなどしなければ、プロダクトへの適用は難しそうだ。そういう意味では本書の展開はなかなかの課題だと思う。

DevSecOps

本書では「DevSecOps」という単語そのものは（たぶん）出てこないのだけれども、一番刺激があった「第8章: セキュリティを意識したデリバリ・パイプライン」は現代で言えばDevSecOpsの話であるとは思う。ただ自分の知る限り、DevSecOpsは外挿的というか「セキュリティに関する考慮を外部から強制する」ものという理解なので、すこし立ち位置は違うのかもしれない。