GitLab高度なSAST

GitLab高度なSASTは、従来のSASTよりも誤検出が少なく、クロスファンクションおよびクロスファイルのテイント解析を使用して複雑な脆弱性を検出する、静的アプリケーションセキュリティテスト（SAST）アナライザーです。

GitLab高度なSASTは、標準のSemgrepベースのSASTアナライザーよりも詳細な分析を実行します。この包括的なアプローチにより、精度が向上し、誤検出が減少しますが、より多くのコンピューティングリソースとより長いスキャン時間が必要です。

概要については、GitLab高度なSAST: を参照してください: Accelerating Vulnerability Resolutionを参照してください。

製品ツアーについては、GitLab高度なSAST製品ツアーをご覧ください。

機能

GitLab高度なSASTを有効にする

プロジェクトでGitLab高度なSASTを有効にするには、以下の手順に従ってください。

前提条件:

• プロジェクトのメンテナーまたはオーナーのロール。
• 標準のSASTアナライザーを有効にします。詳細については、SASTの前提条件を参照してください。
• GitLab Self-Managedの場合は、サポートされているGitLabバージョンを使用してください:
  • 最小バージョン: GitLab 17.1以降
  • 推奨バージョン: GitLab 17.4以降（コードフロービュー、脆弱性の重複排除、更新されたテンプレートが含まれます）
  • テンプレートの互換性:
    • 安定版テンプレート: GitLab 17.3以降
    • 最新テンプレート: GitLab 17.2以降
    • 同じプロジェクトで安定版テンプレートと最新テンプレートを混在させないでください

GitLab高度なSASTを有効にする:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。

2. ビルド > パイプラインエディタに移動します。

3. .gitlab-ci.ymlファイルを作成または編集します。

4. 適切な変数を追加して、高度なSASTを有効にします:

   • C/C++以外のサポートされているすべての言語の場合: GITLAB_ADVANCED_SAST_ENABLED: 'true'

   • C/C++の場合: GITLAB_ADVANCED_SAST_CPP_ENABLED: 'true'

5. 検証タブを選択し、パイプラインの検証を選択します。

   シミュレーションが正常に完了しましたというメッセージは、ファイルが有効であることを裏付けています。

6. 編集タブを選択します。

7. フィールドに入力します。

8. これらの変更で新しいマージリクエストを開始チェックボックスをオンにし、変更をコミットするを選択します。

9. 標準のワークフローに従ってフィールドに入力し、マージリクエストの作成を選択します。

10. 標準のワークフローに従ってマージリクエストをレビューおよび編集し、マージを選択します。

この時点で、GitLab高度なSASTがパイプラインで有効になっています。サポートされているソースコードは、パイプラインの実行時に脆弱性がスキャンされます。対応するジョブがパイプラインのtestステージに表示されます。

これらのステップを完了すると、次のことができるようになります。

• 脆弱性の結果を評価する方法の詳細について学ぶ。
• 最適化のヒントを確認する。
• 幅広いプロジェクトへのロールアウトを計画する。

脆弱性の結果

GitLab高度なSASTの脆弱性には、セキュリティの問題を評価および修正するのに役立つ詳細情報が含まれています。各脆弱性には、以下が表示されます:

• 説明: 脆弱性の原因、潜在的な影響、推奨される修正手順について説明しています。
• ステータス: 脆弱性がトリアージされたか、解決されたかを示します。
• 重大度: 影響に基づいて6つのレベルに分類されます。重大度レベルの詳細はこちらをご覧ください。
• 場所: 問題が検出されたファイル名と行番号を示します。ファイルパスを選択すると、対応する行がコードビューで開きます。
• コードフロー: ユーザー入力（ソース）から脆弱性のあるコード行までのデータのパス。
• スキャナー: 脆弱性を検出したアナライザーを示します。
• 識別子: CWEの識別子やそれを検出したルールのIDなど、脆弱性の分類に使用される参照の一覧です。

SASTの脆弱性には、検出された脆弱性の主要なCWE識別子に従って名前が付けられています。SASTカバレッジの詳細については、SASTルールを参照してください。

結果の表示

前提条件:

• プロジェクトのメンテナーまたはオーナーのロール。

パイプラインで脆弱性を表示するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 左サイドバーで、ビルド > パイプラインを選択します。
3. パイプラインを選択します。
4. セキュリティタブを選択します。
5. 結果をダウンロードするか、詳細を表示する脆弱性を選択します（Ultimateのみ）。

コードフロー

特定の種類の脆弱性について、GitLab高度なSASTはコードフロー情報を提供します。脆弱性のコードフローとは、データが、すべての割り当て、操作、サニタイズを通じて、ユーザー入力（ソース）から脆弱なコード行（シンク）に至るまでの間でたどるパスです。この情報は、脆弱性のコンテキスト、影響、およびリスクを理解して評価するのに役立ちます。入力をソースからシンクまでトレースすることで検出された脆弱性のコードフロー情報を利用できます。この脆弱性には、以下が含まれます。

• SQLインジェクション
• コマンドインジェクション
• クロスサイトスクリプティング（XSS）
• パストラバーサル

コードフロー情報はコードフロータブに表示され、以下が含まれています。

• ソースからシンクまでのステップ。
• コードスニペットを含む、関連ファイル。

サポートされている言語

GitLab高度なSASTは、以下の言語をサポートしています:

• C#（13.0まで）
• C/C++
• Go
• Java（Java Server Pages（JSP）を含む）
• JavaScript、TypeScript
• PHP
• Python
• Ruby

GitLab高度なSAST C++には、コンパイルデータベースを含む追加の設定が必要です。詳細については、C/C++設定を参照してください。GitLab高度なSAST C++とSemgrepは両方ともC/C++プロジェクトで実行され、それぞれ異なるルールセットを使用します。

PHPの既知の問題

PHPコードを分析する際、GitLab高度なSASTには以下の既知のイシューがあります:

• 動的ファイルインクルージョン: ファイルパスに変数を使用する動的なファイルインクルードステートメント(include、include_once、require、require_once)は、このリリースではサポートされていません。クロスファイル分析では、静的なファイルインクルードパスのみがサポートされます。イシュー527341を参照してください。
• 大文字小文字の区別: 関数名、クラス名、およびメソッド名について大文字と小文字を区別しないPHPの特性は、クロスファイル分析では完全にはサポートされていません。イシュー526528を参照してください。

最適化

GitLab高度なSASTのスキャン時間は複数の要因によって決定されますが、主にコードカバレッジとRunnerのリソースに依存します。GitLab高度なSASTのスキャン時間を最適化するには、コードカバレッジとRunnerのリソースを調整できます。

ソースからシンクまでの完全なパスが特定されていない場合でも、オプションで未検証の脆弱性を報告できます。

コードカバレッジを調整する

コードカバレッジとは、コードベースのどの程度が分析されるかを指します。GitLab高度なSASTは、定義済みのルールセットを使用して、サポートされているすべての言語ファイルをスキャンします。SemgrepベースのSASTアナライザーは、これらのファイルをスキャンしません。自動化された移行プロセスにより、両方のアナライザーが同じ脆弱性を検出した場合に、重複する検出結果が削除されます。

デフォルトでは、GitLab高度なSASTはリポジトリ全体をスキャンします。以下の方法でコードカバレッジを調整できます:

• リポジトリのパスを除外することで、分析されるコードの量を減らします。
• 差分ベースのスキャンを有効にして、マージリクエストで変更されたファイル（およびその依存ファイル）のみを分析します。
• インクリメンタルスキャンを有効にすると、以前のスキャンの結果をキャッシュすることで、計算負荷を軽減します。

パスを除外する

スキャン時間を短縮するために、脆弱性が含まれる可能性の低いパスをGitLab高度なSASTのスキャンから除外することができます。

パスを除外する場合は、脆弱性を隠さないように選択的に行ってください。変更をインクリメンタルに行い、それぞれの除外後のスキャン時間への影響をテストします。

以下のものを含むパスを除外することを検討してください:

• データベースマイグレーション
• 単体テスト
• 依存 (node_modules/など)
• ビルドファイル
• 設定情報
• 静的アセット
• テストデータ
• Infrastructure as Code

前提条件:

• プロジェクトのメンテナーまたはオーナーのロール。

パスを除外するには:

• SAST_EXCLUDED_PATHS CI/CD変数に除外するパスをリストします。

差分ベーススキャン

差分ベーススキャンは、マージリクエストで変更されたファイルとその依存ファイルのみを分析します。このターゲットを絞ったアプローチにより、スキャン時間が短縮され、開発中のより迅速なフィードバックが得られます。

完全なカバレッジを確保するために、マージリクエストがマージされた後、デフォルトブランチでフルスキャンが実行されます。

差分ベースのスキャンは、以下の条件でマージリクエストパイプラインとブランチパイプラインの両方でサポートされています:

• マージリクエストパイプライン: 差分ベーススキャンは、マージリクエストパイプラインで実行するようにGitLab高度なSASTが設定されている場合に発生します。
• ブランチパイプライン: 差分ベーススキャンは、ブランチに関連付けられているオープンマージリクエストが1つだけ存在する場合に発生します。存在しない場合、または複数存在する場合、ブランチをどのコミットと比較すればよいかを判断できないため、スキャンはフルスキャンにフォールバックします。

差分ベースのスキャンが有効な場合:

• マージリクエストで変更または追加されたファイルと、その依存ファイルのみがスキャンされます。
• ジョブログには出力: Running differential scanが含まれます。(非アクティブの場合、出力は: Running full scanです。)
• マージリクエストセキュリティウィジェットでは、専用の差分ベースタブに関連するスキャン結果が表示されます。
• パイプラインセキュリティタブでは、Partial SAST reportとラベル付けされたアラートは、部分的な結果のみが含まれていることを示します。

差分ベースのスキャンには、以下の既知のイシューがあります:

• 偽陰性と陽性: 差分ベーススキャンでは、スキャンされたファイル内の完全な呼び出しグラフがキャプチャされず、脆弱性を見逃したり（偽陰性）、解決済みの脆弱性が再浮上したり（偽陽性）する可能性があります。このトレードオフにより、スキャン時間が短縮され、開発中に迅速なフィードバックが得られます。包括的なカバレッジのために、デフォルトブランチでは常にフルスキャンが実行されます。
• C/C++ ヘッダーファイルカバレッジ: 差分ベーススキャンは、C/C++ヘッダーファイルを完全にサポートしていません。ヘッダーファイルとソースファイルの両方にまたがる脆弱性は検出できますが、ヘッダーファイルにのみ存在する脆弱性は検出されない場合があります。
• 修正された脆弱性は報告されません: 誤った結果を避けるため、差分ベーススキャンでは修正された脆弱性が除外されます。ファイルのサブセットのみが分析されるため、完全な呼び出しグラフは利用できず、脆弱性が修正されたかどうかを確認することはできません。フルスキャンは、マージ後にデフォルトブランチで常に実行され、修正された脆弱性が報告されます。結果として、差分ベースのスキャンから生じる可能性のあるギャップは、デフォルトブランチへのマージ時に自動的に実行されるフルスキャンによって軽減され、包括的なカバレッジが確保されます。この多層的なアプローチにより、開発中の迅速なフィードバックループと、コードが本番環境に到達する前の徹底的なセキュリティ分析のバランスが取れます。

差分ベースのスキャンを有効にする

前提条件:

• プロジェクトのメンテナーまたはオーナーのロール。

マージリクエストパイプラインで差分ベースのスキャンを有効にするには:

• プロジェクトの.gitlab-ci.ymlファイルでADVANCED_SAST_PARTIAL_SCAN CI/CD変数をdifferentialに設定します。

依存ファイル

変更ファイルでは検出できないクロスファイルの脆弱性を見逃さないようにするため、差分ベーススキャンには、変更ファイルに直接依存するファイルも含まれます。これにより、迅速なスキャンを維持しながら偽陰性を減らしますが、より深い依存チェーンでは不正確な結果を生じる可能性があります。

次のファイルがスキャンに含まれています:

• 変更ファイル（マージリクエストで変更または追加されたファイル）
• 依存ファイル（変更ファイルをインポートするファイル）

この設計は、変更された関数からそれをインポートする呼び出し元に汚染データが移動するなど、クロスファイルデータフローの検出に役立ちます。

変更ファイルによってインポートされたファイルは、通常、変更されたコード行の動作やデータフローに影響を与えないため、スキャンされません。

たとえば、ファイルBを変更するマージリクエストについて考えてみましょう:

• ファイルAがファイルBをインポートする場合、ファイルAとファイルBがスキャンされます。
• ファイルBがファイルCをインポートする場合、ファイルBのみがスキャンされます。

インクリメンタルスキャン

インクリメンタルスキャンは、パイプラインの実行間でテイント署名分析の結果をキャッシュします。その後のスキャンでは、変更されていないコードはキャッシュされた署名を再利用し、再分析されることはありませんが、変更または新規のコードは完全に分析されます。これにより、コミット間でほとんどのファイルが変更されない大規模なコードベースでのスキャン時間が短縮されます。

インクリメンタルスキャンは次のように機能します:

1. 最初のスキャン（コールドラン）: アナライザーは完全な分析を実行し、テイント署名のキャッシュを作成します。キャッシュはCIアーティファクト (ts-cache.sqlite.gz)として保存されます。
2. その後のスキャン（ウォームラン）: アナライザーは、キャッシュアーティファクトを含む成功したパイプラインを以前のコミットから検索します。見つかった場合、キャッシュがフェッチされ、変更されていない結果が再利用されます。スキャンが完了すると、更新されたキャッシュは新しいアーティファクトとして保存されます。

キャッシュの無効化

キャッシュは、精度を確保しつつ再利用を最大化するために無効化されます:

部分的な無効化: 影響を受けるエントリのみが再計算され、残りのキャッシュは再利用されます:

• 新規または変更されたファイル: ファイルが追加、変更、削除、または名前変更された場合、キャッシュされた署名は無効化され、次回のスキャンで再計算されます。
• 新規または変更されたルール: 検出ルールが追加または変更された場合、その特定のルールのみがコードベースに対して再計算されます。

完全な無効化: キャッシュ全体が再構築されます:

• エンジン変更: エンジンレベルの変更により既存のキャッシュに互換性がなくなった場合、フルスキャンから新しいキャッシュが自動的に生成されます。

インクリメンタルスキャンを有効にする

インクリメンタルスキャンを有効にするには:

• プロジェクトの.gitlab-ci.ymlファイルで、GITLAB_ADV_SAST_INCR_SCAN CI/CD変数をtrueに設定します:

  gitlab-advanced-sast:
    variables:
      GITLAB_ADV_SAST_INCR_SCAN: "true"

キャッシュの保持期間を設定する

SAST CI/CDテンプレートは、デフォルトで3日間の有効期限を持つキャッシュアーティファクトを保存します。GITLAB_ADV_SAST_INCR_SCAN_SEARCH_PERIOD変数は、アナライザーがキャッシュアーティファクトをどれだけ遡って検索するかを制御します（デフォルト: 3 days）。

これら2つの値は同期させる必要があります。検索期間はアーティファクトの有効期限を超えてはなりません。超えた場合、アナライザーは既に期限切れのアーティファクトを検索してしまう可能性があります。

両方の値をカスタマイズするには、artifacts:expire_inをオーバーライドし、検索期間変数を設定します:

gitlab-advanced-sast:
  variables:
    GITLAB_ADV_SAST_INCR_SCAN: "true"
    GITLAB_ADV_SAST_INCR_SCAN_SEARCH_PERIOD: "7 days"
  artifacts:
    paths:
      - gl-sast-report.json
      - ts-cache.sqlite.gz
    expire_in: 7 days

検索期間は、d、day、またはdaysのいずれかが続く数値をサポートしています（例: 7 days、14d）。

カスタムジョブ名を設定する

アナライザーは、キャッシュを含むジョブのアーティファクトを特定するためにCI/CDジョブ名を使用します。gitlab-advanced-sastジョブの名前を変更した場合、GITLAB_ADV_SAST_INCR_SCAN_CUSTOM_JOB_NAMEをカスタム名に設定して、キャッシュルックアップが正しいジョブを見つけられるようにします:

my-custom-sast-job:
  variables:
    GITLAB_ADV_SAST_INCR_SCAN: "true"
    GITLAB_ADV_SAST_INCR_SCAN_CUSTOM_JOB_NAME: "my-custom-sast-job"

キャッシュサイズ制限

キャッシュは圧縮されたCI/CDアーティファクトとして保存されます。アーティファクトのサイズ制限が適用されます:

• GitLab.com: 最大アーティファクトサイズは1 GB。
• GitLab Self-Managed: デフォルトの最大アーティファクトサイズは100 MB。管理者は、CI/CD設定でこの制限を調整できます。

未検証の脆弱性を報告する

GitLab高度なSASTは、テイント解析を使用して、信頼できないソースから脆弱性のあるシンクへのデータフローをトレースします。デフォルトでは、アナライザーは完全なパスをトレースできる場合にのみ脆弱性を報告し、カバレッジよりも精度を優先します。より多くの潜在的なデータフローを検出するために、未検証の脆弱性を有効にできます。この機能は、完全なデータフローパスが確立できない場合でも結果を報告します。これによりカバレッジは向上しますが、誤検出の数も増加する可能性があります。

未検証の脆弱性報告を有効にすると、アナライザーは、部分的なテイントフローが検出されたものの、ソースからシンクまで完全に検証できなかった結果も報告します。これらのニアミス結果は、コードが悪用される前にリスクのあるコードを特定し、プロアクティブに修正するのに役立ちます。未検証の結果は、セキュリティ重大度が中以上のルールに対してのみ報告されます。

未検証の結果は、完全に検証された脆弱性とは以下の点で明確に区別されます:

• パイプラインセキュリティタブでは、脆弱性の説明は**(Unverified)**プレフィックスで始まります。
• 脆弱性レポートでは、未検証の結果も同様にプレフィックスが付加されます。
• コードフロービューでは、未検証の脆弱性にはソースノードがありません。フロー内の最初のノードはトレースエントリーポイントであり、部分的なトレースの開始点を示します。

未検証の脆弱性報告を有効にする

スキャン結果に未検証の結果を含めるには、REPORT_UNVERIFIED_VULNS CI/CD変数を.gitlab-ci.ymlファイルで真値に設定します:

gitlab-advanced-sast:
  variables:
    REPORT_UNVERIFIED_VULNS: "true"

Runnerリソースを調整する

Runnerリソースはスキャン時間に直接影響します。GitLab高度なSASTはデフォルトでチェックを並行して実行するため、複数のCPUコアとコアあたり最低4 GBのメモリが必要です。Runnerリソースは自動的に検出されますが、必要に応じて一部の設定を調整できます。

アナライザーは、以下の優先順位に従って利用可能なCPUとメモリを決定します:

1. GitLab SaaS Runnerタグ (CI_RUNNER_TAGS):
   • GitLabがホストするRunnerでは、アナライザーはRunnerタグ（例: saas-linux-large-amd64）を読み取り、そのRunnerタイプに既知のCPUおよびメモリ値を検索します。
2. コンテナリソース制限 (/sys/fs/cgroup/cpu.max, /sys/fs/cgroup/memory.max):
   • セルフマネージドRunnerでは、アナライザーはLinux cgroupからコンテナのリソース制限を読み取ります。cgroupにはリソース制限のみが反映されます。リクエストはコンテナレベルでは強制されず、効果がありません。
3. CI/CD変数のオーバーライド (ADVANCED_SAST_AVAILABLE_CPUS, ADVANCED_SAST_AVAILABLE_MEMORY):
   • 設定されている場合、これらの値はステップ1または2で検出されたものをオーバーライドします。

ステップ1と2で検出に失敗した場合、アナライザーはデフォルトで1コアと4 GBのメモリを使用します。

CPUとメモリの割り当てを確認するには、gitlab-advanced-sastジョブログを表示し、GitLab高度なSASTのエントリを探してください。例:

[INFO] [GitLab Advanced SAST] [2026-03-30T02:38:09Z] ▶ Detected 2 CPU Cores
[INFO] [GitLab Advanced SAST] [2026-03-30T02:38:09Z] ▶ No Memory limit is detected

Runnerリソース設定を構成する

以下の状況で、CI/CD変数を使用してアナライザーのCPUおよびメモリ設定を手動で調整できます:

• Runnerにcgroup制限が設定されていない場合（例えば、ベアメタルや制約のないVM）。
• 検出された値がRunnerの実際のリソースと一致しない場合。
• アナライザーが利用可能なリソース以下で使用するよう制限したい場合。

GitLab高度なSAST Runnerのリソースを調整するには、以下のCI/CD設定を使用します:

• ADVANCED_SAST_AVAILABLE_CPUS - アナライザーが利用できるCPUコアを指定します。
• ADVANCED_SAST_AVAILABLE_MEMORY - アナライザーが利用できる合計メモリを指定します。
• MAX_UNVERIFIED_CORES - 自動コア検出の上限を設定します。
• DISABLE_MULTI_CORE - マルチコアスキャンを完全に無効にします。

セルフマネージドRunnerの場合、セキュリティスキャナー設定で--multi-coreフラグを使用して、requestedコアの数を指定できます。

詳細については、設定を参照してください。

プロジェクトに最適な設定を見つけるには、一度に1つの設定のみを変更し、スキャン時間を監視してください。

以下の例では、GitLab高度なSASTアナライザーに4つのCPUコアと16 GBのメモリが利用可能です。4つのワーカーそれぞれに4 GBのメモリが利用可能です。

include:
  - template: Jobs/SAST.gitlab-ci.yml

variables:
  GITLAB_ADVANCED_SAST_ENABLED: 'true'
  ADVANCED_SAST_AVAILABLE_CPUS: '4'
  ADVANCED_SAST_AVAILABLE_MEMORY: '16384'  # 16 GB for 4 cores

設定

次の変数を使用して、GitLab高度なSASTの動作を調整できます:

GitLab高度なSASTスキャンはデフォルトで無効になっています。上位レベル（例えばグループ）で有効になっている場合に明示的に無効にするには、GITLAB_ADVANCED_SAST_ENABLED（C/C++プロジェクトの場合はGITLAB_ADVANCED_SAST_CPP_ENABLED）をfalseに設定します。

ロールアウトする

1つのプロジェクトでGitLab高度なSASTの結果に満足したら、追加のプロジェクトとグループに拡張します。GitLab高度なSASTを含む共有CI/CD設定を作成し、必要に応じてグループとプロジェクト全体に適用します。

詳細については、セキュリティ設定を参照してください。

脆弱性検出基準

GitLab高度なSASTは、テイント解析によるクロスファイル、クロスファンクションスキャンを使用して、ユーザー入力のプログラムへのフローを追跡します。これにより、SQLインジェクションやクロスサイトスクリプティング（XSS）などのインジェクション脆弱性が、複数の関数やファイルにまたがる場合でも検出されるようになります。

アナライザーは、信頼できないユーザー入力をソースから、信頼できないデータがセキュリティ脆弱性を引き起こす可能性のあるポイントに導く、検証可能なフローがある場合にのみ、テイント解析ベースの脆弱性を報告します。このアプローチは、検証が不十分な脆弱性を報告する可能性のある他の製品と比較して、ノイズを最小限に抑えます。

検出では、HTTPリクエストからソースされる値など、信頼境界を越える入力が重視されますが、コマンドラインの引数、環境変数、またはプログラムを操作するユーザーが通常提供するその他の入力は除外されます。

GitLabの高度な静的アプリケーションセキュリティテストが検出する脆弱性の種類の詳細については、GitLab高度なSASTのCWEカバレッジを参照してください。

SemgrepからGitLab高度なSASTへの移行

SemgrepからGitLab高度なSASTに移行すると、自動移行プロセスにより、脆弱性が重複排除されます。このプロセスでは、以前に検出されたSemgrepの脆弱性を対応するGitLab高度なSASTの発見にリンクし、一致するものが見つかった場合に置き換えます。

デフォルトブランチで高度なSASTスキャンを有効にした後、スキャンが実行されて脆弱性が検出されると、次の条件に基づいて、既存のSemgrepの脆弱性を置き換える必要があるかどうかがチェックされます。

重複排除の条件

1. 識別子の照合:

   • GitLab高度なSASTの少なくとも1つの脆弱性識別子（CWEとOWASPを除く）が、既存のSemgrep脆弱性のプライマリ識別子と一致する必要があります。
   • プライマリ識別子は、SASTレポート内にある脆弱性の識別子配列の最初の識別子です。
   • たとえば、GitLab高度なSASTの脆弱性にbandit.B506などの識別子があり、Semgrepの脆弱性のプライマリ識別子もbandit.B506である場合、この条件は満たされます。

2. 場所の照合:

   • 脆弱性は、コード内の同じ場所に関連付けられている必要があります。これは、SASTレポート内にある脆弱性の次のいずれかのフィールドを使用して判別されます。
     • 追跡フィールド（存在する場合）
     • 場所フィールド（追跡フィールドが存在しない場合）

脆弱性の変更

条件が満たされると、Semgrepの既存の脆弱性はGitLab高度なSASTの脆弱性に変換されます。この更新された脆弱性は、次の変更を加えて脆弱性レポートに表示されます。

• スキャナーの種類がSemgrepからGitLab高度なSASTに更新されます。
• GitLab高度なSASTの脆弱性に存在する追加の識別子が、既存の脆弱性に追加されます。
• 脆弱性のそれ以外の詳細は変更されません。

重複する脆弱性を修正する

重複排除の条件が満たされない場合、Semgrepの脆弱性が重複としてそのまま表示されることがあります。脆弱性レポートでこれを解決するには、次の手順に従います。

1. 高度なSASTスキャナーで脆弱性をフィルタリングし、結果をCSV形式でエクスポートします。
2. Semgrepスキャナーで脆弱性をフィルタリングします。これらは、重複排除されなかった脆弱性である可能性があります。
3. Semgrepの脆弱性ごとに、エクスポートされた高度なSASTの結果に対応する一致があるかどうかを確認します。
4. 重複が存在する場合は、Semgrepの脆弱性を適切に解決します。

GitLab高度なSASTで、LGPLライセンスコンポーネントのソースコードをリクエストする

GitLab高度なSASTで、LGPLライセンスコンポーネントのソースコードに関する情報をリクエストするには、GitLabサポートにお問い合わせください。

迅速な対応を確保するために、リクエストにGitLab高度なSASTアナライザーのバージョンを含めてください。

この機能はUltimateプランでのみ利用できるため、そのレベルのサポート資格を持つ組織と関連している必要があります。