【2026年版】GitLab Ultimate のセキュリティ機能を一通り設定する ── Secret Detection／Dependency Scanning／SAST・Advanced SAST

Posted at 2026-10-07

はじめに

GitLab Ultimate には、コードを書いてからマージするまでの間に脆弱性を見つけるセキュリティ機能がそろっています。ただ、機能が多く、テンプレートやメニューも年々変わるため、「結局どれをどう有効にすればよいのか」が分かりにくくなっています。

この記事では、よく使う次の3つの機能を、初めて設定する人が迷わず有効にして、結果を確認できるところまで手順でまとめます。

機能	ひとことで言うと	主な検出対象
Secret Detection	パスワードや API キーの「うっかりコミット」を防ぐ	アクセストークン、秘密鍵、クラウドの認証情報
Dependency Scanning	使っているライブラリの既知の脆弱性を見つける	npm／Maven／PyPI などのパッケージ (間接依存を含む)
SAST／Advanced SAST	自分たちが書いたコードの脆弱性を見つける	SQL インジェクション、XSS、コマンドインジェクション

対象バージョン: GitLab 19.5 (2026年10月時点) の公式ドキュメントと UI に合わせています。メニュー名は英語 UI の表記です。古いバージョンでは名称や既定値が異なる場合があります。

この記事で扱わないもの: コンテナスキャン、DAST、IaC スキャン、API セキュリティテスト、ライセンスのコンプライアンスは対象外です。

この記事で分かること

3つの機能が「いつ・どこで」動くのかの全体像
画面からの設定と .gitlab-ci.yml での設定の両方の手順
最近の変更点 (Dependency Scanning の v2 テンプレート、グループ単位の一括有効化など)
結果の見方と、組織全体に広げるためのポリシー設定

全体像 ── どのタイミングで何が動くのか

最初に「いつ動くか」を押さえると、設定の意味が分かりやすくなります。

タイミング	動く機能	結果
① `git push` した瞬間	シークレットプッシュ保護	シークレットを含むプッシュを拒否
② MR のパイプライン	パイプラインシークレット検出／Dependency Scanning／SAST	MR のセキュリティウィジェットに「この MR で増えた脆弱性」を表示
③ デフォルトブランチのパイプライン	同上	脆弱性レポートに登録され、トリアージの対象になる
④ パイプラインとは無関係に随時	継続的脆弱性スキャン	新しいアドバイザリが出たら既存の SBOM と自動で再照合

設定方法は大きく3通りあります。

方法	向いているケース
A. 画面 (Secure > Security configuration) から MR を作る	CI 設定がない、またはシンプルなプロジェクト
B. `.gitlab-ci.yml` に `include` を書く	既存の CI が複雑、細かく調整したい
C. グループ単位で一括適用 (プロファイル／ポリシー)	複数のプロジェクトに同じ設定を配りたい、強制したい

まず1つのパイロットプロジェクトで A か B を試し、結果に納得してから C で広げる、という順番がおすすめです。

事前準備

必要なロール

作業	必要なロール
Security configuration 画面の表示・編集、プッシュ保護の有効化	Security Manager、Maintainer、Owner
画面から SAST を有効化、Advanced SAST の有効化	Maintainer、Owner
`.gitlab-ci.yml` を編集して有効化	Developer、Maintainer、Owner
脆弱性のステータス変更 (却下など)	Security Manager、Maintainer、Owner
セキュリティポリシープロジェクトの作成・紐付け	Owner (またはカスタムロール)

Runner の条件

Linux 上の GitLab Runner で、Executor が docker か kubernetes
CPU アーキテクチャが amd64 (Windows Runner や arm64 Runner では動きません)
GitLab.com の Hosted Runner なら最初から条件を満たしています

`test` ステージを忘れずに

スキャンジョブは既定で test ステージで動きます。stages: を自分で定義している場合は test を必ず入れてください。入れないと chosen stage test does not exist エラーになります。

.gitlab-ci.yml

stages:
  - build
  - test      # ← セキュリティジョブはここで動く
  - deploy

Self-Managed／Dedicated の場合だけ必要な管理者作業

GitLab.com の場合は不要です。

シークレットプッシュ保護の利用を許可する
Admin > Settings > Security and compliance > Secret detection の Allow secret push protection にチェックを入れます。
パッケージメタデータを同期する (Dependency Scanning に必須)
Admin > Settings > Security and compliance > License compliance の Package registry metadata to sync で、使うレジストリにチェックを入れて保存します。

メタデータの同期には storage.googleapis.com への外向き通信が必要です。同期されていないと、Dependency Scanning のジョブは成功しても脆弱性が1件も出ません。

1. Secret Detection (シークレット検出)

この記事では、コードを守る2つの仕組み (プッシュ保護とパイプライン検出) を扱います。両方を有効にする多層防御が推奨です。

このほかに、Issue や MR の説明・コメントに入力されたシークレットを保存前に警告する クライアント側のシークレット検出 もあります。また、公開リポジトリで漏えいしたシークレットは、種類によっては GitLab が自動で失効させます (自動対応)。

	シークレットプッシュ保護	パイプラインシークレット検出
動くタイミング	`git push` の受け付け時 (pre-receive)	CI/CD パイプラインのジョブ
見つけたら	プッシュを拒否 (入る前に止める)	MR・脆弱性レポートに表示 (入った後に気付く)
ルール	誤検知の少ない高信頼パターンのみ	より広いルールセット (Gitleaks ベース)
対象	プッシュの差分のみ	コミット範囲 (設定で全履歴も可)

1-1. シークレットプッシュ保護

有効にする

プロジェクトの左サイドバー Secure > Security configuration を開きます。
Secret push protection のトグルをオンにします。

これだけです。HTTP(S)、SSH、Web IDE からのプッシュがすべてチェックされます。

グループ配下の全プロジェクトにまとめて設定したい場合は、REST API を使います (特定のプロジェクトを除外することもできます)。

curl --request PUT \
  --header "PRIVATE-TOKEN: <アクセストークン>" \
  --url "https://gitlab.example.com/api/v4/groups/<グループID>/security_settings?secret_push_protection_enabled=true&projects_to_exclude[]=101"

ブロックされるとこうなる

remote: PUSH BLOCKED: Secrets detected in code changes
remote: Secret push protection found the following secrets in commit: 1a2b3c4d...
remote:
remote: -- config/settings.py:12 GitLab Personal Access Token
remote:
remote: To push your changes you must remove the identified secrets.

コミット ID、ファイルと行、シークレットの種類が表示されます。

ブロックされたときの対応

基本は「コミットからシークレットを取り除いてプッシュし直す」です。

該当する行のシークレットを削除し、環境変数や CI/CD 変数から読み込む形に書き換える
最新コミットなら git commit --amend、それより前なら git rebase -i で修正する
プッシュし直す
外部に出た可能性があるシークレットは必ず失効させて再発行する

テスト用のダミー値など、どうしてもプッシュしたい場合はスキップできます。スキップした操作は監査イベントに記録されます。

# Git CLI の場合
git push -o secret_push_protection.skip_all

# Web IDE など他のクライアントの場合は、コミットメッセージに次を含める
# [skip secret push protection]

スキップしても、パイプラインシークレット検出が有効ならプッシュ後に検出され、脆弱性として記録されます。スキップは運用ルールで制限し、監査イベントを定期的に確認しましょう。

誤検知を除外する

Secure > Security configuration > Secret push protection の歯車アイコン (Configure Secret Detection) > Add exclusion から登録します。

種類	例	補足
パス	`tests/fixtures/**`	glob。1プロジェクト最大10件
生の値	特定のダミー文字列	その値だけ許可
ルール	`gitlab_personal_access_token`	既定ルールを ID で無効化

この除外が効くのはプッシュ保護だけです。パイプライン側の除外は後述の変数やルールファイルで設定します。

スキャンされないケース

バイナリファイル、1 MiB を超えるファイルや差分
内容を変えないリネーム・移動・削除
リポジトリを作成した最初のプッシュ
1回のプッシュで 3,150 パス超、または 35 万行超の変更
既にファイル内にあり、今回の差分に含まれないシークレット

1-2. パイプラインシークレット検出

方法A: 画面から

Secure > Security configuration を開きます。
Pipeline secret detection の行で Configure with a merge request を選択します。
Create merge request を選択し、できた MR をマージします。

方法B: `.gitlab-ci.yml` に書く

Build > Pipeline editor で次を追加し、Validate タブで検証してからコミットします。

.gitlab-ci.yml

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

初回は履歴スキャンを1回だけ実行する

通常のスキャンは最新の状態と新しいコミットだけを見ます。過去の履歴に埋もれたシークレットを見つけるため、有効にした直後に1回だけ履歴スキャンを実行します。

Build > Pipelines > New pipeline を選択
変数 SECRET_DETECTION_HISTORIC_SCAN = true を追加して実行

大きなリポジトリでは時間がかかります。履歴スキャンは初回だけにしてください。

MR パイプラインでも動かす

既定ではブランチパイプラインで動きます。MR パイプラインを使っているプロジェクトでは、次の変数で MR パイプラインでも動きます。

.gitlab-ci.yml

variables:
  AST_ENABLE_MR_PIPELINES: "true"

よく使うカスタマイズ

やりたいこと	設定
パスを結果から除外	`SECRET_DETECTION_EXCLUDED_PATHS: "docs,spec/fixtures"`
1行だけ無視	その行に `gitleaks:allow` コメント
既定ルールを無効化	`.gitlab/secret-detection-ruleset.toml`

SECRET_DETECTION_EXCLUDED_PATHS を設定しても、脆弱性レポートに登録済みのシークレットは消えません。手動で Dismissed や Resolved にしてください。

.gitlab/secret-detection-ruleset.toml

[secrets]
  [[secrets.ruleset]]
    disable = true
    [secrets.ruleset.identifier]
      type  = "gitleaks_rule_id"
      value = "RSA private key"

EXAMPLE_TOKEN = "dummy-token-for-unit-test"  # gitleaks:allow

2. Dependency Scanning (依存関係スキャン)

依存ライブラリ (直接依存・間接依存・開発用依存) を洗い出して CycloneDX 形式の SBOM を作り、GitLab Advisory Database と照合します。19.5 からは悪意のあるパッケージ (マルウェア) のアドバイザリとも照合されます。

テンプレートが変わっています。 現在の推奨は SBOM ベースの Dependency-Scanning.v2.gitlab-ci.yml です。従来の Gemnasium (Dependency-Scanning.gitlab-ci.yml) は 17.9 で非推奨になり、GitLab 20.0 で削除予定です。新規は v2 を使い、既存は移行ガイドに沿って移行しましょう。

前提: ロックファイルを用意する

Dependency Scanning はバージョンが確定したファイルを読みます。リポジトリにコミットするか、前のジョブで生成してアーティファクトとして渡します。

言語	読み取るファイル (主なもの)
JavaScript／TypeScript	`package-lock.json`、`yarn.lock`、`pnpm-lock.yaml`、`bun.lock`
Python	`requirements.txt` (pip-compile 生成)、`Pipfile.lock`、`poetry.lock`、`uv.lock`
Java (Maven)	`maven.graph.json`、`pom.xml` (*)
Java／Kotlin (Gradle)	`gradle.lockfile`、`gradle.graph.txt`、`build.gradle(.kts)` (*)
Go	`go.mod`、`go.graph`
C#	`packages.lock.json`
Ruby／PHP／Rust	`Gemfile.lock`／`composer.lock`／`Cargo.lock`

(*) Maven、Gradle、Python でマニフェストしかない場合は、依存関係の解決ジョブが自動でロックファイル相当を生成します。それもできないとマニフェストだけを読むフォールバックで動きますが、間接依存が取れないので精度が下がります。

有効にする

.gitlab-ci.yml

include:
  - template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml

CI/CD コンポーネントを使う場合はこちらです (設定は inputs: で渡します)。

.gitlab-ci.yml

include:
  - component: $CI_SERVER_FQDN/components/dependency-scanning/main@1

v2 テンプレートは既定で MR パイプラインで動きます。他のジョブがブランチパイプラインのままだと、MR ごとにパイプラインが2本走ります。ブランチパイプラインに揃えたいときは AST_ENABLE_MR_PIPELINES: "false" を設定してください。

出力されるもの

gl-sbom-<種別>-<マネージャー>.cdx.json … ディレクトリごとの SBOM (依存関係リストの元)
gl-dependency-scanning-report.json … 脆弱性レポート (MR・脆弱性レポートに反映)

対応ファイルが見つからないと、ジョブは警告を出して成功で終わります。「緑なのに結果が空」のときはジョブログの警告を見てください。

よく使う変数

変数	既定値	用途
`DS_EXCLUDED_PATHS`	`/spec,/test,/tests,/tmp,/node_modules,/.bundle,/vendor,/.git`	スキャンしないパス (カンマ区切り、スペース禁止)
`DS_MAX_DEPTH`	`2`	探索する階層。`-1` で無制限。モノレポでは増やす
`DS_INCLUDE_DEV_DEPENDENCIES`	`"true"`	`"false"` で開発用依存を除外
`DS_STATIC_REACHABILITY_ENABLED`	`"false"`	`"true"` で実際に使われている依存かを解析
`DS_SKIP_IF_NO_SUPPORTED_FILES`	`"false"`	対応ファイルがなければジョブを実行しない

除外パスの変数は、既定値に追加されるのではなく既定値を置き換えます。 DS_EXCLUDED_PATHS や SAST_EXCLUDED_PATHS を設定するときは、既定値をコピーしてから自分のパスを足してください。そうしないと node_modules やテストコードまでスキャンされ、遅くなったり誤検知が増えたりします。

.gitlab-ci.yml

include:
  - template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml

variables:
  DS_EXCLUDED_PATHS: "**/spec,**/test,**/tests,**/tmp,**/node_modules,**/.bundle,**/vendor,**/.git,docs/**,examples/**"
  DS_MAX_DEPTH: "4"
  DS_STATIC_REACHABILITY_ENABLED: "true"

継続的脆弱性スキャン

デフォルトブランチで SBOM が作られていれば、新しいアドバイザリが公開されるたびに自動で再照合されます。パイプラインを動かしていない週末に出た CVE も、脆弱性レポートに載ります。追加の設定は不要です。

3. SAST と GitLab Advanced SAST

	SAST (標準)	GitLab Advanced SAST
解析の深さ	基本は1ファイル・1関数の中	ファイル・関数をまたいだテイント解析
精度	誤検知が出やすい	悪用できる経路に絞るため誤検知が少ない
修正の手がかり	行番号	入力から脆弱な行までのコードフローを表示
対応言語	幅広い	C#、C/C++、Go、Java (JSP)、JS／TS、PHP、Python、Ruby (ベータ: Dart、Kotlin、Objective-C、Rust、Scala、Swift)

3-1. SAST を有効にする

画面から (Ultimate): Secure > Security configuration > SAST の行で Configure with a merge request を選び、MR をマージします。

.gitlab-ci.yml で:

.gitlab-ci.yml

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

リポジトリの言語を自動判定して、semgrep-sast などのジョブが test ステージに追加されます。

既存の .gitlab-ci.yml が複雑だと、画面からの設定が解析に失敗することがあります。その場合は YAML を直接編集してください。

3-2. Advanced SAST を有効にする

標準の SAST を有効にしたうえで、変数を1つ追加するだけです (Maintainer 以上)。

.gitlab-ci.yml

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

variables:
  GITLAB_ADVANCED_SAST_ENABLED: "true"        # C/C++ 以外
  # GITLAB_ADVANCED_SAST_CPP_ENABLED: "true"  # C/C++ (コンパイルDBが別途必要)

パイプラインに gitlab-advanced-sast ジョブ (ベータ言語は gitlab-advanced-sast-ext) が増えていれば成功です。

Advanced SAST を有効にすると、対応言語のファイルは semgrep-sast ではスキャンされなくなり、同じ脆弱性は自動で重複排除されます (C/C++ と一部のベータ言語は Semgrep も並行して動きます)。

Self-Managed では 17.4 以降を推奨します。また、同じプロジェクトで stable と latest のテンプレートを混ぜないでください。

3-3. スキャンを速くする

機能	変数	効果
差分スキャン	`ADVANCED_SAST_PARTIAL_SCAN: "differential"`	MR では変更ファイルと依存ファイルだけをスキャン。マージ後は必ずフルスキャン
インクリメンタルスキャン	`GITLAB_ADV_SAST_INCR_SCAN: "true"`	前回の解析結果をキャッシュして再利用
パス除外	`SAST_EXCLUDED_PATHS: "spec,test,tests,tmp,*/.min.js,db/migrate"`	解析不要なパスを除外

SAST_EXCLUDED_PATHS も既定値 (spec,test,tests,tmp) を置き換えるので、上の例では既定値を先頭に残しています。除外を足したら、以前のフルスキャンと検出件数を比べましょう。大きく減ったら、本物のコードを除外している可能性があります。

3-4. 誤検知への対処

標準 SAST のルールを無効にする:

.gitlab/sast-ruleset.toml

[semgrep]
  [[semgrep.ruleset]]
    disable = true
    [semgrep.ruleset.identifier]
      type  = "semgrep_id"
      value = "gosec.G107-1"

Advanced SAST で特定の行だけ除外する:

# gitlab-advanced-sast-exclude
result = db.execute(query)

result = db.execute(query)  # gitlab-advanced-sast-exclude: rule-id-1

行単位の除外は、安全だと確認できた箇所だけにしてください。多用すると本物の脆弱性を隠してしまいます。

4. 全部入りの `.gitlab-ci.yml`

3つをまとめて有効にする例です。既存の設定に合わせて調整してください。

.gitlab-ci.yml

stages:
  - build
  - test
  - deploy

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml        # パイプラインシークレット検出
  - template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml  # 依存関係スキャン (SBOM)
  - template: Jobs/SAST.gitlab-ci.yml                    # SAST

variables:
  # 共通
  AST_ENABLE_MR_PIPELINES: "true"             # MR パイプラインでもスキャンする
  # SAST / Advanced SAST
  GITLAB_ADVANCED_SAST_ENABLED: "true"
  ADVANCED_SAST_PARTIAL_SCAN: "differential"
  SAST_EXCLUDED_PATHS: "spec,test,tests,tmp,**/*.min.js"
  # Dependency Scanning
  DS_EXCLUDED_PATHS: "**/spec,**/test,**/tests,**/tmp,**/node_modules,**/.bundle,**/vendor,**/.git,docs/**"
  # Secret Detection
  SECRET_DETECTION_EXCLUDED_PATHS: "docs/samples"

# --- 以下、既存のビルド／デプロイのジョブ ---
build-job:
  stage: build
  script:
    - echo "build"

シークレットプッシュ保護は CI ではなく、Security configuration のトグルで有効にします。 CI とは別に、忘れずにオンにしてください。

5. 結果の確認とトリアージ

結果が出る場所

場所	開き方	分かること
MR のセキュリティウィジェット	MR の Overview	この MR で増えた／解消した脆弱性
MR の Changes ビュー	MR の Changes	SAST の検出行に印が付く
パイプラインの Security タブ	Build > Pipelines > 対象 > Security	そのパイプラインの全結果 (ダウンロード可)
脆弱性レポート	Secure > Vulnerability report	デフォルトブランチの脆弱性一覧。トリアージの中心
依存関係リスト	Secure > Dependency list	依存パッケージ、バージョン、ライセンス

フィーチャーブランチで見つかったものは「検出結果 (finding)」です。デフォルトブランチにマージされて初めて「脆弱性 (vulnerability)」として脆弱性レポートに登録されます。

ステータスを変更する

Secure > Vulnerability report で対象にチェックを入れる
Set status でステータスを選ぶ
Dismiss の場合は理由を選び、コメントを書く (必須)
Change status を選択

ステータス	使いどころ
Needs triage	検出されたばかりで未確認
Confirmed	本物と確認。Issue を作って対応
Dismissed	誤検知、許容できるリスクなどで対応しない
Resolved	修正済み

脆弱性のレコードは削除できず、変更履歴は監査ログに残ります。却下の理由は、後で読んで分かるように書いておきましょう。

6. 組織全体に広げる

プロジェクトが増えてくると、1つずつ .gitlab-ci.yml を直すのは大変です。Ultimate にはグループ単位で配る・強制する仕組みがあります。

仕組み	役割
セキュリティ設定プロファイル＋Scanner Enablement Wizard	未設定のプロジェクトに推奨設定を画面から一括で有効化
スキャン実行ポリシー	パイプラインにスキャンジョブを強制的に追加
MR 承認ポリシー	脆弱性が見つかった MR にセキュリティ担当者の承認を必須にする

6-1. Scanner Enablement Wizard (19.3 で一般提供)

グループの Secure > Security configuration > Scanners タブを開く
Enable scanners を選択
Quick setup (未設定の全プロジェクトに既定プロファイルを適用) か Advanced setup (最大100件を選んで適用) を選ぶ
Review configuration で確認して Apply configuration

既定プロファイルで有効になるもの:

プロファイル	有効になるもの
Secret detection	プッシュ保護＋MR パイプライン＋デフォルトブランチのパイプライン
SAST	MR パイプライン＋デフォルトブランチのパイプライン
Dependency scanning	MR パイプライン＋デフォルトブランチのパイプライン

6-2. スキャン実行ポリシー

Secure > Policies > New policy > Scan execution policy から作成します。Configure with a merge request を選ぶと、初回はセキュリティポリシープロジェクトが自動で作られます。

.gitlab/security-policies/policy.yml

scan_execution_policy:
- name: デフォルトブランチで3種類のスキャンを必須にする
  description: Secret Detection / SAST / Dependency Scanning を強制する
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  - scan: sast
  - scan: dependency_scanning
    template: v2                      # SBOM ベースの v2 テンプレートを明示する

ポリシーで追加したジョブはプロジェクト側で上書きできません。プロジェクトの CI にも同じスキャンを書いていると二重に実行されるので、どちらかにまとめましょう。

ポリシーで動かすシークレット検出は、既定では標準のルールセットだけを使います。プロジェクトの .gitlab/secret-detection-ruleset.toml は使われません。独自ルールを使う場合は、ポリシーで SECRET_DETECTION_RULESET_GIT_REFERENCE 変数を指定します。
スケジュール型 (type: schedule) のポリシーでは、最初のシークレット検出が履歴スキャンになります。
dependency_scanning の template を省略した場合の扱いは GitLab のバージョンによって異なります (19.1 からは、新規ポリシーの既定が v2)。明示しておくのが確実です。

6-3. MR 承認ポリシー

「Critical／High の脆弱性が新しく1件でも見つかったら、security-team の承認が必要」というポリシーの例です。

.gitlab/security-policies/policy.yml

approval_policy:
- name: Critical/High の新しい脆弱性にはセキュリティ承認を必須にする
  enabled: true
  rules:
  - type: scan_finding
    branches: []                      # 保護されたすべてのターゲットブランチ
    scanners:
    - sast
    - secret_detection
    - dependency_scanning
    vulnerabilities_allowed: 0
    severity_levels:
    - critical
    - high
    vulnerability_states: []          # 新規の脆弱性 (needs triage / dismissed)
  actions:
  - type: require_approval
    approvals_required: 1
    group_approvers:
    - security-team                   # グループのパス (直接のメンバーが承認できる)

判定は MR のパイプラインでスキャンが終わってから行われます。6-1 か 6-2 と組み合わせて、MR のパイプラインでスキャンが動くようにしておきましょう。

ハマりどころ

症状	原因と対処
`chosen stage test does not exist`	`stages:` に `test` を追加する
ジョブがパイプラインに出てこない	include の書き方を Validate で確認。SAST は対応言語のファイルがないとジョブを作らない
Dependency Scanning が緑なのに結果が空	ロックファイルがない、または `DS_MAX_DEPTH` が足りない。ジョブログの警告を見る
Self-Managed で依存関係の脆弱性が出ない	パッケージメタデータが同期されていない
MR ごとにパイプラインが2本走る	`AST_ENABLE_MR_PIPELINES` と `workflow:rules` を揃える。stable と latest を混ぜない
ジョブが待機したまま	Windows／arm64 の Runner に当たっている。Linux・amd64 の Runner をタグで指定する
Security configuration が「Not enabled」のまま	デフォルトブランチのパイプラインが完了していない (MR をマージした後に変わる)

チェックリスト

Linux／amd64／docker・kubernetes の Runner がある
stages: に test がある
プッシュ保護のトグルをオンにした
パイプラインシークレット検出を include し、初回の履歴スキャンを実行した
ロックファイルをコミットし、Dependency-Scanning.v2 を include した
SAST を include し、GITLAB_ADVANCED_SAST_ENABLED: "true" を設定した
MR のセキュリティウィジェットに結果が出ることを確認した
トリアージの担当者とルールを決めた
ポリシーの適用範囲を決めた

おわりに

まずは1つのプロジェクトで

プッシュ保護のトグルをオンにする
「全部入りの .gitlab-ci.yml」を入れる
MR を1本作ってセキュリティウィジェットを見る

までやってみてください。結果の見え方をつかんでから、Scanner Enablement Wizard やポリシーで組織に広げていくと、スムーズに導入できます。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

【2026年版】GitLab Ultimate のセキュリティ機能を一通り設定する ── Secret Detection／Dependency Scanning／SAST・Advanced SAST

はじめに

この記事で分かること

全体像 ── どのタイミングで何が動くのか

事前準備

必要なロール

Runner の条件

test ステージを忘れずに

Self-Managed／Dedicated の場合だけ必要な管理者作業

1. Secret Detection (シークレット検出)

1-1. シークレットプッシュ保護

有効にする

ブロックされるとこうなる

ブロックされたときの対応

誤検知を除外する

スキャンされないケース

1-2. パイプラインシークレット検出

方法A: 画面から

方法B: .gitlab-ci.yml に書く

初回は履歴スキャンを1回だけ実行する

MR パイプラインでも動かす

よく使うカスタマイズ

2. Dependency Scanning (依存関係スキャン)

前提: ロックファイルを用意する

有効にする

出力されるもの

よく使う変数

継続的脆弱性スキャン

3. SAST と GitLab Advanced SAST

3-1. SAST を有効にする

3-2. Advanced SAST を有効にする

3-3. スキャンを速くする

3-4. 誤検知への対処

4. 全部入りの .gitlab-ci.yml

5. 結果の確認とトリアージ

結果が出る場所

ステータスを変更する

6. 組織全体に広げる

6-1. Scanner Enablement Wizard (19.3 で一般提供)

6-2. スキャン実行ポリシー

6-3. MR 承認ポリシー

ハマりどころ

チェックリスト

おわりに

参考

`test` ステージを忘れずに

方法B: `.gitlab-ci.yml` に書く

4. 全部入りの `.gitlab-ci.yml`