Broadcom TrueSource始動、AI検出後もパッチは人が検証

Broadcomは2026年8月31日、米ラスベガスで開かれたVMware Explore 2026で、商用サポート付きの検証可能なオープンソースソフトウェア群「TrueSource by Broadcom」を発表し、提供を開始した。Broadcomの発表 では、既存のSpring Enterprise、新設のTrueSource Trusted Artifacts、TrueSource Data Servicesを一つのポートフォリオにまとめ、Java、Python、Node.js、強化済みコンテナ、主要なデータエンジンまで対象を広げている。

同じ8月31日の Network Worldの現地報道 も、三つの提供物が利用可能になったことと、Springおよび依存ツリーを先端モデルで継続的に走査しながら、各パッチはBroadcomの技術者が手作業で検証する運用を確認している。TrueSourceは脆弱性を知らせるだけのスキャナーではなく、選定、ビルド、修正、配布、保守を供給側の責任範囲に含めるサービス群だ。

Springを核に三つの提供物を束ねる

TrueSourceはSpring Enterpriseの改称ではない。Spring Enterpriseを残したまま、他言語のライブラリとコンテナ、データ基盤を扱う二つの新サービスを加えた上位ポートフォリオである。

• Spring Enterprise：Springを開発・保守するチームが、対応するリリース系列向けに選定済みリリースとセキュリティ修正を提供する。Spring本体だけでなく、各Spring Boot系列が固定するApache TomcatやKotlinなどの依存関係も範囲に入る。
• TrueSource Trusted Artifacts：Java、Python、Node.jsのライブラリを参照アーキテクチャに照らして選定し、隔離されたクリーンルーム工程でビルドする。SLSA Build Level 3の成果物を掲げ、Bitnami Secure Imagesの強化済みコンテナも含む。
• TrueSource Data Services：PostgreSQL、RabbitMQ、MySQL、Valkeyについて、検証済み成果物、サポート、導入支援を提供する。重要な拡張機能、Operators、Helm Charts、導入自動化、セキュリティーと運用状態の可視化も対象となる。

三つのサービスに共通するのは、OSSをそのまま再配布するのではなく、Broadcomの技術者が参照構成に沿って選び、ビルドと検証を行うという考え方だ。ただし、対象パッケージや保守期間は一律ではないため、ポートフォリオ名だけで自社の依存関係がすべて含まれるとは判断できない。

AI走査と人手検証の境界はSpringで明確

発表でAIの工程が最も具体的に示されたのはSpring Enterpriseである。先端モデルによる分析はSpringと依存ツリーから問題候補を探すために使われるが、そこから生じる修正は、コードを理解する技術者が作成、レビュー、検証する。モデルの出力を無条件に顧客環境へ適用する仕組みではない。

Spring Enterpriseでは、対応中の各リリース系列へ修正を用意し、通常のポイントリリースとは別に、脆弱性修正だけを届けるCVE-onlyパッチも提供する。機能変更を伴う更新とセキュリティ修正を切り分け、適用時の変更範囲を抑える設計だが、顧客固有の互換性や運用影響までBroadcomが保証するという説明ではない。

ここで見落とせないのは、AI走査と各パッチの手作業検証という説明が、主としてSpringとその依存関係を指している点だ。Java、Python、Node.jsの成果物については、Broadcomの技術者が選定、ビルド、検証、修正への貢献に関わることは示されたものの、Springと完全に同一のAI工程を全成果物へ適用するとは公表されていない。

クリーンルーム、修正PR、上流還元をつなぐ

TrueSourceの供給網対策は、完成したバイナリの検査だけでは終わらない。Trusted Artifactsは、採用するライブラリを参照アーキテクチャに沿って選び、クリーンルームでビルドし、来歴を追える検証済み成果物として供給する。これにより、公開リポジトリから取得したバイナリをそのまま社内へ持ち込む場合とは、供給元とビルド工程の責任範囲が異なる。

修正もBroadcom内部の商用フォークだけに閉じ込めない方針だ。Techzineの検証記事 は、修正を上流のメンテナーへ返す方針に加え、自動化が顧客リポジトリを走査し、影響範囲を評価して低リスクの修正経路を反映するプルリクエストを開く流れを報じている。

自動PRは適用候補を顧客へ届ける入口であり、本番環境への自動反映を意味しない。TrueSource側で成果物や修正が検証されても、利用企業にはアプリケーション固有のテスト、変更承認、配備判断が残る。タイトルにある「人が検証」はBroadcom側のパッチ工程を指し、顧客側の確認作業を不要にする約束ではない。

スキャナーやSBOMを置き換える製品ではない

通常の脆弱性スキャナーは、使用中のパッケージと既知の問題を突き合わせる。SBOMは構成要素や来歴を記録し、SCAは依存関係やライセンス、脆弱性の把握を支える。これらが主に「何を使い、どこに問題があるか」を可視化するのに対し、TrueSourceは「誰がビルドし、どの成果物と修正を供給するか」に商用責任を加える。

重なる領域はある。TrueSourceにもリポジトリ走査、セキュリティー状態の表示、自動PRが含まれるため、既存ツールの検出結果や更新機能と競合する可能性がある。一方、資産台帳の整備、組織独自の利用可否ルール、アプリケーションの回帰試験を包括的に代行するとは説明されていない。

そのため導入時の比較対象は、単独のスキャナーだけではなく、検証済みパッケージと長期保守を提供する商用OSSディストリビューションにもなる。TrueSourceの特徴は、Spring、複数言語のライブラリ、Bitnamiのコンテナ、データエンジンを共通原則で扱い、顧客リポジトリへの修正PRと上流還元までを一つの流れに含めた点にある。

公開情報だけでは保守範囲と価格を確定できない

発表時点で、三つのサービスは段階制のサイトライセンスで利用可能とされている。一方、価格、各段階の具体的な権利、地域別条件は公開発表に記載されていない。Java、Python、Node.jsについても、全対象パッケージ、対応バージョン、更新頻度、保守期限を確認できる公開カタログは示されていない。

日本の導入担当者にとって重要なのは、TrueSourceを検出件数を増やす製品ではなく、OSSのビルド元、修正主体、供給経路を契約対象にするサービスとして評価することだ。Spring利用企業には既存のSpring Enterpriseを核とした選択肢となるが、他言語やコンテナ、データ基盤まで含める場合は、現在のSCA、SBOM、社内リポジトリ、CI/CD統制との責任分界が判断材料になる。今後は対象カタログ、SLA、保守期限、日本での販売・サポート条件の開示が焦点となる。