Infrastructure as Codeスキャン
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
Infrastructure as Code（IaC）スキャンはCI/CDパイプラインで実行され、既知の脆弱性がないかインフラストラクチャ定義ファイルをチェックします。アプリケーションへのリスクに事前に対処するために、デフォルトブランチにコミットされる前に脆弱性を特定します。
IaCスキャンアナライザーは、JSON形式のレポートをジョブアーティファクトとして出力します。
Ultimateでは、IaCスキャン結果も処理され、以下を行うことができます:
- マージリクエストで表示します。
- 承認ワークフローで結果を使用する。
- 脆弱性レポートで確認します。
はじめに
IaCスキャンを初めて使用する場合は、プロジェクトで有効にするには次の手順に従います。
前提条件:
- IaCスキャンにはAMD64アーキテクチャが必要です。Microsoft Windowsはサポートされていません。
- 一貫したパフォーマンスを確保するために、最小4 GBのRAM。
.gitlab-ci.ymlファイルにはtestステージが必要です。プロジェクトが独自のstagesリストを定義する場合は、testパイプラインステージが含まれていることを確認してください。- GitLab Self-Managedでは、GitLab Runnerに
dockerまたはkubernetesexecutorが必要です。 - 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スキャンジョブはすべてのパイプラインで実行され、KICSアナライザーを実行します。
- アナライザーは、プロジェクトにサポートされているIaCファイルが含まれているかどうかを判断します。
- サポートされているファイルが見つかった場合、アナライザーは脆弱性をスキャンします。
- サポートされているファイルが見つからない場合、ジョブは結果なしで完了します。
対応するジョブは、パイプラインのテストパイプラインステージの下に表示されます。
動作中の例は、IaCスキャン例プロジェクトで確認できます。
これらのステップを完了すると、次のことができるようになります。
結果について理解する
パイプラインの脆弱性を確認できます:
- 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 左側のサイドバーで、ビルド > パイプラインを選択します。
- パイプラインを選択します。
- セキュリティタブを選択します。
- 脆弱性を選択して、次の詳細を表示します:
- 説明: 脆弱性の原因、潜在的な影響、推奨される修正手順について説明しています。
- ステータス: 脆弱性がトリアージされたか、解決されたかを示します。
- 重大度: 重大度レベルの詳細はこちらをご覧ください。
- 場所: 問題が検出されたファイル名と行番号を示します。ファイルパスを選択すると、対応する行がコードビューで開きます。
- スキャナー: 脆弱性を検出したアナライザーを示します。
- 識別子: CWEの識別子やそれを検出したルールのIDなど、脆弱性の分類に使用される参照の一覧です。
セキュリティスキャンの結果をダウンロードすることもできます。
- パイプラインのセキュリティタブで、結果をダウンロードを選択します。
詳細については、パイプラインセキュリティレポートを参照してください。
IaCスキャン結果を確認する追加の方法:
- マージリクエストウィジェット: 新しく導入された、または解決された発見を示します。
- マージリクエストの変更ビュー: 変更された行のインライン注釈を示します。
- 脆弱性レポート: デフォルトブランチで確認された脆弱性を示します。
サポートされている言語とフレームワーク
IaCスキャンは、さまざまなIaC設定ファイルをサポートしています。プロジェクトでサポートされている設定ファイルが検出されると、KICSを使用してスキャンされます。複数のIaC設定ファイルが混在するプロジェクトもサポートされています。
サポートされている設定形式:
Ansible
AWS CloudFormation
Azure Resource Manager
Dockerfile
Google Deployment Manager
Kubernetes
OpenAPI
Terraform
最適化
- プラン: Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
ノイズを減らし、関連する結果に焦点を当てるために、IaCスキャンを最適化できます:
sast-ruleset.tomlファイルを使用して特定のルールを無効にします。sast-ruleset.tomlファイルを使用して、ルールの属性（重大度など）をオーバーライドします。- KICS注釈をファイルで使用して、特定のファイルのスキャンを無効にします。
sast-ruleset.tomlファイルを使用して、ルールを無効にするか、ルールの属性をオーバーライドします。このアプローチにより、以下が提供されます:
- ルールが無効になっている場合に既存の検出結果を自動的に解決するためのGitLab脆弱性管理とのインテグレーション。
- バージョン管理されたセキュリティポリシーの決定に関するドキュメント。
- IaCスキャンをロールアウトする際に、複数のプロジェクトでルールセットを共有する機能。
ルールセットの定義
すべてのIaCスキャンルールはrulesetセクションに含まれ、以下を含みます:
- ルールの
typeフィールド。IaCスキャンの場合、識別子タイプはkics_idです。 - ルール識別子の
valueフィールド。KICSルール識別子は英数字文字列です。ルール識別子を見つけるには:- JSONレポートアーティファクトで探します。
- KICSクエリリストでルール名を検索し、表示されている英数字の識別子をコピーします。ルール違反が検出されると、ルール名は脆弱性の詳細ページに表示されます。
ルールを無効にする
特定のIaCスキャンルールを無効にできます。無効化されたルールによって以前に検出された結果は、自動的に解決されます。
アナライザールールを無効にするには:
- まだ存在しない場合は、プロジェクトのルートに
.gitlabディレクトリを作成します。 - まだ存在しない場合は、
.gitlabディレクトリにsast-ruleset.tomlという名前のカスタムルールセットファイルを作成します。 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ディレクトリを作成します。 - まだ存在しない場合は、
.gitlabディレクトリにsast-ruleset.tomlという名前のカスタムルールセットファイルを作成します。 - 1つ以上の
ruleset.identifierサブセクションで、オーバーライドするルールをリストします。 rulesetセクションのruleset.overrideコンテキストで、オーバーライドするキーを指定します。キーの任意の組み合わせをオーバーライドできます。有効なキー:- description
- message
- name
- 重大度（有効なオプション: Critical、High、Medium、Low、Unknown、Info）
次の例の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を設定する
デフォルトでは、Runnerはローカルコピーが利用可能な場合でも、GitLabコンテナレジストリからDockerイメージをプルしようとします。Dockerイメージが最新の状態に保たれるように、このデフォルト設定を使用する必要があります。ただし、ネットワーク接続が利用できない場合は、デフォルトのGitLab Runner pull_policy変数を変更する必要があります。
GitLab RunnerCI/CD変数pull_policyをif-not-presentに設定します。
ローカルIaCアナライザーイメージを使用する
GitLabコンテナレジストリではなく、ローカルDockerレジストリからイメージを取得したい場合は、ローカルIaCアナライザーイメージを使用します。
前提条件:
- DockerイメージをローカルのオフラインDockerレジストリにインポートするかどうかは、ネットワークセキュリティポリシーによって異なります。外部リソースをインポートまたは一時的にアクセスするための承認されたプロセスを見つけるためにITスタッフに相談してください。
デフォルトのIaCアナライザーイメージを
registry.gitlab.comからローカルDockerコンテナレジストリにインポートします:registry.gitlab.com/security-products/kics:6IaCアナライザーのイメージは定期的に更新されるため、ローカルコピーも定期的に更新する必要があります。
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_TAGCI/CD変数を追加します。タグを以下に設定します:
- メジャーバージョン（例:
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_SUFFIXCI/CD変数を使用します。
variables:
SAST_IMAGE_SUFFIX: '-fips'
include:
- template: Jobs/SAST-IaC.gitlab-ci.yml脆弱性の自動修正
まだ関連性の高い脆弱性に焦点を当てるのに役立つように、IaCスキャンは次の場合に脆弱性を自動的に解決します:
- 定義済みルールを無効にする場合
- デフォルトのルールセットからルールを削除する場合
後でルールを再度有効にすると、トリアージのために検出結果が再度オープンされます。
脆弱性管理システムは、自動的に脆弱性を解決するときにメモを追加します。
JSON形式のレポート
IaCスキャナーは、既存のSASTレポート形式でJSONレポートファイルを出力します。詳細については、このレポートのスキーマを参照してください。
JSONレポートファイルは以下からダウンロードできます:
- CI/CDパイプラインページ。
- マージリクエストのパイプラインタブで、
artifacts: pathsの設定はgl-sast-report.jsonとなります。
詳細については、アーティファクトのダウンロードを参照してください。
ロールアウトする
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スキャンの前提条件の詳細については、前提条件を参照してください。