AIは確かに悪いことをするための言い訳としてかなり使われてるね。スタッフを大量に解雇したい？ - AI 消費者製品部門を切りたい？ - AI ソースを奪いたい？ - AI

彼らの製品はコモディティ化が進んでるね。

うーん、納得いかないな。もしセキュリティレポートが欲しくないなら、無視して自分たちの道を進めばいいじゃん。AIを責めるのは、ソースを閉じるための言い訳に過ぎないよ。もしAIに自分たちのコードを学ばせたくないなら、もう手遅れだよ。遺伝的アルゴリズムやファジングをAIに組み込めば、何百万倍も早く学習できるから、人間が学ぶ必要なんてないんだ。

人々は「プロ」機能を有効にしたり、LLMを使ってそれを簡単に実装するための適切な拡張ポイントを見つける方法を見つけていると思う。セキュリティは見せかけに過ぎないよ。

ここに共同創業者がいるよ。隣の16歳の息子が、君のオープンソースプロジェクトをハックするのに15分と100ドルのClaudeコードクレジットがあればできるってさ。

これは隠蔽によるセキュリティじゃなくて、攻撃面をできるだけ減らすことだよ。

不明瞭さによるセキュリティは、それが唯一の防御層、または主要な防御層である場合に問題になるだけだよ。徐々に抑止力や遅延を加える層としては、全く有効な戦術だと思う。（ここでの理由についてはコメントしないけどね。）

LLMが見つけた問題を全て解決して「全てグリーン」の反応を得ることは十分可能だけど、それでも攻撃者がLLMが見つけられなかった問題を見つけることがある。彼らは別のモデルを使ったり、違うプロンプトを使ったり、君より多くのお金を使ったりするかもしれない。これは対称的なゲームじゃないんだ。防御側は毎回運が必要だけど、攻撃者は一回だけ運が良ければいいんだから。

もちろん、出荷する前にLLMによる監査はある程度必要だよね、一般的なPRプロセスの一部として。でも、脆弱性を見つけるためには何千回もセッションが必要かもしれないし、セキュリティチェックに時間がかかって変更を出荷するのを止めたくはないよね。

これは、資金が厳しいオープンソースプロジェクトにとっては、かなりのコストだよね。

LLMはコードの脆弱性を見つけるのが本当に得意だから、クローズドソースのコードでは、できるだけセキュアにするために使うことになると思う。でも、他の人がそれを使うためにドアを開けておくことはないよね。だから、残念ながら理解できる部分もあるかな…。

攻撃者は、ランダムに一つの脆弱性を見つけるのが得意であればいいけど、サービス提供者はすべての脆弱性を見つけるのが得意でなきゃいけないんだ。

リリース後、攻撃者はあなたのコードの各行に対して無限に時間をかけてLLMを使えるようになるんだよね。しかも、そのLLMは時間が経つにつれてどんどん賢くなって、運用コストも安くなる。だから、安心感を得るためには、リリースごとに攻撃者がやりそうなことを全部自分でやらなきゃいけないんだ。

どんな変更もシステムに脆弱性が追加される可能性をもたらすし、全コードベースに対してLLMスキャンを実行する必要があるんだ。定期的にコミットを行う環境では、かなりコストがかかるよ。GitHubみたいな会社はすでに静的解析用のスキャンツールを提供していて、そのコストも高いんだ。

LLMが進化して、採用が増えるにつれて、FOSSプロジェクトの維持がますます複雑で、時間や人手の面でも高くなってきてるよね。その点は分かりやすい。LLMを使ったユーザーが低品質な問題や疑わしいセキュリティレポート、うるさいPRを増やしてるのもトレンドになってきてる。これじゃオープンソース全体を維持する価値がなくなってきた感じがするよ。本当の理由がセキュリティじゃなくてマネタイズだとしても、その決定は理解できる。FOSSコアを中心にした商業製品から、こういうのがもっと出てくると思う。もう一つの失敗パターンは、メンテナがセキュリティの開示を特別なものとして扱わず、普通のバグと同じように扱うこと。libxml2みたいにね。そういう意味では、ChromiumがRustベースのXMLライブラリに移行するのも面白い展開だね。

今のAIの時代、監査がこれまで以上に安くなったから、セキュリティは問題にならないはずだよね。AIのメンテナンス不可能性の議論を使ったら、もっとクレジットあげるのに。

オープンソースライブラリには、どれくらい監査予算があるのかな？

この結論には納得できるけど、もしかしたら僕が単純すぎるのかも。こういう脅威のメディアの盛り上がりは、ミソスが出てきた時に始まったよね。あれって2、3週間前のことだし。そんな短期間でコアの原則を変えるのは難しいと思う。彼らは他のビジネス上の理由でこれをやりたかったけど、今は一般に売れる言い訳を見つけたって感じがするな。（ここは間違ってるかもしれないけど）

これは、専門家によって検証されたオープンソースライブラリが最も信頼されるという暗号ライブラリの教訓に似てるね。でも、一般的なオープンソースライブラリはそんなに厳しいチェックを受けることはないだろうね。結局、各カテゴリで人気のあるライブラリに集約される結果になりそう？

本当の理由は、誰かがAIを使って自分たちの製品を著作権で洗浄するのを避けようとしてるんじゃないかな。セキュリティを口実にしてるだけだと思う。

経済的に見ても理にかなった結論だね。それは、トークンのコストをカバーするだけの価値を引き出さなきゃいけないってことでもあるし、エクスプロイトを見つける経済的利益を減らさなきゃいけないってことでもある。経済的利益を減らすには、配布の範囲を狭めたり、システムの特権を減らしたりすることが重要だね。配布を減らす一つの方法は、価格を上げること。もう一つは、質の悪い製品を作ること。もちろん、価値の低いソフトウェアは望ましくない結果だよね。だから、オープンを維持するコストを減らすか（クローズにすることで）、オープンを維持するコストをカバーするために価格を上げるかのどちらかだね（これもまた配布を減らすことにつながる）。ソフトウェアの経済は今後数年で大きく再構成されるだろうし、特にオープンソースが影響を受けると思う。もっと「オープンスペック」なソフトウェアが増えて、実際のソースがモデルによってオンデマンドで生成されるようになるんじゃないかな。そうすれば、すべてのセキュリティやガバナンスはモデルレイヤーで行われることになる。

システムを強化するには、攻撃者がそれを悪用するために使うトークンよりも、エクスプロイトを発見するためにもっと多くのトークンを使わなきゃいけない。それは正しいのか？安定したソフトウェアがあれば、相対的な攻撃面はどんどん小さくなっていくはずだ。Mythosはエクスプロイトを生み出さない。守る側のメリットがあるはずだよね、トークン的に。

ありがとう！これを再投稿したよ：サイバーセキュリティは今やプルーフ・オブ・ワークみたいだね - https://news.ycombinator.com/item?id=47769089（まだコメントはないけど） * a la https://news.ycombinator.com/item?id=26998308

システムを強化するには、攻撃者がそれを悪用するのにかかるトークンよりも、脆弱性を発見するのにもっと多くのトークンを使わなきゃいけない これはある程度まで正しいけど、要件や契約自体に攻撃者が無限に悪用できる抜け穴がある場合は別だね。でも、そういうケースではないと思う。例えば、sort()にサービス拒否を引き起こす抜け穴が見つかったとしたら、その原因は実装自体であって、ソートの契約ではない。人間とAIがそれを見つけて、最終的には修正するだろうね。

長期的にはそうかもしれないけど、短期的には違うよ。それに、ホワイトハットがブラックハットと同じくらいモチベーションがあるとは限らないしね。保証がないプロジェクトではリスクは最小限だから、確かにメリットはあるよ。でも、cal.comみたいな商業プロジェクトでは、侵害が大きな責任を伴うから、短期的にリスクを取って長期的により良いソフトウェアを得る余裕はないんだ。

「Thunderbird、オープンソースのCal.com」

サインイン画面の前に、READMEかどこかにスクリーンショットを追加した方がいいよ。すごく良さそうなツールだね。ホスティング版はいくらなの？

そうでもないよ。オープンソースってのは、ソースを配布することを意味するだけだよ。CDかインターネットベースのプロトコルでね。もしかして、GitHubのことを言ってるのかな？