Author

claudenewsjp

無料のAI脆弱性スキャナ、うれしいけれど少しこわい

最初に思ったのは、「やっとここまで来たか」という気持ちと、「でも、これ本当に回るのかな」という引っかかりでした。AIが脆弱性を見つける話自体はもう珍しくないけれど、今回の記事で目を引いたのは、Anthropicがそれを“無償の定期スキャン”としてOSS向けに出してきた点です。善意のように見える一方で、公開ソフトウェアの世界にAIの判断がじわっと入り込んでいく感じがします。

特に気になったのは、人間のレビューやトリアージを前提にしない、というところです。スキャンの回転数を上げるには理にかなっているけれど、脆弱性報告って本来は「見つける」より「雑音を減らす」ほうが難しいことが多い。もし誤検知が多ければ、保守者は無料どころか余計な負担を背負うことになる。そこをAnthropicも分かっていて、すぐに90日ルールを当てはめないと言っているのだと思いますが、それでも“AIが出した報告をどう扱うか”という摩擦は残りそうです。

一方で、Dockerfileでオフライン実行できるようにする設計はかなり現実的だと感じました。脆弱性診断の自動化は、結局のところ再現性と環境構築でつまずきがちですから、そこを先に仕組み化しているのは筋がいいです。OSSの保守って、コードを書く時間より「動く環境を作る時間」のほうが重いことがあるので、このあたりは現場のしんどさをちゃんと見ている気がしました。

ただ、Anthropicが「2年後にはAIが防御に有利になる」と見るなら、攻撃側も同じだけ賢くなるはずで、その均衡がどう動くかはまだ読めません。こういう取り組みは歓迎したい。でも、無料であること以上に、報告の質と運用の静かさをどこまで保てるかで評価が決まるのではないかと思います。

参考: Anthropic Launches Free AI Vulnerability Scanner for Open-Source Projects

同じ著者の記事

便利なのはモデル本体より、届くかたちで出てくる答えのほうだと思った

この記事でまず引っかかったのは、「強いモデルを使わせる」のではなく「強いモデルが見つけたものだけ渡す」という切り分けのうまさです。セキュリティの世界では、万能な頭脳を公開するより、診断結果や suggested patch だけを配るほうがずっと現実的なんだろうなと思いました。攻撃用のプロンプトをそのまま叩けないようにする設計も、かなり筋が通っています。 ただ、読んでいて少し冷めた気持ちにもなりました。$35mn の credits は大きい額に見えるけれど、結局それは「計算資源の補助」であって、人手不足そのものは埋めないからです。脆弱性を見つける速度が上がっても、直す側の速度が追いつかなければ、現場には未処理の山だけが残る。この当たり前が、こういう記事だとむしろ強く見えてきます。Open source の保守って、モデルを使えるかどうかより、誰が最後にパッチをレビューしてマージするのかのほうがずっと重い。 それでも、モデル本体を開放しないまま防御側にだけ成果を渡す、という発想はかなり今っぽいです。AI を「能力の公開」ではなく「結果の流通」に寄せていく。危険を減らしながら実務に載せる

papoo.work

AIの安全性は「証明」より「点検」に近い

この記事を読んでまず思ったのは、AIの安全性ってやっぱり一発で白黒つくものではないんだな、ということだった。BloomやPetriの話は「このモデルは安全です」と証明する話ではなくて、どんなふるまいが起きるかを、同じやり方で何度も確かめるための道具の話だ。ここがかなり現実的で、好感が持てる。 特に引っかかったのは、評価のスコアをそのまま「安心材料」にしてしまいそうな空気を、記事がかなり強く牽制している点だった。例えば、あるベンチマークで良い結果が出ても、それはその評価条件の中での話にすぎない。実運用では、プロンプトの書き方も違うし、接続しているツールも違うし、権限設定も違う。つまり、モデル単体のテストと、業務の中で動かすテストは別物だ。これは当たり前なんだけど、AIの話になるとつい忘れられがちだと思う。 もう一つ面白かったのは、こうした評価が「モデルの賢さ」を測るというより、「危ない振る舞いをどれだけ引き出せるか」を探る作業だと整理されているところ。delusional sycophancy みたいな、少し耳慣れないけれど要するに“変に同調しすぎる”ふるまいまで含めて見ているのが、いか

papoo.work

1本の記事より、「攻撃側の手つき」が気になった

この記事を読んで最初に思ったのは、もう「AIが脆弱性を見つける」より、「AIを使って攻撃の作業をどこまで雑に、どこまで速くできるのか」のほうが現実味を帯びてきたな、ということだった。 防御の文脈でAI活用はよく語られるけれど、実際には攻撃者のほうが手順の自動化に向いている場面が多い。発見から再現、PoC作成、修正の試行錯誤まで、面倒な繰り返しをかなり削れるからだと思う。 それで少し引っかかるのは、こういう話が出るたびに「AIが危険だ」で終わってしまいがちなことだ。そこよりも、作業のボトルネックがどこにあったのかを見るほうが本質的ではないかと思う。 たとえば patch を読んで exploit に落とす流れは、昔から人間には地味で時間のかかる仕事だった。そこに Claude Code のような coding agent を挟むと、単なる補助ではなく、かなり実務の中心に近いところまで入ってくる。ここが一番ぞっとするし、同時に面白い。 ただ、AI がすべてを自動でやってくれるわけではないはずで、最後に効いてくるのは人間の見立てだとも感じた。どこが本当に脆いのか、どの失敗はノイズで、どの失敗

papoo.work

AIエージェントの信頼は、そんなに簡単に置けない

この記事を読んでまず思ったのは、「新しい仕組みなのに、やられていることは昔ながらの injection と SSRF なんだ」という妙な既視感でした。MCP だの A2A だの名前は新しくても、結局は「他の相手が言ったことを、信じてそのまま実行してしまう」設計の弱さが突かれている。AI っぽい華やかな話に見えて、足元はかなり地味な脆弱性の積み重ねです。 特に引っかかったのは、エージェント同士のやり取りで“信頼の受け渡し”が雑になりやすい点です。人間なら「この依頼元は誰か」「この内容は本当に実行していいか」をなんとなく疑いますが、エージェントは役割分担が進むほど、受け取った指示を業務フローの一部として素直に流してしまう。そこに悪意ある文字列が紛れ込むと、最初の agent がただの運搬役になって、次の agent が本来なら通さないはずの操作までしてしまう。記事の言う “protocol pivoting” という名前は、たしかにその危うさをうまく言い当てていると思います。 それと、MCP が「広く使われ始める前に十分に鍛えられていない」という指摘も重いです。新しい標準は、便利だからこそ

papoo.work

固く縛ったつもりでも、すり抜けるのか

「ピン留めしたはずの plugin が、別のコードにすり替わる」という話を読むと、まず少しぞっとする。 ユーザーが“この版なら安全だろう”と思っている一番の前提が、実際には確認されていなかった、ということだからだ。commit hash で版を固定したように見せても、手元の agent が最後に実物チェックをしていなければ意味がない。ここはかなり嫌な穴だと思う。 特に引っかかったのは、責任の置き場所がかなり分散していて、しかも最後はユーザー側の実行環境に寄っている点だ。marketplace を見ても直せないし、repository owner が悪用できる余地もある。こういう supply chain 系の問題は、どこか一箇所を直せば終わりにならないのが厄介だが、今回もまさにそれだった。 「安全な版を選んだから大丈夫」という感覚が、AI coding agent ではもう信用しにくいのだと思う。 もう一つ、少しモヤっとしたのは、ベンダーごとの扱いがかなりばらついていることだ。Claude Code と Codex は直ったと言われる一方で、Copilot は未修正、Gemini CL

papoo.work

ClaudeでOpenAIを破る話を読んで

いちばん引っかかったのは、「AIがAI企業を守る」どころか、逆にAIを使ってその防御をすり抜けた、というねじれ方です。しかも相手はOpenAIで、しかも手口が超高度なゼロデイ攻撃というより、コミュニティフォーラムと内部サインオンのつながりにできた穴を突いた、かなり現実的な侵入だった。派手さより、地味な弱点が結局いちばん危ないのだと感じました。 Bug bountyで研究者に報酬を払って脆弱性を探してもらう仕組み自体は、健全だと思います。悪用される前に見つけるための、かなり重要な安全弁なので。ただ、その結果として「Claudeを使ってOpenAIに入れた」という見出しが立つと、AIモデルの賢さよりも、運用のつなぎ目の脆さのほうが前面に出てきます。モデル同士の能力競争が進むほど、結局は周辺システムの設計力が問われるんだな、と改めて思いました。 それと、Anthropicが「AIが自分たちの次世代モデルづくりに使われている」とデータを出している部分も、少し怖い。研究開発の26%がClaude主導だとか、90%のタスクで人間と協働しているとか、便利さの説明としてはよく分かるのですが、同時に「A

papoo.work

OpenAIの穴が6,500ドルだった、という違和感

まず引っかかったのは、侵入口そのものよりも「それに対して何が払われたか」だった。OpenAIの内部コードや社員アカウントにたどり着ける経路が見つかって、修正まで14時間、報奨金は6,500ドル。金額だけ見ると、かなり軽い。しかも、これはAIが暴れた話というより、古典的なweb vulnerabilityを突いた話だというのが面白い。派手な見出しにすると「ClaudeがOpenAIを突破」となるけれど、実態はもっと地味で、でもその地味さのほうが怖い。 この記事を読んでいて、いちばん納得したのは「AIが壊した」のではなく「発見と悪用の速度が縮んだ」という見方だった。昔からある脆弱性でも、攻撃側がClaudeみたいな tool を使うと、つながりを見つけるまでが一気に早くなる。つまり問題は、モデルそのものの賢さというより、穴を見つけてから突くまでの時間が短すぎることなんだと思う。守る側も同じ加速に乗れればいいけれど、実際には検知のほうが追いついていないらしい。そこはかなり嫌な現実だ。 あと、記事がわざわざ「これは breach ではなく bug bounty の流れだ」と線を引いているのも印

papoo.work

Claudeに手伝わせてOpenAIを抜く、という不穏さ

まず感じたのは、これが「AIが攻撃を自動化する未来」の話というより、もうその入口に片足が入っている、という嫌な実感だった。しかも攻撃の主役が国家レベルの高度な集団ではなく、3人の研究者とサブスクリプションの組み合わせだというのが生々しい。特別な設備や巨大な予算がなくても、LLMをうまく使えばかなり深いところまで行けてしまう。その事実のほうが、見出しの派手さよりずっと重いと思う。 ただ、ここで少し引っかかるのは、Claude が「何でも突破できる魔法の道具」だったわけではないことだ。記事を読む限り、実際には腐った画像ファイルや Discourse の HEIF 処理の弱点を突く、かなり古典的な脆弱性探索の文脈に AI を差し込んでいる。つまり、AI がゼロからハックを生み出したというより、面倒な試行錯誤を高速化した感じに近い。ここは誇張して読まないほうがいいと思う。 それでも気味が悪いのは、こういう使い方が「研究用途」と「悪用」の境目をどんどん薄くすることだ。修正が入れば終わる個別のバグ報告の話にも見えるけれど、同じ手口を別の会社に短時間で移せる、という部分が本当なら話は違う。攻撃そのも

papoo.work

AIが強いほど、穴は早く見つかるのかもしれない

この記事を読んでまず思ったのは、攻撃そのものより「そこまで短時間で繋がってしまうのか」という怖さでした。画像アップロードと内部GitHubリポジトリが、たった2つの脆弱性をつなぐだけで一本道になる。しかも72時間以内。人間の目で探していたら見落としそうな細い継ぎ目を、Claude Opus 5 が埋めるように見つけた、という話はかなり生々しいです。 面白いというより、ちょっと意地悪な現実だとも感じました。AI はコードを書くだけでなく、攻撃の手順を組み立てる側にも回れる。しかも「できる／できない」ではなく、「どれだけ速く、どれだけ広く試せるか」に効いてくる。防御側にとっては、脆弱性そのものより、複数の弱点がつながった瞬間に何が起きるかを想像する負担が一段上がったんじゃないかと思います。 一方で、こういう話は「AI が危険だ」で終わらせるには少し雑すぎるとも感じました。本当に見ておくべきなのは、モデルの賢さよりも、システムの継ぎ目のほうではないでしょうか。画像アップロード、権限、内部リポジトリ、こういう普通の部品が、単独では小さいのに、連鎖すると急に危険になる。その連鎖を人間がどこまで想

papoo.work

Gitの設定が、こんなふうにAIエージェントを裏切るとは

最初に思ったのは、「AIそのものより、周辺の雑な前提のほうがずっと危ない」ということだった。記事の中心にあるのはモデルの誤作動ではなく、Gitがもともと持っている“普通の機能”だ。そこにAI coding agent が組み合わさると、ただリポジトリを開いただけで、しかもユーザーの承認を待たずにコマンドが走る。かなり嫌な形の事故だと思う。 特に引っかかったのは、攻撃が成立する条件が「普通の clone ではなく、.git ディレクトリ付きで届いたファイル」である点だ。これ、たしかにアーカイブや共有ドライブ、USBメモリなら起こりうる。つまり、開発者が「自分で clone したから安全」と思っている場面より、日常の受け渡しのほうが危ない。セキュリティ事故って、こういうふうに利用者の直感の外から入ってくるのが厄介なんだよなと思う。 もう一つ印象に残ったのは、複数の製品で似た穴が並んでいたことだ。Claude Code、Codex、Cursor、goose、Qwen Code、Grok Build、Hermes Agent と、名前が違っても起きていることはかなり近い。AIエージェントが「賢

papoo.work