オープンソースは死んでいない

 (strix.ai)
1 ポイント 投稿者 GN⁺ 13 일 전 | 1件のコメント | WhatsAppで共有
  • Cal.com は、AIベースの脆弱性検出の脅威を理由に中核コードを非公開へ移行し、「透明性はすなわち露出」 となる時代に言及
  • Strix は、自律型 AIセキュリティエージェント を開発するオープンソースプロジェクトで、Cal.com と協力して 責任ある脆弱性開示プロセス を進めている
  • Strix は、コードの非公開化は AIセキュリティ脅威の解決策ではなく、むしろ 善意あるレビューの機会を遮断する と指摘
  • AI攻撃はコードへのアクセスがなくてもブラックボックス方式で侵入可能 であり、非公開戦略は自動化攻撃に脆弱
  • 真の解決策は、AI防御を開発プロセスに統合 し、継続的な自動検証 を通じてオープンソースの 透明性と協調 を維持すること

Cal.comのコード非公開化とオープンソースセキュリティ論争

  • Cal.com が中核コードベースをオープンソースから非公開へ切り替えると発表
    • CEO の Bailey Pumfleet は、AI が大規模に脆弱性を自動検出し、「透明性はすなわち露出」 となる時代になったと述べた
    • AI がコードスキャンとエクスプロイトをほぼ 「ゼロコスト」 で実行できるようになったことを理由として提示
  • Strix は、自律型 AIセキュリティエージェント を開発するオープンソースプロジェクトで、最近 GitHub スター 24k を突破
    • 1日 150億以上の LLM トークン を処理してソフトウェアの脆弱性を検出
    • Cal.com と協力し、Strix を用いた 責任ある脆弱性開示プロセス を進めており、まだ修正されていないバグの詳細は公開していない
    • Cal.com の決定が ユーザーを保護しようとする意思 から生まれたものであることは認めている
  • しかし Strix は、「コードを閉じることは AIベースのセキュリティ脅威の解決策ではない」 と強調
    • AI がセキュリティを根本的に変えた点には同意するが、オープンソース放棄には反対 の立場

ブラックボックスAIは非公開コードにも侵入可能

  • ソースコードを閉じれば攻撃者はコードを読めないという前提は、現代のAI攻撃モデルには当てはまらない
    • 過去の静的解析ツールには有効だったが、自律型 AI エージェント はコードアクセスなしでも攻撃を実行できる
  • Strix のようなツールは、ブラックボックス・グレーボックステスト に特化
    • 実際のエンドポイントと相互作用しながら、ブラウザ状態の操作、ネットワークトラフィックの分析、ビジネスロジック脆弱性の検出 を行う
  • コード非公開は、善意ある開発者によるレビュー機会 を遮断するだけで、攻撃者に露出している API・Webhook などの攻撃面 はそのまま残る

「セキュリティのための隠蔽」戦略は自動化攻撃に脆弱

  • 非公開コードは、内部セキュリティチームと 定期的な手動ペネトレーションテスト に依存
    • しかし攻撃者は、無限に稼働するAIボット で24時間脆弱性を探索する
  • これは、内部人員が外部のAI攻撃より 速く欠陥を見つけられる という前提に基づくが、現実的には不可能
  • 過去にも 「隠蔽によるセキュリティ(Security through obscurity)」 は失敗してきたが、 AI時代にはその失敗速度が指数関数的に速くなる

本当の解決策: AIでAIを防ぐ

  • ソフトウェア開発速度が人間のセキュリティレビュー速度を超えたのは事実
    • しかし解決策は、コードを隠すことではなく、AI防御を開発プロセスに統合すること
  • AIベースの継続的検証(continuous validation) が必要
    • 開発者が Pull Request を開くと、AI が即座に攻撃を試行
    • インフラ変更時には AI が 自動で攻撃面を検証
  • CI/CD パイプライン 内でセキュリティテストを自動化すべきであり、 攻撃の自動化より優れた内部自動化 で対応する必要がある

オープンソースは依然として有効

  • 「多くの目があればバグは浅くなる」という伝統的原則は弱まるかもしれないが、 オープンソース自体が死ぬわけではない
  • Strix は、透明性が強みを生む という信念のもとでオープンソースを維持
    • 次世代のセキュリティツールは、攻撃ツールと同じくらい 利用しやすくオープン であるべき
  • コードを隠しても AIハッカーを止めることはできない が、 開発者に自律型セキュリティエージェントを提供 すれば防御の可能性は高まる
  • Strix は、AIベースの継続的セキュリティテスト を無料で体験できるよう提供している

関連記事

1件のコメント

 
GN⁺ 13 일 전
Hacker Newsの意見

  • 私はオープンソースプロジェクトを運営しているが、ここ数か月でセキュリティ脆弱性レポートが急増した。
    ほとんどは些細なケースだったが、本当に問題のあるものもあり、すべて修正した。
    クローズドソースのソフトウェアはこうしたレポートを受け取らないだろうが、AIによる悪用リスクはある。
    だからこの記事のメッセージには全面的に共感する。

    • クローズドであっても、内部ではAIスキャナーを回せるのでは？
      外部に対して閉じているだけで、社内開発者に対して閉じているわけではない。
    • 自動化されたリポジトリスキャナーからはレポートは来ないだろうが、バグバウンティプログラムは依然として多くのレポートを生み出す。
      ただしAIツールの登場で、初心者がAIの作り出した幻のようなレポートを提出する問題も起きている。
      クローズドな企業も自発的にセキュリティ監査を実施すべきだ。
    • 攻撃者の立場では、AIを使ってオープンソースのリポジトリを攻撃する方がはるかに得だ。
      Cal.comがクローズド化したのは理解できるが、結局はStrixのマーケティングのように見える。
      オープンソース企業は公開状態を維持するほど損が大きくなる。
    • 私もオープンソースプロジェクトに夜間の自動ペネトレーションテストを設定した。
      こうしたレポートを定期的に公開すれば、セキュリティの信頼性を証明できそうだ。
      ただ既存プロジェクトには中程度・軽微レベルの課題が積み上がっており、解決には時間がかかりそうだ。
    • うちの会社では社内でAIスキャナーと手動ペネトレーションテストを併用している。
      つまり、コードを非公開にした状態でAIによる脆弱性検出と多層防御を同時に活用している。

  • CEOの言う「AIが大規模に脆弱性を自動検出する」という理由は、言い訳のように聞こえる。
    本当の理由は、オープンソースでは持続可能なビジネスモデルを作りにくいからではないかと思う。

    • 同意する。収益性確保のためにクローズド化するのは理解できるが、セキュリティを口実にするのは誠実ではない。
    • 私たちは5年間オープンソースで300%成長率を維持しながら収益を上げてきた。
      クローズド化はむしろビジネスに不利だが、顧客データの保護の方が重要だと判断した。
    • 最近は何でもAIのせいにする傾向がある。
      人員削減でもライセンス変更でも、「AIのため」という言い訳は便利だ。
    • 今ではオープンソースコードをそのまま使わず、必要な部分だけ抜き出して再構成するのがあまりにも簡単だ。
      npmjsのような場所はそのうち参考用サイトに変わるかもしれない。
    • 「cal.diy」を残して企業向けを閉じるのは典型的なオープンコア戦略だ。
      AIスキャナーのせいにするのは単なるPR向けの包装にすぎない。

  • この記事は本当にコンテンツマーケティングの教科書のようだ。

    1. 刺激的なタイトルで関心を引き、
    2. Cal.comの立場に共感して読者の好感を得て、
    3. 問題に対する真面目な解決策を提示しつつ、
    4. 最終的に自社製品の宣伝へ自然につなげている。
      誠意とマーケティングが絶妙に混ざった事例だ。
    • 私もそう読んだ。書いた会社はAI脆弱性スキャンサービスを売っている会社なので、結局は登録を促すためのものだ。
      実際にStrixはCal.comのコードをスキャンしたが、多くの脆弱性を見逃した。
      どのプラットフォームも完璧ではなく、AIスキャナーだけでは十分ではない。
    • この記事がこんなに多く支持されたのは残念だ。内容の密度はコメント1件分しかない。
    • 個人的にはAIを使わない。現時点ではAIブームに乗るのがマーケティング的に簡単なだけで、本当の価値があるのかは疑問だ。

  • 「Security through obscurity（隠すことによるセキュリティ）」は、それ単体で使うときだけ問題になる。
    攻撃者にコストを上乗せする抑止層としては有効な戦略だ。
    結局のところセキュリティは、どちらがより多くのリソースを投入するかの戦いだ。
    AIが人間より効率的なだけで、オープンかクローズドかという本質的な計算式は変わらない。

  • Cal.comが本当にセキュリティを心配しているのか、それともオープンソースSaaSの難しさを覆い隠すための言い訳なのか気になる。
    この論理はすでに数十年前に誤りだと証明された主張だ。

  • 私は「隠蔽によるセキュリティ」が本当の理由だとは信じていない。
    単にオープンソースを閉じればもっと収益を上げられると考えただけだ。

    • その通り。彼らの製品なのだから、好きにすればいい。
      オープンソースの醜い面の一つは、人々が無償労働を当然視する態度だ。
      何年も無償で働いてくれた開発者に感謝する代わりに、無料で働き続けないことに腹を立てる。
      当の本人たちは無給で働きもしないのに。

  • 記事を見ると、Cal.comはレッドチームボットで脆弱性テストを受けていたようだ。
    バグがあまりにも早く見つかるので、CEOが修正コストの負担を重く感じてコードを閉じた可能性がある。
    事実上、「Cal.comのコードには脆弱性が多い」という公開宣言のようにも見える。

    • あるいは、スキャナーが偽陽性（false positive）を出しすぎたのが問題だったのかもしれない。
      それを調整すると本物の脆弱性を見逃すことになり、結局      検証コスト      が膨らむ。
      オープンソースではこうしたレポートが公開されて評判の毀損が生じるが、クローズドではそうではない。
      だからクローズド化した可能性もある。

  • 本当のリスクは脆弱性の発見ではなく、LLMがオープンソースプロジェクトを別の言語で書き直してライセンスを回避する能力だ。

    • クローズドなプロジェクトでも理論上は同じことが可能だが、制約が多い。
    • 実際、こうしたことはよく起きる。AIがコードをほぼそのまま再生成して複製プロジェクトを作るような形だ。
      法的には曖昧だ。人が勉強した後に新しく書くなら問題ないが、AIがやると事実上複雑なコピペだ。
      こうした場合にライセンスがどう適用されるのかは不明確だ。
    • 多くのオープンソースライセンスはフォークと再販を認めている。
      コードを公開するだけではビジネスは成り立たず、運用能力の方が重要だ。

  • 「セキュリティテストはCI/CDパイプラインに自動化されるべきだ」という主張には同意する。
    だが、それがオープンソースの必要性を証明するわけではない。

  • オープンソースのバランスはすでにずっと前に崩れていた。
    企業がオープンソースコードを利用して有料製品を作りながら貢献しない構造は、かなり前から存在していた。
    PHPのように世界中で使われているのに予算不足の言語がその例だ。