アプリケーションセキュリティ

GitLabはアプリケーションのセキュリティ脆弱性をチェックすることができます:

  • 不正アクセス
  • データ漏洩
  • サービス拒否(DoS)攻撃。

GitLabアプリケーションセキュリティの概要については、Shifting Security Leftを参照してください。

脆弱性に関する統計や詳細はマージリクエストに含まれます。変更がマージされる_前に_アクション可能な情報を提供することで、先手を打つことができます。

脆弱性の管理とアドレスの作業を支援するために、GitLabはプロジェクトやグループからアクセスできるセキュリティダッシュボードを提供しています。詳しくは、セキュリティダッシュボードをご覧ください。

アプリケーションカバレッジ

GitLabは、CI/CDパイプラインの一部として、またはスケジュールに基づいて、アプリケーションの様々な詳細を分析します。カバレッジには以下が含まれます:

  • ソースコード
  • プロジェクトやコンテナイメージの依存関係。
  • 実行中のウェブアプリケーションの脆弱性。
  • コード設定としてのインフラ。

GitLabアプリケーションセキュリティツールのそれぞれは、機能開発ワークフローの特定のステージに関連しています。

  • コミット
    • SAST
    • 機密情報の検出
    • IaCスキャン
    • 依存関係の脆弱性スキャン
    • ライセンススキャン
    • カバレッジガイドファズテスト
  • ビルド
    • コンテナの脆弱性スキャン
  • テスト
    • APIセキュリティ
    • DAST
  • デプロイ
    • オペレーションコンテナのスキャン

CI/CD stages and matching GitLab application security tools

ソースコード解析

ソースコード解析はすべてのコードコミットで行われます。検出された脆弱性の詳細はマージリクエストで提供されます。

ソースコード解析には以下のようなものがあります:

実行中のウェブアプリケーションの分析

Webアプリケーションの分析は、すべてのコードコミットで行われます。CI/CD パイプラインの一部として、アプリケーションはビルドされ、テスト環境にデプロイされ、次のテストにさらされます:

依存関係の分析

依存関係の解析は、すべてのコードコミットで行われます。アプリケーションの依存関係を照合し、既知の脆弱性のデータベースと照合します。

依存性分析は実行できます:

詳細は、コンテナスキャンと比較した依存関係スキャンを参照してください。

さらに、オペレーションコンテナイメージの依存関係を、定期的なスケジュールまたはケイデンスで脆弱性を分析できます。詳細については、「オペレーションコンテナスキャン」を参照してください。

インフラストラクチャ分析

アプリケーションのインフラストラクチャは潜在的な脆弱性の源です。これを防御するために、インフラストラクチャ解析はすべてのマージリクエストで行われます。チェックは以下に対して実行されます:

脆弱性スキャナーのメンテナンス

以下の脆弱性スキャナとそのデータベースは定期的に更新されています:

セキュリティスキャンツール脆弱性データベースの更新
コンテナスキャンアップストリームスキャナーからの最新の脆弱性データベース更新を使用して新しいイメージをビルドするジョブが毎日実行されます。GitLabは、データベースが48時間以上古くなったときにエンジニアリングチームに通知する内部アラートを通してこのジョブを監視しています。詳しくは脆弱性データベースの更新をご覧ください。
依存関係スキャン GitLab Advisory Database に依存しています。NVD、ruby-advisory-db 、GitHub Advisory Database のデータをデータソースとして毎日更新されますCVE がイシューされてから製品が更新されるまでの時間については、現在の計測結果をご覧ください。
動的アプリケーション・セキュリティ・テスト(DAST)スキャンエンジンは定期的に更新されます。基礎となるツールのバージョンzaproxy を参照してください。スキャンルールはスキャン実行時にダウンロードされます。
シークレット検出GitLabは検出ルールをメンテナーし、コミュニティからの貢献を受け入れています。スキャンエンジンは、関連するアップデートが利用可能な場合、少なくとも月に1回更新されます。
静的アプリケーションセキュリティテスト(SAST)スキャンルールのソースは、サポートされているプログラミング言語ごとにどのアナライザーを使うかによって異なります。GitLab は Semgrep ベースのアナライザ用のルールセットをメンテナーし、内部調査とユーザーからのフィードバックに基づいて定期的に更新しています。他のアナライザでは、ルールセットはアップストリームのオープンソーススキャナから取得します。各アナライザーは、関連するアップデートがある場合、少なくとも月に1回は更新されます。

同じメジャーバージョンのアナライザを使用しているGitLabのバージョンでは、最新の脆弱性定義の恩恵を受けるためにアナライザをアップデートする必要はありません。セキュリティツールはDockerイメージとしてリリースされます。これらを有効にするベンダージョブ定義は、セマンティックバージョニングに従ってメジャーリリースタグを使用します。各ツールの新しいリリースは、これらのタグを上書きします。主要なアナライザのバージョンでは、スキャンツールの最新バージョンを自動的に取得しますが、このアプローチにはいくつかの既知のイシューがあります。

Auto DevOpsによるセキュリティスキャン

GitLabセキュリティスキャンツールをデフォルト設定ですべて有効にするには、AutoDevOpsを有効にします:

Auto DevOps を直接カスタマイズすることはできませんが、プロジェクトの.gitlab-ci.yml ファイル に Auto DevOps テンプレートを含めることができます。

Auto DevOpsを使用しないセキュリティスキャン

すべてのGitLabセキュリティスキャンツールを設定をカスタマイズするオプション付きで有効にするには、GitLab CI/CDテンプレートを.gitlab-ci.yml ファイルに追加してください。

caution
GitLab セキュリティスキャンツールのすべてのカスタマイズは、デフォルトブランチに変更をマージする前にマージリクエストでテストしてください。これを怠ると、多数の偽陽性を含む予期しない結果をもたらす可能性があります。

静的アプリケーションセキュリティテスト、依存関係スキャン、ライセンススキャン、秘密検出を有効にするには、以下を追加してください:

include:
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Security/License-Scanning.gitlab-ci.yml
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Secret-Detection.gitlab-ci.yml

Dynamic Application Security Testing(DAST) スキャンを有効にするには、以下を.gitlab-ci.yml に追加してください。https://staging.example.com をステージングサーバのウェブアドレスに置き換えてください:

include:
  - template: Security/DAST.gitlab-ci.yml

variables:
  DAST_WEBSITE: https://staging.example.com

デフォルトのレジストリベースアドレスを上書きします。

デフォルトでは、GitLabセキュリティスキャナはDockerイメージのベースアドレスとしてregistry.gitlab.com/security-products 。CI/CD 変数SECURE_ANALYZERS_PREFIX を別の場所に設定することで、ほとんどのスキャナでこれを上書きすることができます。これはすべてのスキャナーに一度に影響します。

コンテナスキャニングアナライザは例外で、SECURE_ANALYZERS_PREFIX 変数を使用しません。Dockerイメージを上書きするには、オフライン環境でコンテナスキャンを実行する手順を参照してください。

マージリクエストパイプラインでのセキュリティスキャンツールの使用

デフォルトでは、アプリケーションセキュリティジョブはブランチパイプラインに対してのみ実行される設定になっています。マージリクエストパイプラインで使用するには、latest テンプレートを参照する必要があります。

すべてのlatest セキュリティテンプレートはマージリクエストパイプラインをサポートしています。

例えば、SAST と依存関係スキャンの両方を実行するには、以下のテンプレートを使用します:

include:
  - template: Jobs/Dependency-Scanning.latest.gitlab-ci.yml
  - template: Jobs/SAST.latest.gitlab-ci.yml
note
lateststable のセキュリティテンプレートを混在させると、MRパイプラインとブランチパイプラインの両方が実行される可能性があります。すべてのセキュリティスキャナにlatest またはstable を選択することを推奨します。
note
最新のテンプレートは、どのリリースでも変更される可能性があります。

GitLabセキュリティスキャンツールのデフォルトの動作

パイプラインのセキュリティジョブ

Auto DevOps を使用したセキュリティスキャニング、または、Auto DevOps を使用しないセキュリティスキャニングで説明したように、セキュリティスキャニングジョブを.gitlab-ci.yml に追加した場合、追加したセキュリティスキャニングツールは、それぞれ以下のように動作します。

互換性のある各分析器について、パイプラインのtestdast またはfuzz ステージでジョブが作成され、次の新しいブランチパイプラインで実行されます。このスキャンデータに依存するセキュリティダッシュボード脆弱性レポート依存関係リストなどの機能は、手動も含めてすべてのジョブが終了した場合にのみ、デフォルトブランチ上のパイプラインからの結果のみを表示します。1つのツールで多くのアナライザを使用することがあります。

私たちの言語やパッケージマネージャに特化したジョブは、あなたのプロジェクトでどのアナライザを実行すべきかを評価しようとするため、設定を少なくすることができます。

パイプラインの速度を上げるためにこれを上書きしたい場合は、特定のツールの変数カスタマイズの指示に従って、該当しない (プロジェクトに含まれていない言語やパッケージマネージャ) 分析器を除外するように選択できます。

ジョブステータスの確保

ジョブがスキャンを完了できれば合格です。_合格の_結果は、発見を特定できたかできなかったかを示しません。唯一の例外はカバレッジファジングです。

スキャンを完了できなかった場合、ジョブは失敗します。詳細はパイプラインログをご覧ください。

すべてのジョブはデフォルトで失敗することが許可されています。つまり、失敗してもパイプラインは失敗しません。

脆弱性がマージされるのを防ぎたい場合、マージリクエストにセキュリティ承認者を追加することで、選択した特定のグループからの承認なしに、未知の、高い、または重大な発見がマージされるのを防ぐことができます。

パイプライン全体が失敗するので、ジョブallow_failure 設定 を変更することは推奨しません。

JSONアーティファクト

セキュアアナライザーが生成するアーティファクトには、対象のブランチで発見したすべての情報が含まれます。それが以前に発見されたものであるか、却下されたものであるか、あるいはまったく新しいものであるかにかかわらず、です (発見したすべての情報が含まれます)。

マージリクエストのセキュリティスキャン情報の表示

全ての階層

セキュリティ スキャンを実行したマージ リクエストは、生成されたレポートがダウンロード可能であることを通知します。レポートをダウンロードするには、結果のダウンロードを選択し、必要なレポートを選択します。

Security widget

セキュリティ スキャンはCIartifacts:reports タイプ のうち少なくとも 1 つを生成します:

  • artifacts:reports:api_fuzzing
  • artifacts:reports:container_scanning
  • artifacts:reports:coverage_fuzzing
  • artifacts:reports:dast
  • artifacts:reports:dependency_scanning
  • artifacts:reports:sast
  • artifacts:reports:secret_detection

究極

マージリクエストには、_新しい_結果の概要を表示するセキュリティウィジェットが含まれています。新しい結果は、機能ブランチがターゲットブランチから作成されたときのコミットについて、マージリクエストの結果を最新の完了したパイプライン (success,failed,canceled またはskipped) の結果と比較することで決定されます。

機能ブランチが作成された時点で、対象ブランチの完了したパイプラインに対してセキュリ ティスキャンが実行されていなければ、比較の基準はありません。マージリクエストで発見された脆弱性は、マージリクエストセキュリティウィジェットに新しいものとして表示されます。開発者のために機能ブランチのスキャンを有効にする前に、default (ターゲット) ブランチのスキャンを実行することをお勧めします。

マージリクエストセキュリティウィジェットには、新しい発見と既存の発見の両方が含まれているため、生成された JSON アーティファクトの脆弱性のサブセットのみが表示されます。

マージリクエストセキュリティウィジェットから、[展開] を選択してウィジェットを展開し、スキャンの種類別に新しい検出結果および検出されなくなった(削除された)検出結果を表示します。

各セキュリティ・レポート・タイプについて、追加された最初の 25 個と修正された 25 個の所見が、重大度順にウィジェットに表示されます。すべての検査結果を表示するには、[レポート全体を表示]を選択して、最新のブランチパイプラインの[セキュリティ]タブに直接移動します。

Security scanning results in a merge request

パイプラインの「セキュリティ」タブでセキュリティスキャン情報を表示

パイプラインのセキュリティタブには、現在のブランチで検出されたすべての検査結果が表示されます。これには、このブランチで新たに発見されたものと、ブランチを作成したときにすでに存在していた既存の脆弱性が含まれます。マージリクエストセキュリティウィジェットには既存の脆弱性が含まれていないため、これらの結果はマージリクエストセキュリティウィジェットに表示される調査結果とは一致しない可能性があります。詳細については、パイプライン内の脆弱性の表示を参照してください。

セキュリティ ダッシュボードでのセキュリティ スキャン情報の表示

セキュリティダッシュボードは、プロジェクトのデフォルトブランチに存在する脆弱性を表示します。データは 24 時間ごとに更新されます。デフォルトにマージされた、新しい脆弱性を導入する機能ブランチの結果としての脆弱性数の更新は、毎日更新されるデータの後に含まれます。

詳細については、セキュリティダッシュボードを参照してください。

脆弱性レポートでセキュリティスキャン情報を見る

脆弱性レポートには、デフォルトブランチで最後に完了したパイプラインの結果が表示されます。パイプラインが完了するたびに更新されます。検出されたすべての脆弱性と、最新のスキャンで検出されなくなった以前の脆弱性が表示されます。検出されなくなった脆弱性は、修復またはその他の方法で削除されている可能性があり、適切な検証後にResolved としてマークできます。検出されなくなった脆弱性には、フィルタリングとレビューのためのアイコンが表示されます。

デフォルトでは、脆弱性レポートには、dismissed またはresolved ステータスの脆弱性は表示されないため、オープンな脆弱性に集中することができます。ステータスのフィルタを変更することで、これらを表示することができます。

脆弱性レポートについてもっと読む.

VS Codeの拡張機能でセキュリティスキャン情報を見る

GitLab Workflow VS Code extensionを使って、マージリクエストと同じようにVisual Studio Code(VS Code)で直接セキュリティ検査結果を確認できるようになりました。

詳細は拡張機能のページをご覧ください。

マージリクエストでのセキュリティ承認者

  • GitLab 12.2で導入されました
  • GitLab 15.0で脆弱性チェック機能を削除しました。
  • GitLab 16.0でライセンスチェック機能を削除しました。

以下のセキュリティ問題のいずれかを引き起こすようなマージリクエストに対して、追加の承認者を強制することができます:

  • セキュリティ脆弱性。詳細については、スキャン結果ポリシーを参照してください。

非公開Mavenリポジトリの使用

ログイン認証情報を必要とする非公開の Apache Maven リポジトリがある場合、MAVEN_CLI_OPTS CI/CD 変数を使用してユーザー名とパスワードを渡すことができます。.gitlab-ci.yml で認証情報が公開されないように、プロジェクトの設定で設定できます。

ユーザー名がmyuser でパスワードがverysecret の場合、プロジェクトの設定で以下の変数を設定します:

種類キー
変数MAVEN_CLI_OPTS--settings mysettings.xml -Drepository.password=verysecret -Drepository.user=myuser
<!-- mysettings.xml -->
<settings>
    ...
    <servers>
        <server>
            <id>private_server</id>
            <username>${private.username}</username>
            <password>${private.password}</password>
        </server>
    </servers>
</settings>

カスタムスキャンステージの使用

自動 DevOps を使用しないセキュリティスキャンのセクションで説明したように、CI/CD テンプレートを含めることでセキュリティスキャンが有効になっている場合、スキャンジョブはデフォルトで定義済みのtest ステージを使用します。test ステージを含めずに.gitlab-ci.yml ファイルにカスタムステージを指定すると、エラーが発生します。

たとえば、以下はunit-tests ステージを使用しようとしています:

include:
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Security/License-Scanning.gitlab-ci.yml
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Secret-Detection.gitlab-ci.yml

stages:
  - unit-tests

custom job:
  stage: unit-tests
  script:
    - echo "custom job"

上記の.gitlab-ci.yml 、リンティングエラーが発生します:

Unable to create pipeline
- dependency_scanning job: chosen stage does not exist; available stages are .pre
- unit-tests
- .post

このエラーは、セキュリティスキャンジョブで使用されるtest ステージが.gitlab-ci.yml ファイルで宣言されていないために発生します。このイシューを修正するには、以下のいずれかを実行してください:

  • .gitlab-ci.ymltest ステージを追加します:

     include:
       - template: Security/Dependency-Scanning.gitlab-ci.yml
       - template: Security/License-Scanning.gitlab-ci.yml
       - template: Security/SAST.gitlab-ci.yml
       - template: Security/Secret-Detection.gitlab-ci.yml
       
     stages:
       - test
       - unit-tests
       
     custom job:
       stage: unit-tests
       script:
         - echo "custom job"
    
  • 各セキュリティジョブのデフォルトステージを上書きしてください。例えば、unit-tests というあらかじめ定義されたステージを使用する場合:

     include:
       - template: Security/Dependency-Scanning.gitlab-ci.yml
       - template: Security/License-Scanning.gitlab-ci.yml
       - template: Security/SAST.gitlab-ci.yml
       - template: Security/Secret-Detection.gitlab-ci.yml
       
     stages:
       - unit-tests
       
     dependency_scanning:
       stage: unit-tests
       
     license_scanning:
       stage: unit-tests
       
     sast:
       stage: unit-tests
       
     .secret-analyzer:
       stage: unit-tests
       
     custom job:
       stage: unit-tests
       script:
         - echo "custom job"
    

セキュリティ・ジョブの上書きに関する詳細は、以下を参照してください:

すべてのセキュリティスキャンツールはステージを定義しているため、このエラーはすべてのツールで発生する可能性があります。

自己管理インストールオプション

セルフマネージドインストールでは、インターネットに接続されていない状態でもGitLabセキュリティスキャナのほとんどを実行することができます。

セルフマネージドインストールでは、OpenShift内で稼働しているGitLab Runner上でセキュリティスキャナを実行することもできます。

セキュリティレポートの検証

GitLab 15.0では、脆弱性を取り込む前にセキュリティレポートのアーティファクトのバリデーションを実施します。これにより、壊れた脆弱性データをデータベースに取り込むことを防ぎます。GitLab は、レポートで宣言されたスキーマのバージョンに従って、レポートのスキーマに対してアーティファクトを検証します。

パイプラインの [セキュリティ] タブには、検証に失敗したレポート アーティファクトと検証エラー メッセージが一覧表示されます。

検証は、セキュリティ・レポート・アーティファクトで宣言されたスキーマ・バージョンに依存します:

  • セキュリティレポートでサポートされているスキーマのバージョンが指定されている場合、GitLab はこのバージョンを使ってバリデーションを行います。
  • セキュリティレポートが非推奨のバージョンを使っている場合、GitLabはそのバージョンに対してバリデーションを試み、バリデーション結果に非推奨の警告を追加します。
  • もしあなたのセキュリティレポートがレポートスキーマのサポートされたMAJOR-MINORバージョンを使っていて、PATCHバージョンがどのベンダードバージョンとも一致しない場合、GitLabはスキーマの最新のベンダードPATCHバージョンに対して検証を試みます。
    • 例:セキュリティレポートはバージョン14.1.1を使用していますが、最新のベンダードバージョンは14.1.0です。GitLabはスキーマのバージョン14.1.0に対してバリデーションを行います。
  • セキュリティレポートがサポートされていないバージョンを使用している場合、GitLabはインストールで利用可能な最新のスキーマバージョンに対して検証を試みますが、レポートを取り込みません。
  • セキュリティレポートがスキーマバージョンを指定していない場合、GitLabはGitLabで利用可能な最新のスキーマバージョンに対してバリデーションを試みます。version プロパティは必須であるため、この場合バリデーションは常に失敗しますが、他のバリデーションエラーも発生する可能性があります。

サポートされているスキーマのバージョンと非推奨のスキーマのバージョンは、ソースコードでいつでも確認できます。

発見や脆弱性との対話

セキュリティスキャンツールの結果は、いくつかの場所で参照できます:

それぞれの場所で表示できる調査結果や脆弱性の詳細については、それぞれのリンクを選択してください。各ページでは、調査結果や脆弱性と対話する方法について詳しく説明しています。例として、ほとんどの場合、調査結果は_検出された_ステータスで始まります。

以下のオプションがあります:

  • ステータスを変更します。
  • イシューを作成します。
  • 既存のイシューにリンクします。
  • 解決策がわかっている場合は、脆弱性を解決してください。

セキュリティスキャン設定のヒント

各 GitLab セキュリティスキャンツールには、デフォルトのCI/CD 設定ファイルがあり、_テンプレートとしても_知られています。

設定をカスタマイズする場合:

  • スキャンツールのCI/CDテンプレートを含めてください。テンプレートの内容は_コピー_しないでください。
  • 本番ワークフローには各テンプレートの安定版を使いましょう。安定バージョンは変更頻度が低く、GitLabのメジャーバージョン間でのみブレークチェンジが行われます。最新版には最新の変更がコンテナされていますが、GitLabのマイナーバージョン間で大きな変更があるかもしれません。
  • テンプレートの値は必要なときだけオーバーライドしてください。それ以外の値はテンプレートから継承されます。

スキャン実行の強制

セキュリティチームとコンプライアンスチームは、セキュリティスキャンを確実に実行する必要があります:

  • すべてのプロジェクトで定期的に実施すること。
  • 開発者が無効にすることはできません。

GitLabはこれを実現するために2つの方法を提供しており、それぞれに利点と欠点があります。

  • コンプライアンスフレームワークのパイプラインは、以下のような場合に推奨されます:

    • SAST IaC, DAST, Dependency Scanning, License Compliance, API Fuzzing, Coverage-guided Fuzzing など、GitLab テンプレートを使用するスキャナーでスキャン実行の強制が必要な場合。
    • スキャン実行の強制は、GitLabの外部のスキャナに必要です。
    • スキャン実行の強制は、セキュリティスキャン以外のカスタムジョブに必要です。
  • スキャン実行ポリシーは、以下の場合に推奨されます:

    • DAST サイトまたはスキャンプロファイルを使用する DAST にスキャン実行が必要な場合。
    • スキャン実行の強制は、SAST、SAST IaC、シークレット検出、依存関係スキャン、またはプロジェクト固有の変数カスタマイズを伴うコンテナスキャンに必要です。このためには、ユーザーはプロジェクトごとに個別のセキュリティポリシーを作成する必要があります。
    • スキャンは、定期的にスケジュールされた周期で実行する必要があります。
  • どちらを使っても同じようにうまくいきます:

    • プロジェクト固有の変数カスタマイズがなく、コンテナスキャンにスキャン実行の強制が必要な場合。

2つのソリューションの違いについての詳細は以下のとおりです:

 コンプライアンス・フレームワーク・パイプラインスキャン実行ポリシー
柔軟性CIファイルで実行できることなら何でもサポートします。GitLabが明示的にサポートを追加した項目のみに限定。DAST、SAST、SAST IaC、シークレット検出、依存性スキャン、コンテナスキャンのスキャンをサポートします。
ユーザビリティCI YAMLの知識が必要です。 rulesactions ベースの YAML 構造に従います。
CIパイプラインへの組み込みコンプライアンスパイプラインはプロジェクトの.gitlab-ci.yml ファイルの .gitlab-ci.yml代わりに実行されます。.gitlab-ci.yml プロジェクトのファイルをインクルード .gitlab-ci.ymlするには、include を使います。定義された変数はインクルードされたプロジェクトの YAML ファイルによって上書きされません。CIパイプラインに新しいジョブを強制的にインクルードします。プロジェクトごとにカスタマイズする必要があるDASTジョブは、プロジェクトレベルのサイトプロファイルとスキャンプロファイルを定義することができます。職務の分離を確実にするため、これらのプロファイルはスキャン実行ポリシーで参照されても不変です。すべてのジョブは、セキュリティポリシーの一部として、通常 CI ジョブで利用可能なものと同じ変数でカスタマイズできます。
スケジューリング可能プロジェクトごとにスケジュールされたパイプラインを通してスケジュールされなければなりません。ポリシー設定自体でネイティブにスケジュール可能。
職務の分離グループ オーナーのみがコンプライアンス フレームワーク ラベルを作成できます。プロジェクト オーナーのみが、コンプライアンス フレームワーク ラベルをプロジェクトに適用できます。コンプライアンス パイプライン定義の変更を行ったり、承認したりできるのは、コンプライアンス パイプラインを含むプロジェクトへのアクセス権が明示的に与えられている個人に限られます。プロジェクト オーナーのみが、リンクされたセキュリティ ポリシー プロジェクトを定義できます。セキュリティ ポリシーの変更を行ったり承認したりできるのは、セキュリティ ポリシー プロジェクトへのアクセス権が明示的に与えられている個人に限られます。
1 つの標準を複数のプロジェクトに適用する機能同じコンプライアンス フレームワーク ラベルをグループ内の複数のプロジェクトに適用できます。同じセキュリティポリシープロジェクトをGitLabの複数のプロジェクトに使用することができ、同じグループにいる必要はありません。

これら二つの機能のユーザー体験を統一するための私たちのビジョンについてのフィードバックを歓迎します。

トラブルシューティング

ロギング・レベル

GitLabアナライザが出力するログの冗長性は、SECURE_LOG_LEVEL 環境変数によって決まります。このログレベル以上のメッセージが出力されます。

重要度の高いものから低いものまで、ロギングレベルは以下の通りです:

  • fatal
  • error
  • warn
  • info (デフォルト)
  • debug

デバッグレベルのロギング

caution
デバッグロギングは深刻なセキュリティリスクになる可能性があります。出力にはジョブの環境変数やその他のシークレットが含まれる可能性があります。出力は GitLab サーバーにアップロードされ、ジョブログで見ることができます。

デバッグレベルのロギングを有効にするには、.gitlab-ci.yml ファイルに以下を追加してください:

variables:
  SECURE_LOG_LEVEL: "debug"

これはすべてのGitLabアナライザーに対して、すべてのメッセージを出力することを示します。詳細については、ロギングレベルを参照してください。

セキュアジョブが終了コード 1 で失敗した場合

セキュアジョブが失敗し、その理由が不明な場合:

  1. デバッグレベルのロギングを有効にします。
  2. ジョブを実行します。
  3. ジョブの出力を調べます。
  4. info のデフォルト値に戻るには、debug ログ・レベルを削除してください。

古いセキュリティ・レポート

マージリクエスト用に生成されたセキュリティレポートが古くなると、マージリクエストはセキュリティウィジェットに警告メッセージを表示し、適切なアクションを取るようレポーターを促します。

これは 2 つのシナリオで発生します:

ソースブランチがターゲットブランチより遅れています。

ターゲットブランチとソースブランチの共通の先祖となる直近のコミットが、ターゲットブランチの直近のコミットでない場合、セキュリティレポートが古くなることがあります。

このイシューを修正するには、リベースするかマージしてターゲットブランチの変更を取り込んでください。

Incorporate target branch changes

ターゲットブランチのセキュリティレポーターが無効です。

これは、失敗したジョブや新しいアドバイザリなど、さまざまな理由で発生する可能性があります。マージリクエストでセキュリティレポートが古いと表示された場合は、対象のブランチで新しいパイプラインを実行する必要があります。新しいパイプラインを選択して、新しいパイプラインを実行します。

Run a new pipeline

警告メッセージの取得… report.json: no matching files

caution
デバッグロギングは深刻なセキュリティリスクになる可能性があります。出力にはジョブの環境変数やその他のシークレットが含まれる可能性があります。出力は GitLab サーバーにアップロードされ、ジョブログで見ることができます。

このメッセージの後にはエラーNo files to uploadが続くことが多く、その前には JSON レポートが生成されなかった理由を示す他のエラーや警告が続きます。このようなメッセージがないかジョブログ全体を確認してください。これらのメッセージが見つからない場合、SECURE_LOG_LEVEL: "debug"カスタム CI/CD 変数として設定した後、失敗したジョブを再試行してください。これは、さらに調査するための追加情報を提供します。

エラーメッセージsast job: config key may not be used with 'rules': only/except

SAST.gitlab-ci.yml のような.gitlab-ci.yml テンプレートをインクルードすると、GitLab CI/CD 設定によっては以下のエラーが発生することがあります:

Unable to create pipeline

    jobs:sast config key may not be used with `rules`: only/except

このエラーは、インクルードされたジョブのrules 設定が、非推奨のonly またはexcept 構文で[上書き](sast/index.md#overriding-sast-jobs)されている場合に表示されます。 このイシューを修正するには、以下のいずれかを行う必要があります:

詳細については、SASTジョブの上書き を参照してください。

only/except 構文からrules

ジョブ実行を制御するためにテンプレートをオーバーライドする場合、only またはexcept の以前のインスタンスはもはや互換性がないため、 rules 構文に移行する必要があります。

オーバーライドの目的がmain でのみ実行されるジョブを制限することである場合、以前の構文は以下のようになります:

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

# Ensure that the scanning is only executed on main or merge requests
spotbugs-sast:
  only:
    refs:
      - main
      - merge_requests

上記の設定を新しいrules 構文に移行するには、オーバーライドを次のように記述します:

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

# Ensure that the scanning is only executed on main or merge requests
spotbugs-sast:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_MERGE_REQUEST_ID

もしあなたのオーバーライドがタグではなくブランチ上でのみ実行されるジョブを制限するものであれば、以下のようになります:

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

# Ensure that the scanning is not executed on tags
spotbugs-sast:
  except:
    - tags

新しいrules 構文に移行するには、オーバーライドを次のように書き換えます:

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

# Ensure that the scanning is not executed on tags
spotbugs-sast:
  rules:
    - if: $CI_COMMIT_TAG == null

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

テンプレートを非推奨バージョンに固定

最新のサポートを確保するために、rulesにマイグレーションすることを強くお勧めします。

CI設定をすぐに更新できない場合は、例えば以前のテンプレートバージョンにピン留めするなどの回避策があります:

include:
  remote: 'https://gitlab.com/gitlab-org/gitlab/-/raw/12-10-stable-ee/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml'

さらに、バージョン管理されたレガシーテンプレートを含む専用プロジェクトを提供しています。これはオフラインのセットアップやAuto DevOpsを使用したい場合に使用できます。

使い方は、レガシー・テンプレート・プロジェクトでご覧いただけます。

脆弱性が見つかりましたが、ジョブは成功しました。代わりにパイプラインを失敗させるにはどうすればよいですか?

このような状況では、ジョブは成功するのがデフォルトの動作です。ジョブのステータスはアナライザー自体の成功または失敗を示します。アナライザーの結果は、ジョブログマージリクエストウィジェット、またはセキュリティダッシュボードに表示されます。

エラー: ジョブis used for configuration only, and its script should not be executed

GitLab 13.4 で Security/Dependency-Scanning.gitlab-ci.ymlSecurity/SAST.gitlab-ci.yml テンプレートに加えられた変更によりrules 属性を設定してsastdependency_scanning のジョブを有効にすると、(job) is used for configuration only, and its script should not be executedというエラーで失敗するようになりました。

sastdependency_scanning のスタンザは、variablesstage を変更するなど、すべての SAST や依存関係スキャンに変更を加えるために使うことができますが、共有rules を定義するために使うことはできません。

拡張性を改善するためのイシューがオープンされています。優先順位付けのためにこのイシューを upvote することができ、貢献者を歓迎します。

空の脆弱性レポート、依存関係リスト、ライセンスリストページ

パイプラインにallow_failure: false オプションを持つジョブの手動ステップがあり、このジョブが終了していない場合、GitLab はセキュリティレポートのデータをリストされたページに入力することができません。この場合、脆弱性レポート依存関係リストライセンスリストページは空になります。これらのセキュリティページは、パイプラインの手動ステップからジョブを実行することで入力することができます。

このシナリオを扱うためのイシューが開かれています。優先順位付けを助けるために、イシューをupvoteすることができますし、貢献者を歓迎します。