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

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

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

機能

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

はじめに

SASTを初めて使用する場合は、次の手順に従ってプロジェクトのSASTを有効にする方法を確認してください。

前提要件:

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

SASTを有効にするには、次の手順に従います:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. プロジェクトにまだ.gitlab-ci.ymlファイルがない場合は、ルートディレクトリに作成します。
3. .gitlab-ci.ymlファイルの先頭に、次のいずれかの行を追加します:

テンプレートを使用:

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

または、CIコンポーネントを使用:

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

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

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

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

その他の設定方法の詳細については、設定を参照してください。

結果を把握する

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

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

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

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

• パイプラインのセキュリティタブで、結果をダウンロードを選択します。

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

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

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

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

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

脚注:

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

標準アナライザーのみをサポートする言語

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

脚注:

1. すべての階層。特に指定がない限り、SemgrepアナライザーとGitLab管理ルールを使用します。
2. 参照されているエピックは、これらの言語に対する高度なSASTのサポートを提案しています。
3. SpotBugs（find-sec-bugsプラグインを使用）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は、高度な脆弱性追跡アルゴリズムを使用して、同じ脆弱性がリファクタリングまたは無関係な変更によってファイル内で移動した場合、より正確に特定します。

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

より多くの言語とアナライザーのサポートが、エピック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レポートファイルの例

設定

SASTスキャンは、CI/CDパイプラインで実行されます。GitLab管理のCI/CDテンプレートをパイプラインに追加すると、適切なアナライザーが自動的にコードをスキャンし、結果をSASTレポートアーティファクトとして保存します。

プロジェクトのSASTを設定するには、次のいずれかの方法があります:

• Auto DevOpsによって提供される自動SASTを使用する。
• CI/CD YAMLでSASTを設定する。
• UIを使用してSASTを設定する。

スキャン実行を強制することで、多くのプロジェクトにわたってSASTを有効にできます。

高度なSASTを設定する方法（GitLab Ultimateでのみ利用可能）については、GitLab Advanced SASTを参照してください。

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

CI/CD YAMLでSASTを設定する

SASTを有効にするには、SAST.gitlab-ci.ymlテンプレートを含めます。このテンプレートは、GitLabインストールの一部として提供されます。

次の内容をコピーして、.gitlab-ci.ymlファイルの末尾に貼り付けます。include行がすでに存在する場合は、その下にtemplate行のみを追加します。

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

ここで含めたテンプレートは、CI/CDパイプラインにSASTジョブを作成し、プロジェクトのソースコードをスキャンして潜在的な脆弱性を検出します。

結果はSASTレポートアーティファクトとして保存され、後でダウンロードして分析することができます。ダウンロードすると、常に最新のSASTアーティファクトを入手できます。

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

SASTには、セキュリティテストをCI/CDパイプラインに組み込むためのテンプレートが2つ用意されています:

• SAST.gitlab-ci.yml（推奨）

  安定版テンプレートは、信頼性が高く一貫性のあるSASTエクスペリエンスを提供します。CI/CDパイプラインで安定性と予測可能な動作を必要とするほとんどのユーザーおよびプロジェクトでは、安定版テンプレートを使用する必要があります。

• SAST.latest.gitlab-ci.yml

  このテンプレートは、最先端の機能にアクセスしてテストしたい方を対象としています。安定版とは見なされておらず、次のメジャーリリースで計画されている破壊的な変更が含まれている可能性があります。このテンプレートを使用すると、安定版リリースに組み込まれる前に新機能やアップデートを試すことができるため、潜在的な不安定さをいとわず、新機能に関するフィードバックを積極的に提供したい方に最適です。

UIを使用してSASTを設定する

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

カスタマイズしてSASTを設定する

カスタマイズしてSASTを有効化および設定するには:

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

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

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

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

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

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

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

これで、パイプラインにSASTジョブが含まれます。

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

デフォルト設定でSASTを有効化および設定するには:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. セキュリティ > セキュリティ設定を選択します。
3. SASTセクションでマージリクエスト経由で設定を選択します。
4. マージリクエストをレビューしてマージし、SASTを有効にします。

これで、パイプラインにSASTジョブが含まれます。

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

ジョブ定義をオーバーライドする（variables、dependencies、rulesのようなプロパティを変更する場合など）には、オーバーライドするSASTジョブと同じ名前でジョブを宣言します。テンプレートの挿入後にこの新しいジョブを配置し、その下に追加のキーを指定します。たとえば、次の設定により、spotbugsアナライザーに対してFAIL_NEVERを有効にすることができます:

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

spotbugs-sast:
  variables:
    FAIL_NEVER: 1

マイナーイメージバージョンにピン留めする

GitLab管理のCI/CDテンプレートは、メジャーバージョンを指定し、そのメジャーバージョン内の最新のアナライザーリリースを自動的にプルします。

場合によっては、特定のバージョンを使用しなければならないことがあります。たとえば、後のリリースで発生したリグレッションを回避する必要がある場合などです。

自動更新の動作をオーバーライドするには、SAST.gitlab-ci.ymlテンプレートを含めた後、SAST_ANALYZER_IMAGE_TAG CI/CD変数をCI/CD設定ファイルで設定します。

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

タグには次のいずれかを設定できます:

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

次の例では、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ベースのアナライザーをカスタマイズして、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プロジェクト用にコンパイルされたバイトコードをスキャンします。デフォルトでは、依存関係のフェッチとコードのコンパイルを自動的に試行し、スキャンできるようにします。

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

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

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

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

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

   • 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プロジェクトをプリコンパイルし、コンパイルされたバイトコードを依存関係とともにアナライザーに提供します:

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変数

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

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

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

variables:
  SEARCH_MAX_DEPTH: 10

カスタム認証局

カスタム認証局を信頼するには、SAST環境で信頼するCA証明書のバンドルをADDITIONAL_CA_CERT_BUNDLE変数に設定します。ADDITIONAL_CA_CERT_BUNDLEの値には、X.509 PEM公開キー証明書のテキスト表現が含まれている必要があります。たとえば、.gitlab-ci.ymlファイルでこの値を設定するには、以下のように記述します:

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

ADDITIONAL_CA_CERT_BUNDLEの値は、UIでカスタム変数として設定することもできます。fileとして設定する場合は証明書のパスを、変数として設定する場合は証明書のテキスト表現を指定します。

Dockerイメージ

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

脆弱性フィルター

脚注:

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

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

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

   たとえば、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がpost-filter（ポストフィルター）として実装されており、スキャンの実行後に適用されます。

   パターンには、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のセキュリティスキャナーを使用して分析を実行します。これらのセキュリティスキャナーについては、推奨される設定をあらかじめ適用しているため、調整について心配する必要はありません。ただし、まれですが、デフォルトのスキャナー設定が要件に合わない場合があります。

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

カスタムCI/CD変数

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

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

コードの特定の行やブロックにマークを付けて、脆弱性の分析から除外できます。発見ごとにコメント注釈を追加する方法を使用する前に、すべての脆弱性を脆弱性管理で管理するか、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アナライザーイメージを利用できるようにする

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

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

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

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

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

カスタム認証局のサポートが必要な場合

次のバージョンで、カスタム認証局のサポートが導入されました。

ローカルのSASTアナライザーを使用するようにSAST CI/CD変数を設定する

次の設定を.gitlab-ci.ymlファイルに追加します。ローカルのDockerコンテナレジストリを参照するように、SECURE_ANALYZERS_PREFIXを置き換える必要があります:

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

variables:
  SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"

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

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

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

SELinuxでSASTを実行する

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