静的アプリケーションセキュリティテスト (SAST)

すべての開発者が目指しているのは、ソースコードのセキュリティをそれほど意識せずに確保できる、という状態です。多くの場合、開発者にはセキュリティのバックグラウンドがないため、安全でないプログラミングパターンを回避できず、安全な API の使用方法も把握していません。そこで、全体的なアプリケーションセキュリティの一環として、静的アプリケーションセキュリティテスト (SAST) を活用できます。SAST を使用すると、セキュリティの脆弱性についてソースコードを分析できるため、手動で分析を行う必要はありません。

静的アプリケーションセキュリティテスト (SAST) の 7 段階

SAST が動作するしくみ

静的アプリケーションセキュリティテスト (SAST) の特性については、以下の 5 つのことを知っておく必要があります。

1. アプリケーションを「内から外に」分析する

2. SDLC の全段階で実行する

3. 通常はツールで解釈可能なビルドモデルの作成が必要

4. 解析を一連のルールに基づいて行う

5. 得意分野の異なる複数の解析タイプで実行 (下のイメージを参照)。

SAST の 5 つの分析タイプ

SAST が他のセキュリティテスト手法と異なる点

特定のセキュリティテスト手法がアプリケーションのテスト環境に適しているかどうかを判断するには、その手法の利点とその限界について検討することが重要です。それでは、それぞれのテスト手法の違いについて見ていきましょう。

SAST vs DAST vs SCA

静的アプリケーションセキュリティテスト (SAST) は、コードに注目します。CI パイプラインの初期段階で動作し、ソースコード、バイトコード、またはバイナリコードをスキャンして、ベストプラクティスに反する、問題のあるコーディングパターンを特定します。SAST はプログラミング言語に依存します。

動的アプリケーションセキュリティテスト (DAST) は、実行時にアプリケーションをスキャンするブラックボックステスト手法で、CI パイプラインの後半で実施します。DAST は、特定のプログラミング言語に依存せず、回帰を防ぐのに適した手法です。

詳しくは、SAST と DAST の比較、その違いと 2 つを組み合わせる方法をご覧ください。

インタラクティブアプリケーションセキュリティテスト (IAST) は、ランタイムのアプリケーションの動作に注目するという点で、DAST と似ています。ただし、IAST の解析は、ブラックボックステスト、スキャン、内部アプリケーションフローの分析の組み合わせに基づいて行われます。IAST の利点は、SAST のように DAST 的な知見をソースコードにリンクさせることができることです。このアプローチの欠点は、IAST のプログラミング言語への依存度が高く、CI パイプラインの後半でしか実行できないことです。

ソフトウェアコンポジション解析 (SCA) は、アプリケーションで使用されるサードパーティのコードの依存関係に注目します。SCA は、多くのオープンソースライブラリを使用するアプリケーションで非常に効果的です。この方法もプログラミング言語に依存します。

SAST と SCA の比較と、それらのツールを活用して安全なソフトウェアをリリースする方法について詳しく読む

DAST は他のアプリケーションセキュリティテスト手法と組み合わせることができますか

SAST はソースコード上で動作し、脆弱性がないかどうかコード行をスキャンします。これは、コードについて何も調べることなく、実行中のアプリケーションの入力と出力に対してのみ動作する DAST とは対照的です。実際には、両者を補完して使用できます。SAST ツールは、DAST ツールでは必ずしも検出できない脆弱性を検出でき、その逆もあります。

しかし、最大の違いはスピードです。DAST ツールは、アプリケーションを実行して使用する必要があり、アプリケーションが非常に複雑な場合、かなりの時間がかかることがあります。一方、SAST ツールは、ソースコードをスキャンし、ベストプラクティスのルールと比較して、改善するためのヒントを与えてくれます。

この考え方は、開発パイプラインの初期段階、たとえば IDE でコーディング中に SAST ツールを実行する、あるいは少なくとも開発サーバーの CI/CD パイプラインの開始時に実行する、というものです。そして後の段階では、コンパイルされたバイナリで DAST ツールを実行します。両方で検出されるような脆弱性については、SAST ツールですばやく検出できます。SAST ツールで検出できない脆弱性はすべて DAST ツールに回されます。

SAST の長所と短所

前述のとおり、SAST ツールは完全ではないため、可能であれば DAST ツールと併用することが望ましいといえます。ここでは、SAST ツールの長所と短所、およびこれらが実際に何を意味するかを見ていきましょう。

長所:

• 開発初期: SAST はソースコード上でのみ動作し、ベストプラクティスと照合してチェックされます。このことは、実際にコードの作成中に SAST を適用できることを意味しています。一般的な SAST ツール用の IDE プラグインを使用することで、バージョン管理ツールにチェックインする前に問題を検出できます。

• 問題のあるコードの場所を表示: SAST はソースコード上で動作するため、脆弱性の正確な位置を表示できます。そのため、検索や修正もかなり効率的に行えます。

• テストケースは不要: DAST ツールでは、テスト対象を指定する必要がありますが、SAST ツールでは、単純にコードベースに対してすべてのルールが適用されます。多くの場合、これらのルールは、様々なプロジェクトや長年のプログラミング経験に基づいています。これにより、存在すら知らなかった脆弱性を検出することができます。これらのルールは、SAST ツール作成者が手動で導入することも、一般的なオープンソースリポジトリで学習した機械学習アルゴリズムによって自動的に生成することもできます。

• 実行は不要: SAST は、アプリケーションが実際に実行される前にソースコードで動作します。そのため、SAST スキャンは DAST テストスイート全体を実行するよりもはるかに短時間で行うことができます。

• 簡単に自動化可能: テキストファイルのスキャンには、GUI の操作は必要ありません。つまり、SAST ツールの自動化は、アプリケーションを実行して使用するために多くの設定が必要な DAST ツールよりも、はるかに簡単に行うことができます。

短所:

• 誤検出: SAST はソースコードで動作するため、多くの場合、全体を考慮していません。その結果、SAST ツールが初めてソースコードをチェックする際には、通常、膨大な数の問題が検出されます。ただし、そのほとんどは誤検出ということがよくあります。また、SAST では特定の行でコードの問題を検出したものの、その行以降で問題が解決されている場合もあります。

• コンテキストの不足: 誤検知の一例として、サニタイズされていないユーザー入力があります。これは大きなセキュリティリスクですが、フロントエンドでサニタイズされていない入力は、多くの場合バックエンドでクリーンアップされます。また、フロントエンドとバックエンドのコードが同じリポジトリにないこともよくあります。つまり、SAST ツールはサニタイズについて認識できないため、開発者はこれを修正するように促されます。

• 言語の依存性: SAST には強いコード依存性があります。一般的なプログラミング言語 (Java や C# など) には、多数の SAST ツールが存在する一方で、もっとニッチな言語 (ReScript や Nim など) には、SAST ツールは非常に少ないのが現状です。

SAST の導入を成功させるための 3 つのステップ

SAST ツールのセットアップは、新しいプロジェクトの開始時に行うと、非常に簡単です。ただし、コードラインが蓄積されすでに数千行に及んでいるようなプロジェクトでは、困難が伴います。後者の場合、作業を開始して実行するまでに数日間かかることも想定しておかなければなりません。また、特に誤検知のチェックなど、問題を解決するために最もスキルの高い開発者のスケジュールをブロックしてしまうこともあります。

1\.適切なツールを見つける

まず、開発プロセスに合った、プログラミング言語や予算に対応したツールを探す必要があります。

従来型の SAST ツールと 開発者ファーストの SAST ツールの違いを区別することが重要です。

SAST は新しい概念ではありません。従来型の SAST ツールは動作が遅く、完了するまでに数時間から数日もかかります。さらに、従来型の SAST ツールは開発者に対して圧倒されるような数の誤検知を送りつけるため、開発者によりまったく無視される可能性もあります。

従来型の SAST ツールでは、CI/CD パイプラインから別のプロセスに移ることになるため、リリースサイクルが複雑化し、遅くなってしまいます。もう一つの問題は、問題について開発者に伝える方法です。多くの場合、ツールはセキュリティの脆弱性について大量の警告を出すだけで、除去方法についての実践的なアドバイスをすることはありませんでした。

Snyk Code のような次世代の開発者ファーストの SAST ツールは、スピードに重点を置くことでこれらの問題に対処しています。さらに、お気に入りの IDE と統合して、コードを入力している最中にセキュリティ上の問題を通知することもできます。

ワークフローによっては、コードリポジトリをコミットまたはプッシュする際に、高速 SAST ツールを実行できます。開発者ファーストの SAST ツールは、問題の解決に役立つセキュリティの脆弱性に関する実際的な通知や知見を提供しています。

2\.誤検知を減らす

次に、誤検知を減らす必要があります。誤検知のアラートが多すぎる場合、開発者は誰も気に留めなくなります。コードベースのサイズによっては、このクリーニングプロセスにかなり時間がかかる可能性があります。スキルのある開発者が SAST ツールで検出されたすべての問題を調べて、本当の脅威ではないことを確認しなければならないからです。

Snyk Code AI エンジンは、Snyk が独自に収集した脆弱性データベースに基づいて動作し、トレーニングセットとしてコミットを参照しています。これらすべてが、誤検知を大幅に減らすのに役立ちます。

3\.CI パイプラインに組み込む

次のステップは、SAST ツールを継続的インテグレーション (CI) パイプラインに組み込むことです。前述のとおり、いくつかのツールは IDE と統合できるようになっています。ただし、開発者は IDE に関してはこだわりがあるため、SAST ツールですべての IDE がサポートされているわけではありません。

また、開発者は、新しいコードをチェックインする前にツールを実行するのを忘れる可能性もあります。そのため、SAST ツールでは CI との統合が非常に重要といえます。こうすることで、セキュリティの脆弱性について少なくとも 1 回もチェックされなかったコードが本番環境に導入されないようにすることができます。

開発者ファーストの SAST

SAST ツールでは、開発プロセスの早い段階でセキュリティ問題を発見できるため、納期に追われる環境でも、開発者は常にベストプラクティスの準拠を意識する必要はありません。

ただし、ソフトウェア開発ライフサイクルのどの段階で SAST を統合するかによっては、SAST の高速化に多大な労力がかかる可能性があることに注意してください。従来型の SAST ツールでは、多数の誤検知が発生するため、開発者が選別する必要があります。また、システムがニッチなプログラミング言語をベースにしている場合、セキュリティ問題を解決するための SAST ツールが市販されていない可能性もあります。開発者ファーストの SAST ツールは、これらの問題を解決し、シームレスで効率的なプロセスを提供することに成功しています。開発者ファーストの SAST には大きなメリットがあるため、セキュリティを重視する企業には必携のツールとなっています。

SAST バイヤー ガイドを確認して、組織に適した SAST ツールを選択してください。

誤検出を選別するために何日も費やす必要はありません。効率的かつ実践的な開発作業を可能にする Snyk Code は、機械学習に基づく開発者ファーストの SAST ツールで、オープンソースリポジトリ向けに無料で提供されています。コードの安全性を簡単に確認できる無料のコードチェックツールもお試しいただけます。