Anthropic の OSS Scanner、AI が脆弱性を探して修正まで出す？

Transcript

1. AIニュース（2026年10月） Anthropic の OSS Scanner、 AI が脆弱性を探して修正まで出す？ 重要なオープンソースを Claude が定期的に調べる仕組み 赤神 青空
2. ▪2026年10月8日、Anthropic 何が発表されたか が OSS Scanner を始めると発表 OSS Scanner 重要なオープンソースの脆弱性を探すサービス 無料 費⽤は Anthropic が負担 いちばん強いモデルで調べる Claude Mythos も含む 今ココ 発表 申し込み制 申し込んだプロジェクトだけ 定期的にスキャン ⼀度きりではなく、くり返す Project Glasswing の経験から Claude で脆弱性を探してきた取り組み 2/15
3. ▪Anthropic人の確認が追いつかない 自身が出している数字（候補と確認の件数は、ここ6か月） モデルが⾒つけた 脆弱性の候補 29,000件超 ⼈が確かめて 仕分けできた 約6,000件 未検証でもと頼まれ 直接送った報告 約5,000件 ⾒つける速さに、⼈が確かめる速さが追いつかない 今ココ 発表 3/15
4. ▪一般的に言われていること オープンソースの脆弱性はなぜ見つけにくいか コードが⼤きく、古い部分も多い ⻑く使われてきたコードほど、読む範囲が広い ⾒る⼈が少ない 広く使われていても、メンテナーは少⼈数やボランティアのことがある 調べるのに⼿間がかかる ファジングの準備や、コードを読むレビューには、時間と知識が要る 今ココ 背景 4/15
5. ▪OSS Scanner OSS-Fuzz と似ているところ は Google の OSS-Fuzz に着想を得ている OSS-Fuzz（Google） ファザーでバグを探し続ける 無料のサービス 似ている点：対象の基準 利⽤者の多さや、インフラへの 影響の⼤きさで選ぶ 今ココ 背景 着想 OSS Scanner（Anthropic） OSS-Fuzz に着想を得た と記事に書かれている 似ている点：申し込み⽅ GitHub のリポジトリに PR を出し、 projects/<名前>/ を⾜す 5/15
6. ▪調べ方・用意するもの・報告の扱いが違う OSS-Fuzz との違い OSS-Fuzz OSS Scanner 調べ⽅ ファザーで⼊⼒を⼤量に試す モデルが、ビルドした プロジェクトを調べる ⽤意するもの Dockerfile などに加え、 ファズターゲットを書く Dockerfile など（ファズ ターゲットは不要） 報告と公開 ⾮公開で知らせ、 原則90⽇で公開する メールで知らせる。未検証なので 90⽇の期限はなく、公開しない 今ココ 背景 6/15
7. ▪GitHub申し込みから報告まで のリポジトリの README と FAQ から ① 申し込み 中⼼メンテナーが GitHub に PR ⽤意するもの project.yaml Dockerfile 申し込みは⼈が確認する 今ココ 仕組み ② ビルド 隔離した VM で ビルドする ③ スキャン インターネットを 切って調べる ④ 報告 連絡先にメール （GitHub にも可） 定期的に再スキャン 頻度は、対象のプロジェクトの数や どれだけ広く使われているかなどで変わる 7/15
8. ▪記事に書かれている3つ 報告の中身 再現の⼿順 単体で動かして再現できる reproducer（self-contained） 脆弱性の説明 できる場合は、バイセクトで「いつ⼊り込んだか」も調べる 修正パッチの案 ⽤意できた場合に付く 今ココ 仕組み 8/15
9. ▪報告はすべてモデルが作っている 人のレビューを通していない モデルが⾒つける モデルが報告を書く メンテナーに届く ⼈のレビュー‧仕分けは通していない 誤った報告もありうる 記事にもそう書かれている 今ココ 注意 だから公開はしない 90⽇の公開期間を設けず、 未検証の報告は公開しない 9/15
10. ▪記事に出ている、会社自身の評価 Anthropic 自身の確かめ 確かめた報告：97件 初期版の48プロジェクトの critical‧high 専⾨のペネトレーションテスターが確認 残りの12件 11件：本物だが、既知や重複 1件：誤検知 今ココ 注意 85件（88%） 協調的な脆弱性の開⽰（CVD）の 基準を満たした メンテナーの声 深刻度が⾼めに出ることがある 脅威モデルを読み違えることがある 10/15
11. ▪受け取った報告を確かめるのはメンテナー メンテナー側の負担 報告が本物かを確かめるのは、受け取ったメンテナー FAQ：確かめられた⾼い深刻度の報告に、既に対応できるプロジェクト向け 深刻度の⽬安を伝える threat_model.md に セキュリティの⽬標や 深刻度の⽬安を書いておく 今ココ 注意 ⽌める‧やめる‧伝える disabled: true で⼀時停⽌ フォルダを消して取り下げ 報告のメールに返信して意⾒ 11/15
12. ▪メンテナーとして、使う側として 開発者にとっての意味 メンテナーなら 使う側なら 申し込める 修正はアップデートで届く 確かめてから直す 依存先を新しく保つ 対象の基準に当てはまれば、 無料で定期スキャン 付いてくる再現の⼿順で、 本当に起きるかを⾒る 今ココ まとめ 依存先で直された脆弱性は、 新しい版で受け取れる 修正を受け取るための 前提になる 12/15
13. ▪報告は まとめ AI が作り、確かめるのはメンテナー 重要なオープンソースを、定期的に調べる 仕組み 報告には、再現の⼿順‧説明‧修正パッチの案 報告 報告は⼈のレビューを通していない 注意 いちばん強いモデルで調べる、無料‧申し込み制のサービス バイセクトでいつ⼊り込んだかも（できる場合） 誤った報告もありうるので、確かめるのはメンテナー 今ココ まとめ 13/15
14. ▪一度止めて考えてみてください。答えは次のページで 今回のクイズ OSS Scanner の報告について、発表の内容と合っているものは？ A 担当者が確かめてから 送られる 今ココ まとめ B GitHub の公開の issue として届く C 人のレビューを通して いない D 修正の案は付かない 14/15
15. ▪報告はモデルが作ったもので、人のレビューを通していない クイズの答えは「C」 今回のクイズ OSS Scanner の報告について、 発表の内容と合っているものは？ 記事に、出⼒はすべてモデルが作り、 ⼈のレビューや仕分けは通していない とある。誤った報告もありうる 答えは C 今ココ まとめ A 担当者が確かめてから送られる ⼈は確かめていない。だから誤った報告もありうる の公開の issue として届く B GitHub メールか、希望で GitHub の⾮公開の報告 C ⼈のレビューを通していない 記事にそのとおり書かれている D 修正の案は付かない ⽤意できた場合は、修正パッチの案が付く 15/15