BroadcomのSpring/Javaセキュリティ投資を導入前に確認する：Day Zeroパッチ、SLSA、Application Advisorの実務ポイント

3行まとめ

このテーマをもう少し広げて見るなら、Tanzu Platform 10.4の脆弱性修復を導入前に確認する：Vulnerability Insights、Tanzu Hub、Upgrade Plannerの実務ポイント と VCF 9.1でIaCを始める前に確認する：SDDC Manager API、Terraform、組織/プロジェクトの実務ポイント も合わせて確認してください。Spring/JavaのCVE対応を、Tanzu Platform側のVulnerability InsightsとUpgrade Plannerによる継続修復へつなげて読めるため。

緊急パッチ

Day Zero CVE-only patchesとSpring Enterprise Repositoryで、緊急CVE時の差分を小さく扱えるかを見ます。

依存関係の来歴

SLSA Level 3 validated Java dependenciesを、自社のSBOM、署名検証、監査証跡へ接続できるかを確認します。

アップグレード支援

Application Advisorで、Springアプリの依存関係、コード、設定変更を継続的に進められるかを評価します。

最初の論点は製品名ではなく、自社のCVE対応SLA、依存関係管理、Git/CI運用にどこまで接続できるかです。

• Broadcomは2026年6月8日、Spring/Java ecosystem securityへの投資拡大を公式発表しました。論点は、Tanzu Spring顧客向けのDay Zero CVE-only patches、Spring Enterprise Repository、SLSA Level 3 validated Java dependencies、Application Advisorによるアップグレード支援です。
• Spring Blogでは、2026年6月8日から14日にかけてSpringのrelease trainが集約され、多くのプロジェクトで新しいセキュリティパッチへのアップグレードが必要になると説明されています。Spring利用企業は、単に「最新へ上げる」だけでなく、緊急パッチ経路と通常アップグレード経路を分けて確認する必要があります。
• この記事では株価材料ではなく、Springアプリを運用する企業が、CVE対応SLA、依存関係の来歴、private artifact repository、SBOM、CI/CD、Application AdvisorのPoC条件をどう棚卸しするかに絞って整理します。

Broadcom Watch JapanはBroadcomおよびVMware by Broadcomの公式サイトではありません。この記事は、公式発表と公開ドキュメントを利用者目線で読み解く非提携の解説であり、投資助言や購入推奨ではありません。

今回の話題は、直近のVCF 9.1記事とは少し性質が違います。VCFやVKSの新機能ではなく、Spring BootやSpring Frameworkを使うJavaアプリケーションの足元、つまり脆弱性報告、パッチ配布、依存関係、アップグレード作業の話です。

需要シグナルとしては、Broadcomの公式発表後、InfoWorld、SD Times、Techzineなどの専門メディアやJava/Spring系コミュニティで、Spring CVE対応とAI-enabled threatsへの関心が出ています。ただし、この記事の事実認定はBroadcom公式発表、Spring Blog、Tanzu Blog、Broadcom TechDocsを軸にします。専門メディアやコミュニティの反応は「読者が何を知りたがっているか」を見る材料にとどめます。

SpringのCVE対応はなぜ今見直すべきなのか

1. 2026年3月

   Spring communityからBroadcomへ報告されるmonthly security advisoriesの比較起点です。

2. 2026年4月

   公式発表では、3月から4月にかけてmonthly security advisoriesが1700%以上増加したと説明されています。

3. 2026年6月8日から14日

   Spring BlogはMay Spring release trainの集約と、多くのSpring portfolioプロジェクトでのパッチ適用を案内しています。

4. 自社の本番反映

   CVE公開から影響判定、テスト、承認、本番反映までの平均日数を測る必要があります。

AI-enabled threatsという言葉だけで判断せず、CVE triageから本番反映までの詰まりを測ることが導入判断につながります。

Broadcomの2026年6月8日発表でまず見るべきなのは、「AI」という見出しよりも、脆弱性の発見速度と修正適用の運用負荷です。発表では、Spring communityからBroadcomへ報告されたmonthly security advisoriesが2026年3月から4月にかけて1700%以上増加したと説明されています。Spring Blogも、2026年6月8日から14日にかけてMay Spring release trainを移動・集約し、多くのSpring portfolioプロジェクトで新しいセキュリティパッチへのアップグレードが必要になると案内しています。

これは、Springを使っている企業にとって「ニュースを読んで終わり」の話ではありません。アプリ数が多いほど、CVEの確認、影響範囲の判断、依存関係の更新、テスト、リリース承認、本番反映が同時に積み上がります。とくにSpring Bootの古い系統や、事業部ごとに分かれたGitリポジトリ、再現性の低いビルド、薄い自動テストが残っている環境では、脆弱性の発見が速くなるほど、修正待ち行列も伸びやすくなります。

AI-enabled threatsで変わるのは攻撃の煽りではなく運用時間

根拠

Broadcomは、foundation modelsの進展によって新たに検出されるセキュリティ脆弱性が増え、脆弱性開示後のtime-to-exploit windowが縮んでいると説明しています。ここで重要なのは、AIを使った攻撃の一般論を広げることではありません。Spring利用企業にとっての実務は、発見された問題をどれだけ早く分類し、どれだけ小さい差分で塞ぎ、いつ通常アップグレードへ戻すかです。

確認項目

たとえば、CVE公開から本番反映までの平均日数が長い企業では、緊急対応の承認フローが詰まりやすくなります。セキュリティ部門が影響判定を終えても、開発チーム側で対象バージョンが分からない、CIが通らない、依存関係の更新で別のテストが落ちる、ということが起きます。AI-enabled threatsという言葉を広く怖がるより、CVE triageから本番反映までのリードタイムを測るほうが、導入判断には役立ちます。

OSSの通常リリースで足りる領域と足りない領域を分ける

条件

Spring Blogは、最新パッチへのアップグレードを強く推奨しています。OSSの通常リリースへ速く追従できるチームなら、それ自体が強い対策です。すべての企業が商用サポートやprivate artifact repositoryをすぐ使う必要があるわけではありません。

一方で、金融、医療、公共、通信、基幹業務のように変更審査が重いアプリや、古いSpring Boot系統をすぐ上げられないアプリでは、通常アップグレードだけでは修正速度が間に合わない場面があります。ここでTanzu SpringのDay Zero CVE-only patchesやSpring Enterprise Repositoryが検討対象になります。

最初の棚卸し

まず作るべきなのは、製品比較表ではなくSpring利用台帳です。最低限、アプリ名、担当チーム、Spring Boot/Spring Frameworkのバージョン、Javaランタイム、BOM、ビルド方式、依存関係更新ツール、CVE対応SLA、直近の緊急パッチ実績を並べます。この台帳がないまま商用サポートを検討しても、どのアプリで効果を測るのかがぼやけます。

Day Zero CVE-only patchesとSpring Enterprise Repositoryをどう評価するか

1. 1CVE影響判定

   対象アプリ、Spring Boot/Spring Frameworkのバージョン、依存関係の影響範囲を確認します。

2. 2Spring Enterprise Repository

   Tanzu Spring customers向けのenterprise supported releasesを、社内Artifact RepositoryやCI/CDへ接続します。

3. 3CVE-only patch適用

   セキュリティ修正を他の変更から分け、レビュー対象の差分を説明しやすくします。

4. 4CIと回帰テスト

   差分が小さくても、アプリごとのテスト、承認、監視は省略できません。

5. 5通常アップグレードへ戻す

   緊急対応後に、minor/major更新、Javaランタイム更新、非推奨API整理へ戻します。

評価ではパッチ入手の速さだけでなく、認証情報、監査ログ、SBOM、CI通過率、承認フローまで含めて見ます。

Broadcomの発表で目立つのは、Tanzu Spring customers向けに、Spring Enterprise Repository経由でvalidated CVE patch-only releasesへのday zero accessを提供するという点です。公式発表は、CVE-only patchがセキュリティ修正を他の変更から分離し、露出時間を短くするためのものだと説明しています。

ここで読み違えやすいのは、CVE-only patchを「通常アップグレードをしなくてよい仕組み」と考えてしまうことです。実際には逆です。CVE-only patchは、緊急時に小さい差分で穴を塞ぐための経路です。技術的負債をなくす通常アップグレード、Spring Bootのminor/major更新、Javaランタイムの更新、非推奨APIの整理は別に残ります。

CVE-only patchは緊急対応の差分を小さくする

根拠

通常のバージョン更新では、セキュリティ修正以外の変更も入ります。これ自体は悪いことではありませんが、緊急CVE対応では、差分が大きいほどテスト範囲と承認負荷が増えます。CVE-only patchの価値は、緊急対応時に「何を変えたのか」を説明しやすくすることにあります。

注意点

ただし、差分が小さければ必ず安全に本番反映できる、という意味ではありません。Spring Security、Spring Framework、Spring Boot、周辺ライブラリ、独自starter、社内共通ライブラリが絡む環境では、アプリごとの回帰テストが必要です。CVE-only patchの導入評価では、パッチ入手の速さだけでなく、CI通過率、差分レビュー時間、承認者の確認項目、本番反映後の監視まで含めて測るべきです。

Spring Enterprise Repositoryを社内の配布経路に接続できるか

確認項目

Spring Enterprise Repositoryは、Tanzu Springのenterprise supported releasesへアクセスするためのリポジトリとしてTechDocsで説明されています。導入企業は、MavenやGradleに直接設定するだけでなく、社内のArtifact Repository、依存関係キャッシュ、プロキシ、認証情報管理、SBOM生成、CI/CDの再現性と合わせて見なければなりません。

とくに大企業では、開発チームが個別に外部リポジトリへ接続する設計は避けたいところです。セキュリティ部門やPlatform Engineeringが、認証情報、アクセス権限、監査ログ、依存関係の取得経路を中央で説明できる形にする必要があります。

評価基準

PoCでは、重要アプリをいきなり全社横断で選ぶより、依存関係が比較的整理されたSpring Bootアプリを3本ほど選ぶのが現実的です。Spring Enterprise Repositoryへの接続、既存の社内リポジトリとの同期、CIでの再現ビルド、SBOMへの反映、緊急パッチ適用時のPR差分を測ります。

older supported versionsを残す場合はサポート範囲を契約で確認する

条件

Broadcomは、OSS support下のSpring projectだけでなく、Tanzu Spring enterprise support下のolder versionsについてもCVEを発行し続けると説明しています。これは古い系統が残る企業には大きな材料です。

ただし、どのバージョンが自社契約で対象になるのか、どのコンポーネントが対象なのか、いつまでenterprise supportを受けられるのかは、公開記事だけで断定できません。Spring BootやSpring Frameworkだけでなく、Apache Tomcat、OpenJDK、Spring Cloud系、社内で使う周辺コンポーネントまで期待範囲を広げている場合は、Broadcom/VMware Tanzuの契約資料とTechDocsで確認が必要です。

下振れ要因

古いJavaランタイム、独自fork、サポート外の依存関係、再現できないビルドが残っている場合、Day Zero accessだけでは適用速度は上がりません。古い系統を残す判断は、商用サポートの有無だけでなく、テスト資産、ビルド再現性、リリース承認の実態と一緒に扱うべきです。

SLSA Level 3 validated Java dependenciesは何を確認させるのか

1. 1Spring Boot BOM

   Spring Boot 4.0では1,768 dependencies、supported portfolio全体では100,000を超えるvalidated dependency buildsが説明されています。

2. 2Transitive dependencies

   直接指定していないライブラリも含め、どの経路で入っているかを説明できる状態にします。

3. 3Clean-room buildとSLSA Level 3

   ビルドプロセスや来歴の信頼性を高める取り組みとして評価します。

4. 4SBOMと署名検証

   CIで生成したSBOMと本番に出た成果物が一致しているかを確認します。

5. 5監査証跡

   調達部門や監査部門に、依存関係の取得元、ビルド来歴、保存先を説明できるようにします。

SLSA Level 3 validated dependenciesは、CVEゼロやアプリケーション安全性の完全保証ではありません。既存のSBOM、署名検証、脆弱性スキャンと組み合わせて評価します。

Broadcomは、Tanzu Spring customersがsecured, SLSA Level 3 validated software supply chain for Java dependenciesへアクセスできると説明しています。さらに、Spring Boot bill of materialsが管理するfull transitive dependency graphを対象にし、Spring Boot 4.0だけで1,768 dependencies、supported portfolio全体では100,000を超えるvalidated dependency buildsに言及しています。

この数字は大きいですが、自社アプリの依存関係がすべて自動的に安全になる、という意味ではありません。公式発表の文脈では、Spring ecosystemとそのdependenciesを、clean-room builtでverifiableなsoftware supply chainとして提供する取り組みです。導入企業側では、それを自社のSBOM、署名検証、依存関係ポリシー、監査証跡へどう接続するかが問われます。

Spring Boot BOMをアプリの外側にある供給網として見る

根拠

Spring BootのBOMは、アプリ開発者が個別依存のバージョンを細かく選ばずに済む便利な仕組みです。一方で、依存関係が増えるほど、どのライブラリがどの経路で入っているかを説明しづらくなります。Broadcomの今回の発表は、このBOM配下のtransitive dependenciesを供給網として扱い、ビルドと検証の来歴を強化する話として読むと実務に落とし込みやすくなります。

確認項目

導入評価では、まず自社のSpring BootアプリでどのBOMを使っているか、依存関係の固定をどう行っているか、SBOMをどのタイミングで生成しているかを確認します。CIで生成したSBOMと、本番にデプロイされた成果物が一致しているかも重要です。SLSAの話を調達部門や監査部門へ説明するには、依存関係の一覧だけでなく、ビルド来歴と取得元を示せる必要があります。

SLSA Level 3は脆弱性ゼロ保証ではない

注意点

SLSA Level 3は、ソフトウェア供給網のビルドプロセスや来歴の信頼性を高めるための考え方です。脆弱性スキャナではありません。SLSA Level 3 validated dependenciesと聞くと、安全保証のラベルのように見えますが、CVEが存在しないことや、アプリケーションの設計が安全であることを保証するものではありません。

そのため、導入判断ではSLSAを単独で見ないほうがよいです。SBOM、署名検証、artifact policy、脆弱性スキャン、runtime防御、変更審査、例外承認を並べ、その中で「依存関係がどこから来て、どうビルドされたか」を説明する材料として扱います。

上振れ要因

すでにSBOM管理や署名検証、CI/CD gateを持つ企業では、SLSAの価値を既存プロセスに乗せやすいはずです。逆に、アプリごとにビルド方法が違い、依存関係の取得元もばらばらな企業では、先に標準化が必要です。SLSAのラベルを導入する前に、artifact repositoryとビルドパイプラインを整理するほうが効果が出ます。

Bitnami由来のclean-room buildをどう監査に使うか

評価基準

Broadcomは、Bitnamiで基盤になっているclean-room build architectureを拡張し、Spring ecosystem全体のJava dependenciesを構築すると説明しています。ここで企業が確認すべきなのは、宣伝文句としてのclean-roomではなく、監査で何を提示できるかです。

調達・監査の観点では、依存関係の出所、ビルドプロセス、改ざん防止、検証記録、更新タイミング、例外時の扱いを聞かれます。Tanzu Springの依存関係供給網を使う場合、自社の監査証跡にどの情報を取り込めるのか、社内のGRCやSBOM管理ツールへどう渡せるのかを、PoC時点で確認しておくと後戻りが少なくなります。

Application Advisorはdependency debtをどう減らすのか

1. 1Gitリポジトリ把握

   対象リポジトリ、ブランチ運用、コードオーナー、PR作成権限を棚卸しします。

2. 2アップグレード計画

   Spring application dependencies、source code、configurationを含めた移行ステップを確認します。

3. 3Pull Request生成

   複数リポジトリに対して一貫した変更を作れるか、既存ツールとのPR重複が起きないかを見ます。

4. 4CI検証

   PR生成数ではなく、CI通過率、テスト信頼性、失敗時の差し戻しやすさを測ります。

5. 5レビューと本番反映

   レビュー担当、変更凍結期間、承認フローまで含めて、マージまでのリードタイムを評価します。

DependabotやRenovateとの比較は勝敗ではなく役割分担で見ます。汎用依存更新とSpring固有のコード・設定変更を分けることが重要です。

Application Advisorについて、Broadcom TechDocsは「all your Git repositories across Spring application dependencies, source code, and configuration」を継続的・段階的にアップグレードするためのツール群として説明しています。Tanzu Springのページでも、Application Advisor CLIをCI pipelineへ統合し、特定のアップグレードステップに対するsource code updatesやmerge requestsを生成できるとされています。

これは単なるバージョン通知ツールではありません。DependabotやRenovateのような汎用依存関係更新と重なる部分はありますが、Spring固有のアップグレード、コード変更、設定変更、移行手順の扱いまで含めて見るべきです。

リポジトリ単位ではなくポートフォリオ単位で評価する

確認項目

Springアプリが数本なら、手動でリリースノートを読み、依存関係を上げ、テストを回す運用でも十分なことがあります。しかし、数十から数百のリポジトリがある場合、dependency debtはアプリ単位ではなくポートフォリオ単位で効いてきます。

Application AdvisorのPoCでは、1つのリポジトリだけをきれいに更新できたかより、複数リポジトリに対してどれだけ一貫したPRを作れるか、CIがどれだけ通るか、レビュー負荷がどこに出るかを測るべきです。対象Gitリポジトリ、ブランチ運用、PR作成権限、CI時間、テスト信頼性、コードオーナー、変更凍結期間まで棚卸しします。

評価基準

緊急CVE対応では、PRが大量に出るほどレビューとテストが詰まります。Application Advisorを導入しても、レビュー担当が足りなければ本番反映は進みません。自動化の評価は、PR生成数だけでなく、PRがマージされるまでのリードタイムで測る必要があります。

DependabotやRenovateとの役割分担を決める

注意点

すでにDependabotやRenovateを使っている企業は、Application Advisorを置き換え候補としてだけ見る必要はありません。汎用的な依存関係の更新は既存ツールに任せ、Spring固有のアップグレード、コード修正、設定変更、enterprise support対象バージョンの扱いをApplication Advisorで補う、という分担がありえます。

重要なのは、同じ依存関係を複数ツールが別々に更新して、PRが乱立しないようにすることです。どのツールがどのファイルを触るのか、security updateとminor updateをどう分けるのか、緊急CVE時にどのPRを優先するのかを決めておきます。

効果はPoCで自社の数字として測る

確認項目

Tanzu Blogや公式発表は、Application Advisorを使ったdeterministicなアップグレード支援を強調しています。ただし、効果は自社のアプリ構成とテスト品質に左右されます。独自starterが多い、古いSpring Boot系統から一気に上げる、ビルドがローカル前提、統合テストが重い、といった条件では、PR生成後の人手作業が大きく残ります。

PoCでは、低リスクアプリ、中リスクアプリ、重要アプリを分けて測ると見えやすくなります。測る項目は、検出されたdependency debt、生成されたPR数、差分行数、CI通過率、レビュー時間、手動修正の量、リリースまでの日数です。「自動化できるか」だけでなく、「どこに人の判断が残るか」を明らかにするのが目的です。

導入前チェックリスト

項目	内容	見方
すぐPoC		Spring Bootアプリが多く、CVE対応の遅れがあり、SBOM、社内Artifact Repository、CI/CD、コードオーナーがある程度整っている企業。
条件付きPoC		Spring利用は多いものの、古いバージョン、薄いテスト、再現しづらいビルド、分散したリポジトリ権限が残る企業。
現状維持で監視		Spring利用が限定的で、OSS通常リリースへの追従が速く、既存運用でCVE対応SLAを満たしている企業。

セキュリティ対応では単純な優劣ではなく、アプリ数、変更審査、テスト品質、既存CI/CDの成熟度で次の一手が変わります。

Tanzu Spring、Day Zero CVE-only patches、SLSA Level 3 validated dependencies、Application Advisorを一気に導入判断する前に、自社の立ち位置を分けます。ここでは「すぐPoCに進みやすい企業」「条件付きで評価する企業」「急がないが監視すべき企業」の3つに整理します。

すぐPoCに進みやすい企業

条件

Spring Bootアプリが多く、過去のCVE対応でリードタイムが長く、すでにSBOM、社内Artifact Repository、CI/CD、コードオーナー、変更審査がある程度整っている企業は、PoCに進みやすいです。基盤があるため、Spring Enterprise RepositoryやApplication Advisorの差分を測りやすいからです。

確認項目

最初のPoCでは、重要度が高すぎず、でも実運用に近いアプリを3本から5本選びます。見る項目は、Spring Enterprise Repositoryへの接続、CVE-only patchの差分確認、Application AdvisorによるPR生成、CI通過率、SBOMへの反映、レビュー負荷です。PoCのゴールは「全社導入の是非」ではなく、「緊急CVE時に既存運用のどこが速くなるか」を測ることです。

条件付きで評価する企業

条件

Spring利用は多いものの、バージョンが古い、テストが薄い、ビルドが再現しづらい、リポジトリ権限が分散している企業は、いきなり製品導入を進めると詰まりやすいです。この場合は、Tanzu Springの評価と並行して、dependency debtの棚卸しを先に行います。

評価基準

まずは1つの事業部、または1つのSpring Boot系統に範囲を絞ります。たとえば、Spring Boot 2.xが残るアプリ群、Spring Boot 3.xへ移行済みのアプリ群、Kubernetes上で動くアプリ群を分け、どこにPoC価値があるかを見ます。テストが薄いアプリでApplication Advisorを走らせると、PR生成後の確認作業が見えます。これは失敗ではなく、導入前に修正すべき運用課題が見えたということです。

急がないが監視すべき企業

条件

Spring利用が限定的で、OSS通常リリースへの追従が速く、CVE対応SLAを自力で満たしている企業は、すぐ商用サポートを導入しなくてもよいかもしれません。既存のDependabotやRenovate、SBOM、脆弱性スキャナ、CI/CDで十分に回っているなら、まずは監視を続ける判断もあります。

注意点

それでも、Spring release train、利用中バージョンのsupport status、Spring Security Advisories、Javaランタイムのサポート期限は追い続ける必要があります。Springアプリが事業上重要になったり、CVE対応SLAが厳しくなったり、監査で供給網の証跡を求められたりした段階で、Tanzu SpringやApplication Advisorの評価に戻ればよいです。

本文末の導入判断メモ

Spring利用台帳

どのアプリがどのSpring Boot、Spring Framework、Javaランタイムを使っているかを把握します。

サポート対象バージョン

OSS通常リリース、enterprise supported releases、自社で残している古い系統を分けます。

緊急パッチSLA

CVE公開から影響判定、テスト、承認、本番反映までの目標日数を定義します。

Spring Enterprise Repository接続可否

Maven/Gradle、社内Artifact Repository、認証情報、監査ログ、SBOM生成に接続できるかを確認します。

Application AdvisorのGit/CI条件

対象リポジトリ、PR作成権限、CI時間、テスト信頼性、レビュー担当を事前にそろえます。

5項目のうち3つ以上が未整理なら、Day Zero patchやSLSAへの期待より先に棚卸しを進めるほうが判断しやすくなります。

今回の発表を導入判断に変えるなら、最初に見るべき項目は5つです。Spring利用台帳、サポート対象バージョン、緊急パッチSLA、Spring Enterprise Repository接続可否、Application Advisorを走らせるGit/CI条件です。

5つのうち3つ以上が未整理なら、製品比較より棚卸しが先です。Day Zero patchへの期待があっても、対象アプリが分からなければ適用できません。SLSA Level 3 validated dependenciesに関心があっても、SBOMやartifact policyがなければ監査で使いにくくなります。Application Advisorに期待しても、CIが不安定ならPRは溜まるだけです。

一方で、Spring利用台帳とCI/CDが整っている企業にとって、今回のBroadcom発表は見る価値があります。Tanzu Springは、単に「Springの商用サポート」というより、緊急パッチ、enterprise supported releases、Java dependenciesの供給網、アップグレード自動化をまとめて検討する入口になっています。

内部リンクとして、BroadcomのQ2 FY2026全体像は<a href="https://avgo-watch.blog.mo-gmo.com/avgo-23-q2-2026-ai-vmware-product-check/">Broadcom Q2 FY2026決算後チェック</a>で整理しています。Springアプリの実行基盤としてKubernetesやVKSを見ている場合は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-35-kubecon-india-2026-vks-ai-kubernetes-check/">BroadcomのKubeCon India 2026出展チェック</a>や<a href="https://avgo-watch.blog.mo-gmo.com/avgo-21-vcf-91-vks-multi-network-check/">VCF 9.1のVKSマルチネットワーク対応</a>も合わせて確認できます。2026年6月の重要トピックは<a href="https://avgo-watch.blog.mo-gmo.com/monthly-topics-2026-06/">月次まとめ</a>で追跡しています。

この記事の確認日は2026年6月10日です。TechDocsの対象バージョン、Application Advisorのドキュメント、Spring Enterprise Repositoryの説明、Tanzu Springのサポート範囲は更新される可能性があります。実際の契約、価格、対象バージョン、利用権限は、Broadcom/VMware Tanzuの最新資料と契約条件で確認してください。

---

次に読むなら

参照した主な情報源

• Broadcom, "Broadcom Expands Its Investment in Spring and Java Ecosystem Security to Prepare Customers for AI-Enabled Threats", 2026年6月8日。確認日: 2026年6月10日。https://news.broadcom.com/releases/broadcom-expands-investment-in-spring-and-java-ecosystem-security
• Spring Blog, "Spring and Security In The Times Of AI", 2026年6月1日。確認日: 2026年6月10日。https://spring.io/blog/2026/06/01/spring_and_security_in_the_times_of_ai
• Tanzu Blog, "Broadcom’s Investment in Spring to Combat AI-Fueled Security Challenges in the Enterprise", 2026年6月。確認日: 2026年6月10日。https://blogs.vmware.com/tanzu/broadcoms-investment-in-spring-to-combat-ai-fueled-security-challenges-in-the-enterprise/
• Broadcom TechDocs, "VMware Tanzu Spring"。確認日: 2026年6月10日。https://techdocs.broadcom.com/us/en/vmware-tanzu/spring/tanzu-spring/commercial/spring-tanzu/index.html
• Broadcom TechDocs, "Application Advisor 1.6 documentation"。確認日: 2026年6月10日。https://techdocs.broadcom.com/us/en/vmware-tanzu/spring/application-advisor/1-6/app-advisor/index.html
• Broadcom TechDocs, "Spring Enterprise Repository"。確認日: 2026年6月10日。https://techdocs.broadcom.com/us/en/vmware-tanzu/spring/tanzu-spring/commercial/spring-tanzu/spring-enterprise-subscription.html