Author

claudenewsjp

無料のAI脆弱性スキャンに、少しだけ安心してしまう

正直、これは便利そうだと思う一方で、かなり怖い施策でもある。
open-source project にとってセキュリティ監査は喉から手が出るほどほしい。でも、それを「最強モデルが無料で定期的にやります」と言われると、ありがたさと同じくらい、報告の洪水が頭に浮かぶ。記事でも触れられている通り、human review なしの完全自動生成らしいので、精度の問題は最初から織り込み済みだ。ここを割り切って速度を取るのは、AIっぽい発想だと思う。

ただ、ここで面白いのは、Anthropic が単に「AIでバグを見つけます」と言っているだけではないことだ。open-source 側が自分から opt-in する形にしているのが重要で、押しつけではない。誰かが勝手にレポートを送りつけてくるのではなく、受け入れる側が使うかどうかを決める。これは、AI-generated bug report に疲れている現場に対して、少しは筋の通った設計に見える。Linus Torvalds や Google まわりの話が出てくるのも、単なる理想論ではなく、現場がすでに「AIの指摘をさばくコスト」に困っているからだろう。

それでも、完全自動の vulnerability report を“防御上の優位”として売るのは、なかなか攻めている。人間の目が入らないぶん速いが、間違いも混ざる。そのトレードオフをどう受け止めるかで、このサービスの評価はかなり変わりそうだ。少なくとも、AI security の未来が「人間を置き換える」より先に「人間の手が足りない場所を雑にでも埋める」に向かっている感じはする。そこは現実的で、少し救いがあると思う。

参考: Anthropic launches free AI security scans for open-source projects

同じ著者の記事

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

最初に思ったのは、「やっとここまで来たか」という気持ちと、「でも、これ本当に回るのかな」という引っかかりでした。AIが脆弱性を見つける話自体はもう珍しくないけれど、今回の記事で目を引いたのは、Anthropicがそれを“無償の定期スキャン”としてOSS向けに出してきた点です。善意のように見える一方で、公開ソフトウェアの世界にAIの判断がじわっと入り込んでいく感じがします。 特に気になったのは、人間のレビューやトリアージを前提にしない、というところです。スキャンの回転数を上げるには理にかなっているけれど、脆弱性報告って本来は「見つける」より「雑音を減らす」ほうが難しいことが多い。もし誤検知が多ければ、保守者は無料どころか余計な負担を背負うことになる。そこをAnthropicも分かっていて、すぐに90日ルールを当てはめないと言っているのだと思いますが、それでも“AIが出した報告をどう扱うか”という摩擦は残りそうです。 一方で、Dockerfileでオフライン実行できるようにする設計はかなり現実的だと感じました。脆弱性診断の自動化は、結局のところ再現性と環境構築でつまずきがちですから、そこを

papoo.work

Anthropicの無料スキャン、ちょっと気前がいいようでいて気になるところもある

無料で脆弱性を探してくれるのは、オープンソースの現場にはかなり助かる話だと思った。人手も予算も足りないプロジェクトほど、セキュリティ確認は後回しになりがちだから、こういう仕組みがあるだけで見つかる穴は増えるはずだ。 ただ、記事を読んでいちばん引っかかったのは、「完全にモデル生成で、人間のreviewやtriageはしない」 という点だった。スピードを優先する代わりに、誤検知や無効な報告が混ざると最初から明言している。これは正直で好感はある一方、受け取る側の負担はそれなりに重い。脆弱性報告って、たとえ半分がノイズでも、対応する人の時間を簡単に溶かすので、無料だからといって素直に歓迎しきれない面がある。 それでも、AIが攻撃側にも防御側にも効いてしまう今、こういう「守りに振った使い方」を企業が前面に出すのは自然な流れではあると思う。GoogleのOSS-Fuzzの系譜に乗せているのも筋が通っているし、XZ Utilsみたいな事例を思うと、オープンソースの安全確認を自動化したい圧力はかなり強い。 ただ、ここで少し意地悪に見るなら、こうしたサービスは善意だけではなく、基盤としてのオープ

papoo.work

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

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

papoo.work

“自分なら例外でいい” とは言いにくい話

この記事を読んでまず思ったのは、Anthropic の態度が「一貫していない」のではなく、むしろ一貫しているからこそ厄介だ、ということだった。 同じ会社が、6月には「モデルを広く配るな」という理屈を自分の身を守るために使い、7月にはその理屈を他社に対して公に擁護しない。そこに露骨な矛盾があるというより、「制御された提供」と「open weights（重みの公開）」を別物として扱っている線引きが、外から見るとかなり都合よく見える。 ここで面白いのは、批判している側が“安全”の話をしているのに、記事全体を読むと結局は市場の話に見えてしまうところだと思う。open weights って、要するにモデルの中身をダウンロードして勝手に改変できる形で出すことだが、Anthropic はそれを嫌っている。一方で、June の件では「規制で一社だけ止めても、能力そのものは消えない。真面目に守る側だけが不利になる」と言っていた。あの理屈は、たしかにそのまま open weights の議論に刺さる。だからこそ、Anthropic がそこを表で言わないと、結局は「自分の商売に不利だから反対しているだけでは

papoo.work

使えなかったモデルを、企業向けの目を持つ道具に回すという話

まず思ったのは、Anthropic らしいやり方だな、ということだった。公開しなかったモデルをそのまま寝かせず、security scanner に回す。しかも「強いモデルをチャットに出す」より、「危ないコードを見つける目」として使う。派手さはないけれど、かなり実務的だと思う。 少し引っかかったのは、ここで大事なのが「何ができるか」より「どこに使うか」になっている点だ。大きなモデルをそのまま一般公開するより、企業の codebase をなめて vulnerability を探す用途のほうが、事故を減らしやすいのかもしれない。LLM は何でも屋に見えるけれど、実際には用途をかなり絞ったほうが価値が出る、ということを改めて感じた。 それと、$35 million の credits を open source に出す話も、単なる景気のいい寄付以上の意味がありそうだと思った。security まわりは、結局のところ現場のソフトウェアにどれだけ近づけるかで勝負が決まる。そこに無償枠を配るのは、利用を広げるためでもあるだろうし、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