• アプリケーションカバレッジ
  • ソースコード解析
  • 実行中のウェブアプリケーションの分析
  • 依存関係の分析
  • インフラストラクチャ分析
• 脆弱性スキャナーのメンテナンス
• Auto DevOpsによるセキュリティスキャン
• Auto DevOpsを使用しないセキュリティスキャン
  • デフォルトのレジストリベースアドレスを上書きします。
  • マージリクエストパイプラインでのセキュリティスキャンツールの使用
• GitLabセキュリティスキャンツールのデフォルトの動作
  • パイプラインのセキュリティジョブ
  • ジョブステータスの確保
  • JSONアーティファクト
• マージリクエストのセキュリティスキャン情報の表示
  • 全ての階層
  • 究極
• パイプラインの「セキュリティ」タブでセキュリティスキャン情報を表示
• セキュリティ ダッシュボードでのセキュリティ スキャン情報の表示
• 脆弱性レポートでセキュリティスキャン情報を見る
• VS Codeの拡張機能でセキュリティスキャン情報を見る
• マージリクエストでのセキュリティ承認者
• 非公開Mavenリポジトリの使用
• カスタムスキャンステージの使用
• 自己管理インストールオプション
• セキュリティレポートの検証
• 発見や脆弱性との対話
• セキュリティスキャン設定のヒント
  • スキャン実行の強制
• トラブルシューティング
  • ロギング・レベル
    • デバッグレベルのロギング
  • セキュアジョブが終了コード 1 で失敗した場合
  • 古いセキュリティ・レポート
    • ソースブランチがターゲットブランチより遅れています。
    • ターゲットブランチのセキュリティレポーターが無効です。
  • 警告メッセージの取得… report.json: no matching files
  • エラーメッセージsast job: config key may not be used with 'rules': only/except
    • only/except 構文からrules
    • テンプレートを非推奨バージョンに固定
    • 脆弱性が見つかりましたが、ジョブは成功しました。代わりにパイプラインを失敗させるにはどうすればよいですか？
  • エラー: ジョブis used for configuration only, and its script should not be executed
  • 空の脆弱性レポート、依存関係リスト、ライセンスリストページ

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

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

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

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

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

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

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

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

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

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

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

ソースコード解析

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

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

• ソースコードの脆弱性を分析する -静的アプリケーション・セキュリティ・テスト(SAST).
• Git リポジトリの履歴からシークレットを分析する -シークレットの検出。

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

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

• 既知の攻撃ベクトルに対するアプリケーションのテスト -動的アプリケーションセキュリティテスト(DAST).
• 既知の攻撃ベクトルに対するAPIの分析 -APIセキュリティ。
• 未知のバグや脆弱性のためのWeb APIの分析 -APIファジング。

依存関係の分析

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

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

• ビルド時 -依存性スキャン。
• コンテナイメージを使用するプロジェクトでは、最終的なコンテナイメージがビルドされた後にも -コンテナスキャン。

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

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

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

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

• アプリケーションのデプロイ環境を定義する Infrastructure as Code (IaC) 設定ファイル -Infrastructure as Code (IaC) スキャン。

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

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

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

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

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

• 自動SAST
• 自動シークレット検出
• 自動DAST
• 自動依存関係スキャン
• 自動コンテナスキャン

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

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

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

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

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

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

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

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

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

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

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

ジョブステータスの確保

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

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

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

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

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

JSONアーティファクト

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

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

• GitLab Free 13.5 で導入されました。
• 13.6で全階層で利用可能に。
• 13.7でレポートのダウンロードドロップダウンリストを追加。
• GitLab 13.9で機能フラグを削除しました。

全ての階層

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

セキュリティ スキャンは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 個の所見が、重大度順にウィジェットに表示されます。すべての検査結果を表示するには、［レポート全体を表示］を選択して、最新のブランチパイプラインの［セキュリティ］タブに直接移動します。

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

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

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

セキュリティダッシュボードは、プロジェクトのデフォルトブランチに存在する脆弱性を表示します。データは 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 の場合、プロジェクトの設定で以下の変数を設定します：

<!-- 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.yml にtest ステージを追加します：

   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"
  

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

• SAST ジョブの上書き」を参照してください。
• 依存関係スキャンのジョブのオーバーライド
• コンテナスキャニングジョブのオーバーライド
• シークレット検出ジョブのオーバーライド
• DASTジョブのオーバーライド

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

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

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

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

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

• GitLab 13.11 で導入されました。
• GitLab 14.0 でスキーマ検証メッセージが追加。

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つのソリューションの違いについての詳細は以下のとおりです：

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

トラブルシューティング

ロギング・レベル

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

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

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

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

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

variables:
  SECURE_LOG_LEVEL: "debug"

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

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

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

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

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

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

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

• ソースブランチがターゲットブランチより遅れている場合。
• ターゲットブランチのセキュリティレポートが古いです。

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

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

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

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

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

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

このメッセージの後にはエラー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)されている場合に表示されます。 このイシューを修正するには、以下のいずれかを行う必要があります：

• only/except 構文をrules に移行してください。
• (一時的に）テンプレートを非推奨バージョンに固定します。

詳細については、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.yml とSecurity/SAST.gitlab-ci.yml テンプレートに加えられた変更により、rules 属性を設定してsast やdependency_scanning のジョブを有効にすると、(job) is used for configuration only, and its script should not be executedというエラーで失敗するようになりました。

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

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

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

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

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