追記: 2026年6月16日の最新情報
2026年6月16日時点で、Broadcom TechDocsのTanzu Hub 10.4リリースノートにTanzu Hub v10.4.1が掲載されています。v10.4.1はセキュリティ脆弱性とバグ修正に対応するパッチリリースで、v10.4.0からv10.4.1、v10.3.7からv10.4.1へのアップグレードが案内されています。
運用判断では、まずTanzu Hubを10.4.1へ上げる必要があるかをリリースノートとSecurity fixesで確認し、そのうえでVulnerability Insightsの「View Remediations」からUpgrade Plannerへ進みます。Upgrade Plannerは対象Foundationのインストール済みバージョンを読み取り、Latest patchを既定のゴールとして計画を生成するため、CVE一覧の件数だけでなく、どのコンポーネントをどの順番で更新するかまで確認してください。
- 一次情報：Tanzu Hub release notes、Remediate vulnerabilities with Upgrade Planner、Platform Services v10.4.1 security fixes
- 注意：CVE項目は今後追加・修正される可能性があります。適用直前に、対象Foundationの製品バージョンとSecurity fixesを見直してください。
このテーマをもう少し広げて見るなら、Tanzu Decoupled Stack Tile v1.0.5を適用前に確認する：cflinuxfs4 1.322.0、buildpack更新、Apply Changesの実務ポイント と BroadcomのSpring/Javaセキュリティ投資を導入前に確認する：Day Zeroパッチ、SLSA、Application Advisorの実務ポイント も合わせて確認してください。Vulnerability Insightsで見つけた修復を、stackやbuildpack更新、Apply Changesの実作業へつなげられるため。
BroadcomのTanzu Platform 10.4で脆弱性対応を見るなら、最初に確認すべきなのは「CVEが何件あるか」だけではありません。Tanzu HubのVulnerability Insightsが扱う対象、AppsとFoundationsの画面差、Latest patchとLatest majorの意味、Upgrade Plannerへ渡す変更順序を分けて見る必要があります。
2026年6月8日のBroadcom公式発表と6月9日のTanzu Blogでは、AIにより脆弱性発見と悪用までの時間が短くなり、Spring/Javaエコシステムの修復速度が重要になっていることが示されました。この記事では、その背景を受けつつ、既存のSpring投資解説とは別に、Tanzu Platform側で実際に脆弱性可視化と修復計画をどう読むかに絞ります。
この記事はBroadcom、VMware、Tanzuの公式サイトではなく、Broadcom Watch Japanによる非公式の確認メモです。確認日は2026年6月13日です。価格、契約条件、サポート範囲、利用権限は、必ずBroadcomの最新資料と契約内容で確認してください。
3行まとめ：Tanzu Platform 10.4で「修復できる脆弱性」をどう見分けるか
buildpack、stemcell、stack、service、secure container imageなど、Tanzu Platformが把握する部品を確認する。
業務ロジック、独自ソースコード、独自コンテナは別のSAST、SCA、SBOM運用で補う。
Latest patchは短期対応、Latest majorは大きな更新計画として分けて読む。
Apps、Foundations、Upgrade Plannerへ渡す単位を分け、担当チームと変更窓につなげる。
CVE件数だけで判断せず、すぐ直せるものと計画が必要なものを分けることが出発点です。
- Tanzu HubのVulnerability Insightsは、buildpack、stemcell、stack、service、secure container imageなど、Tanzu Platformが把握するplatform-managed componentsを中心に可視化する仕組みです。
- Apps > Vulnerability Remediationではアプリ影響、Foundations > Platform Vulnerabilitiesでは基盤側の修復候補を見るため、同じCVE対応でも担当チームと変更単位が変わります。
- Latest patchは日常のパッチ運用、Latest majorは大きな更新計画の検討に使い、Upgrade Plannerでは互換性、EOGS、CVE解消見込み、段階的な順序まで確認します。
Tanzu Platform 10.4の価値は、脆弱性を単に一覧化することではなく、どの基盤部品やアプリ供給経路を直せば、どの範囲のリスクが減るのかを運用判断に近づけるところにあります。セキュリティチームはCritical/High CVEや修復可能性を見たい一方、プラットフォームチームはFoundation Coreや依存関係、アプリチームは再ビルドやrestageの影響を見ます。
導入前レビューでは、次の4つを先に分けてください。第一に、Vulnerability Insightsが見ている対象コンポーネントです。第二に、Tanzu Hubだけでは評価しない対象外範囲です。第三に、Latest patchで短期対応するのか、Latest majorで更新計画を組むのかという時間軸です。第四に、Upgrade Plannerへ渡す変更単位です。
この線引きをしないままCVE件数だけを見ると、Tanzu Hubが万能スキャナのように見えたり、修復率の高いメジャー更新をそのまま推奨のように扱ったりします。実務では、見えるもの、見えないもの、すぐ直せるもの、計画が必要なものを分けるのが先です。
Spring/Java側の背景を先に押さえたい場合は、既存記事の<a href="https://avgo-watch.blog.mo-gmo.com/avgo-39-tanzu-spring-java-security-day-zero-check/" rel="noopener">BroadcomのSpring/Javaセキュリティ投資を導入前に確認する</a>でDay Zero CVE-only patchesやSLSAの位置づけを確認できます。本記事では、そこから一歩進んでTanzu Platform運用の見方に絞ります。
Vulnerability Insightsの対象範囲を最初に線引きする
runtimeやframework準備に関わり、更新後のrestageやアプリ側の再テストにつながる。
イメージ供給経路、レジストリ、再ビルド、再デプロイ手順と結びつけて確認する。
依存関係更新、Tanzu Springサポート、SBOMやCIの確認へつなげる。
OS基盤やコンテナベース層として、foundation単位の変更窓で扱う。
単一アプリではなく、基盤機能全体への影響として変更審査に載せる。
Vulnerability Insightsは万能スキャナではなく、Tanzu Platformが管理する部品の修復候補を見る入口です。
Tanzu HubのVulnerability Insightsを導入判断に使うとき、最初の確認点は対象範囲です。Broadcom TechDocsでは、対象としてbuildpacks、stemcells、stacks、services、secure container images、first-party tiles、foundation management artifactsが示されています。secure container imagesには、application/service workload imagesとsecure marketplace catalog imagesが含まれます。
これらは、Tanzu Platformが管理し、バージョン、利用状況、修復候補を結びつけやすい部品です。たとえばbuildpackに脆弱性がある場合、単に「JavaアプリにCVEがある」と見るのではなく、どのbuildpackのどのバージョンが、どのアプリで使われているかを追う発想になります。stemcellやstackなら、アプリ個別の修正というより、foundation単位の更新計画になります。
platform-managed componentsとして扱うもの
根拠
導入前の棚卸しでは、対象をアプリ側に近いものと基盤側に近いものへ分けると整理しやすくなります。
| 種別 | 主に見るチーム | 実務上の見方 |
|---|---|---|
| Buildpacks | プラットフォーム、アプリ | アプリのruntimeやframework準備に影響し、更新後のrestageが必要になりやすい |
| Secure container images | アプリ、プラットフォーム | アプリやサービスのイメージ供給経路、レジストリ、再デプロイ手順と結びつける |
| Spring libraries | アプリ、セキュリティ | 依存関係更新、Tanzu Springサポート、SBOMやCIの確認へつなげる |
| Stemcells、stacks | プラットフォーム | OS基盤やコンテナベース層として、foundation単位の変更窓で扱う |
| Services、tiles、foundation management artifacts | プラットフォーム、運用 | 単一アプリではなく基盤機能全体への影響として変更審査に載せる |
この表を使う目的は、担当チームを早めに切り分けることです。CVEの深刻度が高くても、修復作業がbuildpack更新なのか、Spring依存関係更新なのか、stemcell更新なのかで、必要な検証、停止影響、ロールバック手順が変わります。
Vulnerability Insightsがやらないことを明示する
注意点
重要なのは、Vulnerability Insightsがfoundationやworkloadの内部で任意の脆弱性スキャナを走らせて棚卸しする機能ではない点です。TechDocsでは、Tanzu Platformがこれらのコンポーネントをfoundationの外側でスキャン、トリアージし、そのデータをTanzu Hubに表示する形と説明されています。
また、custom business logicやproprietary application source codeを評価するものでもありません。業務ロジックの脆弱性、独自コードのSAST、アプリ固有のSCA、独自コンテナの詳細なスキャンは、既存のセキュリティプロセスと接続して扱う必要があります。
ここを曖昧にすると、Tanzu Hubを入れれば全アプリの脆弱性管理を置き換えられる、という誤解につながります。実際には、Tanzu Hubはplatform-managed componentsの修復可能性を読む入口として強く、アプリ固有のコード評価は別の証跡で補う設計が必要です。
customized buildpackやSBOM連携は別枠で扱う
確認項目
customized buildpackにも注意が必要です。TechDocsでは、元のファイル名から変更されたbuildpackはVulnerability Insightsに表示されず、元のファイル名を保持したカスタムbuildpackは元の未変更版のように表示されると説明されています。つまり、カスタム変更を含むbuildpackについては、Tanzu Hubの表示だけでCVE状態を判断し切れません。
Spring libraryやSBOMの扱いも同じです。Tanzu Platformには、リポジトリやCIに接続してアプリメタデータを扱う別のワークフローがありますが、それをVulnerability Insightsそのものと混同しないほうが安全です。導入前レビューでは、Tanzu Hubで見えるもの、Tanzu Platformの別機能で扱うもの、既存のSCA/SAST/コンテナスキャンで扱うものを3分類にしてください。
Tanzu Hubで見る画面をAppsとFoundationsに分ける
foundation group、foundation、component type、deployed/in useで基盤側の更新候補を絞る。
どのアプリがどのコンポーネントを使い、どの更新で修復できる見込みがあるかを見る。
restage、再テスト、対象アプリの確認をプラットフォームチームとアプリチームで分担する。
イメージ作成元、レジストリ、展開経路、署名やSBOMの扱いを確認する。
依存関係更新、Tanzu Springのサポート、CI上の検証と結びつける。
画面やタブを分けて読むほど、誰がどの作業を持つのかが明確になります。
Tanzu Hubの見方は、Apps側とFoundations側で目的が違います。同じ脆弱性対応でも、Apps > Vulnerability Remediationは「どのアプリが、どの修復候補を持つか」に寄り、Foundations > Platform Vulnerabilitiesは「どの基盤コンポーネントを、どのfoundationで更新すべきか」に寄ります。
Foundations > Platform Vulnerabilitiesで基盤側を棚卸しする
根拠
Foundations > Platform Vulnerabilitiesは、stemcells、tiles、services、foundation management componentsなど、基盤側の要素を確認する入口です。ここではアプリ名だけでなく、foundation group、foundation、component type、deployed/in useのようなフィルタを使い、実際に稼働中の基盤コンポーネントに絞って優先度を見ます。
基盤側のCVE対応では、単に「Criticalがある」だけでは作業に落ちません。どのfoundationにあり、どのcomponent typeで、既存のFoundation Coreや関連製品との互換性に触れるかを確認する必要があります。とくにserviceやtileの更新は、影響範囲がアプリ単体より広くなります。
Apps > Vulnerability Remediationでアプリ影響を読む
評価基準
Apps > Vulnerability Remediationは、利用中コンポーネントにCVE修復候補があるアプリを見る画面です。TechDocsでは、buildpack、secure container image、Spring libraryのタブを切り替え、Vulnerable Apps w/ Upgrades、Critical/High CVEs、available component upgrades、Upgrades Fixを見ると説明されています。
ここでアプリチームへ渡すべき情報は、CVEの総数ではありません。どのアプリがどのコンポーネントを使っていて、どの更新でどれだけ修復できる見込みがあるのかです。buildpackならrestageや再テスト、secure container imageなら再ビルドや再デプロイ、Spring libraryなら依存関係更新やサポート方針の確認に落とします。
タブごとに担当チームを変える
buildpack、secure container image、Spring libraryを同じ一覧として扱うと、責任分界がぼやけます。buildpack更新はプラットフォームチームが主導しても、対象アプリのrestageや回帰テストにはアプリチームが必要です。secure container imageは、イメージ作成元、レジストリ、デプロイ経路、署名やSBOMの取り扱いまで確認します。Spring libraryは、依存関係更新、Tanzu Springのサポート、CI上の検証と結びつけます。
導入前のPoCでは、まず3つのタブを別々に見て、誰が、どの作業を、どの変更窓で行うかを書き出すとよいです。Tanzu Hubの値は判断材料であり、実際の修復は各チームの作業に分解して初めて進みます。
Latest patchとLatest majorを同じ「修復率」で見ない
日常パッチの基準として、短期の変更窓に載せる候補を作る。
breaking changes、アプリ改修、テスト工数、サポート期間を含む中期計画として扱う。
パッチで減らせるCVEの見込みを、CVE台帳や変更チケットへつなげる。
更新で減らせるCVE数を見つつ、業務影響や補完統制も合わせて判断する。
platform managed components以外の業務ロジックや独自コードは、別証跡で確認する。
修復されるCVE数が大きく見えても、即日適用できるという意味ではありません。
Tanzu HubのTarget Versionフィルタでは、Latest patchとLatest majorを切り替えてremediation potentialやCVE fix countを確認できます。ここで大切なのは、2つを同じ温度感で比べないことです。Latest patchは日常的なセキュリティ修正やbug fixの候補を見るための軸で、Latest majorはより大きな更新サイクルで修復可能性を見るための軸です。
Latest patchは日常パッチの基準にする
確認項目
Latest patchは、各コンポーネントの最新パッチ版を前提に、どれだけのCVEが修復できるかを見ます。日常運用では、まずここから見るのが自然です。Latest patch version、Patch will fix、Remediation Potential、Critical/High CVEsを使い、短期の変更窓に載せる候補を作ります。
たとえば、あるbuildpackのLatest patchで複数のCritical/High CVEが減るなら、対象アプリ、restage対象、テスト範囲を確認して変更チケット化できます。stemcellやstackなら、foundation単位の変更として、メンテナンス窓とロールバック方針を合わせて見ます。
Latest majorは大規模更新サイクルで見る
条件
Latest majorは、最新メジャーバージョンへ上げた場合の修復可能性を見ます。修復できるCVE数やUpgrades Fixが大きく見えても、それは即日適用できるという意味ではありません。新機能、breaking changes、アプリ改修、テスト工数、サポート期間の確認が必要です。
したがって、Latest majorは四半期や半期の更新計画、主要基盤更新、アプリ互換性検証の入口として使うのが現実的です。短期対応はLatest patchで検討し、積み残しやサポート期限、技術的負債の整理はLatest majorで計画化する、と分けると判断しやすくなります。
Upgrades FixとPatch will fixは優先度付けの材料にする
評価基準
Upgrades FixやPatch will fixは、どの更新でどれだけCVEが減る見込みかを見る材料です。ただし、それだけでリスクが完全に消えるわけではありません。deployed/in use、業務影響、外部公開有無、既存の補完統制、False PositiveやNot Affectedの扱いを合わせて見る必要があります。
セキュリティチームに出す資料では、CVE件数の削減見込みと同時に、対象外範囲も書いてください。「Tanzu Hub上ではplatform-managed componentsのこの範囲を確認した。業務ロジック、独自ソースコード、独自コンテナの詳細は別証跡で確認する」という説明があるだけで、変更審査の誤解はかなり減ります。
component type別に修復アクションを分ける
対象アプリ、restage順序、回帰テスト、bulk restage時の影響範囲を確認する。
OS層やコンテナベース層の更新として、foundation単位の変更窓とロールバック方針を決める。
イメージ更新、再ビルド、再デプロイ、レジストリ運用に戻して修復完了を確認する。
依存関係更新、サポート方針、SBOM、CIの確認をアプリ側の作業として扱う。
依存サービス、maintenance window、EOGS、利用部門への通知を含めて計画する。
深刻度だけでなく、修復作業がどの運用プロセスに戻るかを見ます。
Tanzu Platform 10.4のrelease notesでは、Tanzu Hubのvulnerability and governanceとして、services、stacks、Bitnami-backed workloadsへのinsights拡張、urgent buildpack CVEsへのbulk restage、stack/buildpack無効化、buildpack updatesのfleet展開が挙げられています。つまり、脆弱性対応は「一覧を見る」だけでなく、コンポーネント別の運用アクションに落ちていきます。
buildpack、stack、stemcellは基盤変更とアプリ再起動をセットで見る
確認項目
buildpack更新では、どのアプリがそのbuildpackを使っているか、更新後にどのアプリをrestageするか、どの順番で検証するかが重要です。bulk restageは強力な選択肢ですが、影響を受けるアプリの範囲、テスト担当、失敗時の戻し方を省略してはいけません。
stackやstemcellでは、OS層やコンテナベース層に関わるため、基盤側の変更として扱います。アプリチームに見える症状は「再起動」「再デプロイ」「挙動差分」かもしれませんが、根はfoundationやplatform componentの更新です。変更審査では、アプリ一覧だけでなく、対象foundation、現在バージョン、target version、EOGS、CVE resolved countを並べると説明しやすくなります。
secure container imageとSpring libraryはアプリ供給経路に戻す
注意点
secure container imageの修復候補は、イメージ更新、再ビルド、再デプロイ、レジストリ運用に戻して考えます。Tanzu Hub上で修復候補が見えても、実際にどのパイプラインがイメージを作り、どこに配布し、どの環境へ展開するかを確認しないと、修復は完了しません。
Spring libraryは、依存関係更新とサポート方針の確認に接続します。Broadcomは2026年6月の公式発表で、Spring/Javaエコシステムへのセキュリティ投資、CVE-only patches、clean-room built Java dependenciesなどを示しました。ただし、本記事の文脈では、これをTanzu HubのApps > Vulnerability Remediationで見えるSpring libraryの修復候補と混ぜすぎないことが大切です。アプリ側の更新作業、Tanzu Springの利用条件、SBOMやCIの確認を別々に見ます。
service、tile、foundation management artifactは変更審査の粒度を上げる
評価基準
service、tile、foundation management artifactの更新は、単一アプリの修正よりも影響範囲が広くなりがちです。CVEの深刻度だけでなく、依存サービス、maintenance window、rollback、EOGS、利用部門への通知を含めて計画します。
この領域では、同じ修復をfoundation group単位で横展開できる可能性があります。一方で、foundationごとのバージョン差や依存関係により、同じ順番では進められない場合もあります。Upgrade Plannerへ渡す前に、横展開できるものとfoundationごとに調整が必要なものを分けておくと、計画の精度が上がります。
VCFや基盤更新の順序設計に慣れていない場合は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-28-vcf-52x-to-91-upgrade-planner-check/" rel="noopener">VCF 5.2.xから9.1へ移行前に確認する</a>も合わせて読むと、依存関係と更新順序の見方を横展開しやすくなります。
Upgrade Plannerに渡す前に変更順序を作る
現在バージョン、target version、Foundation Core、対象foundationを確認する。
利用可能なremediation、CVE改善見込み、影響範囲を変更審査の材料にする。
互換性を保つupgrade paths、依存関係、EOGSを見て順序を決める。
どの順番で、どの範囲が止まり、誰が検証し、失敗時にどこへ戻すかを明確にする。
foundation情報やtarget versionの考え方を変えたら、古い計画を使い続けない。
Vulnerability Insightsは入口、Upgrade Plannerは計画の土台、変更チケットは運用チームが作るものです。
Vulnerability Insightsで修復候補を確認したら、次は変更順序です。Tanzuのパッチング記事では、Vulnerability InsightsからView Remediationsを開き、target foundationを選ぶと、実際にインストール済みのバージョンに基づいて、利用可能なremediation、CVE改善見込み、影響範囲を確認できると説明されています。そこからUpgrade Plannerへつなげる流れが、Tanzu Platform 10.4の実務上の見どころです。
installed versionsに基づく計画として読む
根拠
Upgrade Plannerに渡す前に、現在バージョン、target version、Foundation Coreなどの依存関係、EOGS、CVE resolved count、対象foundationを確認します。ここで大事なのは、理想的な最新バージョンの話ではなく、実際に入っているバージョンからどう上げるかを見ることです。
インストール済みバージョンに基づく計画であれば、変更審査で説明しやすくなります。「このfoundationでは、このコンポーネントがこのバージョンで、Latest patchに上げるとこのCVE群が減る。依存関係上、先にこの更新が必要」という形にできます。
compatibility pathsとphased sequenceを変更審査に使う
条件
Upgrade Plannerは、互換性を考慮したupgrade paths、EOGS、各upgradeで解決するCVE数、互換性を保つ段階的な順序を計画材料として示します。これは、CVE対応をCABや変更審査へ渡すときに重要です。
良い変更計画は、CVE数を減らすだけでは足りません。どの順番で、どの依存関係を守り、どの範囲が止まり、誰が検証し、失敗時にどこまで戻すのかが必要です。Vulnerability Insightsは入口、Upgrade Plannerは計画の土台、実際の変更チケットは運用チームの責任で作る、と分けると過信を避けられます。
planの再生成と目標切り替えを運用に入れる
注意点
foundation情報を更新した後、target versionの考え方を変えた後、またはLong Term Supportベースの計画に切り替えた後は、古い計画を使い続けないようにします。Tanzuのパッチング記事では、planの再生成やexportにも触れられています。変更審査へ出す前に、読み取り時点と計画生成時点を明記する運用にしておくと安全です。
特に、Latest patchで短期の安全性を上げる計画と、Latest majorで大きく整理する計画は、同じ会議に出しても判断基準が違います。日常パッチのCABではLatest patch、四半期ロードマップではLatest majorやLTS方針というように、会議体に合わせて資料を分けると話が噛み合います。
導入前チェックリスト：PoCで確認する15項目
対象foundation、foundation group、component type、Deployed/In Useで範囲を説明できる。
buildpack、secure container image、Spring libraryごとに作業担当と検証窓口を決める。
Latest patchで短期対応候補を作り、Latest majorで中期計画を別扱いにする。
target foundation、installed versions、EOGS、互換性を見て変更順序を作る。
業務ロジック、独自ソース、独自イメージを既存プロセスで別管理できるようにする。
PoCの成果物は画面キャプチャではなく、対象、修復見込み、担当、変更窓、対象外範囲を並べた表にします。
PoCでは、Tanzu Hubに表示される値そのものより、既存の運用にどう接続できるかを確認してください。以下の15項目を埋められれば、本番導入前の議論がかなり具体化します。
| 確認項目 | 見る場所 | 合格ライン |
|---|---|---|
| 対象foundationがTanzu Hubに登録されているか | Foundations | 対象範囲と責任者が説明できる |
| foundation groupで絞り込めるか | Foundations | 本番、検証、部門別に分けられる |
| component typeで絞れるか | Vulnerability Insights | buildpack、stemcell、serviceなどを分けて見られる |
| Deployed/In Useで稼働中に絞れるか | Vulnerability Insights | 使っていない部品に引っ張られない |
| Apps側で対象アプリを見られるか | Apps > Vulnerability Remediation | 修復候補のあるアプリを一覧化できる |
| buildpackタブの担当を決めたか | Apps | restageとテスト担当が決まっている |
| secure container imageタブの担当を決めたか | Apps | イメージ更新、再ビルド、再デプロイの経路が分かる |
| Spring libraryタブの担当を決めたか | Apps | 依存関係更新とサポート確認の窓口がある |
| Latest patchで短期対応候補を作れるか | Target Version | 変更窓に載せる候補が出せる |
| Latest majorで中期計画を作れるか | Target Version | breaking changesと検証工数を別扱いにできる |
| Patch will fixを説明できるか | Vulnerability Insights | 修復見込みをCVE台帳へ転記できる |
| Upgrades Fixを過信していないか | Apps | 修復率と業務影響を分けて説明できる |
| Upgrade Plannerへ渡せるか | View Remediations | target foundationとinstalled versionsで計画を作れる |
| EOGSと互換性を見ているか | Upgrade Planner | CVE数だけでなくサポート期限も見ている |
| 対象外範囲を別証跡で補っているか | 既存プロセス | 業務ロジック、独自ソース、独自イメージを別管理できる |
すぐPoCに進める条件
合格ライン
すぐPoCに進めるのは、Tanzu Hubに対象foundationが接続済みで、AppsとFoundationsの両方で脆弱性データを確認でき、既存のCVE管理プロセスと照合できる企業です。この状態なら、まずLatest patchで短期対応候補を作り、次にUpgrade Plannerで変更順序を見ます。
PoCの成果物は、画面キャプチャの束ではなく、対象コンポーネント、該当アプリ、現在バージョン、target version、修復されるCVE数、検証担当、変更窓、対象外範囲を並べた表にしてください。これなら本番導入時の変更審査にも流用できます。
本番導入前に止める条件
注意点
逆に、本番導入前に止めるべき条件もあります。custom business logicの評価、CI内のSCA、コンテナイメージスキャン、SBOM管理をTanzu Hubだけに置き換える前提になっている場合です。Vulnerability Insightsが見ない範囲を明示しないまま本番運用に入ると、見えていないリスクを見えているものとして扱ってしまいます。
また、Latest majorで大きくCVE数が減るからといって、日常パッチのように進めるのも危険です。メジャー更新には互換性、アプリ改修、テスト、利用部門調整が伴う可能性があります。修復率が大きいほど、変更計画も厚くする必要があります。
公開後に更新すべき情報
確認項目
Tanzu PlatformとTanzu HubのTechDocsは更新される可能性があります。公開後も、画面名、列名、Target Versionの説明、Upgrade Plannerの目標選択肢、Tanzu Blogの追加記事は確認対象です。特にTanzu HubのApps画面やVulnerability Insightsの対象コンポーネントは、リリースノートの更新に合わせて変わる可能性があります。
本サイトの月次更新は、<a href="https://avgo-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">2026年6月 重要トピックまとめ</a>にも集約しています。Broadcomの公式発表、VCF、Tanzu、AIインフラ関連の更新を追う入口として使ってください。
本文末の導入判断メモ
Critical/High CVE、Affected/In Triage、Patch will fix、Upgrades FixをCVE台帳へ結びつける。
foundation単位の修復とアプリチームを巻き込む修復を分け、Upgrade Plannerで順序を確認する。
buildpack、secure container image、Spring libraryの候補を、依存関係更新、再ビルド、再デプロイ、テストに落とす。
Tanzu Hub上の修復候補は、作業開始点であり、完了条件そのものではありません。
最後に、チーム別の持ち帰りを整理します。Tanzu Hubを導入するかどうか、または10.4へ更新するかどうかは、単一チームだけでは判断できません。セキュリティ、プラットフォーム、アプリの3チームが、同じ画面を別の観点で読む必要があります。
セキュリティチームに渡す一文
Tanzu Hubは、platform-managed componentsの修復可能性を整理する入口として使う。Critical/High CVE、Affected/In Triage、Patch will fix、Upgrades FixをCVE台帳へ結びつけつつ、業務ロジックや独自ソースコードは既存のSAST/SCA/SBOM運用で補う。
この一文が言えれば、Tanzu Hubを万能スキャナとして誤解するリスクを抑えられます。セキュリティチームは、Tanzu Hubから出る値を「修復候補の証跡」として扱い、別の証跡が必要な範囲を明確にしてください。
プラットフォームチームに渡す一文
foundation単位で実行できる修復と、アプリチームを巻き込む修復を分け、Upgrade Plannerで順序と互換性を確認してから変更審査へ渡す。bulk restageやstack/buildpack無効化は有効な選択肢だが、アプリ影響と検証順序を省略しない。
プラットフォームチームの主な役割は、CVE一覧を「実行可能な変更計画」に変えることです。installed versions、target version、EOGS、依存関係、検証順序をそろえれば、セキュリティ要求と運用現実の間をつなぎやすくなります。
アプリチームに渡す一文
Apps > Vulnerability Remediationで見えるbuildpack、secure container image、Spring libraryの修復候補を、依存関係更新、再ビルド、再デプロイ、テストの作業に落とす。Tanzu Hub上の修復候補は、アプリチームにとっては作業開始点であり、完了条件ではない。
アプリチームは、該当アプリ、利用コンポーネント、現在バージョン、target version、修復されるCVE数、必要な再テストを一覧化してください。KubernetesやGitOps側の展開も合わせて見る場合は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-26-vks-argocd-gitops-platform-check/" rel="noopener">VKSでArgo CD GitOpsを始める前に確認する</a>が関連します。
更新履歴・運用メモ
2026年6月13日時点のTanzu Platform 10.4、Tanzu Hub 10.4、Vulnerability Insights、Upgrade Plannerを前提にする。
Broadcom TechDocs、Tanzu Blog、契約条件、社内のCVE管理台帳と照らし合わせる。
AVGO株式の売買や短期の市場反応ではなく、Tanzu PlatformとTanzu Hubの導入判断に焦点を置く。
Broadcomの公式発表、VMware Cloud Foundation、Tanzu、AIネットワーキング、半導体製品の更新を追う。
変更審査では、記事だけを根拠にせず、公式情報と社内台帳で確認してください。
確認日は2026年6月13日です。Tanzu Platform 10.4、Tanzu Hub 10.4、Vulnerability Insights、Upgrade Plannerに関する画面名、列名、対象コンポーネント、サポート条件は更新される可能性があります。実運用では、この記事を変更審査の根拠そのものにせず、Broadcom TechDocs、Tanzu Blog、契約条件、社内のCVE管理台帳と照合してください。
Broadcomの公式発表では、AI-enabled threatsにより脆弱性発見と修復の速度が重要になっていることが示されています。ただし、本記事は投資助言ではありません。AVGO株式の売買、目標株価、短期の市場反応を推奨するものではなく、読者が触れるTanzu PlatformとTanzu Hubの導入判断に焦点を置いています。
Broadcom Watch Japanでは、Broadcomの公式発表、VMware Cloud Foundation、Tanzu、AIネットワーキング、半導体製品の更新を継続して追っています。更新通知を受け取りたい場合は、記事読了後の導線として<a href="https://avgo-watch.blog.mo-gmo.com/newsletter/" rel="noopener">ニュースレター</a>を確認してください。
次に読むなら
参照した主な情報源
- Broadcom, "Broadcom Expands Its Investment in Spring and Java Ecosystem Security to Prepare Customers for AI-Enabled Threats", 2026年6月8日。確認日: 2026年6月13日。https://news.broadcom.com/releases/broadcom-expands-investment-in-spring-and-java-ecosystem-security
- Tanzu Blog, "Broadcom’s Investment in Spring to Combat AI-Fueled Security Challenges in the Enterprise", 2026年6月9日。確認日: 2026年6月13日。https://blogs.vmware.com/tanzu/broadcoms-investment-in-spring-to-combat-ai-fueled-security-challenges-in-the-enterprise/
- Tanzu Blog, "Smarter Patching at Scale: Vulnerability Assessment and Remediation with VMware Tanzu Platform", 2026年5月22日。確認日: 2026年6月13日。https://blogs.vmware.com/tanzu/smarter-patching-at-scale-vulnerability-assessment-and-remediation-with-vmware-tanzu-platform/
- Broadcom TechDocs, "Tanzu Platform 10.4 release notes"。確認日: 2026年6月13日。https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-platform/10-4/about-tnz-platform/release_notes.html
- Broadcom TechDocs, "Monitor and remediate vulnerabilities"。確認日: 2026年6月13日。https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-hub/10-4/tnz-hub/vulnerabilities-overview.html
- Broadcom TechDocs, "View vulnerabilities in Tanzu Hub"。確認日: 2026年6月13日。https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-hub/10-4/tnz-hub/vulnerabilities-view.html
- Broadcom TechDocs, "Components scanned for vulnerabilities by Tanzu Hub"。確認日: 2026年6月13日。https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-hub/10-4/tnz-hub/vulnerabilities-components.html