GitLabセキュリティポリシー強制術：野良リポジトリを撲滅し、自動化で「守る」開発へ
エンジニアの皆さん、お疲れ様です。テックリードとして現場を見ていると、常に頭を悩ませるのが「セキュリティ設定のバラつき」です。
「特定のプロジェクトだけスキャンが漏れている」「脆弱性が見つかっても放置されている」……こんな事態を防ぐために、各リポジトリを個別に設定していませんか？ それはスケーラビリティの欠如であり、DevOpsの敗北です。
GitLabの「Security Policy Management」を使えば、グループやインスタンスレベルでセキュリティ設定を「強制」できます。今回は、現場の生産性を落とさず、かつガバナンスを鉄壁にするための「極限の実装術」を伝授します。
—
1. なぜ「個別の設定」は悪手なのか？
プロジェクトが10個を超えた瞬間、個別の設定変更は不可能です。GitLabのSecurity Policyは、「Security Policy Project」という独立したリポジトリを作成し、そこから上位（グループ・インスタンス）でポリシーを定義することで、配下の全プロジェクトに強制適用します。
究極の構成案：Policy Projectの分離
セキュリティ担当者と開発チームの権限を分離し、`CI/CDテンプレート`と`セキュリティポリシー`を統合管理します。
.gitlab/security-policies/policy.yml
このファイルをSecurity Policy Projectに配置する
scan_execution_policy:
- name: “強制スキャンポリシー”
description: “全プロジェクトでSASTとSecret Detectionを強制実行”
enabled: true
rules:
- type: pipeline
branches:
- main
- develop
actions:
- scan: sast
- scan: secret_detection
2. 現場の生産性を爆速化する「神ショートカット」と設定
セキュリティを強制すると「開発が遅くなる」と不満が出るはずです。それを防ぐのが、GitLabをハックする生産性向上術です。
隠れたキーボードショートカット（これを使わないと損）
- `g` → `i`: どこにいても「Issue」一覧へ飛ぶ。
- `g` → `m`: 「Merge Request」一覧へ。
- `Shift` + `s`: コマンドパレットを開く（設定やリポジトリ検索が爆速に）。
- `y`: ブランチのコミットハッシュURLへ即座にパーマリンク生成。
チーム開発で絶対入れるべき「GitLab Workflow」拡張
VS Codeの GitLab Workflow 拡張機能は必須です。
- GitLabのIssueをVS Code内で完結: ブラウザに戻る必要がありません。
- MRのパイプライン結果をエディタで確認: 失敗した瞬間に通知が来るため、コンテキストスイッチを最小化できます。
—
3. 「承認プロセス」をポリシーで自動化する
脆弱性が見つかった際、誰が承認するのか？ これを人間系でやるとボトルネックになります。`scan_result_policy`を使って、「高リスクな脆弱性がある場合は、セキュリティチームの承認を必須にする」というルールをコード化します。
scan_result_policy.yml
scan_result_policy:
- name: “高リスク脆弱性に対する強制承認”
enabled: true
rules:
- type: scan_finding
scanners: [sast]
vulnerabilities_allowed: 0
severity_levels: [critical, high]
block_after_append: true
actions:
- type: require_approval
approvals_required: 1
user_approvers:
- security-team-lead
これで、開発者は「脆弱性を直すまでマージできない」という状態を自動的に受け入れざるを得なくなります。これは「規制」ではなく、「品質の自動担保」です。
—
4. プロのベストプラクティス：設定の共有化ルール
GitLab設定を散逸させないための「3つの鉄則」を共有します。
1. Includeの徹底活用:
各リポジトリの `.gitlab-ci.yml` は最小限に保ち、共通テンプレートを `include` してください。
# 各プロジェクトの .gitlab-ci.yml
include:
- project: ‘devops/templates’
file: ‘/security/sast-template.yml’ # グローバルな設定を読み込む
2. Protected Environmentの活用:
本番環境へのデプロイは、特定のグループメンバーしか実行できないよう、GitLabの環境保護機能を必ず使ってください。
3. Audit Eventの監視:
誰がポリシーを変更したかを追跡するため、`Admin Area > Audit Events` を定期的に監視するWebhookをSlackへ飛ばしましょう。
—
最後に：ツールに支配されるな、ツールを支配せよ
セキュリティポリシーの強制は、単なる「縛り」ではありません。「何がOKで、何がNGか」をコードとして明示することで、エンジニアの認知負荷を下げる行為です。
「脆弱性チェックはGitLabが自動でやってくれるから、自分たちはロジックに集中しよう」
チームがそう思える環境を作れた時、あなたのチームのデリバリー速度は、以前とは別次元に到達しているはずです。
さあ、今すぐポリシーリポジトリを立ち上げ、その手でGitLabを最強の守護神へと変貌させてください。健闘を祈ります。