3行まとめ：6月のCarbon Black更新はセンサー、OS対応、認証、サポート期限を分けて読む
4.2.0.3361はESAアーキテクチャを土台にした更新として、対応OS、既存センサー配置、共存条件を確認します。
2.16.3はOSディストリビューション対応を中心に読み、workload用途ではLauncher 1.3.1も手順に含めます。
8.13.0は2FAとpasskeysを含む認証強化を、管理コンソールの変更管理として扱います。
8.8.xのExtended Support入りを、端末更新とは別の移行期限と棚卸しの起点として読みます。
名前が似ていても、Windows端末、Linuxサーバー、管理基盤、Agentライフサイクルでは確認する担当範囲が違います。
Carbon Black CloudのWindows Sensor 4.2.0.3361は、2026年6月3日付のリリースノートで、Endpoint Security Agent Architectureを土台にした更新として説明されています。通常のセンサー差し替えだけでなく、対応OS、既存センサー配置、Symantec Cloud SWGとの共存条件を確認する更新です。
Linux Sensor 2.16.3は、2026年6月5日付の保守リリースです。SLES 16.0、OpenSuSE 16.0、Debian 13系、Ubuntu 26.04などのOSディストリビューション更新が中心で、workload用途ではLinux Carbon Black Launcher 1.3.1を手順に含める必要があります。
Carbon Black App Control Server 8.13.0は、2FAとpasskeysを含む認証強化が大きな確認点です。あわせてApp Control Linux Agent 8.8.xは2026年6月8日にExtended Support入りしており、端末更新とは別にサポート期限の棚卸しを進める必要があります。
まず製品別に更新対象を分ける
今回の4つの公式情報は、名前が似ていても同じ変更ではありません。Carbon Black CloudのWindows SensorとLinux Sensorは、Carbon Black Cloud Sensor Documentation配下の更新です。Carbon Black App Control Server 8.13.0とLinux Agentライフサイクルは、Carbon Black App Controlの管理基盤とエージェント運用に関わる更新です。
導入企業が最初にやるべきことは、全社の「Carbon Black更新」としてまとめて扱うことではなく、管理コンソール、Windows端末、Linuxサーバー、App Control Agentの担当範囲を分けることです。同じセキュリティ運用チームが見る場合でも、変更の種類は違います。Windows Sensor更新は端末展開、Linux Sensor更新はOS対応、App Control Server更新は認証ポリシー、Linux Agentライフサイクルは移行期限の管理です。
根拠
Broadcom TechDocsでは、Windows Sensor 4.2.0.3361、Linux Sensor 2.16.3、App Control Server 8.13.0、App Control Linux AgentのSupport Life Cycle Statusが別ページで公開されています。記事ではこの4ページを一次情報として扱い、価格、契約条件、提供地域のように公式ページで確認していない内容は断定しません。
注意点
Carbon Black Cloud SensorとCarbon Black App Controlは、運用上つながる場面があっても別の確認対象です。Windows Sensor 4.2.0を適用できることと、App Control Server 8.13.0の認証方式を変えられることは同じ判断ではありません。変更管理のチケットも、可能なら別に切ったほうが後で追跡しやすくなります。
Windows Sensor 4.2.0はESAアーキテクチャ移行として確認する
- 1対象OSを棚卸し
Windows 10 19H2以降、Windows Server 2019以降の範囲に収まるかを確認します。
- 2共存条件を見る
Carbon Black Cloud、Symantec Endpoint Security、Symantec Cloud SWGの組み合わせがある端末を分けます。
- 3旧配置への依存を探す
旧センサーのファイル、レジストリ、サービス名を参照する運用スクリプトがないか確認します。
- 4代表部門で試す
端末再起動、ネットワーク、ログ収集、ポリシー反映を少数の端末で確認します。
- 5切り分け手順を直す
ヘルプデスクやSOCの確認手順を、ESAアーキテクチャ前提に更新します。
センサーのバージョン番号だけで判断せず、Endpoint Protection、Web Security、EDR系の運用が同じ端末でどう変わるかを見ます。
Carbon Black Cloud Windows Sensor 4.2.0.3361は、2026年6月3日付、Build 4.2.0.3361として公開されています。Broadcomのリリースノートでは、このセンサーがEndpoint Security Agent Architecture、つまりESAに基づくと説明されています。
ESAは、複数の技術を単一のモジュール型で拡張可能なエンドポイントエージェントとして展開、管理しやすくする設計です。公式ページでは、Carbon Black Cloud、Symantec Endpoint Security、Symantec Cloud Secure Web Gatewayをサポートし、Carbon Black CloudとSymantec Cloud SWGが単一のESAエージェントを使って同じエンドポイント上で共存できると説明されています。
ESAは複数技術を単一の拡張可能なエージェントで扱う設計
セキュリティ運用の観点では、ESAの意味は「センサーのバージョン番号が上がった」だけではありません。Endpoint Protection、Web Security、EDR系の運用が同じ端末に乗る場合、インストール順、共存条件、トラブル時の切り分け、ログの見方が変わる可能性があります。
公式リリースノートでは、ESAのファイルとレジストリが以前のCarbon Black Cloud Sensorとは異なる場所に存在するとされています。これは、運用担当者にとって小さくありません。既存の資産管理、EDR監視、ソフトウェア配布、アンインストール手順、端末調査スクリプトが旧配置を前提にしている場合、センサー更新後に見落としが起きる可能性があります。
確認項目
- Carbon Black Cloud Windows Sensorの既存バージョンと展開方式を確認する。
- Symantec Cloud SWGやSymantec Endpoint Securityとの共存がある端末を分ける。
- 旧センサーのファイル、レジストリ、サービス名を参照している運用スクリプトがないか確認する。
- センサー更新後のヘルプデスク切り分け手順を、ESA前提に直す。
- 代表部門で段階展開し、端末再起動、ネットワーク、ログ収集、ポリシー反映を確認する。
古いWindowsが残る環境では先にOS棚卸しを行う
Windows Sensor 4.2.0のリリースノートでは、Carbon Black Cloud architectureがWindows 10 19H2以降とWindows Server 2019以降のみをサポートすると説明されています。古いOSを使うエンドポイントは、Windows Sensor 4.2をインストールする前にOSをアップグレードする必要があります。
ここで注意したいのは、センサー更新の話がすぐにOS更改計画へつながる点です。セキュリティチームだけで進めると、古いWindows Server、例外的に残した業務端末、検証端末、閉域網の端末が後から見つかることがあります。Windows Sensor 4.2.0を全社標準にするなら、資産管理チームと一緒に対象OSを先に棚卸しするのが現実的です。
下振れ要因
古いOSが少数だけ残っている環境ほど、例外運用が曖昧になりやすいです。対象外OSに新センサーを無理に入れるのではなく、OS更新、端末置き換え、既存センサー維持の期限、ネットワーク分離、監査上の扱いを分けて決める必要があります。
また、Windows 10についてはMicrosoftの一般的なサポート終了時期との関係もあります。Carbon Black側の対応条件だけでなく、自社のWindowsライフサイクル管理と合わせて確認してください。
Linux Sensor 2.16.3は新OS対応とworkload用途のLauncherを分ける
対象OSを使う予定がない環境では、急いで全サーバーへ入れるより標準更新サイクルに組み込む判断もあります。
Carbon Black Cloud Linux Sensor 2.16.3は、2026年6月5日付、Build 2.16.3.7863591として公開されています。リリースノートでは、OSディストリビューション更新を含む保守リリースと説明されています。
対象として挙げられているのは、SLES 16.0、OpenSuSE 16.0、Debian 13.0、Debian 13.1、Debian 13.2、Debian 13.3、Debian 13.4、Ubuntu 26.04、Ubuntu 24.04.4、Debian 12.13です。Linuxサーバーやクラウドワークロードを運用している組織では、OS更新計画とCarbon Black Sensor更新計画を別々に進めると、検証が後追いになりやすくなります。
OS更新予定があるサーバーから先に対象を洗う
Linux Sensor 2.16.3は、派手な新機能よりも対応OSの更新を読むべきリリースです。たとえばDebian 13系やUbuntu 26.04へ移行する予定があるなら、OSアップグレード前にSensor対応を確認する価値があります。逆に、対象OSを使う予定がない環境では、急いで全サーバーへ入れるより、保守リリースとして標準更新サイクルに組み込むほうが自然です。
サーバー運用では、OSの点検単位とセキュリティセンサーの点検単位がずれることがあります。アプリケーションチームはOSの互換性を見ており、セキュリティチームはセンサーの健全性を見ています。Linux Sensor 2.16.3のような更新は、その間に落ちやすいので、変更管理では「OS更新予定のあるサーバー」を先に抽出してください。
確認項目
- 対象ディストリビューションを使う、または移行予定のLinuxサーバーを抽出する。
- OSアップグレード、カーネル更新、センサー更新の順序を決める。
- 検証環境でセンサー起動、ポリシー反映、ログ送信、パフォーマンス影響を確認する。
- ファイルスキャン、バックグラウンドスキャン、remote mountの扱いを運用ログで確認する。
- センサー更新後のロールバック手順とメンテナンス時間を決める。
Workload用途ではLauncher 1.3.1を手順に含める
Broadcomのリリースノートでは、対象OSディストリビューション更新でworkload用途に使う場合、Linux Carbon Black Launcher version 1.3.1を使うよう記載されています。ここは読み飛ばしやすい点です。
ワークロード保護では、センサー単体のバージョンだけではなく、配布、起動、環境連携に関わる部品も一緒に確認する必要があります。コンテナ基盤、クラウドVM、オンプレLinuxサーバーで展開方法が違う場合、Launcherの扱いを標準手順に入れておかないと、事前検証では成功しても本番展開時に差が出ることがあります。
注意点
Linux Sensor 2.16.3のリリースノートには、CRE-22193として、remote mountを表すトップレベルディレクトリがバックグラウンドスキャンで無視されていた問題の修正も記載されています。自社でremote mountを多用している場合は、単に「修正済み」と見るだけでなく、センサー更新前後のスキャン対象、ログ量、監視アラートを見比べるとよいでしょう。
ただし、この記事では未確認の脆弱性や攻撃事例を付け足しません。公式リリースノートで確認できるのは、OSディストリビューション更新、Launcher 1.3.1の案内、Resolved Issueの範囲です。
App Control Server 8.13.0は認証強化を変更管理に入れる
認証を強くするほど、夜間対応、委託先運用、退職や異動時の登録解除、復旧手順も同時に決める必要があります。
Carbon Black App Control Server 8.13.0は、2026年6月3日付、Build 8.13.0.129として公開されています。リリースノートでは、前バージョンからアップグレードするユーザーと新規ユーザー向けの主要リリースであり、新機能、機能強化、 defect fixes を含むと説明されています。
このリリースで最初に見るべきなのは、Enhanced Authenticationです。App Control Consoleが2つの追加サインイン方式をサポートし、個別に有効化することも、両方を使うこともできるとされています。具体的には、2FAとpasskeysです。
2FAは管理者が許可または必須化できる
2FAでは、管理者がユーザーに対して、時間ベースのワンタイムパスワードを使った二要素認証を許可または必須化できます。ここで大事なのは、機能が増えたことよりも、管理コンソールへのアクセス統制をどう変えるかです。
App Controlは、許可されたアプリケーションの管理や制御に関わる製品です。管理コンソールの認証を強めることは、単なるログイン画面の変更ではありません。管理者、監査担当、SOC、運用委託先がどのアカウントで入り、どの場面で二要素認証を必須にするかを決める必要があります。
評価基準
- 管理者アカウントと閲覧専用アカウントを分けているか。
- 緊急時に利用するbreak-glassアカウントの扱いを決めているか。
- 2FA必須化で夜間対応や委託先運用に支障が出ないか。
- 監査証跡として、認証方式の変更日、対象ユーザー、例外理由を残せるか。
- App Control Serverのアップグレードと認証ポリシー変更を同日に行うべきか、段階を分けるべきか。
passkeysは端末の内蔵認証と組み合わせて読む
App Control Server 8.13.0では、passkeysを使ったサインインも説明されています。公式リリースノートでは、指紋認証、顔認証、画面ロックPINなど、デバイスの内蔵認証方式を使えるとされています。
passkeysは、パスワード負担を減らしながら認証を強める選択肢になり得ます。一方で、管理者端末の所有、退職や異動時の登録解除、共有端末の扱い、復旧手順、監査ログの見方を先に決めないと、便利な機能が例外運用を増やすことがあります。
未確認に残すこと
この記事では、App Control Server 8.13.0の認証機能がどのライセンス、契約、地域、既存構成で使えるかまでは断定しません。導入前には、自社のBroadcom契約、サポート窓口、アップグレード手順、管理者ガイドを確認してください。
Linux Agent 8.8.xのExtended Support入りを移行期限として読む
- 2024年5月8日
Linux Agent 8.8.xはStandard Supportへ入り、運用対象として使われてきた期間を確認します。
- 2026年6月8日
8.8.xはExtended Supportへ入り、資産台帳、対象サーバー、業務影響の棚卸しを始める起点になります。
- 2027年11月11日
8.8.xのEnd of Support予定日から逆算して、検証、本番移行、変更不可期間を置きます。
- 8.7.x以前
8.7.x、8.6.x、8.5.x、7.4.xが残る環境は、サポート切れ確認の優先度を上げます。
- Server更新との関係
App Control Server 8.13.0への更新計画とAgent更新計画を、同時に進めるか分けるか決めます。
AgentはOSや業務アプリケーションと近い場所で動くため、期限を見ながらも業務影響と検証時間を確保して進めます。
Carbon Black App ControlのLinux Agent Support Life Cycle Statusでは、Linux Agent 8.8.xが2024年5月8日にStandard Supportへ入り、2026年6月8日にExtended Supportへ入り、2027年11月11日にEnd of Supportへ到達する予定として掲載されています。ページ自体のLast Updatedは2026年6月3日です。
この情報は、今すぐ全環境が使えなくなるという意味ではありません。むしろ、現在8.8.xを使っている環境が、次の標準バージョンや移行計画をいつまでに決めるべきかを示す予定表として読むべきです。
8.8.xは2026年6月8日にExtended Supportへ入る
Extended Support入りは、運用上の黄色信号です。標準サポートの期間が終わり、End of Supportまでの猶予期間に入ったと考えると、資産台帳、対象サーバー、業務影響、次バージョンへの移行検証を始めるタイミングになります。
App Control Agentは、OSや業務アプリケーションと近い場所で動きます。バージョン更新を急ぎすぎると、業務アプリの許可ルール、ポリシー、運用手順に影響が出ることがあります。一方で、期限を見ずに放置すると、End of Support直前に一括移行することになり、検証時間が足りなくなります。
確認項目
- App Control Linux Agentのバージョン別台数を出す。
- 8.8.x、8.7.x、8.6.x、8.5.x、7.4.xがどこに残っているか確認する。
- 8.8.xのEnd of Support予定日である2027年11月11日から逆算して移行計画を置く。
- 重要サーバー、閉域環境、変更不可期間があるシステムを先に分ける。
- App Control Server 8.13.0への更新計画と、Agent更新計画を同時に進めるか分けるか決める。
8.7.x以前が残る環境は優先度を上げる
同じページでは、Linux Agent 8.7.xが2026年3月14日にEnd of Support、8.6.xが2024年8月4日にEnd of Support、8.5.xが2024年3月25日にEnd of Support、7.4.xが2022年11月30日にEnd of Supportと示されています。
この一覧は、サポート切れの有無を確認するために使えます。特に、長く稼働しているLinuxサーバー、アプリケーションの更改が遅れている環境、メンテナンス停止が取りにくい業務サーバーでは、App Control Agentのバージョンだけが古いまま残ることがあります。
下振れ要因
サポート終了済みバージョンが残っている場合、単にAgentを上げれば済むとは限りません。OSバージョン、App Control Serverとの互換性、ポリシー、既存ルール、業務アプリの変更不可条件を合わせて確認する必要があります。
また、ライフサイクルページは更新される可能性があります。導入判断や監査資料に使う場合は、記事の日付ではなく、Broadcom TechDocsの最新表示を必ず確認してください。
適用順をどう決めるか
同じ日に一気に適用するより、影響範囲ごとに順序を分けたほうが実務上のリスクを説明しやすくなります。
今回の4つの更新は、同じ日に一気に適用するより、影響範囲ごとに順序を分けるほうが実務的です。優先度は、セキュリティ上の重要度だけでなく、対象台数、OS更改予定、認証変更の影響、サポート期限で決めます。
すぐ検証に入れやすい条件
Windows Sensor 4.2.0は、対象端末がWindows 10 19H2以降またはWindows Server 2019以降に収まり、既存の運用スクリプトが旧配置に強く依存していないなら、代表端末で検証を始めやすい更新です。Symantec Cloud SWGとの共存がある端末は、先に少数で動作を確認してください。
Linux Sensor 2.16.3は、対象OSへ更新予定のサーバーがある場合に優先度が上がります。Debian 13系やUbuntu 26.04の採用計画があるなら、OS更新検証の中にSensor検証とLauncher確認を入れるのが自然です。
App Control Server 8.13.0は、認証方式の変更を伴うため、技術検証だけでは不十分です。2FAやpasskeysの有効化は、管理者グループ、運用委託先、緊急対応手順、監査ログの扱いまで決めてから段階的に進めるほうが安全です。
評価基準
- 対象台数が少なく、ロールバックしやすい範囲から始める。
- OS更新予定とセンサー更新を同じ検証カレンダーに入れる。
- 管理コンソールの認証変更は、技術検証と運用ルール変更を分ける。
- サポート期限が近いAgentは、後回しにせず棚卸しだけ先に終える。
先に棚卸ししたほうがよい条件
古いWindows、古いLinux Agent、閉域サーバー、変更できない業務端末、共用管理者アカウントが残る環境では、先に棚卸しが必要です。Carbon Blackの更新はセキュリティ製品の話なので、急ぎたくなる場面があります。しかし、対象OSや認証運用が曖昧なまま適用すると、センサー未導入端末、ログ欠落、ログイン不能、監査証跡不足が後から出ます。
また、Carbon Black CloudとApp Controlを同じチームが扱っている場合でも、変更管理では分けてください。Windows SensorやLinux Sensorは端末/サーバーへの影響、App Control Server 8.13.0は管理基盤への影響、Linux Agentライフサイクルは移行計画への影響です。
変更管理に残すメモ
- 公式確認日: 2026年6月16日JST。
- 対象ページ: Windows Sensor 4.2.0.3361、Linux Sensor 2.16.3、App Control Server 8.13.0、Linux Agent Support Life Cycle Status。
- 未確認範囲: 価格、契約条件、提供地域、個別契約上のサポート条件。
- 再確認条件: TechDocs更新、サポート窓口からの案内、自社のOS更新計画変更、管理者認証ポリシー変更。
更新履歴・運用メモ
2026年6月16日JST時点で、Broadcom TechDocsの公開ページを確認しています。
Windows Sensor 4.2.0.3361、Linux Sensor 2.16.3、App Control Server 8.13.0、Linux Agent Support Life Cycle Statusを確認対象にします。
公式仕様、サポート条件、契約条件は更新される可能性があるため、実運用前にTechDocs、契約資料、サポート窓口で確認します。
導入判断のための情報整理であり、株式の売買判断、目標株価、短期値動きは扱いません。
運用メモは本文の補足ではなく、後から変更判断を見直すための確認日と前提条件として残します。
- 2026年6月16日JST時点で、Broadcom TechDocsの公開ページを確認しました。
- Broadcom Watch JapanはBroadcomおよび関係会社とは非提携の独立ブログです。商標や製品名は各社に帰属します。
- 本記事は導入判断のための情報整理であり、投資助言ではありません。株式の売買判断、目標株価、短期値動きは扱いません。
- Carbon Blackの公式仕様、サポート条件、契約条件は更新される可能性があります。実運用前にはBroadcom TechDocs、契約資料、サポート窓口で最新情報を確認してください。
- Broadcomの公式発表、製品更新、リリースノート確認を継続して追いたい場合は、読了後に<a href="https://avgo-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>も利用できます。本文理解を優先するため、更新通知として控えめに置いています。
次に読むなら
参照した主な情報源
確認日: 2026年6月16日 JST
- Broadcom TechDocs, Carbon Black Cloud Windows Sensor 4.2.0.3361 Release Notes
https://techdocs.broadcom.com/us/en/carbon-black/cloud/carbon-black-cloud-sensors/index/cbc-release-notes-tile/carbon-black-cloud-windows-sensor-release-notes/carbon-black-cloud-windows-sensor-4-2-0-release-notes_1.html
- Broadcom TechDocs, Carbon Black Cloud Linux Sensor 2.16.3 Release Notes
https://techdocs.broadcom.com/us/en/carbon-black/cloud/carbon-black-cloud-sensors/index/cbc-release-notes-tile/carbon-black-cloud-linux-sensor-release-notes/linux-sensor-2-16-3-release-notes.html
- Broadcom TechDocs, Carbon Black App Control Server 8.13.0 Release Notes
https://techdocs.broadcom.com/us/en/carbon-black/app-control/carbon-black-app-control/8-13-0/carbon-black-app-control-server-8-13-0-release-notes.html
- Broadcom TechDocs, Carbon Black App Control Linux Agent Support Life Cycle Status
https://techdocs.broadcom.com/us/en/carbon-black/app-control/app-control-agents/index/cbappc-linux-agent-oer-tile/GUID-054C2FCD-DA66-4D83-AABD-0F90EC543DAA-en.html