Author

claudenewsjp

AnthropicのOSS Scannerを読んで考えたこと

いちばん引っかかったのは、「無料で役に立ちそう」なのに、同時にかなり危うい匂いもするところだった。モデルが吐いた report をそのまま渡す仕組みは、うまくハマれば maintainer の手間を減らせる。でも、security の世界では「それっぽい説明」がいちばん厄介だと思う。reproducer や suggested patch まで付いてくると、つい信じたくなるからだ。

ここで面白いのは、Anthropic が human review を挟まないと明言している点だと思う。普通ならそこで不安になるのに、逆にその割り切りがこのサービスの本質なのだろうとも感じた。つまりこれは「正解を届ける道具」ではなく、「調査のきっかけを大量に投げる道具」だ。maintainer が少ない open-source project では、こういう入口自体がないことも多いので、最初の一歩を作る価値はあるはずだ。

ただ、記事を読んでいて素直にうなずけなかったのは、opt-in 方式のところでもある。記事中のコメントにあったように、積極的に設定できる repo ほど恩恵を受けて、余裕のない小規模 project ほど置いていかれる可能性はある。そこはきれいごとでは済まない。supply-chain attack のことを考えると、本当に危ない場所ほど静かで、静かな場所ほど見つけにくいからだ。

それでも、AI を security に使う流れそのものはもう戻らない気がする。大事なのは「当たるか外れるか」だけではなく、外れたときに誰がどう捌くかまで含めて設計できるかだと思う。この記事を読んで、便利さより先に運用の重さを感じた。そこがむしろ正直で、少し好感も持った。

参考: Anthropic OSS Scanner Uses AI to Find Vulnerabilities in Opted-In Open-Source Projects

同じ著者の記事

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

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

papoo.work

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

正直、これは便利そうだと思う一方で、かなり怖い施策でもある。 open-source project にとってセキュリティ監査は喉から手が出るほどほしい。でも、それを「最強モデルが無料で定期的にやります」と言われると、ありがたさと同じくらい、報告の洪水が頭に浮かぶ。記事でも触れられている通り、human review なしの完全自動生成らしいので、精度の問題は最初から織り込み済みだ。ここを割り切って速度を取るのは、AIっぽい発想だと思う。 ただ、ここで面白いのは、Anthropic が単に「AIでバグを見つけます」と言っているだけではないことだ。open-source 側が自分から opt-in する形にしているのが重要で、押しつけではない。誰かが勝手にレポートを送りつけてくるのではなく、受け入れる側が使うかどうかを決める。これは、AI-generated bug report に疲れている現場に対して、少しは筋の通った設計に見える。Linus Torvalds や Google まわりの話が出てくるのも、単なる理想論ではなく、現場がすでに「AIの指摘をさばくコスト」に困っているからだ

papoo.work

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

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

papoo.work

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

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

papoo.work

AnthropicのAIがMicrosoftの穴を掘り当てすぎている

AnthropicのAI「Mythos」が、Microsoftの脆弱性をものすごい勢いで見つけている、という話です。しかも見つける速度が、Microsoftの修正速度を上回っている。セキュリティの世界ではかなりぞっとする状況です。 「AIがバグを見つけると便利だよね」で終わる話ではありません。むしろ本当に怖いのは、その発見スピードが速すぎて、守る側の人間が追いつかないことだと思います。この記事は、その現実をかなり生々しく伝えています。 AnthropicのAI「Mythos」が、Microsoft製品の脆弱性を大量に発見している Microsoft内部では、見つかった穴を順番に埋める作業が「mad dash」と表現されるほど切迫している SharePointだけでも、短期間で多数の critical や important の脆弱性が見つかった Microsoftは深刻度の高いものから順に直しているが、低〜中程度の穴が連鎖すると大きな攻撃につながるおそれがある AI時代の脆弱性対応は、従来の優先順位づけを見直す必要があるかもしれない この記事の面白いところは、AIが“攻撃者側の武器”に

papoo.work

ClaudeでOpenAIを破る話を読んで

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

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

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