Cal.com、AIセキュリティ脅威を受けてオープンソースからクローズドソースへ移行

 (cal.com)
2 ポイント 投稿者 GN⁺ 13 일 전 | 1件のコメント | WhatsAppで共有
  • 5年間オープンソースとして運営されてきたCal.comは、AIベースのセキュリティ脅威の増加を受けて、クローズドソースへの移行を決定
  • AIがコードベースを自動分析して脆弱性を見つける時代が到来し、公開コードが攻撃者に直接的な手がかりとなる状況が発生
  • 会社は顧客データ保護のため、オープンソース維持とセキュリティリスクの間で後者を選択
  • オープンソースの精神を引き継ぐため、Cal.diyプロジェクトをMITライセンスで公開し、コミュニティ向けのセルフホスティング版を提供
  • AIが既存のセキュリティ体制を圧倒する速度で進化する中、Cal.comはセキュリティ安定化後にオープンソースへ復帰する意向を明らかにした

Cal.comのオープンソース終了決定とAIセキュリティ脅威

  • Cal.comは5年間オープンソースとして運営してきたが、AIベースのセキュリティ脅威の急増により、**クローズドソース（Closed Source）**への移行を決定
    • 顧客データ保護を最優先に置き、オープンソース維持はもはや安全ではないと判断
    • 「簡単な選択ではなかった」と説明
  • 過去には、アプリケーションの脆弱性を悪用するには熟練ハッカーの時間と労力が必要だったが、現在はAIがコードベースを自動でスキャンして脆弱性を見つける時代へと変化
    • オープンソースコードは攻撃者に「金庫の設計図を渡すのと同じだ」と表現
    • AIセキュリティスタートアップがこの機能を商用化する中で、それぞれ異なる脆弱性を検出するため、信頼できる単一のセキュリティ基準を確立しにくい状況になっている
  • Cal.comは、2つの選択肢のうち1つを選ばなければならなかったと説明
    • オープンソースを維持しつつ顧客データのリスクを受け入れるか、
    • クローズドソースへ移行してリスクを減らすか
    • 完璧な解決策ではないが、ユーザー保護のための避けられない決定だと判断
  • オープンソースの精神を引き継ぐため、Cal.diyという別プロジェクトをMITライセンスで公開
    • Cal.diyは開発者や趣味ユーザーに開かれたバージョンで、セルフホスティング可能なコミュニティ中心の版
    • 本サービスのコードベースは、認証やデータ処理システムなどの中核構造が大きく変更されており、Cal.diyとは技術的に分離された状態
  • AIがセキュリティ環境を急速に変化させており、AIがBSDカーネルの27年前の脆弱性を数時間で発見し、エクスプロイトを生成した事例にも言及
    • このような速度と精度は、既存のセキュリティ対応体制を圧倒
    • Cal.comは顧客、アプリケーション、機密データを保護するために可能な限りの措置を講じており、 セキュリティ環境が安定すれば再びオープンソースに戻りたいという意向を示した

今後の方向性とメッセージ

  • 現時点ではセキュリティリスクの緩和とユーザー保護が最優先課題
  • オープンソースコミュニティとの関係はCal.diyを通じて維持
  • 長期的にはセキュリティ環境の進化に応じたオープンソース復帰の可能性を残す
  • 今回の決定は、AI時代のセキュリティ現実がソフトウェア配布モデルに直接影響を与えていることを示す事例

関連記事

1件のコメント

 
GN⁺ 13 일 전
Hacker Newsの反応

  • Drew Breunigが昨日投稿した記事では、真逆の結論に達していた
    今やセキュリティ脆弱性はトークンを使って見つけられる資源になったので、むしろオープンソースのほうが価値がある
    オープンソースでは複数のプロジェクトが監査コストを分担できるが、クローズドソースではすべての脆弱性を自力で見つけなければならない

    • その記事はこちらに再投稿されている。タイトルは Cybersecurity looks like proof of work now
    • 実際の理由は、AIが製品を著作権ロンダリング(copyright-wash) するのを防ぐためのように見える。セキュリティは言い訳に使っている印象
    • この結論のほうが説得力があるように聞こえる。Mythosが登場してまだ数週間しか経っていないのに、これほど素早く原則を変えるのは不自然。おそらくビジネス上の理由があり、今は大衆向けに売りやすい大義名分を探したのだろう
    • 経済的にも妥当な結論だ。結局のところ、トークンコストを賄えるだけの価値を生み出すか、脆弱性発見の経済的利益を下げる必要がある
      配布範囲を狭めたり、システム権限を下げたりすることで可能だ。
      今後は**「オープンスペック + モデルベースのコード生成」**という形に進化していく気がする。セキュリティとガバナンスはモデルレイヤーで行われる見通しだ
    • 「システムを強化するには攻撃者が使うトークンより多く使わなければならない」という話は奇妙だ。安定したソフトウェアなら攻撃面は縮小していくし、Mythosは新たな脆弱性を生み出さない。トークン面では防御側に優位があるはずだ

  • Thunderbirdプロジェクトの責任者です。私たちのスケジューリングツールThunderbird Appointmentは、今後もずっとオープンソースのままです
    GitHubリポジトリで一緒に作っていこうと招待している。Cal.comの代替になれるよう支援する予定とのこと

    • READMEやログイン前の画面にスクリーンショットを追加するとよさそう。ツールは良さそうだが、ホスティング版の価格が気になる
    • ただ、古いLinuxノートPCではThunderbirdが重すぎる。低スペック環境の利用者にも配慮してほしい。インターネットを手頃なものに保ってほしいという要望だ
    • サイトに入ってメールアドレスを入力したらウェイトリスト送りになり、結局メールをブロックした。ユーザー体験がよくなかった
    • 「一緒に作っていこう」という言葉に対して、冗談で「ではappointmentが必要ですか？」という反応もあった
    • 良い代替案に見えるという前向きな反応もあった

  • LLMがコードの脆弱性をそこまで見つけるのが得意なら、リリース前に自前のLLMペンテストを回せばいいのでは？
    Linusの法則(リンク)がようやく現実になった感じだ

    • ただしリリース後は、攻撃者が無限の時間と、ますます賢くなるLLMでコードを分析できる。
      防御するには、攻撃者がやることを毎リリースごとにすべて先回りして実行しなければならない
    • LLMの進化に伴って、FOSSメンテナンスの時間と人件費は急増する。
      AIが作った低品質なissueやPRが増え、オープンソースを維持するインセンティブが下がる。
      商用製品がFOSSコアを基盤にしている場合、こうした転換はさらに増えそうだ
    • クローズドソースでは、LLMを内部的に活用してセキュリティを強化できる。
      ただし外部に攻撃の機会を開かないために閉じるという判断も理解できる
    • コミットが頻繁な環境では、そのたびにコードベース全体をLLMでスキャンする必要があり、コストが爆発的に増える。
      GitHubのようなところでも、すでに静的解析コストは高い
    • 結局は単純なコードを書くこと、そしてコンパイラレベルでもLLMによるセキュリティテストを行うのがよいという意見だ

  • 今回の決定はセキュリティよりビジネス判断に見える。
    AIのおかげでセルフホスティングが容易になり、オープンソースプロジェクトの有料ホスティング収益が減っている

    • 人々はLLMを使って「プロ機能」を自作したり、拡張ポイントを見つけたりしている。セキュリティは見せかけにすぎない
    • AIを責めるのは言い訳だ。AIはすでにコードから学習済みだ。遺伝的アルゴリズム + ファジングを組み合わせれば、人間よりはるかに速く学習する
    • 最近は何でもAIのせいにされる。人員削減も、製品終了も、ソースコードの非公開化も、全部AIが理由だという話になる
    • Google Workspaceの予約ツールのように、製品はすでにコモディティ化しつつある
    • 結局「売り渡した人(sellout)」だという批判も出ていた

  • 潜在顧客として、Cal.comの決定には失望した。
    オープンソースは透明なSSDLCによって信頼を得られるが、クローズドソースではベンダーを信じるしかない
    Drew Breunigの主張には同意しない。バグの数は有限であり、十分に強力なモデルが定期的にコードをスキャンすれば、残っている脆弱性の確率は急減する

  • 「AIがオープンソースコードをスキャンできるなら？」→ ならバグを直せばいいだけ。
    この論理はまったく説得力がない

  • 「AIがコードにアクセスできるから閉じる」というのは単なる言い訳だ

    • 本当の理由はAIでもセキュリティでもなく、クローンプロジェクトが多すぎて収益が減ったからだ

  • こうした決定は結局隠蔽によるセキュリティ(Security through obscurity) に見える。
    いつからそれが正しいモデルになったのか疑問だ

    • 隠蔽は主たる防御手段ではなく、補助的な抑止策である場合にのみ有効だ
    • 攻撃面を減らすのは隠蔽ではなく、攻撃ベクトル最小化の戦略だ
    • それでも「隠蔽のないセキュリティ」よりはましだという意見もある
    • 共同創業者とされる人物が、「隣の16歳の子でも15分と100ドルあればハッキングできる」と語っていた
    • なぜ「セキュリティを隠蔽に頼ってはいけない」という考え方が生まれたのかを忘れているようだ。
      過去の世代が愚かだったからではなく、見た目は良くても失敗したアプローチだったからだ

  • 「私たちはオープンソースを信じていた」というCal.comの言葉は空虚だ。
    本心だったなら、こんな意味のない言い訳はしなかったはずだ

  • これはAI以前にも使えた言い訳だ。
    中核製品に十分な差別化がなく、収益を守ろうとしている試みに見える。
    結局は売上防衛のための措置にすぎない