add

entities/scrutineer.md

@@ -0,0 +1,33 @@
+---
+title: Scrutineer
+created: 2026-06-30
+updated: 2026-06-30
+type: entity
+tags: [tool, security, supply-chain, automation, quality, human-in-the-loop]
+sources: [raw/articles/scrutineer-oss-security-workflow-2026.md]
+confidence: medium
+---
+
+# Scrutineer
+
+Scrutineer は、オープンソースリポジトリを AI 支援で脆弱性スキャンし、検証、連絡先特定、修正案、開示、リリース確認までを一つのワークフローで扱うローカルツール。James Nesbitt の紹介記事では、LLM が脆弱性らしきものを大量に見つけられるようになった一方で、未検証の報告がメンテナの注意を消耗する問題を避けるため、モデルの出力を直接メンテナに送らない設計が強調されている。
+
+この道具は [[ci-cd-runtime-security]] と同じ供給網防御の文脈にあるが、焦点は CI ジョブの実行時監視ではなく、OSS の脆弱性探索・検証・開示を人間のゲート付きで運用することにある。AI エージェントがコードを読む力を、[[ai-agent-identity-security]] 的な権限管理だけでなく、誰に何をいつ報告するかという社会的境界にも接続している。
+
+## Workflow pattern
+
+- スキャンは `SKILL.md`、JSON schema、補助 script からなる skill として定義される。
+- `triage` が先に走り、`security-deep-dive`、`threat-model`、`maintainers`、`patch`、`breaking-change`、`release-watch` などの skill を並列・段階的に起動する。
+- 深掘りは sink inventory を作り、敵対入力が trust boundary から到達できるかを確認してから finding にする。
+- finding は human gate を通って、検証、triage、開示文面、GitHub private vulnerability reporting、修正リリース確認へ進む。
+- patch skill は最小差分と regression test を提案するが、危険経路と正当利用の境界が読めないときは推測せず拒否する。
+
+## Why it matters
+
+Scrutineer の重要な設計判断は、「AI で見つける量」を増やすだけでなく、「AI が出したものをどこで止めるか」をワークフローに含めている点。これは [[loop-engineering]] の実例でもある。発見、検証、修正、開示、リリース監視という loop を、メンテナの受信箱ではなくローカルの操作面と状態管理に閉じ込め、外部に出す前に証拠と人間判断を要求する。
+
+## Open questions
+
+- skill 化された脆弱性探索が増えたとき、誤検知だけでなく「検証コスト」をどう測るか。
+- 人間 gate の担当者に必要な監査ログ、反証材料、再現手順をどこまで標準化できるか。
+- エコシステム横断スキャンを行う主体が、各プロジェクトの SECURITY.md や開示慣行をどれだけ尊重できるか。