Eric Chen és distinguished engineer de Broadcom i un dels que han construït el producte. Va descriure així el seu propi virtual patching: «we always still want you to patch; that is the right thing to do, but this basically buys you time». Té raó en les dues meitats, i s'agraeix que ho digui ell. La pregunta que queda oberta és en què gastaràs aquest temps. Perquè si no vas apedaçar a temps no va ser perquè no sabessis que hi havia un pedaç.
Què és, en paraules del fabricant
La nota porta data d'avui, 13 d'octubre de 2026, i dateline de Palo Alto; el mateix dia, VMware ho explica a VMware Explore on Tour Frankfurt, que se celebra avui i demà. VMware HyperArmor protegeix el component ESX de VMware Cloud Foundation, suporta ESX 8.x i posteriors, es ven com a producte a part, com a add-on de VCF, i no té preu publicat. Són tres peces, amb els noms que els posa el fabricant:
- 1«Virtual patching for VCF's ESX Component Host Environment». Detecta i bloqueja l'intent d'explotació sense tocar el programari vulnerable: ni reinici de l'amfitrió ni actualització. El binari continua sent el mateix d'ahir.
- 2«Positive Host Security Guardrails». Llista blanca d'execució: «unauthorized executables and scripts are blocked by default». Per no trencar-te res el primer dia, inventaria els scripts que ja hi ha a l'amfitrió i els dona per bons; els nous els aproves tu.
- 3«Hypervisor-level multi-factor authentication». A l'SSH de l'ESX hi afegeix un segon factor: credencials i, al darrere, un codi temporal «tied to a separate identity». Amb la contrasenya de root robada no s'arriba a la línia d'ordres.
Paul Turner, chief product officer de la divisió de VMware Cloud Foundation, ho resumeix així: «VMware HyperArmor takes a different approach by allowing only what is 'known good' to run on the host». El reclam central de la nota és que tot això arriba «with no downtime, software upgrades, or in-guest agents». Són exactament les tres coses que converteixen una actualització d'hipervisor en un projecte.
Per què ara: el ritme el marca un altre
El context el va posar a Frankfurt Prashanth Shenoy, de Broadcom: VMware va passar fa poc a publicar actualitzacions mensuals, en part per atendre errors trobats per IA. I Shenoy reconeix que ja abans d'aquell canvi els clients «struggled to keep up with the pace of change», perquè provar l'impacte d'un pedaç porta temps. La seva manera de dir-ho és que a la gent li cal «room to breathe». Això és el que es posa avui a la venda.
La nota remata la idea amb Stephen Elliot, d'IDC: «attackers are using automation and AI to exploit infrastructure weaknesses faster than most organizations can patch». És el mateix càlcul que vam fer a La IA ja troba errors de dia zero sola: el coll d'ampolla són els dies que passen entre que existeix el pedaç i entra a la teva producció. El que és nou avui és que aquesta acceleració ja no es nota només al calendari de l'atacant. Es nota al calendari del fabricant, i aquest sí que l'has de seguir tu.
Ja tenies una manera de no reiniciar. Ve amb llista d'exclusions
Des de vSphere 8.0 Update 3 existeix Live Patch, i la seva documentació promet exactament el mateix que el titular del producte nou. Durant la remediació, diu Broadcom, «vSphere Lifecycle Manager does not place the hosts in the cluster into maintenance mode», els amfitrions no es reinicien i «there is no need to migrate the virtual machines running on the hosts in the cluster». De franc, dins del que ja pagues.
La lletra petita ocupa més. Live Patch exigeix que el clúster es gestioni amb una imatge única de vSphere Lifecycle Manager —no funciona amb baselines, i la conversió no té marxa enrere: un cop convertit, no es pot desfer—, exigeix DRS activat i obliga a apedaçar seqüencialment, amfitrió a amfitrió. Hi ha dues línies més: «Live Patch is incompatible with systems configured with TPM devices or systems using DPUs via vSphere Distributed Services Engine», amb l'afegitó que la compatibilitat amb TPM comença a vSphere 9.1.
El camí gratuït per no reiniciar deixa fora els amfitrions configurats amb TPM. És el mateix expedient del qual parlàvem a Hardening de VCF: el P0 tanca la porta i el P2 et deixa la clau — els controls no es contradiuen al paper, es contradiuen a l'amfitrió concret que tens muntat. Hi ha sortida —vSphere 9.1 aixeca la restricció—, però la sortida és una altra actualització, que és exactament la feina que estaves intentant ajornar.
Hi ha una tercera exclusió, aquesta del costat de les màquines virtuals: les que no suporten Fast Suspend and Resume —Fault Tolerance, DirectPath I/O en passthrough, vSphere pods, clúster de disc compartit— cal migrar-les o apagar-les i encendre-les igualment. I al mateix article de la base de coneixement: «remediation is blocked if you attempt a live patch on hosts that require maintenance mode». El pedaç en calent no t'avisa que aquell amfitrió queda fora del seu abast: bloqueja la remediació sencera.
De les tres peces, una ja la tens de franc. I està apagada
Aquest és l'ordre que ens sembla útil: començar pel que ja tens i acabar pel que de debò cal comprar.
- →El segon factor de l'SSH. A ESXi 8 l'SSH ve desactivat de fàbrica. Si està apagat i ningú no l'encén, no hi ha login a protegir. El matís importa: el mode lockdown no tanca aquesta porta, la documentació de Broadcom ho diu en una línia —«if the ESXi Shell or SSH is activated and the host is placed in lockdown mode, accounts on the Exception Users list who have administrator privileges can use these services»—. Així que la pregunta útil és qui és a la llista d'excepcions i per què. Si allà hi ha un compte que vas obrir per a un cas de suport de fa any i mig, l'MFA del fabricant et tapa un forat real.
- →La llista blanca d'execució. ESXi ja en porta una, més estricta i de franc:
execInstalledOnly, que fa que «the VMkernel executes only those binaries that have been packaged and signed as part of a VIB». Les pegues són a la mateixa pàgina: exigeix l'arrencada segura UEFI per sota, ve en false de sèrie i encendre-la demana reiniciar l'amfitrió. És a dir, la versió gratuïta del «només corre el conegut» costa just allò que el producte de pagament promet estalviar-te. - →El virtual patching. Aquesta no la pots construir, i és honest dir-ho. Cal saber quina seqüència de crides explota quin error en quina versió de l'hipervisor, i això ho sap qui escriu l'hipervisor. I l'argument del fabricant és aquest: Broadcom sap quins processos haurien de córrer al seu hipervisor, i per això pot imposar la restricció dins de l'amfitrió i no només inspeccionant la xarxa. És l'argument més fort del producte, i no té equivalent casolà.
Queda un detall de la peça 2 que convé mirar de cara, perquè és la diferència entre una llista blanca i una fotografia. La línia base d'HyperArmor es construeix inventariant els scripts que ja corren i permetent-los. És la decisió correcta perquè el producte es pugui encendre un dimarts sense trencar mitja plataforma. Però el «known good» de Turner dona per fet que l'amfitrió estava bé el dia que es va fer la foto. Si ja hi tenies res des d'abans, la línia base ho beneeix i passa a estar autoritzat per escrit.
El que no et direm
- ✗Que això sigui fum. No ho és. És una mitigació real, descrita amb precisió per qui l'ha feta, i cobreix dos camins d'entrada que existeixen: la credencial de root robada i l'error sense apedaçar. Que la frase de capçalera del producte la posi el seu propi enginyer en «et compra temps» és més honest que la mitjana del sector.
- ✗Que te'n vagis de VMware per això. I ho diem amb el conflicte d'interès per davant: fem migracions de VMware a Proxmox, i no som resellers de Proxmox ni de VMware —no venem llicències de cap de les dues—. Un producte de seguretat de l'hipervisor no és un argument per canviar d'hipervisor.
- ✗Que sabem si surt a compte. No s'ha publicat preu, es ven com a producte a part i no l'hem passat per laboratori. Tot el d'amunt és documentació pública i declaracions d'avui. El dia que el provem amb ferro al davant, ho explicarem amb números i amb les pegues que trobem.
Les dues preguntes que decideixen si et serveix
Cap de les dues no és tècnica, i per això no les contesta cap fullet.
Primera: quant va trigar l'últim amfitrió a tornar? Amb data. Des que va entrar en mode manteniment fins que el clúster va recuperar la redundància completa. Si aquest número no existeix enlloc, no tens una finestra de manteniment; tens una expectativa. I les expectatives no es poden multiplicar pel nombre d'amfitrions.
Segona: qui signa la finestra? Seguretat vol el pedaç a dins; qui respon de l'ERP vol que ningú no toqui res fins després del tancament de mes. Mentre aquesta discussió no tingui un responsable amb nom, qualsevol capa que permeti no decidir es farà servir per no decidir. Aquesta és la trampa de comprar temps: funciona, i precisament perquè funciona, el mes que ve estàs igual.
Si les dues preguntes tenen resposta a casa teva, HyperArmor et treu pressió del damunt durant les setmanes que van de l'avís a la finestra, i això val diners. Si no en tenen, el que compres no és seguretat: és l'ajornament de la mateixa conversa, renovable cada mes.
El que queda apuntat
El pedaç virtual caduca el dia que entra el de debò. Fins llavors, el binari del teu hipervisor continua sent el d'ahir, i això ha d'estar escrit al lloc on apuntes què està mitigat i què està corregit, que no són la mateixa columna.
Broadcom ha posat a la venda la respiració. El reinici continua sent teu.
Fonts (consultades el 13-10-2026): els noms de les tres capacitats, la cita de Paul Turner, la de Stephen Elliot (IDC), el suport d'ESX 8.x i el «with no downtime, software upgrades, or in-guest agents» surten de la nota de premsa Broadcom Introduces VMware HyperArmor (Palo Alto, 13-10-2026). Les cites d'Eric Chen, el bloqueig per defecte d'executables i scripts, l'inventari de la línia base, el detall del segon factor i que el preu no s'ha fet públic, de la cobertura de SiliconANGLE. Les declaracions de Prashanth Shenoy sobre la cadència mensual, els errors trobats per IA i el «room to breathe», i que es ven com a producte a part, de The Register des de VMware Explore Frankfurt. El que Live Patch evita, els seus requisits i les seves exclusions —TPM, DPU, FSR, imatge única de vLCM, DRS, remediació seqüencial—, de la documentació de vSphere Lifecycle Manager i de l'article 419942 de la base de coneixement de Broadcom, que és on figura que la compatibilitat amb TPM comença a 9.1. El comportament del mode lockdown amb l'SSH i la llista d'excepcions, de Lockdown Mode Behavior. El cas d'execInstalledOnly —què aplica, que exigeix arrencada segura UEFI, que ve desactivat i que demana reinici—, de la seva pàgina a techdocs. Totes les frases entre cometes són literals d'aquestes fonts. No hem provat HyperArmor: aquí no hi ha cap mesura pròpia.
Quant va trigar a tornar l'últim amfitrió que vas reiniciar?
Si la resposta és «depèn», la finestra encara no existeix. A everyWAN operem hipervisors en producció i donem el suport 24x7 de la matinada en què un amfitrió no torna; documentem els controls i el risc assumit a compliment i continuïtat, que és on aquesta distinció ha de quedar escrita; i quan la finestra no se signa perquè seguretat i aplicacions no es posen d'acord, això ho resol un equip amb objectius compartits, que és del que va el programa RID.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN