Static Application Security Testing

Static Application Security Testing（略称:SAST、別名:静的アプリケーションセキュリティテスト）は、ソースコードをレビューしてセキュリティ上の脆弱性を特定することにより、ソフトウェアを保護するために使用される。静的プログラム解析はコンピュータが存在する限り存在してきたが、この技術がセキュリティ分野に広がったのは90年代後半であり、SQLインジェクションに関する最初の公的な議論は、WebアプリケーションがJavaScriptやFlashのような新技術を統合し始めた1998年に行われた。

アプリケーションの機能をブラックボックステストするためのDynamic Application Security Testing（DAST）ツールとは異なり、SASTツールはアプリケーションのコード内容、つまりホワイトボックステストに焦点を当てている。SASTツールは、アプリケーションとそのコンポーネントのソースコードをスキャンし、ソフトウェアやアーキテクチャにおける潜在的なセキュリティの脆弱性を特定する。静的解析ツールは、テスト対象のアプリケーションに存在するセキュリティ脆弱性の推定50%を検出できる^[1]。ソフトウェア開発ライフサイクル（SDLC）において、SASTは開発プロセスの初期段階やコードレベルで実行されるだけでなく、すべてのコード断片やコンポーネントが一貫したテスト環境に統合された際にも実行される。SASTはソフトウェアの品質保証にも使用されるが^[2]、結果として生じる多くの偽陽性が開発者による採用を妨げている場合もある^[3]。

SASTツールは、主に要求された仕様に従ってソフトウェアを開発し提供することに注力している開発チームを支援するために、開発プロセスに統合されている^[4] 。他のセキュリティツールと同様に、SASTツールはアプリケーションのダウンタイムのリスクを低減することや、アプリケーションに保存された個人情報が侵害されないようにすることに焦点を当てている。

リリース前に実施されるアプリケーションセキュリティテストには、SASTとDAST、およびこれら2つを組み合わせたInteractive Application Security Testing（IAST）が含まれる^[5]。

静的解析ツールは、プログラムのテキストを構文的に検査する。これらはソースコード内の固定されたパターンやルールを探す。理論的には、コンパイルされた形式のソフトウェアを検査することも可能である。この技術は、コンパイルされたコンポーネントとソースコードコンポーネント間のマッピングを行い、問題を特定するためにコードの計装（インストルメンテーション）に依存している。静的解析は、コードレビューや、セキュリティを含むさまざまな目的のためのコードの監査として手動で行うこともできるが、それには時間がかかる^[6]。

SASTツールの精度は、解析の範囲と脆弱性を特定するために使用される特定の技術によって決定される。解析のレベルには以下が含まれる。

• 関数レベル: 命令のシーケンス
• ファイルまたはクラスレベル: オブジェクト生成のための拡張可能なプログラムコードテンプレート
• アプリケーションレベル: 相互作用するプログラムまたはプログラムのグループ

解析の範囲によって、文脈情報を使用して脆弱性を検出する正確さと能力が決まる^[7] 。SASTツールは、DASTツールとは異なり、開発者にリアルタイムのフィードバックを提供し、コードを次の段階に進める前に欠陥を修正するのを助ける。

関数レベルでは、一般的な技術として、関数内のデータの流れを制御するための抽象構文木の構築がある^[8]。

90年代後半以降、ビジネス上の課題に適応する必要性から、開発チームのプロセスと組織によって強化されたコンポーネント化^[9]により、ソフトウェア開発は変化してきた^[10]。アプリケーションまたはアプリケーション群のすべてのコンポーネント間のデータの流れを追跡することで、サニタイズのための専用プロシージャへの必須呼び出しの検証や、特定のコード部分でデータをテイント（汚染）させるための適切なアクションが取られているかの検証が可能になる^[11][12]。

Webアプリケーションの台頭に伴い、それらのテストが必要となった。Verizon Data Breachは2016年に、全データ侵害の40%がWebアプリケーションの脆弱性を利用していると報告した^[13]。外部的なセキュリティ検証と内部脅威への注目の両方が高まっている。Clearswift Insider Threat Index（CITI）は、2015年の調査で回答者の92%が過去12ヶ月間にITまたはセキュリティインシデントを経験し、これらの侵害の74%が内部関係者によるものであったと報告している^[14][15]。Lee Hadlingtonは内部脅威を、悪意あるもの、偶発的なもの、意図しないものの3つのカテゴリに分類した。モバイルアプリケーションの爆発的な成長は、悪意のあるコード開発を減らすために、開発プロセスの早い段階でアプリケーションを保護することを意味する^[16]。

ソフトウェア開発ライフサイクルにおいて脆弱性が早期に修正されるほど、修正コストは安くなる。開発段階での修正コストはテスト段階よりも10倍低く、本番環境よりも100倍低い^[17]。SASTツールは、コードレベルまたはアプリケーションレベルで自動的に実行され、対話を必要としない。CI/CDのコンテキストに統合された場合、SASTツールは重大な脆弱性が特定された場合に統合プロセスを自動的に停止するために使用できる^[18]。

他の種類のテストに対するもう一つの利点は、DASTツールが実行をカバーするためアプリケーションの一部^[5]や設定ファイル内の安全でない設定を見逃す可能性があるのに対し、SASTツールはソースコード全体をスキャンすることである。

SASTツールは、品質テストやアーキテクチャテストなどの拡張機能を提供できる。ソフトウェアの品質とセキュリティには直接的な相関関係がある。品質の悪いソフトウェアは、セキュリティも不十分なソフトウェアである^[19]。

開発者はSASTツールの使用に肯定的であるにもかかわらず、その採用にはさまざまな課題がある^[4]。例として、これらのツールによって生成される長い出力にもかかわらず、ユーザビリティが欠けている可能性があることを示す研究がある^[20]。

ソフトウェア開発におけるアジャイルプロセスでは、このフレームワークを使用する開発者が機能とデリバリーに重点を置くため、SASTの早期統合により多くのバグが発生する^[21]。

SASTツールで多数の行のコードをスキャンすると、単一のアプリケーションに対して数百または数千の脆弱性警告が発生する場合がある。これは多くの偽陽性を生成し、調査時間を増加させ、そのようなツールへの信頼を低下させる可能性がある。これは特に、脆弱性のコンテキストをツールが把握できない場合に当てはまる^[3]。

• Dynamic Application Security Testing（DAST）
• Interactive Application Security Testing（IAST）
• Lint
• 静的プログラム解析