chore(security): 🔒 Gitleaks カスタムルール拡張 による コミット前検知・CI 強化

[genzouw]

背景

事前調査の結果、本リポジトリでは .pre-commit-config.yaml や CI ワークフローを通じて Gitleaks や TruffleHog などの強力なシークレットスキャンツールがすでに設定されています。しかし、プロジェクトの拡大に伴い利用が増加しうる汎用的な Bearer トークンや、Basic 認証のURL直書き、各種SaaS（LINE、Notion等）のAPIキーについては既存のカスタムルールでカバーされていないため、開発者のハードコードによる意図せぬ情報露出リスクが存在します。

現状認識

• 既存防御策: gitleaks.yml, trufflehog.yml, trivy.yml, .pre-commit-config.yaml によるローカル/CIの多層防御が導入済み
• 未カバー領域: 汎用 Bearer トークン、Basic認証を含むURL、SaaS特有の識別子 (LINE, Notion等) のパターン検知
• 直近の漏洩リスク兆候: 現在のファイル群に漏洩は確認されなかったが、将来的なサービス拡張時に該当キーがハードコードされる潜在的リスクがある

このPRで導入・強化するもの

• 対象: 既存の .gitleaks.toml および docs/security/leak-prevention.md の更新
• ツール名とバージョン: Gitleaks (既存のバージョンを利用。今回はカスタムルールの拡張のみ)
• 期待される効果:
  • monopo-basic-auth-url: 開発中に記述しがちなBasic認証情報付きのURLを検知・ブロック。
  • monopo-line-token / monopo-notion-api-key: 特定SaaSに紐づくキー形式を明示的に検知・ブロック。
  • monopo-generic-bearer-token: 上記に該当しない汎用的な Bearer トークンを検知・ブロック。
  • ローカルコミット前およびCI（全履歴対象）での漏洩防止カバレッジを向上。

検知漏れリスクと補完策

• 検知できないケース: 今回追加したルールに含まれない、非常に短いランダムなパスワードや、標準的なプレフィックス（Bearer等）を持たない独自のセッショントークン
• 補完策: 既存の detect-secrets（エントロピーベース検知）、およびGitHubネイティブの Secret Scanning と併用することで多層防御を維持

マージ前に必要な手動作業（チェックリスト）

レビュアーは PR をマージする前に必ず以下を実施してください。本 PR の CI は手動作業完了を前提に通る設計です。

• 既存の開発ブランチにて、今回追加されたルールで誤検知が発生しないかローカルで pre-commit run --all-files などを実行して確認する
• （必要であれば）開発メンバーに対し、今回新たに追加された検知ルールの概要についてアナウンスを行う

マージ後の確認手順

• 次の push / PR で既存の Gitleaks ワークフローが正常にパス（Green）になることを確認する
• 意図的なダミーキー（例: secret_dummy123456... 等のNotion形式）をテスト的にコミットしようとした際、ローカルの pre-commit フックで正しくブロックされるかを確認する

ロールバック手順

• 問題が発生した場合、該当するルールの変更を取り消す（git revert <commit-hash>）PRを作成・マージすることで以前の状態に復元できます。

参考情報

• 公式ドキュメント: https://github.com/gitleaks/gitleaks
• 直近の関連Issue: なし

---

PR created automatically by Jules for task 12435543589279923108 started by @genzouw

Summary by CodeRabbit

• セキュリティ
  • Basic認証URL、Bearerトークン、LINE Messaging APIトークン、Notion APIキーの検出に対応しました。
  • ローカル環境およびCIで、認証情報の漏洩を検知・ブロックできるようになりました。
  • ダミー値や環境変数形式は検出対象から除外されます。

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[coderabbitai]

Warning

Review limit reached

@genzouw, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 6 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: d54f5ab7-93bf-4edb-8e90-8ad327819125

📥 Commits

Reviewing files that changed from the base of the PR and between 9af598d and 7a2829d.

📒 Files selected for processing (2)

• .gitleaks.toml
• docs/security/leak-prevention.md

📝 Walkthrough

Walkthrough

Gitleaksに、Basic認証URL、LINEトークン、Notionトークン、Bearerトークンの検知ルールを追加しました。誤検知を抑制するallowlistを設定し、検知対象をセキュリティ文書に追記しました。

Changes

認証情報漏洩検知

Layer / File(s)	Summary
カスタム検知ルールと運用文書 .gitleaks.toml, docs/security/leak-prevention.md	Basic認証URL、LINE関連トークン、Notion Internal Integration Token、Bearerトークンの検知ルールを追加しました。ダミー値と環境変数形式をallowlistで除外しました。ローカルとCIでの検知・ブロック対象を文書化しました。

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related PRs

• genzouw/monopo#425: .gitleaks.tomlとセキュリティ文書にSaaS/API認証情報の検知ルールを追加しています。
• genzouw/monopo#495: .gitleaks.tomlとセキュリティ文書のカスタムGitleaksルールを拡張しています。
• genzouw/monopo#194: .gitleaks.tomlとセキュリティ文書にカスタム漏洩検知ルールを追加しています。

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	タイトルは、Gitleaksのカスタムルール拡張とコミット前検知・CI強化という主な変更内容を明確に示しています。
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch security/gitleaks-rules-expansion-12435543589279923108

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Gitleaksカスタムルール拡張でBearer/Basic認証URL/LINE/Notion検知を強化

✨ Enhancement 📝 Documentation ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• GitleaksにBasic認証URL・Bearerトークン・LINE/Notionキーの検知ルールを追加
• 誤検知を抑えるため一部パターンをallowlist化
• 漏洩防止ドキュメントに追加ルールの目的と効果を追記

Diagram

graph TD
  Dev["開発者"] --> PreCommit["pre-commit"] --> GitleaksLocal["Gitleaks(ローカル)"] --> Rules[".gitleaks.toml"] --> Block["コミットをブロック"]
  Dev --> CI["CIワークフロー"] --> GitleaksCI["Gitleaks(CI)"] --> Rules
  Rules --> Docs["docs/security/leak-prevention.md"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. コミュニティ/公式ルールセットの取り込み（extend/同期）

• ➕ メンテナンス負荷を下げつつ検知範囲を広げやすい
• ➕ 既知パターンの更新を追従しやすい
• ➖ プロジェクト固有の誤検知が増える可能性
• ➖ 更新頻度次第で意図しない挙動変化が起こりうる

2. ルールの自動回帰テスト（fixtureでの検知/非検知テスト）を追加

• ➕ 誤検知/検知漏れの変更をPR単位で検出できる
• ➕ 正規表現の将来改修が安全になる
• ➖ テスト用のサンプル管理・運用コストが増える
• ➖ CI時間がわずかに増える

3. Bearer系をより厳密に（JWT形式/既知prefix中心）へ寄せる

• ➕ 汎用Bearerの誤検知リスクを抑えられる
• ➕ 意図しないトークン文字列（例: ダミー値）を拾いにくい
• ➖ 汎用トークンの検知カバレッジが下がる
• ➖ サービスごとの差異を別ルールで補う必要が出る

Recommendation: 現状の「SaaS特有 + 汎用Bearer + Basic認証URL」を追加する方針は、既存多層防御（pre-commit/CI/他スキャナ）と整合し、効果が明確で妥当です。次の改善としては、誤検知を継続的に抑えるためにfixtureベースの回帰テストを追加し、ルール変更の安全性を高めるのが最も投資対効果が高いです。

Files changed (2) +45 / -0

Documentation (1) +5 / -0

leak-prevention.md追加したGitleaks強化内容（汎用トークン/Basic認証対応）を追記 +5/-0

追加したGitleaks強化内容（汎用トークン/Basic認証対応）を追記

• LINE/NotionなどのSaaS APIキー、Basic認証URL、汎用Bearerトークンのハードコード抑止としてGitleaksカスタムルールを拡張した旨を追記しました。ローカルおよびCIで早期検知・ブロックできる点を明文化しています。

docs/security/leak-prevention.md

Other (1) +40 / -0

.gitleaks.tomlBasic認証URL/LINE/Notion/Bearerのカスタム検知ルール追加 +40/-0

Basic認証URL/LINE/Notion/Bearerのカスタム検知ルール追加

• Basic認証情報を含むURL、LINE関連トークン/シークレット、NotionのInternal Integration Token、汎用Bearerトークンを検知するGitleaksルールを追加しました。誤検知抑制のため、Basic認証URLのダミー値と環境変数展開のBearerをallowlistに登録しています。

.gitleaks.toml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. LINEが部分文字列に一致 ✓ Resolved 🐞 Bug ☼ Reliability

Description

monopo-line-token は (?i)(?:line|channel) に前方境界がなく、pipeline_access_token のように
line_access_token を部分文字列として含む識別子まで一致し得ます。結果として LINE と無関係な設定でも、値が長い文字列だと誤検知で gitleaks チェックが失敗します。

Code

.gitleaks.toml[R192-195]

+id = "monopo-line-token"
+description = "LINE Messaging API / Login 関連のトークン・シークレット検知"
+regex = '''(?i)(?:line|channel)[_-]?(?:access[_-]?token|secret)[\s]*[:=][\s]*["']?[A-Za-z0-9+/=]{20,}["']?'''
+tags = ["saas", "api-key", "credential", "line"]

Relevance

●●● Strong

gitleaks ルールの境界不足による誤検知低減は過去に受け入れられている。

PR-#405
PR-#504
PR-#495

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

追加された正規表現は line/channel の直前に境界がなく、部分文字列一致が起こり得る形です。gitleaks は commit hook と CI
で走るため、誤検知はそのままフロー失敗につながります。

.gitleaks.toml[191-197]
.husky/pre-commit[14-18]
.github/workflows/gitleaks.yml[5-13]
PR-#425

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`monopo-line-token` が `line` を単語としてではなく部分文字列として扱うため、無関係な識別子（例: `pipeline_access_token`）を誤検知し得ます。

## Issue Context
このルールは `...token|secret\s*[:=]\s*...` まで含むため、設定ファイルや環境変数の一般的な書き方に乗ると誤検知が起きやすくなります。

## Fix Focus Areas
- .gitleaks.toml[191-197]

### Suggested change direction
- `line` / `channel` の前後に境界条件を追加する（例: `(?:^|[^A-Za-z0-9])(?:line|channel)(?:[_-](?:access[_-]?token|secret))\b` のように“キー名”としてのみ一致させる）。
- 可能ならキー名をより具体化する（例: `LINE_...` / `CHANNEL_...` のような想定命名に寄せる）か、`(?i)` を外してプレフィックスはケースセンシティブにする。

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Bearer誤検知しやすい ✓ Resolved 🐞 Bug ☼ Reliability

Description

monopo-generic-bearer-token は bearer の後ろが1文字以上ならマッチするため、Bearer token
のようなプレースホルダ文言まで検知し、コミット/CIの gitleaks チェックを誤って失敗させ得ます。既存の他ルールが長さや境界でノイズ低減しているのに対し、このルールだけ制約が弱すぎます。

Code

.gitleaks.toml[R209-212]

+description = "汎用的な Bearer トークンのハードコード検知"
+regex = '''(?i)bearer\s+[A-Za-z0-9\-\._~\+/]+=*'''
+tags = ["credential", "bearer", "token"]
+secretGroup = 0

Relevance

●●● Strong

汎用パターンの制約強化（長さ固定/境界追加）による誤検知削減が過去に採用済み。

PR-#424
PR-#486
PR-#495

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Bearer ルールは長さ制約がなく、他のトークン系ルール（例: 20文字以上・境界あり）に比べて誤検知しやすい形です。さらに gitleaks は commit hook と CI
の両方で実行されるため、誤検知がそのまま開発フローのブロックに直結します。

.gitleaks.toml[207-216]
.gitleaks.toml[151-165]
.husky/pre-commit[14-18]
.github/workflows/gitleaks.yml[5-13]
PR-#486

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`monopo-generic-bearer-token` が短い非シークレット文字列（例: ドキュメント上の `Bearer token`）まで一致してしまい、誤検知でローカルフック/CIを落とし得ます。

## Issue Context
このリポジトリでは Husky の pre-commit で `gitleaks protect`、CI で gitleaks workflow が常時走るため、誤検知は開発フローを継続的に阻害します。

## Fix Focus Areas
- .gitleaks.toml[207-217]

### Suggested change direction
- 文字列長の下限を設ける（例: `bearer\s+[A-Za-z0-9\-\._~\+/]{20,}=*` など）。
- 可能なら HTTP ヘッダ文脈（`Authorization:`）や JWT 形状（`eyJ...`）など、より強い文脈制約を追加する。
- 併せて、よくある安全なプレースホルダ（例: `Bearer <TOKEN>`、`Bearer YOUR_TOKEN_HERE` 等）を allowlist に追加するか、ドキュメント側の表現を `${TOKEN}` 形式に統一する。

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Notionが末尾境界なし ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

monopo-notion-api-key は末尾境界がないため、より長い secret_...
文字列の先頭43文字だけに一致するなど、部分一致/埋め込み一致による誤検知や曖昧な検知結果を招き得ます。トークン全体の一致を保証する境界を付けるべきです。

Code

.gitleaks.toml[R200-202]

+id = "monopo-notion-api-key"
+description = "Notion API キー (Internal Integration Token) のハードコード検知"
+regex = '''(?i)secret_[a-zA-Z0-9]{43}'''

Relevance

●●● Strong

シークレット検知 regex の境界/アンカー追加で誤検知を減らす修正は通る傾向。

PR-#202
PR-#495
PR-#486

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

現在の Notion ルールは secret_ + 43文字の直後に境界条件がなく、部分一致を許す形です。過去にも境界なしの汎用キー検知が誤検知要因として扱われています。

.gitleaks.toml[199-205]
PR-#486

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Notion トークン検知が末尾境界なしのため、長い文字列中の部分一致や先頭部分だけの一致が起こり得ます。

## Issue Context
既存の他ルールでは `\b` などの境界を使って部分一致による誤検知を抑えている例があります。

## Fix Focus Areas
- .gitleaks.toml[199-205]

### Suggested change direction
- 末尾境界を追加して完全一致に寄せる（例: `\bsecret_[A-Za-z0-9]{43}\b`）。
- `(?i)` は prefix の `secret_` にしか効かず冗長なので、必要性を再確認のうえ削除も検討する。

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context used

✅ Compliance rules (platform): 34 rules

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.gitleaks.toml:
- Around line 200-202: Update the gitleaks rule id “monopo-notion-api-key” in
.gitleaks.toml (lines 200-202) to detect both current ntn_ tokens and legacy
secret_ tokens while preserving the existing token lengths and character
constraints. Update the corresponding documentation in
docs/security/leak-prevention.md (lines 130-133) to describe both supported
Notion token prefixes; no other behavior changes are needed.
- Around line 186-189: Update the regex in the [rules.allowlist] configuration
to restrict Basic Authentication URL exemptions to test-only hosts such as
localhost and reserved test domains, rather than allowing any host via @.*.
Preserve the existing test credential patterns while ensuring production hosts
remain detectable.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: d7d50e7e-096c-4b21-aa3e-d23b0ee54779

📥 Commits

Reviewing files that changed from the base of the PR and between 768fc6d and 9af598d.

📒 Files selected for processing (2)

• .gitleaks.toml
• docs/security/leak-prevention.md