OSSは、企業システムやクラウドサービス、業務アプリケーション、セキュリティ製品、AI基盤の内部で広く使われている。情報システム（情シス）部門が直接OSSを管理していなくても、自社が利用するSaaS、開発環境、運用ツール、社内システムの中には、多数のOSSコンポーネントが組み込まれている。

　従来、OSSの脆弱性対応は、研究者やベンダー、利用企業、OSSメンテナーが個別に連絡を取り合いながら進めることが多かった。だが、AIによって脆弱性発見の速度が上がると、この「個別対応」は限界を迎える。複数の企業が同じ脆弱性を別々に調査し、異なる修正案を出し、メンテナーに重複した報告を送る。こうしたつぎはぎの対応は、現場の混乱を招き、結果として修正の遅れにつながる。

　問題は、脆弱性を「見つけられるか」ではなく、「見つかった後に、誰が検証し、誰が修正し、どの順番で公開し、どれだけ早く本番環境に適用できるか」に移っている。AI時代のOSSセキュリティでは、発見能力よりも、修正と適用の体制が問われる。

Akritesは何をするのか

　Akritesの中核は、OSS脆弱性対応の窓口を一元化することだ。これまでのように、各社がばらばらに脆弱性を報告し、メンテナーに重複した負荷をかけるのではなく、共同のSecurity Incident Response Team（SIRT）を設け、脆弱性の修正と開示を調整する。

　Akritesは、標準化された「協調的な脆弱性の開示」（CVD：Coordinated Vulnerability Disclosure）の手順を一本化し、標準化されたプロセスとして運用する。脆弱性をすぐに公開するのではなく、まず秘密厳守でメンテナーや関係者と連携し、修正コードを作成、検証する。その上で、安全が確保された段階で責任ある形で開示する。利用する仕組みには、CVE（共通脆弱性識別子）、CWE（共通脆弱性タイプ一覧）、CVSS（共通脆弱性評価システム）、EPSS（脆弱性悪用予測スコアリングシステム）、SSVC（ステークホルダー固有の脆弱性分類）、VEX（脆弱性の影響有無を共有する仕組み）などの業界標準が含まれる。

　重要なのは、修正をOSSプロジェクトの本来の場所に戻す点だ。AIによる脅威が高まったからといって、OSSを企業ごとの独自パッチや閉じた製品の中に分断するのではない。Akritesは、上流プロジェクトで修正し、その成果をOSSコミュニティ全体に還元することを重視する。

「最後のメンテナー」としての役割

　OSSの脆弱性対応で難しいのは、全ての重要パッケージに十分なメンテナーがいるわけではないことだ。社会的に重要なソフトウェアであっても、実際には少人数のボランティアに依存していたり、長期間メンテナンスされていなかったりするケースがある。

　Akritesは、こうした重要パッケージにアクティブなメンテナーがいない場合、「最後のメンテナー」として機能する。つまり、放置された重要OSSについて、修正を最新バージョンに反映し、利用者へ届ける役割を担う。これは、OSSの安全性を善意の個人だけに依存させないための仕組みでもある。

　この考え方は、企業の情シス部門にも示唆を与える。自社が利用するOSSやソフトウェア部品について、「誰かが直してくれるはず」と考えるだけでは不十分だ。どのOSSに依存しているのか、メンテナンス状況はどうか、修正が出た場合にどのシステムへ影響するのかを把握する必要がある。

ゴールは「パッチ公開」ではなく「パッチ適用」

　Akritesが特徴的なのは、脆弱性修正を公開して終わりにしない点だ。JPMorganChaseのCISOパトリック・オペット氏は、成功指標を「パッチの公開」ではなく「パッチの適用」に置く考えを示している。脆弱性情報や修正コードが公開されても、病院、銀行、電力網、通信網などの実際のシステムに適用されなければ、リスクは残り続ける。

　これは企業の脆弱性管理でも同じだ。セキュリティ部門が脆弱性情報を検知しても、開発部門や運用部門が影響範囲を特定できず、検証やリリースの手順が整っていなければ、修正は本番環境に届かない。AI時代には、脆弱性の発見から悪用までの時間が短くなるため、「いつか適用する」ではなく、「どの脆弱性を、どの順番で、何日以内に適用するか」を決める必要がある。

　そのためには、SBOM（ソフトウェア部品表）の整備、依存関係の可視化、脆弱性管理ツールの活用、パッチ適用の優先順位付け、例外管理、経営層へのリスク説明が欠かせない。Akritesの登場は、企業側にも「修正を受け取れる体制」と「迅速に展開できる体制」を求めている。

競合企業が手を組む異例の枠組み

　Akritesには、本来は競合関係にある大手IT企業、AI企業、金融機関、通信事業者、セキュリティベンダーが参加している。クラウドやメガテックではAWS、Google、MicrosoftとGitHub、IBM、Red Hat、Ciscoが名を連ねる。AI領域ではOpenAI、Anthropic、NVIDIA。金融、通信、セキュリティ領域ではCitigroup、JPMorgan Chase、Vodafone、Ericsson、Zscaler、Chainguard、Endor Labs、RapidFort、Sonatypeなどが加わる。The Linux Foundationの基金であるAlpha-Omega（注）は、Akritesにシード資金を提供する。

※注：オープンソースのセキュリティ向上を目指す業界横断組織OpenSSF（Open Source Security Foundation）とThe Linux Foundationの傘下で発足したプロジェクト。MicrosoftとGoogleの支援を受けて発足。

　この顔ぶれが示すのは、OSSセキュリティが特定企業だけの問題ではなくなっているということだ。OSSの脆弱性は、1つのベンダー製品や1つの業界に閉じない。金融機関、通信事業者、クラウド事業者、AI企業が同じOSSに依存している以上、1つの脆弱性が複数の社会インフラに波及する可能性がある。

　だからこそ、各社が個別に脆弱性を囲い込むのではなく、上流で修正し、業界全体で共有する体制が必要になる。Akritesは、OSSを「誰かが無償で提供してくれる便利な部品」ではなく、社会全体で守るべき共有資産として位置付け直す取り組みだ。

参加各社が共有する危機感

　参加企業のコメントには、共通したメッセージがある。第1に、「見つけるのは機械、直すのは人間」という問題意識だ。ソフトウェアベンダーEndor Labsは、AIによって脆弱性発見は容易になった一方、検証済みのOSS脆弱性のうち、実際に修正されているものは5％未満だと指摘している。発見の自動化が進んでも、修正、検証、上流への反映、利用企業への展開は自動的には進まない。

　第2に、OSSを閉鎖的にしてはならないという考え方だ。ソフトウェアベンダーRapidFortは、AIによる脆弱性危機への対応として、OSSを独自製品の壁の中に閉じ込めたり、フォークによって分断したりするべきではないと訴えている。修正はオープンなまま上流に戻し、共有資産としてのOSSを守るべきだという立場だ。

　第3に、メンテナーの負担を減らすことだ。JPMorgan ChaseやRust Foundationは、OSSメンテナーに重複した大量の報告を送りつけるのではなく、検証済みの脆弱性と、テスト済みの修正案を、信頼できる窓口から届けることの重要性を強調している。善意のメンテナーに依存し続けるのではなく、業界全体で支援する仕組みが必要だ。

情シスは何を準備すべきか

　Akritesの発足は、情シス部門にとっても無関係ではない。今後、OSS脆弱性情報はこれまで以上に高速に流通し、修正もより短いサイクルで求められる可能性がある。そのとき、自社のシステムがどのOSSに依存しているか分からなければ、影響範囲を判断できない。パッチ適用の責任分界点が曖昧であれば、対応は遅れる。

　まず必要なのは、ソフトウェア資産と依存関係の可視化だ。自社開発システムだけでなく、外部委託先が開発したシステム、利用中のSaaS、パッケージ製品、コンテナイメージ、開発ツールに含まれるOSSを把握する必要がある。SBOMを整備し、脆弱性情報とひも付けられる状態にすることが第一歩になる。

　次に、パッチ適用の優先順位を決める仕組みが必要だ。CVSSのスコアだけでなく、実際に悪用される可能性、インターネット公開の有無、業務影響、代替策の有無を踏まえて判断する。EPSSやSSVCのような指標は、こうした優先順位付けの参考になる。

　さらに、開発、運用、セキュリティ、調達、法務、経営層の連携も欠かせない。OSS脆弱性対応は、セキュリティ部門だけで完結しない。パッチ適用にはシステム停止、検証、ベンダー調整、業務部門との調整が伴う。AI時代の脆弱性対応では、技術的な検知よりも、組織として早く意思決定し、実行する力が問われる。

OSSを「使うだけ」の時代は終わる

　Akritesは、AI時代のOSSセキュリティに向けた野心的な共同防衛の枠組みだ。脆弱性を見つける速度がAIによって高まる中、業界全体で修正を調整し、上流に戻し、重要インフラに確実に適用することを目指している。

　企業にとって重要なのは、Akritesの発足を単なる海外の業界ニュースとして捉えないことだ。自社が依存するOSSを把握し、脆弱性が見つかったときにどのシステムへ影響するのかを判断し、修正を迅速に適用できる体制を整える必要がある。

　OSSは、もはや開発者だけのものではない。銀行、病院、電力網、通信網、AIサービス、行政システムを支える社会インフラの一部だ。AIが脆弱性を数分で見つける時代には、OSSを「無料で使える部品」として扱うのではなく、「共同で守るべき基盤」として捉えることが、情シス部門にも求められる。