DevSecOpsは必要だと改めて思った話

本稿はJCB Advent Calendar 2023の12月24日の記事です。

はじめに

セキュリティチームの長沼です。

DevSecOpsという技術ワードがあります。
開発〜運用を一体に行うDevOps全般にわたりセキュリティを考慮し、より開発前工程で気づくことにより手戻りを減らすこと(Shift Left)を目的とするものです。
アジャイルで開発していく上で、その必要性を改めて強く感じることがありましたので、ご紹介したいと思います。

JDEP初期のアプリ開発の流れ

この話をする上で、まず初期のJDEPにおけるアプリ開発の流れについて説明させてください。

JDEPではアジャイル・スクラム開発で1〜2週の開発スプリントを繰り返し、開発を進めています。
初回リリース、すなわち顧客ニーズを満たす最小プロダクトであるMVP（Minimum Viable Product）リリースまでは、アジャイル開発とはいえMVP完成までは相応の開発期間が必要のため、大きく見ればウォーターフォールの流れに近くなっていました。

このときセキュリティ対策の面では、以下等を行うことにより担保していました。

開発フェーズ向けに実装上のセキュリティ注意点をまとめたガイドラインの提示・教育
リリース前に各種セキュリティテスト（有識者によるコードレビュー、脆弱性・ペネトレーションテスト等）の実施

アプリのリリース後に生じた問題

時間の経過とともにMVPリリース済アプリも増えてくると、セキュリティに関して新たな問題が発生してきました。

リリース後のセキュリティ維持という観点では、カード取扱システムが準拠すべきセキュリティを定めたPCIDSSに準拠するアプリであれば、四半期または年次でPCIDSSが定めるセキュリティテストや審査をうけることになり、一定のセキュリティは維持できます。
しかしアジャイルで開発するとリリースサイクルが短くなり、下図のように定期の対策ではカバーしきれない部分が出てきます。
PCIDSS準拠ではないアプリにおいては、さらにどのようなタイミングで実施すべきか、から検討が必要になります。

結果、Shift Leftの必要性に加えて、次のような問題が発生し始めました。

#	問題	発生対象
(1)	各リリースにおいてどの程度セキュリティ対策やテストをすればよいか分からない	アプリ開発チーム
(2)	(1)が不十分だった場合、リリース後にセキュリティリスクが増加する	アプリ
(3)	頻度増によりレビューやセキュリティテストの有識者・実施者のリソースが不足する（またはコストが増加する）	セキュリティチーム
(4)	(1)〜(3)に関する問い合わせ増による対応者の調整コストが増加する	セキュリティ &アプリ両チーム

※ 各チームの構成はこちらの体制図を参照ください。

問題に対する取り組み

前述表の(2)は言うまでもなく問題ですが、アジリティを重視するJDEPの開発では、(1)や(3)(4)も十分に問題たりえます。
実際に現場ではリリース済アプリが増えるほど「xxxという機能追加したときは有識者コードレビューしたほうがよいですか？」、「そのセキュリティテストは対応者の負荷集中で少し日程変更したいのですが大丈夫ですか？」といった相談・調整が増加していくのを実感しています。

そうした課題を解決する1つの手段が、DevSecOpsという考え方であり、それを実現するツール群ではないかと最近よく感じます。
具体的には、前述の表の問題に対して、次のような課題を設定し解決のために評価検討を進めています。これにより開発全般にわたり一定のセキュリティが自動的に担保された状態を維持しつつ、有識者による対応でセキュリティを確実なものにすることを目指しています。