2.8 KiB
2.8 KiB
title, created, updated, type, tags, sources, confidence
| title | created | updated | type | tags | sources | confidence | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Scrutineer | 2026-06-30 | 2026-06-30 | entity |
|
|
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 や開示慣行をどれだけ尊重できるか。