2022年3月4日

NEC サイバーセキュリティ戦略本部 セキュリティ技術センターの山本和也です。セキュリティサービスのアジャイル開発業務を担当しており、スクラムマスター[1]として活動しております。今週のセキュリティブログでは、アジャイル開発におけるセキュリティテストのいくつかの方法と、その中でも特に、リアルタイムに繰り返し検証が可能とされるIASTというテスト方式を紹介します。

1．アジャイル開発における品質確保

本記事で取り扱う開発は、スクラム[2]を用いたソフトウェアのアジャイル開発を想定します。スクラムとは「経験主義」と「リーン思考」に基づく、主にソフトウェア開発の方法論として使われるフレームワークで、反復的に少しずつ価値を積み上げていくことが特徴です。スクラムを用いたアジャイル開発では、継続的に顧客に価値を提供するために、スプリントと呼ばれる周期（１～２週間のケースが多い）での開発を繰り返していきます。リリース可能なものを作り、品質を確保し、リリースを行うということを短い期間で繰り返すことになりますので、特に品質確保を維持するために自動化・可視化などの工夫が重要となります。

例えばUI/UXの品質確保に関しては、ステークホルダー向けに開発した機能を披露するイベントであるスプリントレビューでのユーザーテストや、Selenium[3]のようにブラウザー操作を再生できるようなツールを使ってチェックできます。また、REST APIの品質確保であれば、リクエストの対となるレスポンスを事前に定義し、それに合致するかを検証することでチェックできます。

品質確保には「セキュリティ」も含まれます。設計やコーディングの中で意図せず作り込まれた脆弱性を検出するために、ツールを用いての脆弱性診断等を行うことになります。しかし、数多くの脆弱性や脅威を検出するためのテストを短い周期で継続的に実施していくことは、技術面・コスト面など複数の点で困難を伴います。

以降の章で、実際にアジャイル開発を進めていく上で、どのようなテスト方法が存在するかについてご紹介します。その中で特に、リアルタイムに繰り返しの検証が可能という特性からアジャイル開発の中で活用が期待されるIAST(Interactive Application Security Testing)の説明をします。

2．セキュリティテストのアジャイルへの組み込み

スクラムにおいてどのようにセキュリティ対策を組み込むのでしょうか。スクラムの指針を示したガイドとして”スクラムガイド” [4]。があります。このスクラムガイドの中では「セキュリティ」については明確には触れられていません。

スクラムガイドの中でセキュリティを確保する方法について触れられていないのは、スクラム自体は単なるソフトウェアの開発手法ではなく、変化に追従するためのアプローチ・方法論であるからであり、ソフトウェアがもつ脆弱性やその対処は、ソフトウェア開発特有のものであるからです。

それでは、アジャイル開発においてスクラムガイド以外にセキュリティを確保する方法はないのでしょうか。例えば、ソフトウェア開発や運用の中で、セキュリティが実装されていることを担保する方法として以下が存在します。

SAST (Static Analysis Security Testing)

SAST(Static Analysis Security Testing)[5]とは、静的なセキュリティテストのためのテスト手法・およびそれを支援するツールです。SASTを使ってソースコードやバイナリなどに問題がないかを検査します。これにより、作成した成果物の中の意図しない脆弱性を検出することができます。

ソースコード等の分析になるので、対応しているプログラミング言語やソフトウェアの範囲が広く、既知の脆弱性を多く検出することができます。同時に、該当するソースコードの箇所も特定できるため、修正に移りやすいというメリットもあります。一方で、ソースコード単体では把握しにくい、システムのコンポーネント間の連携の不整合によって発生するような認証機能の不備、データ同期、アクセス制御の脆弱性をはじめとした、検出が難しい領域がある点や、誤検知の多さが問題とされています[6]。

SASTをアジャイル開発に組み込む場合は、例として、CI/CDツールにてSASTを実行できるように準備する方法があります。そして、ソースコードに変更があった時や、定期（数日に一度等）実行という使用方法が考えられます。多くのプロジェクトに適用しやすくCI/CDツールとの相性もいいため、組み込むのは比較的容易と考えられます。しかしながら、開発者がスプリント内で誤検出の対応を迫られるというコストが問題となります。

DAST (Dynamic Application Security Testing)

DAST(Dynamic Application Security Testing) [7]とは、動的なセキュリティテストのためのテスト手法・およびそれを支援するツールです。実際にアプリケーションを動作させた上で、攻撃シナリオに基づいたシミュレーションによって脆弱性を検出します。

実際の環境に対してテストを行うという性質上、プログラミング言語やフレームワークには依存しないこと、サーバ構成の不備や認証、ユーザログインの問題など、実際のシナリオ上で起こる脆弱性を見つけやすいというメリットがあります。一方、効果的なテストを行うためにはセキュリティの専門家がシナリオ・ツールのチューニングを行う必要があるケースが多いことや、スキャンに時間がかかる（5～7日程度続く可能性がある）傾向にあることなどがデメリットと言われています。 [8]

アジャイル開発においてDASTは、ツールによっては毎スプリントで実施することは難しいです。例えば、新しい機能の開発に合わせてDASTのテストシナリオやパラメータを調整する必要があり、単純な自動化は難しいことが多いです。また、DASTはスキャン時間が長くかかる傾向があり、スプリントの終盤にスキャンをはじめても終わらせられないこともあります。そのため、サービスの正式リリース前など、あるタイミングでまとめて実施されることが多いと考えます。一方で、実際のサービス構成に近い脆弱性が特定されやすいことから、実施する重要度が高いです。

IASTは次章で説明しますので、一旦ツール以外の方法を合わせて説明します。

脆弱性診断サービス

脆弱性診断サービスとは、セキュリティの専門家が、開発したサービスに対してスキャンなどを実施しサービスに脆弱性がないかの診断を依頼できるサービスです。脆弱性診断サービスでは、専門家がシステムの脆弱性を調査し、調査結果をレポートにまとめて結果報告するという形式が一般的です。

また、単にセキュリティテストを実施して結果を報告するのみではなく、業種に合わせた示唆や、実際に被害を受けた際の影響範囲などを報告の範囲に含めるといったように、付加価値をつけて提供されるサービスも存在します。

広義のセキュリティ検査サービスには、実際のシステムの構成や運用状況を提示して任意の基準やガイドラインを満たすかどうかを確認する情報セキュリティ監査サービスや、不正アクセスや情報漏えいが発生した際にインシデントの原因調査や早期復旧を支援するデジタルフォレンジックサービスなど、多様なサービスメニューが存在しています[9]。

いずれのサービスも、利用契約から診断範囲の決定、実際の調査に必要な期間やレポートの提出まで、２週間のスプリント内で完結させることは難しいです。したがって、製品・サービスのファーストバージョンやメジャーバージョンアップのリリース時、あるいは年次の定期監査など、ポイントを絞って実施していくのが良いと考えます。

マネージドサービスの活用

マネージドサービスとは、広義ではプロセスや機能のアウトソーシングをする手法を指しますが、ここでは開発時に必要な基盤としてクラウドサービスを活用することを想定します。セキュリティの検査とは異なりますが、提供するサービスの基盤としてIaaS、PaaS、SaaSなどのマネージドなクラウドサービスを用いることで、クラウドサービス事業者のセキュリティ実装や対策に委ねるという方法もあります。もちろん、クラウドサービスは適切なものを使う必要があり、適切な管理が必要になります [10]。

この方法は、アジャイル開発であってもそうでなくても広く活用できるため、開発が不要な部分は適宜マネージドサービスを活用していくということは、セキュリティ実装の面でも大切なことです。

3．IAST (Interactive Application Security Testing)

ここまで挙げたいずれの方法も、開発と並行して短期間でセキュリティ実装を行うには準備や時間が負担になることをご理解いただけるかと思います。アジャイル開発において、すべてのセキュリティ対策の作業を１～２週間程度のスプリントの中で実行し続けるのは、簡単ではありません。というのも、ここまで紹介したツールや作業内容は、開発のリリース単位などで実行されることが想定されるため、１～２週間ごとに繰り返し、すべて実施されるようには必ずしも設計されておりません。

この課題を解決するための一つの手段としてIAST(Interactive Application Security Testing)[11]が注目されています。IASTとは、SASTとDASTの要素を部分的に兼ね備えたツールです。システムにIASTのエージェントを導入して、ソフトウェアの動作をエージェントが自動的に確認し、リアルタイムにレポーティングが行われます。開発者はそれに基づいて対処を素早く行うことが期待できます。

IASTはおおよそ以下の順で使用します。

開発者は、上記の図のようなレポートを確認し、危険性がCritical 、Highのような優先度の高い対応項目から優先的に対応していきます。この方式は、コーディング後の機能テストなどに組み込みやすく、開発者がリアルタイムで発見された問題に対応することが可能となります。

エージェントは、システムの動作にフックして検査を行うなど、内部の挙動に密に関わる動作を行います。このため、対応しているプログラミング言語やフレームワークは現状では限定的です。使用しているシステムやソフトウェアの環境と一致していれば、アジャイル開発においても有力な手段となり得ます。

IASTが魅力的な点は、誤検知を減らせる可能性がある点です[12]。ソフトウェアに合わせてエージェントをインストールするため、トラフィックや実行フローをエージェントが直接分析できるようになります。しかし、誤検知が多くあると、リアルタイム性が高いとしても結局はスプリント内で膨大な誤検知の確認が発生してしまいます。精度の高さは、時間が短く区切られてるアジャイル開発の品質確保において極めて重要な要素です。そして、IASTはSASTやDASTに比べて高い精度で脆弱性を検出できることが期待されています。実際の導入時には、利用するツールのベンチマーク[13]の確認や事前検証は大切です。

4．テストを組み合わせる

ここまで紹介したセキュリティテストの手法は、どれか一つを選択するのではなく、組み合わせによって使用するケースが多いと考えられます。それぞれ紹介したように、メリット・デメリットがあり、特にデメリットの部分を組み合わせによってカバーするためです。当然、各手法でカバー範囲が異なりますので、新たにIASTを活用していくということは、スプリント内で担保できるセキュリティ実装を増やすための選択肢がひとつ増えたと捉えるのが良いと考えます。

ここまでの各手法を組み合わせると、例えば以下のような運用が考えられます。SAST/DASTについては、スプリント内で開発する内容に合わせて最小限の実施にするようにします。

5．まとめ

スクラムを用いたアジャイル開発において、よく使用されるセキュリティ対策の方法を紹介しました。一般的な機能要件と比較して、セキュリティというカテゴリについては、年次の監査などであればともかく、まだまだ１週間～2週間という短いスパンで継続的に検査・可視化し続けるという土壌が整っていません。その中でIASTなどの分野が今後発展していき、短いスパンの反復開発の中でも、セキュリティをより高めた製品・サービスが開発をできるようになっていくことを期待しております。

参考：

執筆者の他の記事を読む