開発フェーズのセキュリティ課題に応えるツール"LAC Karasu"開発の背景

私たちは、企業の保有するシステムのセキュリティリスクを統合的に可視化することでセキュリティリスクをコントロールできるようにすることを目指した新規プロダクトの企画・開発を進めています。その第一歩として、開発フェーズにおけるセキュリティチェック推進とセキュリティリスク把握を実現する"開発セキュリティリスク可視化ツール LAC Karasu"を2024年9月に公開しました。

現時点では、私が実際に直面した課題を解決するための機能を提供しますが、みなさまにも使っていただき、フィードバックを反映することでより多くのお客様の課題を解決できるプロダクトを目指します。今回はこのプロダクトを公開するに至った背景をご紹介します。

開発におけるセキュリティリスクの可視化

"開発セキュリティリスク可視化ツール LAC Karasu"を企画したきっかけは、私自身が開発者として体験したモヤモヤにあります。それは「セキュリティ、やらなきゃいけないのはわかるけど、どうしたらよいか決めるのが難しい」ことです。

セキュリティの悩み

開発者としてはちゃんと動作するシステムを開発したいものです。

ちゃんと動作することを確認するためには様々なテストを実施します。そのテストはシステムに対する想定された操作に基づいて設計されています。それによりシステムの不具合をなくしていきます。

しかしながら、不具合のなかでもセキュリティの不具合である脆弱性については、こうした想定された操作に基づくテストでは検出が難しいです。脆弱性の検出には想定されない操作に基づいたテスト設計が必要であり、セキュリティ専門家の観点が求められます。ここが開発者にとっての悩みとなります。

次に私の実体験に基づくセキュリティの悩みをご紹介します。

セキュリティチェックをする

Webアプリケーションを開発する場合、テストフェーズでセキュリティ専門家にWeb診断を実施してもらうケースが多いかと思います。確かにこのWeb診断で大抵の脆弱性が検出されるでしょう。しかしながらWeb診断はWebアクセスを介した診断です。Webアクセスを介さない脆弱性はどうしましょう。

システムのインフラに問題がある場合はWeb診断では見つかりません。そこで、プラットフォーム診断を実施し、インフラ的な観点の脆弱性を検出します。これでWebアプリケーションとそのインフラの脆弱性は検出できました。

これでバッチリでしょうか？Webアプリケーションが使っているOSSライブラリに脆弱性があったら？ミドルウェアは？OSは？コンテナは？クラウドの設定は？設計に起因する脆弱性は？と不安は尽きません。すべて診断できればよいですがコストの問題もありますし、一度実施すれば大丈夫というものでもなく、キリがありません。

このように、セキュリティについてどこまで何をやればよいか開発者だけで考えて決めるのは難しいものがあります。

セキュリティチームに頼る

そこで頼りになるのが、社内各部門や開発・運用チームに対し、セキュリティ施策を浸透、実行させる役割を担っているセキュリティチームです。彼らはこのシステムをリリースするためにはどうすればよいか示し、リリースしても大丈夫かどうかセキュリティ観点でチェックしてくれます。しかしながらその示し方が抽象的なケースが多いです。

例えば「必要に応じてセキュリティチェックをすること」のようなガイドラインは、どんなセキュリティチェックをすればよいかを開発チームに委任しています。よってガイドラインだけでは先ほどの悩みは全く解決されず直接セキュリティチームと会話して必要なセキュリティチェックを決めていく必要があります。

考察

セキュリティの悩みについてもう少し考えてみます。

開発チームの立場を考える

開発者は開発に対する専門家であって、セキュリティの専門家ではありません。脆弱性をなくすためにどんなテストをすればよいか、これをやれば大丈夫と言えるレベルを判断するのは難しいです。

もし自分が開発した箇所に脆弱性があり、セキュリティインシデントが発生してしまったら、想像するだけで血の気が引きます。

セキュリティチームの立場を考える

セキュリティチームの立場では、各部門の各開発チームが開発している様々なアーキテクチャのシステムがあるなかで、一律このセキュリティチェックをすればよいとは決められないでしょう。さらには各部門の開発チームが具体的にどんなことをしているか把握するのも困難です。

社内の情報システム部門が用意した環境へのシステム構築であればある程度把握できますが、昨今はクラウド上へのシステム開発が普及しているためそれらの全てを個別に把握するのは現実的に難しいでしょう。ある程度抽象的なガイドラインの設定が妥当と言えます。

また、全ての開発でガイドラインが守られているかをセキュリティチームが直接確認するのは難しく、開発チームにチェックリストへ回答してもらう形でセキュリティの対応状況を把握するのが精一杯でしょう。

そこには、アジャイル開発やDevOpsといった開発サイクルの短期化や頻繁なリリース、クラウド・コンテナ・OSSなど開発環境の多様化、セキュリティエンジニア不足といった背景があり、セキュリティチームで各開発チームがどのような開発をしているか把握するのが難しくなっていることが原因として挙げられます。

そのため、セキュリティチームから開発チームに具体的な依頼ができず、また開発チームでも何をやればよいかわからず、といった負の連鎖が発生してしまうのではないでしょうか。

課題は何か

ここまでの話のなかから、開発チームは具体的にどんなセキュリティの取り組みを実施すれば良いかわからない、セキュリティチームは様々な開発チームに対して一歩踏み込んでいくことが難しい、という課題が設定できるかと思います。

開発チームは、具体的にどんなセキュリティの取り組みを実施すれば良いかわかれば、開発フェーズでのセキュリティの組み込みを推進していくことができるようになるでしょう。セキュリティチームは、開発チームに対して一歩踏み込んでいくことができれば、開発におけるセキュリティリスクを正しく把握できるようになり、適切なセキュリティ施策を推進できるようになるでしょう。

この課題はアジャイル開発やDevOpsの普及によってより困難で、かつ、より重要な課題になってきているのではないでしょうか？

必要なこと

求められることは、開発のスピードを落とさずにセキュリティを確保することです。そのためにはDevSecOpsやセキュアソフトウェア開発ライフサイクル（SDLC）と言われているように、開発にセキュリティを組み込むことが必要です。

開発にセキュリティを組み込む

開発にセキュリティを組み込むにはどうしたらよいでしょうか？

「開発チームとセキュリティチームが密に連携すればよい」と言うのは簡単ですがそれが簡単にできるならDevSecOpsという言葉も出ないと思います。DevOpsでさえ難しいと言うのにさらにSecurityを追加しようと言うのですから。

セキュリティエンジニアの不足が社会問題となっているなか、セキュリティチャンピオンという開発チームにセキュリティ担当者を配置する取り組みもまだまだ時間がかかりそうです。

であれば、先ほどの悩みを解決するために、開発にセキュリティを組み込むには現状の体制のなか、できることをやっていくしかありません。まず手をつけるべきは下記2点かと思います。

1. 開発チームが何をすればよいかわかるようにする
2. セキュリティチームが開発チームを理解できるようにする

開発チームが何をすればよいかわかるようにする

開発チームが何をすればよいかわかれば、先ほどの悩みはほとんど解決したようなものです。ですが、各開発チームに合わせて都度開発チームとセキュリティチームが協議するのも効率が悪いです。それにはガイドラインの具体化が必要です。

システム特性に応じてこういったシステムはこのセキュリティチェックをする、といったようなパターン化が必要でしょう。ここでのシステム特性とはシステムのアーキテクチャだけではなく、公開範囲や保有しているデータの機密性、必要とされる可用性、売上規模、ユーザー数など様々な観点で必要とされるセキュリティ品質がどの程度かレベル分けし、パターンごとに具体的なセキュリティチェックを提示できるとよいでしょう。

セキュリティチームが開発チームを理解できるようにする

セキュリティチームがシステムの全てを理解し、開発で何をやっているか事細かに理解することは難しいですが、少しずつであれば理解していけるのではないでしょうか。

先ほど「開発チームが何をすればよいかわかるようにする」でも取り上げた、パターン化するために必要なシステム特性を収集するところから始めることで、開発しているシステムがどのようなものか把握できます。

また、セキュリティチェックを予定通り実施しているかどうか、また検出された脆弱性の対応状況について共有できれば、これまでのチェックリストで確認している時と比べ解像度が全く違ってくるのではないでしょうか？すると開発チームとセキュリティチームがともにセキュリティリスクを正しく把握できるようになり、そのセキュリティリスクに対してどのように取り組んでいくか考え行動していけるようになるでしょう。

この2つの取り組みを繰り返していくなかで、パターンが洗練されていき、開発チームとセキュリティチームの連携が進み、正しいセキュリティリスクの把握による適切なセキュリティ施策が推進されていくのではないでしょうか？

開発セキュリティリスク可視化ツール LAC Karasu

ここまでお話ししたDevSecOps推進の第一歩としての新プロダクト"開発セキュリティリスク可視化ツール LAC Karasu"の企画と開発を進めており、2024年9月に公開しました。このプロダクトは私自身が開発者として直面した悩み・課題に対する「必要なこと」を形にしたものです。

開発者のセキュリティの悩み・課題は私だけではなく、みなさまのなかにも同じように抱えている方が多くいらっしゃると思います。このプロダクトをみなさまの悩み・課題を解決できるものに昇華させたいと考えています。そのためには、実際にみなさまにこのプロダクトを利用していただき、フィードバックをいただくことが必要です。

セキュリティの課題を共有し、解決策を共に見つけ出すことで、より良いプロダクトを作り上げていきたく、ぜひ、みなさまのご意見やご提案をお寄せください。