オープンソースのセキュリティを共に守るための Akrites 公開書簡

 (akrites.org)
1 ポイント 投稿者 GN⁺ 6 시간 전 | 1件のコメント | WhatsAppで共有
  • AIベースの脆弱性発見がメンテナーの対応速度を上回るようになり、Akrites は中核的なオープンソースソフトウェアを共同で強化するための業界横断の協力として発足
  • 深刻な脆弱性の発見は、かつては専門家が数週間かけて行う作業だったが、いまでは AIモデル が数分で複数の脆弱性を見つけられるようになり、対応負担が急激に増大
  • AWS、Anthropic、Chainguard、Cisco、Citi、Ericsson、Google、IBM、Microsoft と GitHub、NVIDIA、OpenAI、Red Hat、Rust Foundation などは、アップストリーム修正 と責任ある公開の調整を行うことで合意
  • Akrites は重複報告や競合するパッチを減らすため、機密性のある調整窓口と専任の Security Incident Response Team を提供し、メンテナー不在の中核パッケージには最後の手段としてのメンテナー役も担う
  • パッチ公開後は攻撃者が AI で脆弱性をリバースエンジニアリングできるため、成功基準は公開そのものではなく、実際のシステムまで パッチが展開されること にある

AIが変えたオープンソースセキュリティの速度

  • オープンソースは、銀行、通信、公益事業など、人々が日々依存する 中核インフラとサービス の基盤となっている
  • 技術スタック全体で同じオープンソース構成要素が広く使われているため、多くのシステムが同じ潜在的欠陥を共有することになっている
  • AI は攻撃者と防御側のバランスを変え、脆弱性発見と再利用のコスト構造を引き下げている
    • 深刻な脆弱性の発見は以前は専門家に数週間かかっていたが、いまでは機械が数分で実行できる
    • AI モデルが1回の実行で複数の脆弱性を返す場合もある
    • 同じ能力は防御にも使えるが、悪用されれば脆弱性発見が パイプライン化 されうる

重複報告がメンテナーを圧迫する構造

  • 既存のセキュリティ対応と公開手順は、複数の組織やチームが緩く分かれて動く方式だったため、同じ問題を同時に扱ったり、競合するパッチや複数の報告書が生じたりしていた
  • 何十社もの企業が同じライブラリを独立にスキャンしてそれぞれ報告書を提出すれば、メンテナーは ノイズに埋もれてしまう
  • まだパッチ未適用の脆弱性を知る当事者が増えるほど、修正前に漏えいする可能性も高まり、そのリスクはエコシステム全体へ広がる
  • 調整のない善意の対応であっても、問題を悪化させ、時間を浪費するおそれがある

Akrites の共同対応方式

  • Akrites は、中核的なオープンソースソフトウェアの脆弱性を見つけ、修正し、責任を持って公開するための共同システムとツールを展開する取り組みとして発足
  • 参加者には Amazon Web Services、Anthropic、Chainguard、Cisco、Citi、Endor Labs、Ericsson、Google、IBM、JPMorganChase、Microsoft と GitHub、NVIDIA、OpenAI、RapidFort、Red Hat、Rust Foundation、Sonatype、Vodafone、Zscaler などが含まれる
  • 対応の中心は、メンテナーが存在する アップストリーム に置かれる
    • 脆弱性の発見、修正、公開を調整できる、単一の機密・信頼ベースの場を提供する
    • 専任の Security Incident Response Team が、無数の未調整な報告の代わりに、メンテナーにとって予測可能な単一のパートナーとなる
    • 修正内容は各プロジェクト本来のリポジトリとメンテナーのフローへ戻される
  • 中核パッケージにメンテナーがいない場合、Akrites は修正が適時に届けられるよう 最後の手段としてのメンテナー の役割を担うとしている

なぜパッチ公開より展開が重要なのか

  • パッチが公開されると、攻撃者は AI を使って実際の脆弱性をすばやくリバースエンジニアリングし、エクスプロイトを開発して攻撃を開始できる
  • したがって Akrites の成功は、パッチが公開されたかどうかではなく、実際のシステムに 展開されたかどうか で測定されるべきだ
  • Akrites は、中核インフラの所有者と運用者、市民社会の取り組み、政府と協力して調整レベルを高めようとしている
  • 機密性は交渉の対象ではなく、広く配布されたパッケージの未公開欠陥は事実上 兵器 と同じであるため、漏えい防止が最優先となる

参加組織が強調した負担と約束

  • Endor Labs は、ここ数か月で確認された数千件のオープンソース脆弱性のうち、パッチ済みの比率は 5%未満 だと明らかにした
  • OpenInfra は、OpenStack コミュニティが今四半期だけでセキュリティ勧告を20件発行しており、2025年通年では2件だったと明らかにした
  • JPMorganChase は、AI が脆弱性の発見から悪用までの時間をほぼリアルタイム近くまで圧縮したため、修正から展開までの時間も短縮しなければならないと見ている
  • Chainguard、Sonatype、RapidFort、Red Hat などは、脆弱性修正はフォークや私有化された壁の向こうで分散して行われるのではなく、アップストリーム調整 を通じて元のソフトウェアとメンテナーのフローの中で行われるべきだという立場を示した
  • 参加組織は、エンジニアリング人員、セキュリティ専門性、資金、AI 技術を投入し、共有ソフトウェアを強化すると約束している

関連記事

1件のコメント

 
GN⁺ 6 시간 전
Hacker News の意見

  • 多くのオープンソース関係者が、この参加企業リストを見て懐疑的にならざるを得ないし、それはもっともだ
    核心は「重要なオープンソースソフトウェアの脆弱性を見つけ、修正し、責任ある形で公開する」ことをどう実装するかにある。既存のチャネルとプルリクエストで貢献するならコミュニティと歩調を合わせられるが、「セキュリティ」を名目にフォークすれば、コミュニティを疎外し、リソースを分断して、長期的には多くのプロジェクトを潰しかねない。バグバウンティには可能性があるが、致命的なバグでは速度や公開タイミングが合わない場合があり、資金支援もメンテナー支援と結び付かなければ効果は限定的だ

    • Linux Foundationに雇われているが、このプロジェクトの内部事情は知らない。その代わり、自分が支援しているプロジェクトが何をしているかを言うと、HackerOneプログラムはシグナルよりノイズが多いため縮小中だ
      PQCAはAWSクレジットでハードウェアにアクセスして証明とCIを回し、有給メンターシップも運営している。OWFもAWSクレジットとテスト用サービスのホスティングを提供している。LFDTは有給メンターシップ、Trail of Bitsのレビュー費用、イベント運営、ニューヨークのメンテナーサミット、大型GitHub CIランナー支援などを行ってきた。私たちのチームはOWF/PQCA/LFDTの開発者リレーションズ基準で正社員3人、契約者1人、マネージャー1人だけだが、開発者を助けるためにかなり熱心に働いている
      LFDT: https://www.lfdecentralizedtrust.org/
      OWF: https://openwallet.foundation/
      PQCA: https://pqca.org/
      PQCAベンチマーク例: https://pq-code-package.github.io/mldsa-native/dev/bench/
    • 誰が参加し、何をしようとしているのかを見た瞬間に抱いた最初の考えも同じだった。コモンズが営利企業の手に渡ってはならない
      どのような形であれ、単一の中央拠点や単一の主体が支配権を行使できないよう分散されるべきだ
    • 「これらの企業がオープンソース関係者ではないかのように」言うのはおかしい。オープンソースは排他的なクラブではない
    • 読んだ限りでは、可能なところでは既存の方法で貢献し、必要なところでは別の措置を取る、という方向だと理解した。Linux Foundationなら当然、オープンソースとコミュニティ優先であるべきだ
      資金面での貢献を言っているが、どのように、何のために行うのかも重要だ。ほとんどのプロジェクトは寄付を受け取ったり活用したりする準備ができていない。ただ、すべてのオープンソースプロジェクトがコードベースとプルリクエストをレビューできるよう、相当なAIアクセス権を提供され、メンテナンス負担を減らせるとよいと思うし、すでにそうした試みも一部にはある

  • 企業的な見せかけにすぎない
    Microsoftは「脆弱性を責任ある形で特定し修正するために、専門性、リソース、AI技術を提供する」と言うが、MicrosoftはNPMとGitHubを運営し、最高クラスのAIモデルと巨大なデータセンターにアクセスできる。それにもかかわらず自社製品のセキュリティは急速に悪化しており、同社のサービスは複数のエクスプロイトが広がる中心的ハブになっている
    Microsoftが自社のオープンソースプロジェクトのセキュリティ問題をどう扱っているかを見るには、このGitHubスレッドを勧める: https://github.com/dotnet/efcore/issues/38257
    EF Coreは現在、重大な脆弱性のあるSQLiteバージョンを配布している。この問題は1年以上前に発見され、SQLiteは1週間以内に修正したが、EF Coreは最近ユーザーが再度報告して開発者たちと議論するまで、ドライバーを脆弱なものとして表示していなかった。現在の安定版.NET Coreへの修正は、およそ2か月後に入る予定だ

    • CVE-2025-70873を重大な脆弱性と呼ぶのは少し大げさに見える。攻撃者が任意のZIPファイルを読み込ませることを許可して初めて成立する脆弱性なので、ユーザーに任意のZIPファイルを読み込ませない限り、それほど深刻ではない
    • Microsoftによる買収前のGitHubは、JavaScriptでIDEを作ろうとしてElectronまで作り、それは面白かったし、最終的にまったく別の有用なものになった。技術革新はそういう形で起こる
      Microsoftは買収後、VSCodeでその流れを引き継ぐというより、Electronをけなす雰囲気を作り、今では多くの人が理由も説明できないままElectronを嫌っている。VSCodeはAtomをフォークしたわけでもなく、最初から似たものとして作られ、より大きく遅くなり、今ではCopilotまで付いている。私は結局、Atomの良いフォークであるPulsarに戻った
      Microsoftはいつも機会と競争構図を見て買収するが、買ったものをうまく使うことはまれだ。優秀な社員と良いコードをなくし、製品を壊すという形だ。それでも皆がいまだにMicrosoft製品を使っているのが理解できない。LinkedInを離れ、別のバージョン管理システムへ一緒に移るべきだ。オープンソース開発者たちが言葉だけでなく行動で示さない限り、Microsoftはさらに悪くなり続けるだろう

  • 私たちはそうしないだろう。大げさな宣言だけをして、商業企業が台無しにするのを放置し、実際には自分たちが何もしなかったのに、その状況に大きく不満を言うことになるだろう
    今後は、私が undo fork と呼ぶ流れが生まれると思う。狂気が始まる前の時点に戻って考え直すフォークで、商業的要求に縛られていない人たちだけができることだ

    • ある意味では、Free Software から Open Source へ移行した瞬間からこうした転換は始まっており、その速度は落ちていない
    • さらに悪い。オープンソースは誇大マーケティング企業に乗っ取られ、私たちが望むものではなく、彼らが望むものを作るための無料労働力の搾取手段になり得る
    • 有用なオープンソースの95%は商業企業が作るか保守している。Linux や Postgres などがそうで、細かなユーティリティ類は除いた話だ
    • 今日の Linux Foundation は、事実上、政治的アジェンダを持つ他のグローバル企業と似たようなものだ。金の流れを追えば企業が支配していることが分かるし、Torvalds を無力化し、一緒に仕事をするのもおおむね悪夢に近いと思う
      オープンソースに関心のある人には、Linux Foundation には近づかないよう常に助言している。最近では、ソフトウェアの自由を可能にするどころか、それを妨げる障壁になっている

  • オープンソースを守るには、言葉ではなく、プロジェクトと開発者への実質的な支援から始めるべきだ
    OpenBSD 開発者の立場から見ると、開発者に新しいハードウェアを提供することは本当に重要だ。多くの開発者が、交換が必要な5〜10年前の ThinkPad で作業している
    https://www.openbsd.org/want.html
    OpenBSD Foundation は、2026年の資金調達目標までまだ約50%残っている
    https://www.openbsdfoundation.org/campaign2026.html

    • 利用しているオープンソースプロジェクトに資金を出すだけでなく、可能であれば、そのプロジェクトで働く個々のコントリビューターや開発者も直接支援してほしい。多くの人はボランティアであり、少額の月額支援でも大きな違いを生み得る
      https://brynet.ca/wallofpizza.html
    • Debian にアップロードできる GPG キーを保護するために YubiKey をいくつか買いたかったが、必要なら結局は自腹で買わなければならない雰囲気だ

  • 「Amazon Web Services が協力する」というくだりで、この記事の信頼性はすべて消えた

  • これは中央集権化と統制の試みに読める。Akrites が何者であれ、Google を含む大手テック企業にオープンソースを統制する力を与えるだけだ
    ありがたいが遠慮しておく。Google がこの9月に Android で .apk によるサードパーティインストールを阻止しようとしていることを覚えている

    • 懸念は同じだ。重要なオープンソースパッケージがこれら企業の「セキュリティ」リリースに依存するようになると、例えばパッケージに本人確認を強制できるようになるのではないかと思う
      関連して、私の知る賢い人たちのほとんどは、オープンソースAIが Anthropic と OpenAI を財務的に成り立たなくすると見ている。ここに名を連ねる多くの企業は両社と深く結びついており、顧客が価格ショックを感じる前にオープンソースAIを揺さぶる誘因が大きい。彼らの次の一手が何かを待っていたが、これがその一部かもしれない

  • 最も重要な情報は、「参加者がエンジニアリングリソースを提供する」という部分だ
    計画通りにいくかは見守る必要がある。それ以外では、このプロジェクトの主張にはあまり感心しない。中央集権化と企業中心のネットワークに有利な構造で、正当な理由からハッカー倫理が促してきた方向とは正反対だ

    • 包摂的には見えない。入ってくる脆弱性を中央に集め、情報を収集し、秘密裏に処理するもう一つのレイヤーのように見える
      さらに別の圧力源にもなり得る。実際の脆弱性をうまく選別できるかもしれないが、その結果はメンテナーに高い優先度で押し寄せることになる。多くのメンテナーはAI由来のノイズがなくてもすでに疲弊しており、修正案が提供されてもなおレビューは必要だ
      最善の場合、ノイズを減らせるかもしれないが、作業そのものは残る。業界は、オープンソースプロジェクトが自分たちで対処する権限を持てるよう、全体として資金を出すべきだ。それが品質にとっても最も良い可能性が高い。AIノイズをフィルタリングする必要があるなら、その機能を追加すればよいが、すべてを統制する秘密主義で不透明な構造であってはならない
    • もっと短く言えば、企業が時間を奪い、何も返さない偽の協力のように見える。ハッカー倫理が促すものとは正反対だという点に同意する

  • 「私たちは皆オープンソースに依存している。共に資金を出す」のような見出しを見る日を待っている

    • 大企業のかなりの数は、従業員を雇って参加させる形ですでに「オープンソースに資金を出して」いる。例えば LKML に投稿される企業メールアドレスを見れば分かる

  • 「Akrites」という名前は良い
    ギリシャ人でない人にはそれほど印象的ではないかもしれないが、ギリシャ人にはかなり強いイメージを与える

    • 調べる人のために要約すると、akritai は9〜11世紀のビザンツ帝国で東方国境を守っていた辺境兵を指す言葉だ
      akron は端や境界を意味するので、「辺境の人」または「国境の人々」くらいの意味になる。ここで重要なのは、現代の紛争や偏見を千年前の歴史にそのまま当てはめることはできないという点だ。歴史的文脈では、異なる文明間にある多くの国境と同様であり、自分たちの土地を守るために集まった集団組織だったという点が重要だ
    • より最近の例としては、Mark Carney の Davos 演説がある。特に「中堅国は共に行動しなければならない。私たちがテーブルに着いていなければ、メニューに載せられることになる」というくだりを思い出す
      [1] https://en.wikipedia.org/wiki/Mark_Carney%27s_Davos_speech

  • Hacker News にこういう投稿をしても、あまり意味はないと思う。ここにいる多くの人は AI の流れを深く受け入れていて、あまり気にしていない
    それに、リストに載っている多くの企業は、オープンソースが今の状態になったことに対する主要な疑惑の対象でもある

    • 私は AI ゴミを受け入れていないし、そういう結論がどこから出てくるのかもよく分からない。コメントの大半は AI ゴミにかなり反対する側だと思う
      ただし、リストに載っている多くの企業がオープンソースの現状に対する主要な疑惑の対象だという点には同意する。これはその企業たちをホワイトウォッシュしようとするPR広告のように見えるし、彼らがオープンソースの倫理を本当に気にかけているとは考えにくい