Linux Foundation、OSS 脆弱性対応プロジェクト Akrites を発表 AI時代の脆弱性発見と開示に対応|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月01日更新日時: 2026年07月01日

Linux Foundationは2026年6月25日、重要なオープンソースソフトウェア、OSSの脆弱性を調整し、修正と責任ある開示を進める新たな業界横断プロジェクト Akrites を発表しました。

Akritesは、AIを活用した脆弱性発見が進む中で、OSSメンテナーに重複報告や未整理の脆弱性情報が集中する問題に対応する取り組みです。共有のSecurity Incident Response Team、SIRTと、標準化されたCoordinated Vulnerability Disclosure、CVDプロセスを設け、重要OSSの脆弱性を上流プロジェクトと連携して修正・開示することを目的としています。

発表時点では、Amazon Web Services、Anthropic、Chainguard、Cisco、Citi、Endor Labs、Ericsson、Google、IBM、JPMorganChase、Microsoft and GitHub、NVIDIA、OpenAI、Red Hat、Rust Foundation、Sonatype、Vodafone、Zscalerなどが支援組織として名を連ねています。

1 サマリー
2 概要
3 何が発表されたか
4 Akritesが必要とされる背景
5 Akritesの仕組み
6 機密性を重視する理由
7 メンテナー・オブ・ラストリゾートの役割
8 情シス部門が確認すべきポイント
9 開発・セキュリティチームが見るべき点
10 関連記事
11 出典

サマリー

- Linux Foundationは2026年6月25日、OSS脆弱性対応プロジェクト Akrites を発表
- Akritesは、重要OSSの脆弱性を修正し、責任ある開示へつなげるための業界横断プロジェクト

共有SIRTと標準化されたCVDプロセスを提供
AIによる脆弱性発見の高速化で、OSSメンテナーに重複報告や未整理の報告が集中する課題に対応
Akritesは、脆弱性情報を機密性重視で扱い、修正が整う前の悪用や情報漏えいを抑える設計
ワークフローは、受付、重複排除と検証、修正、同期された開示で構成
CVE、TLP、CWE、CVSS、EPSS、SSVC、VEX、VINCEなどの標準やツールを活用
Alpha-Omegaが初期資金を提供し、参加組織はエンジニアリング、人材、資金面で支援
情シス部門では、OSS利用状況、SBOM、パッチ適用体制、脆弱性情報の監視を改めて確認する必要があります

概要

Akritesは、重要インフラが依存するOSSを対象に、脆弱性の発見、検証、修正、開示を調整するための取り組みです。

Linux Foundationの発表では、Akritesは共有SIRTを設け、OSSメンテナーに対して単一で予測可能な調整窓口を提供するとされています。従来は、複数の企業や研究者が同じOSSを個別にスキャンし、同じ脆弱性を別々の形で報告することがありました。その結果、メンテナー側に重複報告や品質のばらついた報告が集中し、実際に修正すべき脆弱性の見極めやパッチ作成に負荷がかかっていました。

Akritesは、この問題に対して、脆弱性報告を一元的に受け付け、重複を整理し、深刻度を確認し、上流プロジェクトと連携して修正を進める仕組みを提供します。公開前の脆弱性情報はTLP:REDとして扱われ、修正や開示までの間、限定された関係者のみがアクセスできる設計です。

何が発表されたか

Linux Foundationは、AkritesをAI時代のOSSセキュリティ対応基盤として発表しました。

公式発表によると、Akritesは、重要OSSの脆弱性を修正し、責任ある開示を行うための調整プロジェクトです。共有SIRTと単一の標準化されたCVDプロセスを設け、機密性を重視した形で脆弱性対応を進めます。

Akritesの公式サイトでは、AIセキュリティツールにより、深刻なソフトウェア脆弱性を見つけるコストが、従来の専門家による数週間単位の作業から、自動スキャンによる数分単位の作業へ変化していると説明されています。これにより、防御側は脆弱性発見のスピードに対応する必要が出ています。

また、Akritesは、脆弱性情報の受付、重複排除と検証、修正、同期された開示という流れで運用されます。メンテナーや業界エンジニアが修正を準備し、公開時には本来の上流プロジェクトへ修正を戻すことを重視しています。

Akritesが必要とされる背景

OSSは、金融、医療、エネルギー、通信、政府機関、AI基盤など、現代のITシステムの多くを支えています。

一方で、広く使われるOSSで脆弱性が見つかった場合、その影響は単一企業にとどまりません。同じライブラリやコンポーネントが、クラウドサービス、業務システム、組み込み機器、SaaS、社内アプリケーションに組み込まれているため、1つの上流脆弱性が多数の組織に波及します。

Linux Foundationのオープンレターでは、AIによって脆弱性発見の速度が大きく上がり、従来の調整・開示モデルでは追いつきにくくなっていると説明されています。特に、同じライブラリを複数組織が個別にスキャンし、それぞれが報告やパッチを進めると、メンテナーに負荷が集中し、修正が分断され、公開前情報が漏れるリスクも高まります。

Akritesは、こうした問題を整理し、脆弱性を上流で修正し、下流の重要インフラ利用者が攻撃を受ける前にパッチ適用できる状態を作ることを目指しています。

Akritesの仕組み

Akritesの中心は、共有SIRTと標準化されたCVDプロセスです。

公式サイトによると、Akritesでは、メンバーまたはベンダーが発見した脆弱性情報をSIRTへ提出します。提出された情報は最初からTLP:REDとして扱われ、ケースチームのみが閲覧できる状態で管理されます。その後、SIRTが重複報告を統合し、深刻度を検証し、修正の担当を割り当てます。

修正段階では、メンテナーや業界エンジニアがパッチを作成・検証します。修正内容は、開示までTLP:REDのケース資料として保持され、最終的には上流プロジェクトの本来の名前空間へ戻されます。

Akritesは、CVE、TLP、CWE、CVSS、EPSS、SSVC、VEX、VINCEといった既存の標準やツールを活用すると説明しています。これは、独自の閉じた仕組みを作るのではなく、既存の脆弱性管理・開示・リスク評価の標準に沿って調整する意図といえます。

機密性を重視する理由

Akritesでは、公開前の脆弱性情報を厳格に扱うことが重視されています。

理由は、修正前の脆弱性情報が広がるほど、悪用されるリスクが高まるためです。オープンレターでは、公開されたパッチから攻撃者が脆弱性を逆解析し、エクスプロイトを作成して攻撃へ移る可能性があるため、成功の指標はパッチの公開ではなく、パッチが実際に展開されることだと説明されています。

この考え方は、情シス部門にとっても重要です。CVEが公開された時点で初めて調査を開始するのでは、攻撃者がパッチ差分を解析して攻撃コードを作る速度に追いつけない場合があります。特にインターネット公開システムや、広く使われるOSSコンポーネントを組み込んだサービスでは、CVE公開前後の短い時間がリスクになります。

メンテナー・オブ・ラストリゾートの役割

Akritesは、重要なOSSパッケージにアクティブなメンテナーがいない場合、maintainer of last resortとして機能することも示しています。

これは、広く使われているにもかかわらず、メンテナーが不在または対応できないOSSで脆弱性が見つかった場合でも、修正を進められるようにする考え方です。Linux Foundationの発表では、重要パッケージにアクティブなメンテナーがいない場合、Akritesが最後のメンテナーとして機能し、最新バージョンに対する修正が適時に届くようにすると説明されています。

企業が利用しているOSSの中には、長年更新されていないライブラリや、実質的にメンテナンスが停止している依存関係が含まれている場合があります。こうしたコンポーネントは、脆弱性発見後の修正先が曖昧になりやすく、利用企業側で代替・フォーク・独自修正の判断を迫られることがあります。

Akritesの取り組みは、この空白を業界全体で埋めようとするものです。

情シス部門が確認すべきポイント

Akritesの発表は、OSSを使っている企業にとって、直接のアップデート指示ではありません。しかし、OSS脆弱性対応の速度が今後さらに上がることを前提に、自社の管理体制を見直す必要があります。

まず、自社システムで利用しているOSSコンポーネントを把握してください。SBOMを整備していない場合、どのシステムにどのOSSが含まれているかを、インシデント発生時にすぐ把握できません。特に、Java、Node.js、Python、Go、コンテナイメージ、Linuxディストリビューション、ネットワーク機器、SaaS連携ツールなど、OSS依存が多い領域は優先して棚卸しする必要があります。

次に、脆弱性情報を受け取った後の判断プロセスを整備してください。CVEが出たときに、影響有無、到達可能性、公開面、悪用状況、EPSS、KEV登録有無、パッチ有無、代替緩和策を誰が判断するのかを決めておく必要があります。

また、OSS脆弱性は、開発部門だけでなく、情シス、SOC、CSIRT、委託先、クラウド運用担当、SaaS管理者が関係します。パッチを適用するだけでなく、依存関係の更新、コンテナ再ビルド、検証、リリース、監視、ロールバックまでを含めた運用が必要です。