生成AI時代だからこそ必要なDevSecOps:概念から実践例まで
ベネッセ様からご招待いただき、8/27にDevSecOpsのお話をしてきました！掲載の許可をいただきましたので、当日の資料とパネルディスカッションの内容を公開します。
資料はこちらです。
パネルディスカッションでの質問と回答の一部はこちらに。
大企業でDevSecOpsを導入する際のあるあるな課題は？
説得すべきステークホルダーが多いこと。DevSecOpsの場合、セキュリティ担当者、プロダクト開発チーム、そして導入には多少なりともコストがかかるので予算を管理している意思決定者などのビジネスレイヤーがステークホルダーになり得るので、部署間を超えたステークホルダーの説得や交渉が最初の課題になり得る。
また、現場とビジネスレイヤーの意思決定者（DevSecOpsのツールを導入する際に予算関連の意思決定ができるレイヤー）とのコラボレーションできるパスが作れるかということも重要。
ビジネスレイヤーから現場に対して生産性向上やDX推進のためにやれ！と丸投げされて現場がモチベーションもなくやらされ感を感じたままでもうまくいかないし、現場の開発者だけがやる気に満ちていてもビジネスレイヤーの意思決定者に開発体験の向上以外の具体的なビジネスメリットや成果への結びつきを説明して説得できないと全社展開に至ることは難しい。
DevSecOpsに限らずカルチャーやプロセスの変更を伴う変革を大規模な企業で推進する際には、ビジネスレイヤーの意思決定者と現場が同じ目標に向かってコラボレーションできるような状況をつくれるかが最初の課題になり得る。
ステークホルダー間の摩擦にはどのようなことが想定されるか？
セキュリティスキャンを導入することで、そのスキャンの実施のためにも時間がかかるので、開発プロセスに導入することで開発スピードが遅くなってしまうのでは、という不満が開発チームから発生することは1つ想定される。実際にスキャンのすべてのチェックポイントで実施して、Middle, Lowレベルの脆弱性も一切許容しない、すべてのセキュリティ脆弱性をクリアにすることなどを品質ゲートのように適用することは現実的ではないため、既存の開発プロセスのどこに適用するのか、開発スピードとセキュリティ担保によるコストのバランスを両立していくことが重要。
もうひとつは、セキュリティ部門からDevSecOpsを実施するように開発チームに依頼がくるけれども、どうすればいいかわからない、どちらがどの程度コミットすべきか責任分界点があいまいになってしまうということも想定される。
セキュリティスキャンを実施する際のチェックポイントとして、どのようなポイントでどのようなチェックを実施すべきか？
ひとつはmainブランチなどの長命ブランチに対してPRが作成されたタイミングで、単体テストやセキュリティチェックを行うこと。次はmainブランチ（のような統合後にテスト環境→stg環境にデプロイされるようなブランチ）にマージされたタイミングで、セキュリティチェック、単体テスト、結合テストを行うというのがAzure Pipelinesのベースラインアーキテクチャで提唱されている。そして逆にシフトレフトしないほうがよいテスト（本番環境に近い環境でやることに意味があるテスト）もあるので、動的アプリケーションテストや侵入テスト、パフォーマンステストなどは本番環境にできるだけ近づけたstaging環境などで実施する。
DevSecOpsやDevOpsを企業で実施していく場合、実際問題プロダクト開発と並行して推進していくのは大変だと感じる。どのようなチーム編成で始めるべきか。
プロダクト開発と並行して実施してくのが大変というのはほんとうにその通りで、DevOpsの推進で必要な技術スキルセットの習得、ステークホルダーの説得等々は兼務するにはコストが高くなっていると思う。そのような問題はPlatform Engineeringの成立背景としても指摘されている。
（参考：https://sre-magazine.net/articles/9/yuriemori/）
SREでは、Googleのようにプロダクト開発とは切り離した専門のEnablementチームを別で作るタイプ、Netflixのようにプロダクト開発のチームの中にSREを推進するEnablerを配置するタイプのフォーメーションがある。前者の場合は、大規模な組織の中で標準化したプラクティスを確立して全社展開することが必要な場合に有効で、後者の場合は事業部やチームの自立性がある程度高くて、その中で裁量があり、スピーディーな展開を優先する場合に適している。
個人的には、大規模な企業ではDevOps/DevSecOpsなどカルチャーやプロセスを変革するには多くのコストが必要になるため、それぞれのプロダクト開発と足並みを揃えるよりも専属のEnablementチームを作って推進していくというのがやりやすいと思う。
DevSecOpsやDevOpsのような活動やムーブメントをスモールスタートしていく際に、どうやってはじめればいいか？メンバークラスにできるキャッチアップや活動等はどのようなものがあるか？
キャッチアップという意味では導入を検討しているDevSecOpsのプロダクトにDevSecOspのロールアウト戦略や考え方などがある程度整備されているので、そういったものを参照するというのが1つ。
最も取り組みやすいのは、小規模でも社内でカジュアルなLT会などの勉強会を開催して啓蒙活動をしていくこと。理想的にはそういった取り組みが社内で認められれて、正式に予算を割り当てられててEnablementの責務を持つチームに進化していくというのが理想的。
そしてそういった社内へのアピールの取り組みの際には、DevSecOpsによって何がどうよくなるのか？というbefore/afterが示せると強い。できれば定量的なメトリクスをpublicに公開されている事例からでもよいので、このような効果が見込める、と定量的に示せるとさらによい。
DevSecOpsを導入する際のロールアウト戦略として、標準化されたプラクティスを一気にロールアウトした方がよいのか？それとも段階的にロールアウトしていくのがよいのか？後者の場合、何から始めるのがよいか？
DevSecOpsを導入する場合、いきなり多くの開発者に既存の開発プロセスに統合していくと誰がどうするとかの運用の問題や、セキュリティ的な脆弱性がたくさん検知されたときにどうするなどのプロセス整備が追い付かない可能性があるため、最も事業に影響を与えているプロダクトを作っている事業部から/10-20人ぐらいの小規模なチームからPoCをして効果が実感できたら徐々に展開する、という段階的なロールアウトをおすすめする。
プロセスの適応コスト以外のもうひとつの問題として、DevSecOpsを導入する場合当然ながらツールの料金等のお金もかかるので、最初からうまくいくかわからない状態で一気にたくさんの利用料を払うことを意思決定することは難しいと思うので、そういったお金の面からも最初は限定的な範囲で検証をして効果が実感できたら展開、という進め方をおすすめする。
そしてロールアウトの際に最初はまずこれから、というものに関しては、シークレットスキャンを強く推奨する。SQL injectionやXSSなどセキュリティ的な脆弱性のあるコードに比べると、シークレットに関しては実際にそれを使って攻撃されなかったとしても本番環境で露出しただけで一発で信用問題になり、それ自体がセキュリティインシデントになる。そのため、一番最初に着手すべきことはシークレットスキャン。
DevSecOpsを導入した後、セキュリティスキャンを行ったときに数千件などの大規模のセキュリティ脆弱性が見つかった場合、それらをトリアージしていって対応していくというのはとても大変に感じるが、どうすればよいか？
DevSecOpsを実施する際、運用と同じでアラート疲労や発見された脆弱性のトリアージの際の認知負荷の問題は大きな課題になる。GitHubではSecurity Campaignというセキュリティ的な脆弱性を数千件規模でトリアージして重要度をラベル付けし、さらにCopilot Autofixが修正案を提案してくれるような機能もあるので、そういったツールの助けを借りるというのも一つの方法。
前提として、アラートで直接通知してすぐに直さねばならない、というのはかなり心理的な負担になるため、アラート自体を本当にCriticalなものに絞るということが必要。Middle, Low以下のリスクに関しては、定期的なレトロスペクティブなどで数を決めてトリアージするなど、チームとして定点観測できる機会を持つということもひとつの手段。
開発生産性やパフォーマンス向上に関しては、開発タスクの完了の時間が早くなったなどわかりやすいメリットが示せると思うが、セキュリティの場合メリットを示しにくいと感じている。どのように美ジュネスレイヤーにDevSecOpsのメリットを訴求すべきか？
セキュリティの訴求の際によくある方法としては、セキュリティ対策をしない場合にどのような影響があるのかというホラーストーリーを語るということがひとつあるが、もう少し具体的な話をするとしたら、DORAのFour Keysの変更障害率や平均復旧時間などのシステムの安定性を測るメトリクスがどうなるのか、ということを語るということがひとつの方法としてあげられる。たとえばリリースしたあとに発生したセキュリティ的なリスクやインシデントの発生件数や、それらの検知するまでの時間、修正するまでの時間がDevSecOps導入のbeforeとafterでどう変わるかなど。更にいうと、リリース前に検知できたはずのリスクや脆弱性を修正したり調査したりするのにかかる時間とそれに伴うエンジニアの単価を計算して、どれだけコストメリットがあるかなどを語る。
おまけ
キティちゃんとベネッセのしまじろうと記念撮影
Discussion