SASTとは何ですか？
静的アプリケーションセキュリティテスト

更新日：2026年6月

概要

SASTツールは、アプリケーションを攻撃にさらす可能性のあるコードやコーディングパターンを特定するために、ソースコードを分析します。このアプローチにより、SASTはアプリケーション内に見られる一般的なセキュリティリスクのいくつかの種類について、開発者に警告できます。

SAST Detected Vulnerabilities

Static testing is essential for detecting specific vulnerabilities such as command Injection, Buffer Overflow and other code based attacks.

Command Injection

Command Injection is a type of attack in which malicious parties “trick” applications into running commands, often with the goal of exploiting the application to expose sensitive data or plant malware on the host system. If the application fails to validate user input properly, the injection attack will result in the commands actually being run.

For example, consider a Java application that contains the following code:

import java.util.Scanner;
…
cmd = user_input.next( );
String comm = "cmd.exe"+cmd

This code tells the application to use the cmd.exe program on the host system to run a command defined using the variable cmd. In this example, cmd is a string of input supplied by the application user, so it could be anything the user wants – such as code that tells the system to install a new application or display the contents of a sensitive data directory.

Hopefully the developer is aware of this threat and includes a validation function to ensure that the cmd varIable is not part of a malicious command. If this precaution has not been taken, then the application will simply pass all types of user input into cmd.exe, which will run it.

In this scenario, DevOps and security teams should be using a SAST solution to flag the code as being risky because of a possible Command Injection attack. Developers should be required to take the necessary steps to mitigate this risk, such as adding a function to validate the cmd variable to ensure it doesn’t contain malicious commands or preferably use an alternative method to execute the commands on the system, as in general, calling an external shell command like cmd.exe from within an application is not considered a secure coding practice.

Buffer overflow

A buffer overflow is a coding error that allows an application to overwrite memory that has not been allocated. By exploiting buffer overflows, attackers can potentially run code of their choosing on a host system.

In Java, a buffer overflow could be triggered by code such as the following:

Public class Overflow
{
 public static void main(String[] args)
  {
    int importantData =1;
    int[]  buffer = new int[10];
    for (int i =0; i < 15; i++)
    buffer[i] = 7;
  }
}

In this example, the overflow is triggered because the loop iterates through 15 elements, but only 10 elements are assigned to the memory buffer. As a result, the application may attempt to write to memory outside its buffer.

Most Java applications attempt to block buffer overflows automatically. In practice, then, the code above would most likely result in an application exception, rather than a security vulnerability. Still, the overflow issue would qualify as a security risk. It’s possible that it could be exploited if Java fails to detect the overflow on its own, or attackers find a way to bypass Java’s overflow checks. In addition, not all languages have built-in overflow protection like Java, in such cases SAST tools would be instrumental in flagging code that could cause  potential attack.

Additional threats

The examples above represent just some of the risks that SAST tools can detect in source code. SAST can also identify risks such as cross-site scripting vulnerabilities, lack of input validation, and bad coding practices that result in vulnerabilities based on the original source code.

SASTはどのように機能しますか？

ソースコードの脆弱性スキャン

SASTはその本質において、アプリケーションのソースコードに潜む脆弱性や潜在的なセキュリティリスクの発見に重点を置く、ソフトウェア開発における重要な取り組みです。コードを実行せずに分析することで、SASTは開発者に、ソフトウェアに関わるセキュリティリスクについて重要な知見を提供します。

SASTの主なメリットの1つは、開発プロセスの早い段階でセキュリティリスクを検出できることです。コードレベルで問題を特定することで、開発者は、問題が開発プロセスの後半やデプロイ後に、より大きくコストのかかるものへと発展する前に対処できます。

欠陥と脆弱性の特定

SASTは、ソフトウェア開発ライフサイクルにシームレスに溶け込むように設計されています。さまざまな開発環境やビルドシステムに簡単に統合でき、コードを自動的にスキャンしてセキュリティ上の脆弱性を検出できます。これにより、セキュリティテストがワークフローに不可欠な要素となり、開発者がコードの作成中に欠陥や弱点を特定できるようになります。

SASTツールはコードを1行ずつ確認し、潜在的なセキュリティ上の欠陥を探します。コードの構造とロジックを調べ、セキュリティ上の問題につながる可能性のある一般的なコーディングエラーや安全でないプログラミング手法の検出に役立ちます。このレベルの検出を行うのに最適な場所は開発者のIDEです。これにより、SDLCの後工程まで待つのではなく、リスクが生じる前に対処できます。

レポートと推奨事項の生成

スキャンプロセスの後、SASTツールは詳細なレポートを生成し、推奨事項を提供します。これらのレポートは、特定されたセキュリティ問題の詳細な分析、深刻度レベル、推奨される修復手順を開発者に提供します。これにより、開発者は深刻度と機能への影響に応じて、脆弱性の優先順位付けと対処を行うことができます。

さらに、SASTツールは多くの場合、拡張機能やプラグインとしてVS CodeやEclipseなどのIDEと統合できます。この統合により、特定された脆弱性を開発環境内の対応するコード行に直接リンクすることで、修復プロセスが簡素化されます。この機能により、開発者はセキュリティ上の欠陥を迅速に特定して修正できるようになり、アプリケーションの安全性を確保するために必要な時間と労力を削減できます。

SASTの効果的な実施

SASTソリューションを効果的に活用するには、いくつかの重要な手順があります。これらの手順に従うことで、SASTプロセスを最適化し、可能な限り最良の結果を得ることができます。 これらの手順は次のとおりです。

環境のセットアップ

SASTを実行する前に、環境を正しくセットアップする必要があります。これには、必要なツールのインストール、依存関係の設定、コードベースおよび開発環境との互換性の確保が含まれます。十分に準備されたSASTの導入は、互換性の問題を回避し、スキャンの精度を向上させるのに役立ちます。

スキャンパラメーターの設定

SASTスキャンの効果を最大限に高めるには、スキャンパラメーターを適切に設定することが重要です。これには、適切なルールセットの設定、アプリケーションで使用されている言語とフレームワークの指定、重大度レベルの調整が含まれます。スキャンパラメーターを具体的なニーズに合わせてカスタマイズすると、アプリケーションで最も重要な脆弱性に注力できます。

結果の解釈と優先順位付け

SASTスキャン後は、結果を分析して解釈する段階です。このステップでは、特定された脆弱性、その深刻度、およびアプリケーションのセキュリティに及ぼす潜在的な影響を理解します。コードベースのセキュリティ問題に対処するには、脆弱性の深刻度と悪用可能性に基づいて修復作業の優先順位を決めることが重要です。

これらの手順に従うことで、SASTプロセスを最適化し、アプリケーションのセキュリティに関する有益な知見を得ることができます。適切なツールとプラクティスを用いることで、組織のソフトウェア開発業務全体のセキュリティ態勢が大幅に強化されるとともに、自動化されたワークフローをSLSA Frameworkに沿わせてソフトウェアの完全性をソースから保護できます。

品質とセキュリティを統合するメリットとは？

セキュリティと品質をソフトウェア開発プロセスに統合することは、ビジネス成果につながる信頼性の高いソフトウェアを一貫して提供するうえで不可欠です。 セキュリティと品質を統合する主なメリットの一つは、ソフトウェア全体の品質が向上することです。SASTは、開発サイクルの早い段階で潜在的なバグ、脆弱性、コードエラーを特定して解消するのに役立ちます。これらの問題を早期に検出して修正することで、後にさらに複雑な問題へと発展するのを防ぎ、顧客満足度の低下や業績への悪影響を招く可能性を抑えられます。

もう1つの大きなメリットは、セキュリティリスクと脆弱性を低減できることです。SASTツールは、アプリケーションのソースコードを分析し、SQLインジェクション、クロスサイトスクリプティング、安全性の低い認証メカニズムなどのセキュリティ上の弱点や脆弱性を特定します。これらの脆弱性に積極的に対処することで、組織はセキュリティ侵害やデータ漏えいのリスクを最小限に抑え、評判と顧客の機密情報を守ることができます。

また、SASTの自動化を継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインに組み込むことで、開発プロセスの効率化にも役立ちます。組織はコード分析とセキュリティテストを自動化し、潜在的な問題に関するリアルタイムのフィードバックを開発者に提供できます。これにより、リリースサイクルが加速し、手作業が減り、ソフトウェア開発ライフサイクル全体を通じてセキュリティと品質の基準が一貫して満たされるようになります。

SASTと他のテスト方法の比較

アプリケーションセキュリティテストには、SAST、DAST、IAST、RASPなど、いくつかの方法があります。それぞれの方法には長所と短所があるため、各方法の違いを理解し、ニーズに合った適切なソリューションを選択することが重要です。

• ソフトウェア構成分析（SCA）
  SCAとは、アプリケーションのコードベース内にあるオープンソースコンポーネントを特定するために、自動化ツールを使用することです。SCAツールはソフトウェアをスキャンし、その中に存在する依存関係やその他のコンテンツを特定したうえで、それらのコンポーネントの元のソースを特定します。  このように、SCAツールは、コードベースのどの部分がサードパーティソースから取得されたものかを特定します。
• 動的アプリケーションセキュリティテスト（DAST）
  DASTはアプリケーションの実行中にテストを行います。実際の攻撃をシミュレートし、アプリケーションの応答を分析して脆弱性を特定します。DASTは、実行時にしか検出できない脆弱性を明らかにするのに役立ちます。
• 対話型アプリケーションセキュリティテスト（IAST）
  IASTは、SASTとDASTの両方の利点を組み合わせています。アプリケーションの実行中にリアルタイムで分析し、脆弱性を特定します。この方法により、より正確な結果が得られ、誤検出が減少します。
• ランタイムアプリケーション自己保護（RASP）
  RASPは、アプリケーションの実行時保護に重点を置いた比較的新しいアプローチです。アプリケーションの動作を監視し、不審なアクティビティを自動的に検出してブロックします。RASPは攻撃に対するリアルタイム保護を提供しますが、開発段階で脆弱性を特定する効果はそれほど高くありません。

どのテスト方法も、考えられるすべてのセキュリティ上の問題に単一で対処できるわけではありません。しかし、前述の方法を組み合わせて実施することで、アプリケーションセキュリティに対する包括的で効果的なアプローチを提供できます。各方法にはそれぞれ独自の強みがあり、組み合わせることでセキュリティ上の脅威に対する多層防御を実現できます。

2026年の規制環境：NIST SSDFへの準拠

2026年の現代のセキュリティ環境において、静的分析はもはや単なるベストプラクティスではなく、厳格な規制上の義務となっています。現行の連邦政府ガイドラインに基づき、NISTのセキュアソフトウェア開発フレームワーク（SSDF）は、連邦政府のベンダーに対するSAST要件を直接規定しています。

米国政府にソフトウェアを提供する組織は、開発ライフサイクルの早い段階で脆弱性を特定および修復するために、自動コードスキャン（SAST）を採用していることを証明する必要があります。さらに、SASTスキャンによる脆弱性の検出結果は厳格に文書化され、アプリケーションのソフトウェア部品表（SBOM）と関連付けられる必要があります。これにより、独自のソースコードと広範なソフトウェアサプライチェーンの両方のリスクプロファイルに関して、完全な透明性と説明責任が確保されます。

JFrog SASTソリューション

JFrog SASTは、リリースを遅らせることなく、開発チームが最初から信頼できるソースコードを提供できるようにしたい企業向けのソリューションです。開発者のワークフローとDevOpsパイプラインにシームレスに統合され、脆弱なコードが本番ソフトウェアに含まれるのを未然に防ぎます。

JFrog SAST

高速かつ正確なセキュリティ重視のエンジンによるスキャンで誤検知を最小限に抑え、リリースサイクルを遅らせることなく、ソースコードの脆弱性を効率的に発見して修正できます。Jfrog SASTでは、優先順位付けや重大な欠陥の迅速かつ効率的な修正に役立つ結果を通じて、効率的なトリアージも実現できます。

このソリューションはJFrog CLIまたはIDEプラグインの一部として利用でき、一般的なIDEと統合することで、開発者がネイティブの開発環境で安心してコーディング、コミット、ビルドできる、シームレスな開発者中心のシフトレフト体験を実現します。

JFrogとGitHubのパートナーシップ

JFrogとGitHubの最近の提携により、シフトレフトソリューションとソースコードスキャン機能がさらに強化されます。JFrog CLIおよびFrogbotツールにより、プルリクエストが作成される際にGitリポジトリ内でコードチェックを実行できます。

この緊密な統合には、ソースコードとバイナリ間の直感的なナビゲーションとトレーサビリティ、GitHub ActionsとJFrog ArtifactoryによるCI/CD、そしてソフトウェアサプライチェーン全体にわたるセキュリティ調査結果の統合ビューが含まれており、ソフトウェア開発をより簡単、迅速かつ安全にするという当社のビジョンを加速させます。

GitHubとの提携によりJFrog Platformが提供する、迅速で効果的かつ安全なSASTソリューションについては、ご都合に合わせてウェビナーをご覧いただくか、  オンラインツアーに参加するか、ガイド付きの1対1デモを予約することでご確認いただけます。

よくあるご質問

1. SASTとSCAの違いは何ですか？

静的アプリケーションセキュリティテスト（SAST）は、アプリケーションの実行前にコーディングエラーや脆弱性を見つけるため、独自の自社ソースコードを一行ずつ分析します。一方、ソフトウェア構成分析（SCA）は、サードパーティのオープンソース依存関係、ライブラリ、バイナリをスキャンし、既知の公開脆弱性（CVE）やライセンスコンプライアンスの問題を確認します。どちらも包括的なDevSecOps戦略に不可欠な要素です。

2. 静的アプリケーションセキュリティテストの制限事項は何ですか？

SASTツールはコードが実行されていない（静的な）状態で評価するため、実行時環境、設定エラー、実行中にのみ発生するデータフローの挙動を把握できません。さらに、従来型のSASTエンジンは誤検知を発生させることがあり、開発者は結果のトリアージに時間を費やす必要があります。これは、最新のコンテキスト認識型セキュリティエンジンが最小化に取り組んでいる課題です。

3. SDLCでSASTスキャンを実行する最適な場所はどこですか？

SASTを実行する最も効果的な場所は、拡張機能またはプラグインとして開発者の統合開発環境（IDE）内に直接組み込むこと、およびプルリクエスト（PR）時に自動ゲートとして実行することです。この「シフトレフト」アプローチにより、開発者はコードが共有リポジトリやビルドパイプラインにコミットされる前に、コードの欠陥をリアルタイムで修正できます。

4. SASTツールでAIが生成したコードをスキャンできますか？

はい。開発チームがAIコーディングアシスタントにますます依存するようになるにつれ、安全性が不十分なコードパターンや古い関数が持ち込まれるリスクが高まっています。最新のSASTツールは、テキストベースのソースコードをすべて同等にスキャンするため、ソフトウェアアーティファクトにコンパイルされる前のAI生成コードブロックの管理と検証に不可欠です。