Zenn
🔑

これはシークレット？ NotebookLM で社内ルールを LLM に判定させてみた

に公開
secret
OWASP
NotebookLM
idea

何をもって“シークレット”とするのか？

最近、社内でリポジトリ内におけるシークレットの取り扱い方法を見直しました。
その中で、そもそも「何をもって“シークレット”とするのか？」という疑問が出てきました。

パスワードや API キーといった明らかなものはともかく、例えば Webhook の URL や DB のユーザ名など、グレーなケースに対する判断基準が人によって異なると思います。

そこでまずは一定のガイドラインを設けようという話になり、それをベースに「LLM で自動判定できないか？」という案が出ました。

そして NotebookLM を使うのがちょうど良さそうだったので、PoC 的に試してみることにした、というのが今回の取り組みの背景です。

社内ルールの整備：OWASP 8.2をベースに

シークレットの基準を定めるにあたって、最初は「なんとなく今までこうしてきた」という過去の慣習や対応例をベースに草案を作成していました。

しかし、いざ社内に共有・展開するとなると、説得力のある根拠が必要になります。
そこで参照したのが、OWASP（Open Worldwide Application Security Project）の 8.2 Types of secrets to be detectedです。

OWASP に準拠することで、社外にも説明可能な根拠を持たせつつ、そこに社内の実情を加味して運用可能な形にアレンジしていく方針を取りました。

具体的には、すでに利用されている環境変数を洗い出し、みんなで1つずつ「これはシークレット」「これはシークレットではない」と分類していきました。

この作業を通じて得られた判断基準をルール化し、具体的な例も明示することで、
誰が見ても判断しやすいドキュメントを目指しました。

NotebookLM 導入の位置付け

シークレットの基準を明文化したとはいえ、どうしても判断に迷うケースというのは残ります。
そんなとき LLM に答えさせることで、判断の参考になるのでは？という案が出ました。
あくまで最終判断は人が行うものですが、補助的に意見を出してくれる存在として、LLM が役立つのではないかという期待です。

プロンプト設計

NotebookLM には以下の2種類のドキュメントを読み込ませています：

  1. OWASP Cheat Sheet Series の 8.2 Types of secrets to be detected
  2. 社内向けに作成した「判定指示用ドキュメント」

このうち後者のドキュメントには、判断手順・具体例・注意点の3つのセクションがあり、それぞれがプロンプトとしての重要な役割を果たしています。

判断ステップ（= Chain of Thought）

まず「これはシークレットか？」という問いに対して、いきなり結論を出させるのではなく、段階的な判断プロセスを踏ませるようにしています。これはいわゆる CoT（Chain of Thought）に該当するアプローチです。

※ 説明用に一部を抜粋・加工した例で、実際の記述とは異なります

## 判断ステップ
1. OWASP Cheat Sheet Series の 8.2 Types of secrets to be detected に一覧されているタイプに該当するか確認する
2. 既に決まった判断例として **## 具体例** を参照する
3. 万が一、リポジトリの情報が漏洩し値が公開されてしまった場合に悪用リスクがあるかを想定し判断する
   - リスクがある場合：シークレット値
   - リスクがない場合：非シークレット値
...

具体例（= few-shot）

次に、「具体例」として実際の変数名とその判断理由を提示し、few-shot 的にモデルの判断基準をチューニングしています。

※ 説明用に一部を抜粋・加工した例で、実際の記述とは異なります

## 具体例
- DB_PORT（ポート）：非シークレット値
  - 標準ポートであることが多く、秘匿しても攻撃の抑止にならないため
- SLACK_WEBHOOK_URL（Slack Webhook URL）：シークレット値
  - 漏れた場合にメッセージの大量送信に悪用される可能性があるためシークレットと判断する
...

注意点（= 無理に答えさせないための処置）

「とりあえず答えようとする」のを防ぐため、判断が困難な場合は回答を保留するように明示的に指示しています。

※ 説明用に一部を抜粋・加工した例で、実際の記述とは異なります

## 注意点
以下に該当する場合は判断を中止し、「追加の情報を提供して欲しい」と回答してください。
- 判断するための情報が不足している
- 情報が曖昧で判断できない
- 関係のない情報が渡されている
...

運用してみた雑感

この仕組みはまだ導入したばかりで、正直なところ「どう使われていくか」はこれから見ていく段階です。

とはいえ、

  • 迷ったときの“壁打ち相手”として LLM に聞ける
  • 社内ルールの背景や判断基準を文章で確認できる
  • 「こういう例はどうなるのか？」というケースの洗い出しに使える

という点は、個人的にも手応えを感じている部分です。今後、実際の社内フィードバックや運用状況を踏まえて、また続報を書けたらと思います。

おわりに

今回の取り組みは社内ルールづくりの中で、LLM をどう活用できるか試す良い機会になりました。
「ルール策定 → プロンプト設計 → 判定実験」というサイクルを通じて、LLM にルールを解釈させる工夫や、曖昧な情報をどう扱うかといった点について多くの気づきを得ることができました。

同じように「社内ルール × LLM 活用」に取り組んでいる方がいれば、ぜひ知見を交換させてください！

Discussion