Infrastructure as Code (IaC)スキャン

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

Infrastructure as Code（IaC）スキャンはCI/CDパイプラインで実行され、既知の脆弱性についてインフラストラクチャの定義ファイルをチェックします。既定のブランチにコミット済みの脆弱性を特定することで、アプリケーションのリスクにプロアクティブに対処できます。

IaCスキャンアナライザーは、JSON形式のレポートをジョブアーティファクトとして出力します。

GitLab Ultimateでは、IaCスキャンの結果も処理されるため、次のことが可能です。

マージリクエストで確認できます。
承認ワークフローで結果を使用する。
脆弱性レポートで確認できます。

はじめに

IaCスキャンを初めて使用する場合は、次の手順に従って、プロジェクトのIaCスキャンをすばやく有効にできます。

前提要件:

IaCスキャンにはAMD64アーキテクチャが必要です。Microsoft Windowsはサポートされていません。
一貫したパフォーマンスを確保するには、最小4GBのRAMが必要です。
.gitlab-ci.ymlファイルにはtestステージが必要です。
GitLab Self-Managedでは、dockerまたはkubernetesexecutorを持つGitLabランナーが必要です。
GitLab.comでSaaS Runnerを使用している場合、これはデフォルトで有効になっています。

IaCスキャンを有効にするには：

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

テンプレートを使用:

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

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

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

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

動作例は、IaCスキャンのサンプルプロジェクトで確認できます。

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

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

結果について理解する

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

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

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

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

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

発見がフィーチャーブランチ上に生成されます。その発見がデフォルトブランチにマージされると、脆弱性になります。この区別は、セキュリティ対策状況を評価する上で重要です。

IaCスキャンの結果を確認するその他の方法：

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

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

IaCスキャンは、さまざまなIaC設定ファイルをサポートしています。KICSを使用して、サポートされている設定ファイルがプロジェクトで検出されると、スキャンされます。IaC設定ファイルが混在するプロジェクトもサポートされています。

サポートされている設定形式：

Ansible
AWS CloudFormation
Azure Resource Manager
IaCスキャンは、Azure Resource ManagerテンプレートをJSON形式で分析できます。Bicepでテンプレートを作成する場合は、IaCスキャンで分析する前に、Bicep CLIを使用してBicepファイルをJSONに変換する必要があります。
Dockerfile
Google Deployment Manager
Kubernetes
OpenAPI
Terraform
カスタムレジストリ内のTerraformモジュールは、脆弱性についてスキャンされません。提案されている機能の詳細については、issue 357004を参照してください。

最適化

プラン: Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

IaCスキャンは、以下によってカスタマイズできます。

すべてのファイルのルールを無効にする。
ファイルまたはルールのみのスキャンを無効にする。
ルールの属性をオーバーライドする。

ルールセットの定義

すべてのIaCスキャンルールは、rulesetルールセットセクションに含まれています。このセクションには、以下が含まれています。

ルールのtypeフィールド。IaCスキャンの場合、識別子のタイプはkics_idです。
ルール識別子のvalueフィールド。KICSルールの識別子は、英数字の文字列です。ルール識別子を見つける方法：
- JSONレポートアーティファクトで検索します。
- KICSクエリのリストでルール名を検索し、表示されている英数字の識別子をコピーします。ルール違反が検出されると、脆弱性の詳細ページにルール名が表示されます。

ルールを無効にする

特定のIaCスキャンルールを無効にできます。

アナライザールールを無効にするには：

まだ存在しない場合は、プロジェクトのルートに.gitlabディレクトリを作成します。
カスタムルールセットファイルsast-ruleset.tomlを.gitlabディレクトリに作成します（まだ存在しない場合）。
rulesetルールセットセクションのコンテキストで、disabledフラグをtrueに設定します。
1つ以上のrulesetサブセクションで、無効にするルールのリストを表示します。

sast-ruleset.tomlファイルをデフォルトブランチにマージすると、無効になっているルールに対する既存の発見が自動的に解決されます。

次の例sast-ruleset.tomlファイルでは、無効になっているルールは、識別子のtypeとvalueを照合することでkicsアナライザーに割り当てられます。

[kics]
  [[kics.ruleset]]
    disable = true
    [kics.ruleset.identifier]
      type = "kics_id"
      value = "8212e2d7-e683-49bc-bf78-d6799075c5a7"

  [[kics.ruleset]]
    disable = true
    [kics.ruleset.identifier]
      type = "kics_id"
      value = "b03a748a-542d-44f4-bb86-9199ab4fd2d5"

ファイルのスキャンを無効にする

ファイル全体のスキャン、またはルールのみのスキャンを無効にするには、そのファイルでKICS注釈を使用します。

この機能は、一部の種類のIaCファイルでのみ使用できます。サポートされているファイルタイプの一覧については、KICSドキュメントを参照してください。

ファイル全体のスキャンをスキップするには、ファイルの先頭に# kics-scan ignoreをコメントとして追加します。
ファイル全体の特定のルールを無効にするには、ファイルの先頭に# kics-scan disable=<kics_id>をコメントとして追加します。

ルールをオーバーライドする

特定のIaCスキャンルールをオーバーライドしてカスタマイズできます。たとえば、ルールの重大度を低く割り当てたり、発見の修正方法に関する独自のドキュメントにリンクしたりします。

ルールをオーバーライドするには：

まだ存在しない場合は、プロジェクトのルートに.gitlabディレクトリを作成します。
カスタムルールセットファイルsast-ruleset.tomlを.gitlabディレクトリに作成します（まだ存在しない場合）。
1つ以上のruleset.identifierサブセクションで、オーバーライドするルールのリストを表示します。
ruleset.overrideセクションのrulesetコンテキストで、オーバーライドするキーを指定します。任意にキーの組み合わせをオーバーライドできます。有効なキーは次のとおりです。
- 説明
- メッセージ
- 名前
- 重大度（有効なオプションは次のとおりです。クリティカル、高、中、低、不明、情報）

次の例sast-ruleset.tomlファイルでは、ルールは識別子のtypeとvalueによって照合され、オーバーライドされます。

[kics]
  [[kics.ruleset]]
    [kics.ruleset.identifier]
      type = "kics_id"
      value = "8212e2d7-e683-49bc-bf78-d6799075c5a7"
    [kics.ruleset.override]
      description = "OVERRIDDEN description"
      message = "OVERRIDDEN message"
      name = "OVERRIDDEN name"
      severity = "Info"

オフライン設定

プラン: Premium、Ultimate
提供形態: GitLab Self-Managed

オフライン環境では、インターネット経由での外部リソースへのアクセスが制限されているか、制限されているか、断続的です。このような環境のインスタンスでは、IaCに設定の変更が必要です。このセクションの手順は、オフライン環境で詳述されている手順と合わせて完了する必要があります。

GitLab Runnerを設定する

ランナーは、ローカルコピーが利用可能な場合でも、GitLabコンテナレジストリからDockerイメージをプルしようとします（プル）。Dockerイメージが最新の状態に保たれるように、このデフォルト設定を使用する必要があります。ただし、ネットワーク接続が利用できない場合は、デフォルトのGitLabランナーpull_policy変数を変更する必要があります。

GitLabランナー CI/CD変数CI/CD変数 pull_policyをif-not-presentに設定します。

ローカルIaCアナライザーイメージを使用する

GitLabコンテナレジストリの代わりに、ローカルのDockerレジストリからイメージを取得する場合は、ローカルのIaCアナライザーイメージを使用します。

前提要件:

DockerイメージをローカルのオフラインDockerレジストリにインポートするプロセスは、ネットワークのセキュリティポリシーによって異なります。IT部門に相談して、外部リソースをインポートまたは一時的にアクセスするための承認済みプロセスを確認してください。

registry.gitlab.comからデフォルトのIaCアナライザーイメージをローカルDockerコンテナレジストリにインポートします。
```
registry.gitlab.com/security-products/kics:5
```
IaCアナライザーのイメージは定期的に更新されるため、ローカルコピーを定期的に更新する必要があります。

CI/CD変数SECURE_ANALYZERS_PREFIXをローカルDockerコンテナレジストリに設定します。

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

variables:
  SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"

これで、IaCジョブは、インターネットアクセスを必要とせずに、アナライザーDockerイメージのローカルコピーを使用するはずです。

特定のアナライザーバージョンを使用する

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

特定のアナライザーバージョンを使用するには：

左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
左側のサイドバーで、ビルド > パイプラインエディタを選択します。
SAST-IaC.gitlab-ci.ymlテンプレートを含む行の後に、SAST_ANALYZER_IMAGE_TAG CI/CD変数CI/CD変数を追加します。
この変数は、特定のジョブ内でのみ設定してください。トップレベルで設定すると、設定したバージョンが他のSASTアナライザーにも使用されます。
タグを以下に設定します。
- メジャーバージョン（例: 3）: パイプラインは、このメジャーバージョン内でリリースされるマイナーまたはパッチアップデートを使用します。
- マイナーバージョン（例: 3.7）: パイプラインは、このマイナーバージョン内でリリースされるパッチアップデートを使用します。
- パッチバージョン（例: 3.7.0）: パイプラインはアップデートを受け取りません。

この例では、IaCアナライザーの特定のマイナーバージョンを使用しています。

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

kics-iac-sast:
  variables:
    SAST_ANALYZER_IMAGE_TAG: "3.1"

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

GitLabスキャナーには、サイズと保守性のために、ベースのalpineイメージが付属しています。

FIPS対応イメージ

GitLabは、標準イメージに加えて、FIPS対応のRed Hat UBIバージョンのスキャナーイメージを提供します。

パイプラインでFIPS対応イメージを使用するには、SAST_IMAGE_SUFFIXを-fipsに設定するか、標準タグに-fips拡張子を追加します。

次の例では、SAST_IMAGE_SUFFIX CI/CD変数CI/CD変数を使用しています。

variables:
  SAST_IMAGE_SUFFIX: '-fips'

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

脆弱性の自動修正

関連性の高い脆弱性に集中できるように、IaCスキャンは次の場合に脆弱性を自動的に解決します。

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

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

脆弱性管理システムは、脆弱性を自動的に解決すると、ノートを追加します。

JSON形式のレポート

IaCスキャナーは、既存のSASTレポート形式でJSONレポートファイルを出力します。詳細については、このレポートのスキーマを参照してください。

JSONレポートファイルは、以下からダウンロードできます。

CI/CDパイプラインCI/CDパイプライン
gl-sast-report.jsonにartifacts: pathsを設定することによる、マージリクエストのパイプラインタブ。

詳細については、アーティファクトのダウンロードを参照してください。

ロールアウトする

1つのプロジェクトでIaCスキャンの結果を検証したら、追加のプロジェクト全体で同じアプローチを実装できます。

スキャン実行の強制を使用して、グループ全体にIaCスキャン設定を適用します。
リモート設定ファイルを指定して、中央ルールセットを共有および再利用します。

トラブルシューティング

IaCスキャンを使用する場合、以下の問題が発生することがあります。

IaCスキャンの発見が予期せず`No longer detected`として表示される

以前に検出された発見が予期せずNo longer detectedとして表示される場合は、スキャナーの更新が原因である可能性があります。更新により、効果がないか誤検出であることが判明したルールが無効になる可能性があり、発見はNo longer detectedとしてマークされます。

ジョブログの`exec /bin/sh: exec format error`メッセージ

ジョブログにexec /bin/sh: exec format errorと表示されるエラーが表示される場合があります。この問題は、AMD64アーキテクチャ以外のアーキテクチャでIaCスキャンアナライザーを実行しようとすると発生します。IaCスキャンの前提要件の詳細については、前提要件を参照してください。