読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第40回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。ここ最近はこんな本を読んでいる。
- #39 「セキュア・バイ・デザイン」を読んでいる（１） #デッドライン読書会 - 勘と経験と読経
- #38 「Team Topologies」後半読んだ #デッドライン読書会 - 勘と経験と読経
- #37 「Team Topologies」前半読んだ #デッドライン読書会 - 勘と経験と読経
- #36 「恐れのない組織」読んだ #デッドライン読書会 - 勘と経験と読経
- #35 「リーン・エンタープライズ」後半も読んだ #デッドライン読書会 - 勘と経験と読経
さて、今回のお題は前回に引き続き「セキュア・バイ・デザイン」である。
けっこうな分量があるので、３回に分けて読んでいる。この記事は２回目で、「第6章: 状態の完全性（integrity）の保証～第11章: ちょっと休憩: 保険料の支払いなしに成立してしまった保険契約」までを読んでの感想になっている。
中盤を読んでの感想
- とりあえず「設計」と「実装」を別の作業者で切り分けるようなトラディショナルなエスアイアーさん向けの本ではない
- DDD章（7章まで）では設計をミスると、どんなひどい目に合うかという事例が豊富で学びは深い
- 8章以降は別の観点で開発プロセスとセキュリティ（というかシステム脆弱性）の観点に関する様々な知見が取り込まれていて刺激的だ
中盤まで読んだところで、改めて著者の以下の主張である「セキュリティを機能（feauture）ではなく心配事（concern）として捉える必要性」が重要であるということがずっしりと腹落ちしてくる。ここまでに列挙されるあんなことや、そんなことは、はっきりいってテストで見つけるのは無理だ。セキュリティテストを最後にやってOKという判断は現実的ではないということがわかる。
しかし一方で、本書に書かれているような「セキュア・バイ・デザイン」を実際に実行することもなかなか難しそうだ。チーム単位で本書（および本書の前提となるいくつかのDDD本）の勉強会を継続的に開催するなどしなければ、プロダクトへの適用は難しそうだ。そういう意味では本書の展開はなかなかの課題だと思う。
DevSecOps
本書では「DevSecOps」という単語そのものは（たぶん）出てこないのだけれども、一番刺激があった「第8章: セキュリティを意識したデリバリ・パイプライン」は現代で言えばDevSecOpsの話であるとは思う。ただ自分の知る限り、DevSecOpsは外挿的というか「セキュリティに関する考慮を外部から強制する」ものという理解なので、すこし立ち位置は違うのかもしれない。
あとDevOpsのプラクティスとしてよく語られるフィーチャートグルについて、セキュリティ的な脆弱性となる場合があるので特に注意をしてテストをすべきという話は、他ではあまり見ないような気がする重要な論点だと思う。覚えておこう。
次回、完結編
さて、なかなかに難しかった基礎編が終わり、次回は「第3部: 応用編」である。レガシー・コードへの適用や、マイクロサービスでの指針などが語られるそうで、ちょっと楽しみである。
