圧力
(daniel.haxx.se)- curlメンテナンスは公益性、エンジニアリング上の挑戦、品質目標が結び付いたフルタイムの仕事となっており、週50時間前後に及んできた
- curlは約300億件のインストール基盤を持つ転送ライブラリとツールであり、セキュリティ上の失敗がユーザーに波及しないようにしなければならないという重圧が大きい
- 現在のセキュリティ報告の流入は2024年より4〜5倍、2025年の2倍の水準で、平均すると1日1件を超えており、即時対応が必要になっている
- セキュリティ対応には、主張の検証、重要度評価、パッチ作成、導入時点の特定、勧告文の作成、研究者・セキュリティチームとのコミュニケーションまで含まれる
- 予定リリースまでにすでに確定済みの脆弱性12件が控えており、前例のない圧力の中で資金面と人員面の支援の限界が露呈している
curlへの責任感と長期メンテナンス
- オープンソースの仕事は金や華やかな生活のためではなく、社会的意義と公益性、そして誰にとっても動くものにするエンジニアリング上の挑戦があるからこそ続いている
- curlの作業は2019年からフルタイムとなり、通常は週50時間ほどを費やし、昼も深夜も、平日も週末も含めて続いてきた
- curlの目標は可能な限り最高の転送ライブラリとツールになることであり、オープンソースの品質・性能・セキュリティの面で最上位のプロジェクトになることだ
- curlは一人のプロジェクトではなく、チームメンバーがいなければ今のcurlは存在しなかったが、それでも多くの人はcurlをDaniel Stenberg個人と強く結び付けて見ている
- curlへの批判は、自分が支持したり自ら下した決定や選択への批判のように受け止められ、curlは人生を永久に変えた個人的なプロジェクトになった
- 2026年末にはcurlプロジェクトは30周年を迎え、世界中のcurlインストール数は約300億件と言及されている
セキュリティ報告環境の変化
- ここ数年のcurlのセキュリティ報告環境は、愚かなLLMへの不満から、AIスロップ報告、バグバウンティ終了、そして2026年3月ごろに始まった高品質な混乱へと変化してきた
- インターネット製品、ソフトウェア基盤、オープンソースで大きなセキュリティ事故が繰り返されるたびに、curlがあらゆる場所に存在するという事実と、そのようなことがcurlやユーザーに起きてはならないという圧力が強まっている
- curlプロジェクトは、より多くの点検、テスト、ガイドラインを追加しながら、欠陥が漏れたり致命傷になったりする可能性を少しずつ減らしてきた
高い検証水準と残るリスク
- Mythosが最初のスキャンで低深刻度の問題を1件だけ見つけたこと以降、curlは想像し得る範囲で最も多くレビューされ、ファジングされ、検証されたコードの1つだという評価が繰り返されている
- この状態は偶然や幸運ではなく、数十年にわたる執拗な作業、細部への注意、終わりのない反復改善の結果である
- レビューと検証が多いからといってバグやセキュリティ問題がないことを意味するわけではなく、curlは複数のプロトコル、OS、CPUアーキテクチャで高度に並列なネットワーキングを行う数十万行のCコードである
- 問題は見つかるたびに修正され、パッチがリリースされるという過程が繰り返される
- 約300億件の世界的なインストール基盤は、携帯電話、タブレット、自動車、テレビ、プリンター、ゲーム機、キッチン家電などにcurlが複数回含まれている可能性を意味する
- 過去に大きなバグで世界をしばらく騒がせたプロジェクトは注目を集め、その一部は資金と人員を得て複数のフルタイムエンジニアを雇えるようになった
前例のないセキュリティ報告量
- 現在のセキュリティ報告の流入速度は2024年より4〜5倍高く、2025年の2倍で、平均すると1日に1件を超える報告が届いている
- 報告の品質は以前よりはるかに高く、たいてい非常に詳細かつ長文で書かれている
- 報告が継続的に届くため、可能な限り到着次第処理しなければならず、到着速度に近いペースで処理しなければ潜在的なセキュリティ問題の一覧が積み上がり続ける
- 制御できない潜在的セキュリティ問題の一覧は精神的な負担になる
- 現在、時間の大半はHackerOneに報告されたセキュリティ問題一覧の処理に使われている
- 主な作業は、主張の検証、重要度評価、パッチ作成、バグが導入された時点の特定、脆弱性の理解、詳細なセキュリティ勧告の作成、セキュリティ研究者およびcurlセキュリティチームとのコミュニケーションである
健康とチームへの圧力
- 初めて配偶者が作業時間と不均衡なワークライフの状態を心配し、周囲の人々もこの大量流入をどうさばいているのか、そして燃え尽きる可能性を気にしている
- チームメンバーへの懸念も大きくなっており、近いうちに一息つく時間を確保するため、作業時間を減らさなければならないかもしれない
- 現在の状況は、curlプロジェクトとセキュリティチームのメンバーがこれまで経験したことのない圧力である
- セキュリティ問題の処理は、プロジェクト内の他のすべての仕事を押しのけるほど優先度が高く、責任感と良心、そして仕事への誇りゆえに無視しない
- curlが世界中の機器に配布されているソフトウェアである以上、その中のセキュリティ問題を修正しなければならないという義務感が強い
- 予定されたリリースまでにリリースサイクルが半分ほど残っている時点で、すでに確定脆弱性12件があり、これは発表待ちのCVEが12件あることを意味する
- これはプロジェクトの新記録であり、2026年が半分も過ぎないうちに公開CVEが30件に達することを意味する
- この傾向が続けば、2026年全体のcurl CVE公開数は少なくともその2倍になると見込まれる
必要な支援と構造的限界
- 短期的には、すでに処理しなければならない仕事が多すぎて、すぐに助けを受けるには遅すぎる状態である
- curlまたはlibcurlを商用ソフトウェアやサービスで利用し依存している企業が、より多くの資金支援を行えば、より多くの開発者に費用を支払い、作業負荷を分担できる
- サポート契約を通じて雇用主に費用を支払ってもらう方式も、支援の可能な経路である
- すでにこのような支援をしている顧客がいるため、一部メンバーはcurlにフルタイムで取り組むことができている
- ただし、この領域で意味のある変化がすぐに起こるとは期待しておらず、前例のない状況とより厳しい局面の中でも、結局は自力で嵐をやり過ごすことになる可能性が高い
- curlプロジェクトは会社の所有ではなく、どのアンブレラ組織にも属していない
- このような構造は時に資源不足を招くが、同時に最大限の自由と柔軟性をもたらす
- プロジェクトの行動基準は、世界とcurlユーザーのためにcurlを可能な限り良くすることに置かれている
前向きな面と現在の状況
- バグや問題を修正すること自体は良いことであり、報告された問題1件は、すなわち修正された問題1件を意味する
- 報告が増えるほどcurlはより良い製品になる
- ここ数年で見つかったcurlの脆弱性はすべて深刻度LOWまたはMEDIUMと評価されており、非常に深刻な脆弱性はほとんど見つかっていない
- 今後HIGHが再び出ないという意味ではないが、少なくともまれな状態である
- 直近の高深刻度のcurl CVEは、2023年10月に公開されたCVE-2023-38545である
- 現在、curlチームは圧力を受けており、時には応答が遅くなる可能性がある
1件のコメント
Lobste.rs の意見
Danielさんや他の方々が、健康や家族に大きな悪影響を受けることなく、この困難な状況をうまく乗り越えられることを願う。
とはいえ、これがどう展開するのかはかなり興味深い。新しい自動解析手法が複数の FOSS プロジェクトで突然たくさんの脆弱性を見つけたのは今回が初めてではなく、今は 2010 年代にグレーボックスファジングが登場したときに近い感覚がある。あり得る展開は 3 つあるように見える。A) 開発者が LLM をセキュリティ研究の流れに組み込み、LLM が見つける新たな脆弱性の数が大きく減り、LLM の手が届かない脆弱性は引き続きファザーが見つけるシナリオ。B) A に似ているが、LLM が一通りさらった後は脆弱性発見が事実上止まる、「LLM がセキュリティ研究を解決する」シナリオ。C) curl のような大規模プロジェクトで引き続き高い割合で脆弱性が見つかり、数十万行規模のコードを持つプロジェクトのバグ数は実質的に無限だという「Tony Hoare の復讐」シナリオ
特定のコードベースのスナップショットに存在し得るセキュリティバグの数は有限だ。セキュリティバグ探索空間が枯渇すれば洪水は収まり、その後はコードのマージ、新しいテストハーネス、モデル改善によって生じるバグが少しずつ残るだろう。
curl プロジェクトにおける C シナリオとの関係では、これまでのセキュリティテストや従来型のバグ発見手法の基準が高かったため、見つかったバグの深刻度は低かったのだと思う。これは、バグ発見への継続的な投資が長期的には報われ続けることを示している。今日であれ将来であれ、どんな発見手法があっても同じだ。
Marcus Hutchins の言葉を借りれば、「ボトルネックだったのはバグ発見ではなく、組織がセキュリティ研究者に投資しないと決めたことだった」という話に近い。LLM はその投資を安くしただけで、組織はもともと、もっと投資してもっと多くのバグを見つけることもできた。結局はポリシー判断だ
LLM 技術を作る企業は、自然界だけでなくソフトウェア世界も破壊している。ハードウェア価格が高騰することでパーソナルコンピューティング自体も脅かされており、作りたいから作っている善意のオープンソース開発者たちも同様だ。
既存のコミュニティ運営のオープンソースプロジェクトを貶めて壊すための資金は無限にあるように見えるのに、その後始末に使う金はまったくないというのが_興味深い_。
これは Zig が正しかったことを証明していると思う。LLM が見つけた CVE など相手にせず、やりたい人に任せておけばいい
これがまさに論点だとは思わないが、LLM CVE の問題は、同じツールを使う他の誰かもおそらくまったく同じものを見つけられる点にある。実際に重大な問題が見つかるなら、より多くの人がそれを使って有害な何かを作れるということだ。
もちろん、curl に殺到している低深刻度や非セキュリティ問題にこれがそのまま当てはまるという意味ではない。それでも、どの問題が高優先度なのかは実際に判断しなければならず、そうなるとまた振り出しに戻る
Zig はまだ活発に開発中で、たとえばインクリメンタルコンパイルや非同期 I/Oのような機能を具体化するたびに新しいバグを入れてしまう可能性が高く、同時に以前の実装が不完全だったために生じていたバグを取り除くこともある。
この開発段階で、誰かが Mythos のようなものを Zig に走らせて「すべてのバグを見つけてミスするな」という形で進めたら、膨大な量のレポートが出るだろうが、その全体は私たちにとって実質的に役に立たない可能性が高い。今のバグ報告の主な価値は、特定のユースケースで詰まっているユーザーがいるというシグナルを与える点にあり、優先度を付けると決めればそのユーザーを助けられるという点にある。
だからといって、この状態が永遠に続くわけではない。重要なコンパイラ機能の多くが整いつつあり、安定化したらすべてのバグを見つけて修正することが最優先になる。そのときは、バグが知られているという事実が発見手法とは無関係に重要になるだろうが、その問題はその時点で扱う予定だ。
それまでの方針は単純にLLM 禁止だ
LLM による貢献を禁止するのは理解できるが、賛成はしない。セキュリティ脆弱性は、どう見つかったかに関係なく脆弱性だ。
Daniel のやり方が最善だと思う。直せるバグを直してユーザーをより安全にし、その負担が大きいことを伝えて支援を求めることだ。彼がこれを読む可能性は低いだろうが、身体的・精神的健康を優先するために作業量を制限することも支持したいし勧めたい。世の中の大半は理解し、文句を言うのはごく一部だと思う
ここでは 2 つの重要な点が抜けているように思う。1) LLM 企業や Project Zero がそのセキュリティバグをコードに入れたわけではない。2) セキュリティバグの修正は、LLM 企業や Project Zero のためではなく、ユーザーのためのものだ。セキュリティバグが悪用されれば被害を受けるのはユーザーだ。
特に LLM が見つけたバグについては、複数のオープンソースプロジェクトで、同じ LLM を使う別の人たちが重複報告を上げているというシグナルがすでにある。したがって、防御側が手を引けば、攻撃側も LLM 発見バグを知ることになると想定すべきだ
「昔、世界をしばらく燃やし尽くしたひどいバグを配布したプロジェクトがうらやましい。彼らは注目を集め、その一部は資金と財政的な力を得て、スタッフを持ち、複数のフルタイムエンジニアを雇えた。ときどき、うちにもああいうのが一つあった方がよかったのではと思う」
こういうことは多くの職場でも起きる。失敗しているチームには人員が追加され、うまくいっているチームはひどいことが起きていないという理由でより少ない人数でより多くの仕事をしなければならない
curl のようなプロジェクトに合うかは分からないが、一定期間機能凍結して、入ってくるバグ/CVE 報告だけに集中するのは役立つだろうか。
機能セットが固定されているなら、潜在的なバグ/CVE の数は有限で、修正していけば 0 に近づくように思える。
とにかく、彼らの幸運を祈る。それほど重要なソフトウェアをメンテナンスする時期が楽なはずはない
開発者満足度に対しては、この順に増加、維持、低下として働く。
機能凍結はリリースをうまく締めくくるための優れた手段だが、自分で方向性を決めて働く開発者のプレッシャーを和らげるための手段としては適していない