8 ポイント 投稿者 GN⁺ 2025-10-03 | 1件のコメント | WhatsAppで共有
  • Joshua Rogers が自身の AIベースのツールセット を使い、curl のコードベースから大規模な潜在的問題の一覧を発見
  • この一覧には、些細なコードスタイルの欠陥だけでなく、小さなバグや 潜在的なセキュリティ上の欠陥 も含まれる
  • 見つかった問題の大半は 小さなバグ だが、1〜2件はセキュリティ面で致命的な欠陥である可能性がある
  • これまで見つかっていなかった問題であり、実際に非常に価値のある結果
  • 報告内容に基づき、22件のバグ修正がすでに完了 している状態
  • なお、未確認の問題がまだその2倍以上残っており、引き続きレビューと修正が進められている
  • 詳細な問題は "Reported in Joshua's sarif data" と記されており、関心があればそのデータを直接確認できる

1件のコメント

 
GN⁺ 2025-10-03
Hacker Newsのコメント
  • これこそ自分が考える理想的な「AIコーディング伴走者」の姿だと思う
    コードを直接書いたり直したりするのではなく、コード内の怪しい箇所や、自分がもっと詳しく確認すべき場所を教えてくれる役割を期待している
    Claudeに自分の2万行あるCライブラリのバグを探してくれと頼むと、ファイルを分割して特定のコードパターンをgrepするようなやり方になり、結局は自分のFIXMEコメントを並べるだけになる(笑)
    実際のところ単純なbashスクリプトでもできる程度で、かなりがっかりする
    ChatGPTはそれ以上に役に立たず、ただ「全部よさそうです! すごいです! ハイタッチ〜」と繰り返すだけだ
    これまで実際のバグを見つけるには従来の静的解析の方がはるかに役立ってきたが、静的解析がクリーンだからといって論理バグがないことを意味するわけではない
    まさにこの点でLLMが真価を発揮すべきだと思う
    もしLLMからより有用な潜在バグ情報を得るのに非常にカスタマイズされた環境が必要だとしたら、静的解析ツールも複雑な設定を求めると使われにくいのと同じで、結局は実用性が下がる
    • 多くのプログラマーは(特に繰り返しコードを除けば)自分で設計してコーディングするのは好きでも、コードレビューはあまり好まないという点は、ほとんど議論されていない
      AIがコードを書き、プログラマーはレビューだけをするべきだという方向性は、どこかおかしい流れに思える
      もちろん「コード行数が増えますよ〜」という売り方をしたい理由は理解できる
    • Claudeで上のような残念な結果が出たときは、「どんなプロンプトが有効かをClaude本人に直接聞く」というやり方がうまくいくことが多い
      たとえば「Claude CodeにFIXMEやTODOのようなコメントを無視させて、論理バグを効果的にレビューする計画を立てさせるには、どんなプロンプトを書けばいいですか?」と尋ねる
      得られるプロンプトは長いのでここには書けないが、gistで公開されている例で見られる
      その結果をもとに改善を重ねて、エージェント化することもできる
    • Cursor BugBotはこういう役割にかなり向いている
      無料トライアル後、うちの開発チーム内で評判がよかったので正式導入した
      たまに誤検知はあるものの、非常に有用だ
      PR作成者とレビュアーの両方にとって大きな時間節約になる
    • Claudeに「特定のエンドポイントで応答速度が遅いバグがあるが、CPU/メモリ使用量やDBとの関連はない。原因は何でしょう?」と聞くと、何度かやり取りした末に本当に見つけにくいバグのヒントを得られたことがある
      以前なら数時間かかっていたはずの問題を、手がかりを得て解決できたことがあった
      こうした形でのAI活用には大きな期待を持っている
    • GPT-5はこういう場面で以前のモデルよりずっとお世辞っぽくない
      「全部よさそうです」のような返答が出たというのは少し意外だった
      Codex CLIで使うと、しばしば疑問を投げかけてくれる
      Gemini 2.5 Proもこの点では悪くない
  • curlとAIの話でポジティブなエピソードが出てくるとは本当に予想していなかった
    経緯を知るには curl+AI関連のHN検索リンク を見るとよさそう
    • Daniel StenbergがAIバグレポート関連で過去にいろいろ問題を抱えていたにもかかわらず、今回寛容な姿勢で臨んでいるのは本当にすごいと思う
  • ポイントは「ツールセット」だということに見える。自動操縦と取り違えず、適切にツールを組み合わせてシステムのように使っている
    • 寄稿者は本文でさらに詳しく説明しているのだと思う 参考ブログ(Mastodon言及: 関連リンク
    • 議論が「自動運転 vs. 放任」のような二項対立に矮小化されているのが残念だ
      結局のところ、きちんと理解して使う人と、単に雰囲気でコーディングする人の違いに帰着するという見方が正しい気がする
    • Stenbergはツールセットとして描写していたが、実際にそのツールを使った貢献者本人がどう考えているのかも気になる
  • curlリポジトリには「sarif data」に言及したclosed PRが55件あり、今回言及されたPRはまさにこのグループだ
    Daniel Stenbergが過去にAI製の雑な誤ったセキュリティ問題報告に悩まされていたこととは対照的だ
    HackerOne関連では、「AIが作ったゴミみたいな問題報告をする人は即バンにする。実質DDoS攻撃レベルだ。時間の浪費について請求したいくらいだ」と述べていた
    今年1月のDanielのブログ記事も参照: The I in LLM stands for Intelligence?
    • 一部のバグ(例: size_tで誤ったprintfフォーマット指定子を使っているケース)は、コンパイラのwarningフラグを適切に設定するだけでも検出できる
      「重要なコンパイラ警告フラグが不足しています」とAIが助言してくれるのはかなり有用だろう
      一部のPRはdependabotとの一致によるもののようで、「Joshua sarif data」で検索すれば、より具体的なPR一覧が見られる リンク
    • 当時使われていたモデルはかなり進歩したように見える
      Daniel Stenbergの印象が変わった理由もそこにあるのではないかと思う
  • 商用SASTスキャナーの中には優れたものもあるが、大半は満足できるものではない
    AIベースのSAST技術を導入しようという主張は多く、実際に関連製品も出ているが、ほとんどはまだ期待外れだ
    がっかりするだけならまだいいが、悪い場合には誤ったセキュリティへの信頼を生み、危険でもある
    AIベースSASTスキャナーに対する批判的な見方とその根拠は ここで紹介されている
  • 具体的にどのAIツールだったのか、すぐには把握しづらかった
    既存のさまざまなツールがバグを見つけられなかった中で、今回の戦略がなぜより効果的だったのか気になる
    • 製品関連の章があるブログで、もう少し情報が得られる
      Mastodonのリンクは、誤ったコードスニペットがあっても実際にバグであることを確認するためのものだと推測する
  • 関連する話題として、「AIで何かをやっておきながら、自分が何をしているのか分かっていないケース」の例が紹介されている You did this with an AI and you do not understand what you're doing here