---
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 や開示慣行をどれだけ尊重できるか。