.@trailofbits の Buttercup チームが今、AIxCC のステージで私たちの競争戦略について話しています。コアチーム(コア8人+~3人の傭兵)は次のとおりです。

私たちの戦略の指針となる原則。TLDR 仕事に最適なツールを使用してください。LLM が魔法のように得意であるとは期待しないでください。

元のキンポウゲのデザインは大幅に洗練されていました。ルールに準拠し、チームのリソースの制約を考慮して削減されました。

準決勝ではかなり良い成績を収め、多くのファーストブラッドを獲得しましたが、Javaのバグファインダーが壊れてしまい、その理由はまだわかりません。

準決勝は私たちの全体的なアプローチを証明しましたが、決勝戦の規模の大幅な拡大に対応するために調整が必要でした。私たちはプロトタイプを捨てて、決勝に向けてゼロから始めました。

Henrik は、コンペティション API にどのように、何を、いつ提出するかというオーケストレーターに取り組みました。私たちは、提出物に対する信頼を最大限に高めるために、常にPoVを要求することにしました。

Run は脆弱性検出エンジンに取り組みました。標準の oss-fuzz ファザーを使用しました。LLM がファザーのカバレッジ獲得を支援する共有コーパスを使用しました。

Ronald は、脆弱性検出エンジンに取り組みました。標準の oss-fuzz ファザーを使用しました。LLM がファザーのカバレッジ獲得を支援する共有コーパスを使用しました。

Ronald は、脆弱性検出エンジンに取り組みました。標準の oss-fuzz ファザーを使用しました。LLM がファザーのカバレッジ獲得を支援する共有コーパスを使用しました。

パッチャーは、マルチエージェントシステム、6k行のコード、LangChain/LangGraph、非推論GPT-4.1です。セキュリティエージェントが根本原因を特定し、エンジニアエージェントがテスト手順を検索し、QAエージェントがパッチを検証します。失敗した場合、Reflection エージェントは戦略を調整します。

エキシビションラウンドでは、第1ラウンドで先制点を奪い、第2ラウンドで激しくクラッシュし、第3ラウンドで立ち直りました。ラウンド 1 ではリソース効率が高く、LLM 予算 $30k のうち $1k しか使用しませんでした。ラウンド 2 では、小さなタイプミスがあり、すべてがクラッシュしました。

採点ラウンドでは、限られた予算(利用可能な半分)で、高い精度で、すべてのタスクで高得点のバグがたくさん見つかりました。また、他のCRSでは見つからなかったバグが少なくとも1つ見つかり、新しい領域をカバーしたことがわかります。

どうしてこんなに良いスコアを決めたのか?90%の精度で、すべてのタスクでスコアを獲得し、すべてのバグに対して高品質のパッチを作成しました。

先月、ラップトップで動作するキンポウゲの縮小版を作成しました。賞金の一部で維持するつもりです。現在はオープンソースです!