Broadcom's HyperArmor gives ESX admins more time to test patches

Some VMware customers tried to build their own hypervisor protections and struggled to keep them going, according to Broadcom distinguished engineer Eric Chen ^[12]. He added that customers face a steady flow of patches and want less pressure to deploy each update immediately ^[11].

The pitch is speed. Broadcom marketing executive Prashanth Shenoy said, "You don't have enough time to triage a single alert, and you can't apply patches at machine speed" ^[9]. As Chen describes it, the product delays the patch work without removing it. We think the risk with any stopgap is that it becomes the schedule, because a mitigation already running makes the patch feel less urgent. Chen was direct on the point. "We always still want you to patch; that is the right thing to do, but this basically buys you time," he said ^[10].

Both statements come from Broadcom staff, and SiliconANGLE's report includes no customer deployment results or independent testing ^[15].

For Monday, sort clusters on two facts: whether they run ESX 8.x or later ^[7], and whether the team already maintains its own host controls ^[12]. Four cases follow.

- ESX 8.x or later, own controls: put Broadcom's price next to the hours spent keeping the homegrown version alive. - ESX 8.x or later, no controls: pilot first, since there is nothing to displace. - Older release, own controls: keep them, and treat the upgrade as the gate. - Older release, no controls: patch cadence is the only control. Move the upgrade up.

In any of the four, we'd put an expiry date on every virtual patch and name the person who signs off the official one. The tradeoff is that a dated exception shortens the window the product creates; an undated one leaves nobody responsible for the patch.