適用範囲
静的アプリケーションセキュリティテスト（略してSAST）は、調査対象のアプリケーションを実際に起動せずにコードまたは脆弱性の一部を分析することです。 通常、これには専用のソフトウェアが使用されます。 有名なコンピューター科学者は、他のプログラムが他のプログラムを分析して、データセットで実行が停止されるかどうかを判断できないことを証明したため、チューリングの仕事に精通している人々はおそらく悪意に満ちた笑い声をあげています。
そして理論的には、これは実際にそうです。 ただし、実際には、すべてがやや複雑です。 まず、停止の問題はチューリングマシンであるためです。これは、無制限の供給と、それに応じて配置できる状態の数が無限である抽象的なコンピューターです。 したがって、分析は不可能です。
現在、このようなコンピューティングシステムは存在せず、長期間存在しないことは明らかです。 したがって、SAST技術の実用化を検討するには、チューリング理論を有限状態マシン、またはより単純に、無限の状態を持たない通常のコンピューターに適用する必要があります。 また、このような環境で実行されているアプリケーションは、別のプログラムで簡単に分析できます。
さらに、原則として、セキュリティ分析では脆弱性を含む可能性がある部分のみを調査する必要があるため、静的なセキュリティテストでコード実行のすべての可能なバリアントを調査する必要はありません。 したがって、チューリングマシンについて話している場合でも、その状態の数をSASTの有限数に照らすことは可能です。
静的解析メソッド
アプリケーションコードの脆弱性を分析するために、通常は3つのアプローチが一緒に使用され、別々に使用されます。
- 署名検索。 最も簡単な方法。 これは、脆弱性につながる、特定の構文モデルの出現のメインコードでの検索に基づいています。 明らかに、このため、この方法をメインの方法として使用することはできません-誤検知と見逃された脅威の両方の可能性が高すぎます。 基本的に、このメソッドは、追加の分析を必要とするコードの疑わしいセクションを識別するために使用されます。
- コード実行パターンの調査。 より高度な方法。 これは、脆弱性につながる可能性のある、アプリケーションによって処理されるデータのこのような組み合わせの検索に基づいています。 この方法では、コードの多くの要素を考慮していないため、多くの場合、誤検出の結果が生じます。 たとえば、このような分析はXSSインジェクションに対する機能の脆弱性を検出できますが、実際にはデータストリームは正常にフィルタリングされ、そのような攻撃は不可能です。
- フローコンピューティングの研究。 これは、シンボリック計算の使用に基づいています-特定のコードを抽象解釈に変換し、明確に定義された変数だけでなく、未知の変数でも効果的に機能することができます。 将来的には、この手法に基づいて、特定のタイプの攻撃に対する脆弱性のモデルが開発され、記号言語で記述され、コード内の問題領域の検索が大幅に簡素化および改善されます。
SASTの代替
分析の名前に基づいてのみ-静的-別の種類があると仮定できます。 実際、プログラムでコードの脆弱性をチェックするために、動的テスト（動的アプリケーションセキュリティテスト、略してDAST）も使用できます。
この場合、すでに実行中のアプリケーションが調べられます。 特定のパラメーターと変数で始まり、その後、潜在的な脅威をチェックします。 この方法の欠点は明らかです。プログラムを展開して、そのプログラムで多くのテストを実行できるとは限りません。 また、以前の研究の開始により、分析結果が歪む場合があります。
別の種類のテストは、面白い、またはインタラクティブなIASTです。 動的分析と静的分析の両方を使用します。 SASTは脆弱性につながる可能性のある入力データの潜在的なセットをモデル化し、この情報に基づいてDASTはアプリケーションの実際のテストを実施します。
理想的なアナライザー
そこで、脆弱性に対するコードアナライザーの機能、方法、および代替手段を検討しました。 可能な限り効率的に仕事をするためには、どのような特性を持たなければなりませんか？
- SASTメソッドとDASTメソッドの組み合わせ。 前述のように、動的テストと静的テストを同時に使用すると、分析の効率が大幅に向上します。 ただし、両方のメソッドのアプリケーションがそれらの欠点を継承することを覚えておくことが重要です。 したがって、アナライザープログラムは、特定のコードで柔軟に動作し、使用容量と稼働時間のバランスを維持できる必要があります。
- システムは、分析の完了時に、攻撃の実行方法を明確に示す必要があります。これにより、後でこれが誤検知ではないことを個別に検証できます。
- テストでは、コード、特に確認も脆弱性の拒否も受信していない部分を手動でチェックする機能を提供する必要があります。 もちろん、多くの点でこれらの要件は理論的なものであり、このような理想的なアナライザーを今すぐ見つけたり作成したりすることは不可能です。 しかし、これは彼らの共通の開発のベクトルでなければなりません。
どう思いますか？