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

静的アプリケーションセキュリティテスト（SAST）では、本番環境に移行する前にソースコードの脆弱性を検出します。CI/CDパイプラインに直接統合されたSASTは、修正が最も簡単で費用対効果の高い開発中にセキュリティ上の問題を特定します。

開発の後期段階でセキュリティの脆弱性が発見されると、コストのかかる遅延や潜在的なセキュリティ侵害が発生する可能性があります。SASTスキャンはコミットごとに自動的に実行されるため、ワークフローを中断することなく、すぐにフィードバックを得られます。

GitLab Duoによる誤検出の削減と脆弱性の解決

SASTスキャナーは、誤検出を出すことがあり、それが脆弱性レポートにノイズを生む原因になります。GitLab Duoは、脆弱性管理を支援します。

誤検出判定

GitLab Duoの誤検出判定は、重大度が致命的および高いSAST脆弱性を自動的に分析し、誤検出の可能性が高いものを特定します。これにより、セキュリティチームは真の脆弱性に集中し、手動トリアージに費やす時間を削減できます。

GitLab Duoアドオンをご利用のUltimateのお客様の場合、誤検出の検出は、各セキュリティスキャンの後に自動的に実行され、各評価の説明とともに信頼性スコアが提供されます。

エージェント型SAST脆弱性の修正

エージェント型SASTの脆弱性の修正は、重大度が高または重大に分類されるSAST脆弱性に対し、状況に応じたコード修正を自動で生成し、マージリクエストを作成します。このエージェント型アプローチは、複数段階の推論を用いて、最小限の人手で脆弱性を解消します。

GitLab Duo Enterpriseをご利用のUltimateのお客様の場合、エージェント型の脆弱性の解決は、脆弱性が特定の条件を満たす場合に、各セキュリティスキャンの後に自動的に実行されます。

機能

次の表に、各機能が利用可能なGitLabのプランを示します。

はじめに

UIを使用するか、プロジェクトのGitLab CI/CD設定ファイルを編集して、プロジェクトでSASTを有効にします。

UIを使用してSASTを有効にする

UIを使用してSASTを有効化および設定できます。設定はデフォルトのままにすることも、カスタマイズすることも可能です。使用できる方法は、GitLabのライセンスプランによって異なります。

カスタマイズでSASTを有効にする

前提条件:

• プロジェクトのメンテナーまたはオーナーのロールを持っている。
• DockerまたはKubernetes executorを使用した、LinuxベースのGitLab Runner。ホストされているGitLab.com用のRunnerを使用している場合、DockerまたはKubernetes executorはデフォルトで有効になっています。
  • Windows RunnerでのGitLab Runnerはサポートされていません。
  • AMD64以外のCPUアーキテクチャはサポートされていません。
• GitLab CI/CD設定（.gitlab-ci.yml）に、testステージを含める必要があります。これはデフォルトで含まれています。.gitlab-ci.ymlファイルでステージを再定義する場合は、testステージが必要です。

カスタマイズしてSASTを有効化および設定するには、以下の手順に従います:

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

2. セキュリティ > セキュリティ設定を選択します。

3. プロジェクトのデフォルトブランチに対する最新のパイプラインが完了し、有効なSASTアーティファクトが生成された場合は、SASTを設定を選択します。それ以外の場合は、静的アプリケーションセキュリティテスト（SAST）行でSASTを有効にするを選択します。

4. SASTのカスタム値を入力します。

   カスタム値は.gitlab-ci.ymlファイルに保存されます。SASTの設定ページに表示されていないCI/CD変数については、GitLab SASTテンプレートから値が継承されます。

5. マージリクエストの作成を選択します。

6. マージリクエストをレビューしてマージします。

これで、パイプラインにSASTジョブが含まれます。サポートされているソースコードが存在する場合、パイプラインの実行時に、適切なアナライザーとデフォルトルールにより、脆弱性のスキャンが自動的に行われます。対応するジョブは、プロジェクトのパイプラインのtestステージの下に表示されます。

デフォルト設定のみでSASTを有効にする

前提条件:

• プロジェクトのメンテナーまたはオーナーのロールを持っている。
• DockerまたはKubernetes executorを使用した、LinuxベースのGitLab Runner。ホストされているGitLab.com用のRunnerを使用している場合、DockerまたはKubernetes executorはデフォルトで有効になっています。
  • Windows RunnerでのGitLab Runnerはサポートされていません。
  • AMD64以外のCPUアーキテクチャはサポートされていません。
• GitLab CI/CD設定（.gitlab-ci.yml）に、testステージを含める必要があります。これはデフォルトで含まれています。.gitlab-ci.ymlファイルでステージを再定義する場合は、testステージが必要です。

デフォルト設定でSASTを有効化および設定するには、以下の手順に従います:

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

2. セキュリティ > セキュリティ設定を選択します。

3. SASTセクションでマージリクエスト経由で設定を選択します。

   マージリクエストページが開きます。

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

5. マージリクエストの作成を選択します。

6. マージリクエストをレビューしてマージし、SASTを有効にします。

これで、パイプラインにSASTジョブが含まれます。サポートされているソースコードが存在する場合、パイプラインの実行時に、適切なアナライザーとデフォルトルールにより、脆弱性のスキャンが自動的に行われます。対応するジョブは、プロジェクトのパイプラインのtestステージの下に表示されます。

CI/CDファイルを編集してSASTを有効にする

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。
• DockerまたはKubernetes executorを使用した、LinuxベースのGitLab Runner。ホストされているGitLab.com用のRunnerを使用している場合、DockerまたはKubernetes executorはデフォルトで有効になっています。
  • Windows RunnerでのGitLab Runnerはサポートされていません。
  • AMD64以外のCPUアーキテクチャはサポートされていません。
• GitLab CI/CD設定（.gitlab-ci.yml）に、testステージを含める必要があります。これはデフォルトで含まれています。.gitlab-ci.ymlファイルでステージを再定義する場合は、testステージが必要です。

プロジェクトでSASTを有効にするには、次の手順を実行します:

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

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

3. SAST CI/CDテンプレートまたはコンポーネントのいずれかを追加します。

   テンプレートを使用するには、次の行を追加します:

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

   CI/CDコンポーネントを使用するには、次の行を追加します:

   include:
     - component: gitlab.com/components/sast/sast@main

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

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

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

6. フィールドに入力します:

   • コミットメッセージ。
   • ブランチ。例: add-sast。

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

   マージリクエストページが開きます。

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

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

これで、パイプラインにSASTジョブが含まれます。サポートされているソースコードが存在する場合、パイプラインの実行時に、適切なアナライザーとデフォルトルールにより、脆弱性のスキャンが自動的に行われます。対応するジョブは、プロジェクトのパイプラインのtestステージの下に表示されます。

動作例は、SASTサンプルプロジェクトで確認できます。

次の手順

SASTを有効にした後、次のことができます:

• 結果の把握方法について詳しく理解する。
• 最適化のヒントを確認する。
• 幅広いプロジェクトへのロールアウトを計画する。

結果について理解する

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

パイプラインの脆弱性を確認できます:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 左側のサイドバーで、ビルド > パイプラインを選択します。
3. パイプラインを選択します。
4. セキュリティタブを選択します。
5. 結果をダウンロードするか、詳細を表示する脆弱性を選択します（Ultimateのみ）。詳細には以下の内容が含まれます:
   • 説明: 脆弱性の原因、潜在的な影響、推奨される修正手順について説明しています。
   • ステータス: 脆弱性がトリアージされたか、解決されたかを示します。
   • 重大度: 影響に基づいて6つのレベルに分類されます。重大度レベルの詳細はこちらをご覧ください。
   • 場所: 問題が検出されたファイル名と行番号を示します。ファイルパスを選択すると、対応する行がコードビューで開きます。
   • スキャナー: 脆弱性を検出したアナライザーを示します。
   • 識別子: CWEの識別子やそれを検出したルールのIDなど、脆弱性の分類に使用される参照の一覧です。

SASTの脆弱性には、検出された脆弱性の主要なCWE識別子に従って名前が付けられています。スキャナーが検出した特定の問題の詳細については、各脆弱性の発見の説明をお読みください。SASTカバレッジの詳細については、SASTルールを参照してください。

Ultimateでは、セキュリティスキャンの結果をダウンロードすることもできます:

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

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

詳細については、パイプラインセキュリティレポートを参照してください。

SASTの結果を確認するその他の方法:

• マージリクエストウィジェット: 新しく導入された、または解決された発見を示します。
• マージリクエストの変更ビュー: 変更された行のインライン注釈を示します。
• 脆弱性レポート: デフォルトブランチで確認された脆弱性を示します。

パイプラインは、SASTやDASTスキャンを含む複数のジョブで構成されています。何らかの理由でジョブが完了しなかった場合、セキュリティダッシュボードにSASTスキャナーの出力は表示されません。たとえば、SASTジョブは完了したがDASTジョブが失敗した場合、セキュリティダッシュボードにSASTの結果は表示されません。失敗すると、アナライザーは終了コードを出力します。

マージリクエストウィジェット

ターゲットブランチからのレポートを比較できる場合、SASTの結果がマージリクエストウィジェット領域に表示されます。マージリクエストウィジェットには以下が表示されます:

• MRによって導入された新しいSASTの検出結果。
• MRによって解決された既存の検出結果。

結果は、高度な脆弱性追跡が利用可能な場合はそれを使用して比較されます。

マージリクエストの変更ビュー

SASTの結果は、マージリクエストの変更ビューに表示されます。SASTのイシューを含む行は、ガターの横に記号でマークされます。記号を選択してイシューのリストを表示し、イシューを選択して詳細を表示します。

最適化

要件に応じてSASTを最適化するには、次の操作を実行します:

• ルールを無効にする。
• ファイルまたはパスをスキャンから除外する。

ルールを無効にする

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

たとえば、誤検出が多すぎるためにルールを無効にするには、次の手順に従います:

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

2. .gitlab/sast-ruleset.tomlファイルがまだ存在しない場合は、プロジェクトのルートに作成します。

3. 脆弱性の詳細で、発見をトリガーしたルールのIDを探します。

4. ルールIDを使用して、ルールを無効にします。たとえば、gosec.G107-1を無効にするには、.gitlab/sast-ruleset.tomlに以下を追加します:

   [semgrep]
     [[semgrep.ruleset]]
       disable = true
       [semgrep.ruleset.identifier]
         type = "semgrep_id"
         value = "gosec.G107-1"

ルールセットのカスタマイズの詳細については、ルールセットをカスタマイズするを参照してください。

ファイルまたはパスをスキャンから除外する

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

テストコードや一時コードなどのファイルまたはパスをスキャンから除外するには、SAST_EXCLUDED_PATHS変数を設定します。たとえば、rule-template-injection.goをスキップするには、.gitlab-ci.ymlに以下を追加します:

variables:
  SAST_EXCLUDED_PATHS: "rule-template-injection.go"

設定オプションの詳細については、利用可能なCI/CD変数を参照してください。

ロールアウトする

単一のプロジェクトのSASTの結果に確信が持てたら、その実装を他のプロジェクトに拡張できます:

• スキャン実行の強制を使用して、グループ全体にSAST設定を適用します。
• リモート設定ファイルを指定して、中央ルールセットを共有および再利用します。
• 固有の要件がある場合、SASTはオフライン環境またはSELinux制約下で実行できます。

サポートされている言語とフレームワーク

GitLab SASTは、次の言語とフレームワークのスキャンをサポートしています。

利用可能なスキャンオプションは、GitLabのプランによって異なります:

• Ultimateでは、GitLabの高度なSASTのほうがより正確な結果が得られます。サポート対象の言語には、これを使用することをおすすめします。
• 全プランで、オープンソーススキャナーを基にしたGitLab提供のアナライザーを使用して、コードをスキャンできます。

SASTにおける言語サポート計画の詳細については、カテゴリの方向性のページを参照してください。

完全にサポートされている言語

これらの言語は、GitLabの高度なSAST（Ultimate）と標準アナライザー（全プラン）の両方でサポートされています:

脚注:

1. GitLab高度なSAST - Ultimateプランのみ。
2. 全プラン。特に指定がない限り、GitLab管理ルールを適用したSemgrepアナライザーを使用します。
3. Java Server Pages（JSP）およびAndroidを含みます。
4. Node.jsとReactを含みます。
5. Ruby on Railsを含みます。
6. YAMLサポートは、次のファイルパターンに制限されています:
   • application*.yml
   • application*.yaml
   • bootstrap*.yml
   • bootstrap*.yaml

標準アナライザーのみでサポートされている言語

これらの言語は、標準アナライザー（全プラン）でサポートされていますが、GitLab高度なSASTではサポートされていません:

脚注:

1. 全プラン。特に指定がない限り、GitLab管理ルールを適用したSemgrepアナライザーを使用します。
2. 参照されているエピックでは、これらの言語に対するGitLabの高度なSASTのサポートが提案されています。
3. find-sec-bugsプラグインを使用したSpotBugs。Gradle、Maven、SBTをサポートします。また、Gradleラッパー、Grails、Mavenラッパーなどのバリアントでも使用できます。ただし、SpotBugsは、Antベースのプロジェクトで使用する場合、制限があります。AntベースのJavaまたはScalaプロジェクトには、GitLab高度なSASTまたはSemgrepベースのアナライザーを使用する必要があります。
4. Androidを含みます。

SAST CI/CDテンプレートには、KubernetesマニフェストとHelmチャートをスキャンできるアナライザージョブも含まれています。このジョブはデフォルトでオフになっています。Kubesecアナライザーを有効にするを参照するか、代わりに、追加のプラットフォームをサポートするIaCスキャンをご検討ください。

サポートされなくなったSASTアナライザーの詳細については、サポートが終了したアナライザーを参照してください。

高度な脆弱性追跡

ソースコードは頻繁に変更されるものです。デベロッパーが変更を加えると、ソースコードが同じファイル内またはファイル間で移動する可能性があります。セキュリティアナライザーは、脆弱性レポートで追跡されている脆弱性をすでに報告している可能性があります。これらの脆弱性は、見つけ出して修正できるように、特定の問題のあるコードフラグメントにリンクされています。しかし、コードフラグメントが移動した際に正確に追跡されない場合、同じ脆弱性が再度報告される可能性があるため、脆弱性管理がより困難になります。

GitLab SASTは、高度な脆弱性追跡アルゴリズムを使用して、リファクタリングまたは無関係な変更によって同じファイル内で同じ脆弱性が移動した場合をより正確に特定します。

高度な脆弱性追跡のサポートは、使用される言語とアナライザーによって異なります。

GitLabの高度なSASTアナライザーとSemgrepベースのアナライザーの両方でサポートされている言語は以下のとおりです:

• C
• C++
• C#
• Go
• Java
• JavaScript
• Python

Semgrepベースのアナライザーのみでサポートされている言語は以下のとおりです:

• PHP
• Ruby

より多くの言語とアナライザーのサポートが、エピック5144で追跡されています。

詳細については、機密プロジェクトhttps://gitlab.com/gitlab-org/security-products/post-analyzers/tracking-calculatorを参照してください。このプロジェクトの内容は、GitLabチームメンバーのみが利用できます。

脆弱性の自動修正

関連性の高い脆弱性に集中できるように、GitLab SASTは次の場合に脆弱性を自動的に修正します:

• 定義済みルールを無効にする場合
• デフォルトルールセットからルールが削除される場合

自動解決は、Semgrepベースのアナライザーによる発見にのみ使用できます。自動的に修正された脆弱性には、脆弱性管理システムがコメントを追加するため、脆弱性の履歴記録が保持されます。

後でルールを再度有効にすると、トリアージのために発見が再度オープンされます。

サポートされているディストリビューション

デフォルトのスキャナーイメージは、サイズと保守性の観点からAlpineイメージをベースに構築されています。

FIPS対応イメージ

GitLabは、Red Hat UBIベースイメージに基づき、FIPS 140検証済みの暗号学的モジュールを使用する別バージョンのイメージを提供しています。FIPS対応イメージを使用するには、次のいずれかを実行します:

• SAST_IMAGE_SUFFIXを-fipsに設定します。
• デフォルトのイメージ名に-fips拡張子を追加します。

例:

variables:
  SAST_IMAGE_SUFFIX: '-fips'

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

FIPS準拠のイメージは、GitLab高度なSASTとSemgrepベースのアナライザーでのみ使用できます。

SASTレポートをダウンロードする

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

各SASTアナライザーは、ジョブアーティファクトとしてJSONレポートを出力します。このファイルには、検出されたすべての脆弱性の詳細が含まれています。ファイルをダウンロードして、GitLabの外部で処理できます。

詳細については、以下を参照してください:

• SASTレポートファイルスキーマ
• SASTレポートファイルの例

設定

GitLab SASTは、デフォルト設定で使用するように設計されています。ただし、必要に応じて設定変数を変更したり、検出ルールをカスタマイズしたりすることもできます。

安定版と最新版のSASTテンプレート

SASTには、本番環境で使用されるデフォルトのstableテンプレートと、最先端の機能をテストするためのlatestテンプレートが用意されています。それぞれの違いや使用するタイミングの詳細については、テンプレートのエディションを参照してください。

SASTジョブをオーバーライド

variables、dependencies、およびrulesなどのプロパティをカスタマイズする場合は、SASTジョブをオーバーライドします。

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

ジョブ定義をオーバーライドするには:

• オーバーライドするSASTジョブと同じ名前でジョブを宣言します。

  テンプレートの挿入後にこの新しいジョブを配置し、その下に追加のキーを指定します。

次の例では、CI/CD変数FAIL_NEVERがspotbugsアナライザーに対して有効になっています:

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

spotbugs-sast:
  variables:
    FAIL_NEVER: 1

アナライザーイメージバージョンをピン留めする

パイプラインで特定のアナライザーイメージバージョンを使用する場合は、イメージバージョンをピン留めします。GitLab管理のCI/CDテンプレートは、メジャーバージョンを指定し、そのメジャーバージョン内の最新のアナライザーリリースを自動的にプルします。場合によっては、特定のバージョンを使用しなければならないことがあります。たとえば、後のリリースで発生したリグレッションを回避する必要がある場合などです。

次のいずれかのオプションにタグを設定できます:

• メジャーバージョン（例: 3）。パイプラインは、このメジャーバージョン内でリリースされるマイナーまたはパッチアップデートを使用します。
• マイナーバージョン（例: 3.7）。パイプラインは、このマイナーバージョン内でリリースされるパッチアップデートを使用します。
• パッチバージョン（例: 3.7.0）。パイプラインはアップデートを受け取りません。

この変数は、特定のジョブ内でのみ設定してください。トップレベルで設定すると、設定したバージョンはすべてのSASTアナライザーに使用されます。

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

アナライザーイメージを特定のバージョンにピン留めするには:

• プロジェクトの.gitlab-ci.ymlファイルで、SAST_ANALYZER_IMAGE_TAGCI/CD変数を設定します。このCI/CD変数は、SAST.gitlab-ci.ymlテンプレートを含めた後にリストする必要があります。

次の例では、semgrepアナライザーの特定のマイナーバージョンと、brakemanアナライザーの特定のパッチバージョンが設定されています:

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

semgrep-sast:
  variables:
    SAST_ANALYZER_IMAGE_TAG: "3.7"

brakeman-sast:
  variables:
    SAST_ANALYZER_IMAGE_TAG: "3.1.1"

CI/CD変数を使用してプライベートリポジトリの認証情報を渡す

一部のアナライザーでは、分析を実行するためにプロジェクトの依存関係をダウンロードする必要があります。一方、そのような依存関係はプライベートGitリポジトリに存在する可能性があり、ダウンロードするにはユーザー名やパスワードなどの認証情報が必要になります。そのような認証情報は、カスタムCI/CD変数を使用して、アナライザーに提供できます。

CI/CD変数を使用してプライベートMavenリポジトリにユーザー名とパスワードを渡す

プライベートMavenリポジトリにログイン認証情報が必要な場合は、MAVEN_CLI_OPTS CI/CD変数を使用できます。

詳細については、プライベートMavenリポジトリの使用方法を参照してください。

Kubesecアナライザーを有効にする

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

Kubesecアナライザーを有効にするには、SCAN_KUBERNETES_MANIFESTSを"true"に設定する必要があります。.gitlab-ci.ymlで、次のように定義します:

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

variables:
  SCAN_KUBERNETES_MANIFESTS: "true"

Semgrepベースのアナライザーで他の言語をスキャンする

SemgrepベースのSASTアナライザーをカスタマイズして、GitLab管理ルールセットでサポートされていない言語をスキャンできます。ただし、GitLabではこれらの他の言語向けのルールセットが提供されていないため、それらを対象にするには、デフォルトのルールを置き換えるか、追加する必要があります。また、関連ファイルが変更されたときにジョブが実行されるように、semgrep-sast CI/CDジョブのrulesも変更する必要もあります。

Rustアプリケーションをスキャンする

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

Rustアプリケーションをスキャンするには、次の手順を実行します:

1. Rust用のカスタムルールセットを提供します。リポジトリのルートにある.gitlab/ディレクトリに、sast-ruleset.tomlという名前のファイルを作成します。

   次の例では、SemgrepレジストリのRust用デフォルトルールセットを使用しています:

   [semgrep]
     description = "Rust ruleset for Semgrep"
     targetdir = "/sgrules"
     timeout = 60
   
     [[semgrep.passthrough]]
       type  = "url"
       value = "https://semgrep.dev/c/p/rust"
       target = "rust.yml"

   詳しくは、定義済みルールの置き換えまたは追加 を参照してください。

2. semgrep-sastジョブをオーバーライドして、Rust（.rs）ファイルを検出するルールを追加します。

   .gitlab-ci.ymlファイルで次のように定義します:

   include:
     - template: Jobs/SAST.gitlab-ci.yml
   
   semgrep-sast:
     rules:
       - if: $CI_COMMIT_BRANCH
         exists:
           - '**/*.rs'
           # include any other file extensions you need to scan from the semgrep-sast template: Jobs/SAST.gitlab-ci.yml

SpotBugsアナライザーのJDK21サポート

SpotBugsアナライザーのバージョン6では、JDK21のサポートが追加され、JDK11のサポートが削除されます。デフォルトのバージョンは、イシュー517169で説明されているように、引き続きバージョン5です。

バージョン6を使用するには、アナライザーバージョンをピン留めします。詳細については、アナライザーイメージバージョンをピン留めするを参照してください。

spotbugs-sast:
  variables:
    SAST_ANALYZER_IMAGE_TAG: "6"

SpotBugsアナライザーでプリコンパイルを使用する

SpotBugsベースのアナライザーは、Groovyプロジェクトのコンパイル済みバイトコードをスキャンします。デフォルトでは、依存関係のフェッチとコードのコンパイルを自動的に試行し、スキャンできるようにします。

自動ビルドは、以下のいずれかの場合に失敗する可能性があります:

• プロジェクトにカスタムビルド設定が必要な場合。
• アナライザーに組み込まれていない言語バージョンを使用している場合。

これらの問題を解決するには、アナライザーのコンパイル手順をスキップし、代わりにパイプラインの前のステージからアーティファクトを直接提供する必要があります。この手法は、プリコンパイルと呼ばれます。

プリコンパイルされたアーティファクトを共有する

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

プリコンパイルされたアーティファクトを共有するには、プロジェクトの.gitlab-ci.ymlファイルに次の変更を加えます:

1. コンパイルジョブ（通常はbuildという名前）を使用してプロジェクトをコンパイルし、CI/CD artifacts: paths変数を使用して、コンパイル済み出力をjob artifactとして保存します。

   • Mavenプロジェクトの場合、出力フォルダーは通常targetディレクトリです。
   • Gradleプロジェクトの場合、出力フォルダーは通常buildディレクトリです。
   • プロジェクトでカスタムの出力先を使用する場合は、それに応じてアーティファクトのパスを設定します。

2. spotbugs-sastジョブでCOMPILE: "false" CI/CD変数を設定して、自動コンパイルを無効にします。

3. dependenciesキーワードを設定して、spotbugs-sastジョブがコンパイルジョブに依存するようにします。これにより、spotbugs-sastジョブは、コンパイルジョブで作成されたアーティファクトをダウンロードして使用できるようになります。

次の例では、Gradleプロジェクトをプリコンパイルし、コンパイルされたバイトコードをアナライザーに提供します:

stages:
  - build
  - test

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

build:
  image: gradle:7.6-jdk8
  stage: build
  script:
    - gradle build
  artifacts:
    paths:
      - build/

spotbugs-sast:
  dependencies:
    - build
  variables:
    COMPILE: "false"
    SECURE_LOG_LEVEL: debug

依存関係を指定する（Mavenのみ）

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

プロジェクトで、アナライザーによって外部依存関係が認識される必要があり、Mavenを使用している場合は、MAVEN_REPO_PATH変数を使用してローカルリポジトリの場所を指定することができます。

依存関係の指定は、Mavenベースのプロジェクトでのみサポートされています。他のビルドツール（Gradleなど）には、依存関係を指定するための同等のメカニズムはありません。その場合は、コンパイルされたアーティファクトに必要なすべての依存関係が含まれていることを確認してください。

Mavenの依存関係を指定するには、プロジェクトの.gitlab-ci.ymlファイルに次の変更を加えます:

1. MAVEN_REPO_PATH変数を、ローカルのMavenリポジトリを指すように設定します。
2. ビルドジョブがそのパスにリポジトリを作成することを確認します（たとえば、mvn package -Dmaven.repo.local=./.m2/repositoryを実行して）。
3. spotbugs-sastジョブがビルドジョブに依存し、コンパイルを無効にするように設定します。

次の例では、Mavenプロジェクトをプリコンパイルし、コンパイルされたバイトコードを依存関係とともにアナライザーに提供します:

stages:
  - build
  - test

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

build:
  image: maven:3.6-jdk-8-slim
  stage: build
  script:
    - mvn package -Dmaven.repo.local=./.m2/repository
  artifacts:
    paths:
      - .m2/
      - target/

spotbugs-sast:
  dependencies:
    - build
  variables:
    MAVEN_REPO_PATH: $CI_PROJECT_DIR/.m2/repository
    COMPILE: "false"
    SECURE_LOG_LEVEL: debug

アナライザーが、スキャン中にプロジェクトの依存関係を認識するようになりました。

利用可能なCI/CD変数

SASTは、.gitlab-ci.ymlのvariablesパラメータを使用して設定できます。

GitLab SASTテンプレートを使用すると、すべての標準SAST設定CI/CD変数とカスタム変数が、基盤となるSASTアナライザーイメージに伝播されます。

次の例では、すべてのジョブでSEARCH_MAX_DEPTH変数を10にオーバーライドするために、SASTテンプレートを含めています。テンプレートはパイプライン設定の前に評価されるため、変数の最後の記述が優先されます。

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

variables:
  SEARCH_MAX_DEPTH: 10

カスタム認証局

カスタム認証局（CA）のサポートは、次のアナライザーバージョンで導入されました。

カスタム認証局を使用する

前提条件:

• プロジェクトのメンテナーまたはデベロッパーロール。

• X.509 PEM公開キー証明書のテキスト表現。

  次のいずれかの方法で証明書を提供できます:

  • プロジェクトの.gitlab-ci.ymlファイルに証明書を直接追加します。
  • 証明書へのパスを提供するfileCI/CD変数を作成します。
  • 証明書のテキスト表現を含むUIでカスタム変数を設定します。

カスタムCA証明書を信頼するには:

• SAST環境で信頼するCA証明書のバンドルにADDITIONAL_CA_CERT_BUNDLE変数を設定します。

たとえば、プロジェクトの.gitlab-ci.ymlファイルでこの値を構成するには、次のようにします:

variables:
  ADDITIONAL_CA_CERT_BUNDLE: |
      -----BEGIN CERTIFICATE-----
      MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
      ...
      jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
      -----END CERTIFICATE-----

Dockerイメージ

以下は、Dockerイメージ関連のCI/CD変数です。

脆弱性フィルター

SASTは、ファイルのパスと検索深度に基づいてコードを除外するように構成できます。次のCI/CD変数は、スキャンするファイルと、アナライザーがコードベースをどれだけ徹底的に検索するかを制御します。

脚注:

1. ビルドツールで使用される一時ディレクトリは、誤検出を引き起こす可能性があるため、除外しなければならない場合があります。パスを除外するには、デフォルトの除外パスをコピーして貼り付け、除外する独自のパスを追加します。デフォルトの除外パスを指定しない場合、デフォルト設定がオーバーライドされ、指定したパスのみがSASTスキャンから除外されます。

2. これらのアナライザーでは、SAST_EXCLUDED_PATHSがプリフィルターとして実装されており、スキャンの実行前に適用されます。

   アナライザーは、パスがカンマ区切りのパターンのいずれかに一致するファイルまたはディレクトリをスキップします。

   たとえば、SAST_EXCLUDED_PATHSが*.py,testsに設定されている場合:

   • *.pyは以下を無視します:
     • foo.py
     • src/foo.py
     • foo.py/bar.sh
   • testsは以下を無視します:
     • tests/foo.py
     • a/b/tests/c/foo.py

   各パターンは、gitignoreと同じ構文を使用するglobスタイルのパターンです。

3. これらのアナライザーでは、SAST_EXCLUDED_PATHSがポストフィルターとして実装されており、スキャンの実行後に適用されます。

   パターンには、glob（サポートされているパターンについてはdoublestar.Matchを参照）、またはファイルパスやフォルダーパス（doc,specなど）を使用できます。親ディレクトリもパターンに一致します。

   SAST_EXCLUDED_PATHSのポストフィルターとしての実装は、すべてのSASTアナライザーで使用できます。上付き文字2が付いたものなど、一部のSASTアナライザーでは、SAST_EXCLUDED_PATHSがプリフィルターとポストフィルターの両方として実装されています。スキャン対象のファイル数を減らせるため、プリフィルターのほうが効率的です。

   SAST_EXCLUDED_PATHSをプリフィルターとポストフィルターの両方としてサポートするアナライザーでは、最初にプリフィルターが適用され、次に、残りの脆弱性に対してポストフィルターが適用されます。

4. この変数では、パスパターンとしてglobを使用できます（サポートされているパターンについては、doublestar.Matchを参照してください）。パスパターンが、以下に示すサポート対象ビルドファイルと一致する場合、そのディレクトリはビルドプロセスから除外されます:

   • build.sbt
   • grailsw
   • gradlew
   • build.gradle
   • mvnw
   • pom.xml
   • build.xml

   たとえば、project/subdir/pom.xmlというパスのビルドファイルを含むmavenプロジェクトのビルドとスキャンを除外するには、project/*/*.xmlや**/*.xmlなど、そのビルドファイルに明示的に一致するglobパターン、またはproject/subdir/pom.xmlのような完全一致のパターンを渡します。

   projectやproject/subdirなど、パターンの親ディレクトリを渡しても、そのディレクトリはビルドから除外されません。この場合、ビルドファイルがパターンに明示的に一致していないためです。

5. SAST CI/CDテンプレートは、リポジトリを検索して使用されているプログラミング言語を検出し、一致するアナライザーを選択します。次に、各アナライザーがコードベースを検索し、スキャンする必要がある特定のファイルまたはディレクトリを見つけます。アナライザーの検索フェーズで、検索対象とするディレクトリ階層の数を指定するには、SEARCH_MAX_DEPTHの値を設定します。

アナライザーの設定

一部のアナライザーは、CI/CD変数を使用してカスタマイズできます。

セキュリティスキャナーの設定

SASTアナライザーは、内部的にOSSのセキュリティスキャナーを使用して分析を実行します。GitLabでは、これらのセキュリティスキャナーについては、推奨される設定をあらかじめ適用しているため、調整について心配する必要はありません。ただし、まれですが、デフォルトのスキャナー設定が要件に合わない場合があります。

スキャナーの動作をある程度カスタマイズできるようにするには、基になるスキャナーに制限付きのフラグセットを追加します。SAST_SCANNER_ALLOWED_CLI_OPTS CI/CD変数でフラグを指定します。指定されたフラグは、スキャナーのコマンドラインインターフェースオプションに追加されます。

分析対象からコードを除外する

コードの特定の行やブロックにマークを付けて、脆弱性の分析から除外できます。発見ごとにコメント注釈を追加する方法を使用する前に、すべての脆弱性を脆弱性管理で管理するか、SAST_EXCLUDED_PATHSを使用してスキャン対象のファイルパスを調整する必要があります。

Semgrepベースのアナライザーを使用する場合、次のオプションも使用できます:

• コードの1行を無視する - 行の末尾に// nosemgrep:コメントを追加します（コメントのプレフィックスは開発言語によって異なります）。

  Javaの例:

  vuln_func(); // nosemgrep

  Pythonの例:

  vuln_func(); # nosemgrep

• 特定のルールに対してコードの1行を無視する - 行の末尾に// nosemgrep: RULE_IDコメントを追加します（コメントのプレフィックスは開発言語によって異なります）。

• ファイルまたはディレクトリを無視する - リポジトリのルートディレクトリまたはプロジェクトの作業ディレクトリに.semgrepignoreファイルを作成し、ファイルやフォルダーのパターンを記述します。GitLab Semgrepアナライザーは、このカスタム.semgrepignoreファイルをGitLab組み込みの無視パターンと自動的にマージします。

詳細については、Semgrepのドキュメントを参照してください。

オフライン環境でSASTを実行する

インターネット経由で外部リソースへのアクセスが制限されている、または不安定な環境にあるインスタンスでは、SASTジョブを正常に実行するためにいくつかの調整が必要です。詳細については、オフライン環境を参照してください。

オフラインSASTの要件

オフライン環境でSASTを使用するには、以下が必要です:

• dockerまたはkubernetes executorを備えたGitLab Runner。詳細については、前提条件を参照してください。
• SASTアナライザーイメージのコピーをローカルに保持しているDockerコンテナレジストリ。
• パッケージの証明書チェックの設定（オプション）。

GitLab Runnerでは、デフォルトでpull_policyがalwaysになっています。つまり、ローカルコピーが利用可能な場合でも、RunnerはGitLabコンテナレジストリからDockerイメージをプルしようとします。オフライン環境ではローカルで利用可能なDockerイメージのみを使用する場合は、GitLab Runnerのpull_policyをif-not-presentに設定できます。ただし、オフライン環境にない場合は、プルポリシー設定をalwaysに維持してください。この設定により、CI/CDパイプラインで更新されたスキャナーを使用できるようになります。

Dockerレジストリ内でGitLab SASTアナライザーイメージを利用できるようにする

すべてのサポート対象言語とフレームワークでSASTを使用するには、次のデフォルトのSASTアナライザーイメージをregistry.gitlab.comからローカルのDockerコンテナレジストリにインポートします:

registry.gitlab.com/security-products/gitlab-advanced-sast:2
registry.gitlab.com/security-products/kubesec:6
registry.gitlab.com/security-products/pmd-apex:6
registry.gitlab.com/security-products/semgrep:6
registry.gitlab.com/security-products/sobelow:6
registry.gitlab.com/security-products/spotbugs:5

DockerイメージをローカルのオフラインDockerレジストリにインポートするプロセスは、ネットワークのセキュリティポリシーによって異なります。IT部門に相談して、外部リソースをインポートまたは一時的にアクセスするための承認済みプロセスを確認してください。これらのスキャナーは新しい定義で定期的に更新されています。また、自分で随時更新できる場合もあります。

Dockerイメージをファイルとして保存および転送する方法の詳細については、以下に関するDockerのドキュメントを参照してください:

• docker save
• docker load
• docker export
• docker import

ローカルSASTアナライザーを使用する

前提条件:

• プロジェクトのデベロッパー、メンテナー、またはオーナーのロール。

ローカルSASTアナライザーを使用するには:

• プロジェクトの.gitlab-ci.ymlファイルで、ローカルのDockerコンテナレジストリを参照するようにCI/CD変数SECURE_ANALYZERS_PREFIXを定義します。

例:

variables:
  SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"

この設定により、SASTジョブは、インターネットアクセスを必要とせずに、SASTアナライザーのローカルコピーを使用してコードをスキャンし、セキュリティレポートを生成できるようになります。

パッケージの証明書チェックを設定する

SASTジョブがパッケージマネージャーを実行する場合は、その証明書の検証を設定する必要があります。オフライン環境では、外部ソースを使用して証明書を検証することはできません。自己署名証明書を使用するか、証明書の検証を無効にします。手順については、パッケージマネージャーのドキュメントを参照してください。

SELinuxでSASTを実行する

デフォルトで、SASTアナライザーは、SELinuxでホストされているGitLabインスタンスでサポートされています。ただし、オーバーライドされたSASTジョブにbefore_scriptを追加すると、SELinuxでホストされているRunnerの権限が制限されているため、動作しない場合があります。