デジタルトランスフォーメーションが加速し、さまざまな組織が業務効率化のためにソフトウェアソリューションを導入するようになった今、セキュリティの脅威がこれまで以上にまん延しています。 日々、サイバー犯罪者によってソフトウェアアプリケーションの脆弱性を悪用する手段が開発され、組織のネットワークが攻撃を受けています。 その最たる例が、1 億 4,500 万人のアメリカ人の個人情報が漏えいした 2017 年の Equifax 社データ流出事件です。
もはや、1 種類のテストを実施するだけでは、セキュリティ侵害を防止しアプリケーションのセキュリティを保つことはできません。 取り得る手段をすべて検討し、チームのワークフローに合わせてそれらを組み合わせ、最大限のカバレッジを実現する必要があります。 さらに、コードと顧客情報を保護するためには、一般的なテスト手法の先を見据える必要もあります。
テストの初めの一歩としては、単体テストと結合テストを行う機能テストや、エンドツーエンドテストがあります。 しかし、機能テストは有益なものの、テストの開発段階で思いついた問題しかチェックできません。さらに、目的はビジネス目標への適合に限られます。 機能テストでは、データ侵害につながるセキュリティ上の欠陥はチェックできないのです。
このように一般的なテスト手法でカバーできない穴を埋めるために、さまざまなテストツールが開発されてきました。 そのうちの 2 つが、静的アプリケーションセキュリティテスト (SAST) と動的アプリケーションセキュリティテスト (DAST) です。 この記事では、SAST と DAST の概要と、それぞれの使い分けについて説明します。 さらに、アプリケーションのセキュリティを強化するための他のアプリケーションテスト手法も紹介します。
SAST とは？
SAST (静的アプリケーション・セキュリティ・テスト) では、プログラムのソースコードを分析して、セキュリティ脆弱性を特定します。 テスト対象となる脆弱性には、SQL インジェクション、バッファーオーバーフロー、XML 外部実体 (XXE) 攻撃、OWASP Top 10 のセキュリティリスクなどがあります。
SAST はオープンボックステストです。 コードのコンパイルや実行を行う前に、ソフトウェアアプリケーションを内部からスキャンしてコードに潜むセキュリティ脆弱性を検出します。
SAST の方法論としては、開発の早期段階から、機能コンポーネントを実行せずにアプリケーションのテストを行うことが推奨されています。 このアプローチなら、ソースコード内のセキュリティ上の欠陥を早期に発見して、開発の後段階までセキュリティ問題が残ってしまう事態を回避できます。 そのため、開発時間を短縮し、プログラムの全体的なセキュリティを強化できます。
SAST 用テストツール
人気の高い SAST 用テストツールを 2 つ紹介します。
多くの開発者は、深刻なセキュリティエラーの軽減やアプリケーションのセキュリティ強化を目的として、SAST を継続的インテグレーション & 継続的デプロイ (CI/CD) パイプラインに統合しています。 アプリケーションのセキュリティ強化のため、SAST はさまざまなユースケースで使われています。
SAST を使用すべきケースは？
SAST の活用例としては、ソースコードを継続的に監視することで、ソフトウェア開発のセキュリティベストプラクティスに反する不適切なコーディングパターンを検出する方法があります。 また、OWASP Top 10 や SANS Top 25 など、一般的なセキュリティ業界の標準にもとづいてアプリケーションコードの脆弱性テストを自動化する方法もあります。 また SAST を活用することで、Health Insurance Portability and Accountability Act (HIPAA) や Payment Card Industry Data Security Standard (PCI DSS) などのデータ保護法に準拠しているかどうかもチェックできます。
DAST とは？
DAST のテスト対象はソフトウェアアプリケーションです。 悪意あるユーザーのフリをして、リモートでのアプリケーションへの侵入をシミュレートします。 OWASP Top 10 や SANS/CWE 25 など、著名な脆弱性リストと照らし合わせてソフトウェアアプリケーションをリアルタイムでスキャンし、セキュリティ上の欠陥や未解決の脆弱性を発見します。
DAST と SAST の一番の違いは、セキュリティテストの実施方法にあります。 SAST では、保存されているアプリケーションコードをスキャンして、セキュリティ上の脅威につながるコードの欠陥を検出します。一方 DAST では、実行中のアプリケーションをテストし、ソースコードには一切アクセスしません。
DAST はクローズドボックステスト形式で、外部の攻撃者の視点をシミュレートします。 つまり、テスト担当者はアプリケーションの内部機能を知らないという前提です。 プログラムの実行中にのみ現れるセキュリティ脆弱性など、SAST では検出不可能な脆弱性を発見できます。
DAST テストには完成済みの動作するアプリケーションが必要なため、実施するタイミングはアプリケーション開発プロセスの後半となります。 テスト担当者は、入力の実施や出力のチェックなど、アプリケーションに対してユーザーが行いそうな各種の操作を行います。 DAST を実施することで、クロスサイトスクリプティング (XXS) や SQL インジェクションなどの Web 攻撃に対する脆弱性をアプリケーションから取り除くことができます。
まずはオープンソースの DAST ツールから
ほとんどの DAST ツールは有料ですが、Arachni はオープンソースで機能も豊富です。 Arachni の Ruby フレームワークでは Web アプリケーションをスキャンして、XSS (DOM バリアントを含む)、SQL インジェクション、NoSQL インジェクション、コードインジェクション、ファイルインクルードバリアントなどの脆弱性を調査できます。 どの有料 DAST ツールを購入するか決める前に、この無料ツールを試してみるのもよいでしょう。
DAST を使用すべきケースは？
DAST の活用例としては、サーバーやデータべースに、Web アプリケーションの実行中にセキュリティへ影響を及ぼす構成ミスがないかチェックする方法があります。 SAST では検出できない、不正アクセスにつながる認証や暗号化に関する問題も検出可能です。 さらに、Web アプリケーションの接続先の API や Web サービスに加え、ネットワークやデータストレージといった IT インフラストラクチャのテストもできます。 つまり、DAST は、アプリケーションや Web サービスを運用する IT 環境全体のテストに役立ちます。
SAST と DAST の使い分け
SAST と DAST それぞれの主な特徴と用途を確認したところで、みなさんのアプリケーションのテスト環境にはどちらが最適か考えてみましょう。 アプリケーションのテストには、どちらか一方だけを選ぶのではなく、両方の手法を利用することをお勧めします。
SAST では、開発の早期段階でアプリケーションの内部ソースコードをテストし、コードがセキュリティのベストプラクティスに従って記述されていることを確認します。 一方、DAST は、開発の後半に、動作するアプリケーションを対象に実施します。 実行中のアプリケーションをテストして、一般的なサイバー攻撃に対する脆弱性を明らかにします。
SAST はテクノロジーに依存します。 つまり、テストカバレッジを万全に整えるには、使用しているプログラミング言語と開発フレームワークに対応した SAST ツールを選ぶ必要があります。 一方、DAST は外部ユーザーの視点から実行中のアプリケーションをテストするので、テクノロジーに依存しません。
ソフトウェアアプリケーションのセキュリティを最大限に高めるには、アプリケーションの CI/CD パイプラインに SAST ツールと DAST ツールを組み込むことをお勧めします。 DevSecOps 体制なら、両方の手法を使用して各開発段階にセキュリティを組み込むとよいでしょう。 このアプローチを取ると、生産性を下げることなく設計プロセスにセキュリティ管理を組み込むことができます。 CI/CD で SAST スキャンと DAST スキャンを自動化すれば、最終製品の安全性を損なうことなく、開発時間を短縮できます。
その他のアプリケーションセキュリティテスト (IAST、RASP、HAST)
利用できるテスト手法は、SAST と DAST だけではありません。 開発コミュニティでは、IAST、RASP、HAST などのバリエーションも使われています。
インタラクティブアプリケーションセキュリティテスト (IAST)
インタラクティブアプリケーションセキュリティテスト (IAST) は、SAST と DAST の両方の機能を組み合わせたテスト手法です。 アプリケーションのバックエンドに監視メカニズム (センサーやエージェント) を実装して、実行中の情報を収集します。
このアプローチでは、実行時に DAST 手法を使用してアプリケーションの動作をテストすると同時に、SAST のようにソースコード実行の監視も行うことができます。 SAST には、先進的な Web アプリケーションに付き物の依存関係 (ライブラリやフレームワークなど) を追跡、テストしきれないという大きな欠点がありますが、IAST ならこの欠点も解消できます。
ランタイムアプリケーションセルフプロテクション (RASP)
ランタイムアプリケーションセルフプロテクション (RASP) は、実行中にアプリケーションをテストして一般的な脆弱性から保護する方法です。 DevOps に RASP を導入すれば、本番環境のアプリケーションを監視し、異常なアクティビティ (サイバー攻撃や悪意ある操作など) が検出された際に是正措置を取ることができます。
ハイブリッドアプリケーションセキュリティテスト (HAST)
HAST は SAST と DAST を組み合わせ、アプリケーションのセキュリティ脆弱性を発見して修正する方法です。 他の手法よりも多くの時間と予算が必要になりますが、安全なアプリケーションを設計するには最適のアプローチです。
おわりに
ほとんどのセキュリティインシデントの原因は、現代の複雑化した IT 脅威環境で修正されずに残っていたセキュリティエラーが悪用されることです。 アプリケーションと顧客をサイバー脅威から守るには、オープンボックステストとクローズドボックステストの併用が必須です。
また、セキュリティテストを自動化すると、時間を節約すると同時にテスト結果の正確性も高められます。 ぜひ本記事とあわせて、CircleCI の DevSecOps ツールで CI/CD パイプラインに自動テストを組み込む方法もご覧ください。
