Parches de aplicaciones de terceros en Windows con winget

La guía principal sobre parches termina con una advertencia: buena parte de lo que los atacantes explotan en los equipos Windows no es Windows. Los navegadores, los lectores de PDF, los entornos de ejecución de Java y .NET, las herramientas de compresión, los clientes VPN y el software de acceso remoto tienen sus propios mecanismos de actualización, su propio ritmo de publicación y, a menudo, ninguna administración centralizada. Las directivas de cliente de Windows Update no los tocan.

Esta guía es un punto de partida práctico para parques pequeños y medianos: averiguar qué está instalado, decidir qué importa más y parchearlo con las herramientas que ya tienes, principalmente el Administrador de paquetes de Windows (winget) y las directivas de actualización automática de los fabricantes.

Paso 1: inventaría lo que está instalado

No puedes parchear lo que no conoces. Si tienes Microsoft Defender for Endpoint, su inventario de software (en Defender Vulnerability Management) es la mejor fuente, porque relaciona las versiones instaladas con CVE. El informe Discovered apps de Intune y el inventario de hardware de Configuration Manager son buenas alternativas.

Sin ellos, lee las claves de desinstalación, que es lo que hace Programas y características. Evita Get-CimInstance Win32_Product: consultar esa clase desencadena una comprobación de coherencia de todos los paquetes MSI y puede iniciar reparaciones.

$paths = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
         'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
Get-ItemProperty $paths -ErrorAction SilentlyContinue |
  Where-Object DisplayName |
  Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
  Sort-Object DisplayName |
  Export-Csv "C:\Temp\apps-$env:COMPUTERNAME.csv" -NoTypeInformation

Las instalaciones por usuario (muchos navegadores, clientes de colaboración y herramientas de desarrollo) se registran en cambio en HKCU y se instalan en %LOCALAPPDATA%. Escapan a los inventarios de todo el equipo y suelen ser las versiones más antiguas del dispositivo. Compruébalas también, o bloquea los instaladores por usuario con App Control.

winget también puede mostrar lo que reconoce y lo que tiene actualización:

winget upgrade --include-unknown

Paso 2: prioriza según la exposición

No todas las aplicaciones merecen la misma rapidez. Funciona un modelo sencillo de tres niveles:

Sube cualquier elemento al primer puesto cuando aparezca en el catálogo CISA Known Exploited Vulnerabilities o cuando el aviso del fabricante diga que se está explotando. Las aplicaciones de nivel 1 analizan contenido no fiable todo el día; es ahí donde se produce la explotación.

Paso 3: deja que los fabricantes actualicen donde lo hacen bien

El parche más barato es el que aplica la propia aplicación. Para el nivel 1, activa el actualizador del fabricante e impón una ventana de reinicio, en lugar de reempaquetar cada versión:

• Microsoft Edge se actualiza a sí mismo mediante EdgeUpdate. Deja sus directivas de actualización en el valor predeterminado (actualizaciones permitidas) y configura Notify a user that a browser restart is recommended or required (RelaunchNotification) con un período de reinicio. Los detalles están en la guía de endurecimiento de Edge.
• Google Chrome tiene directivas equivalentes RelaunchNotification y RelaunchNotificationPeriod, y las directivas de Google Update controlan si se permiten las actualizaciones. Usa las plantillas ADMX del fabricante.
• Mozilla Firefox se administra mediante sus directivas empresariales (policies.json o ADMX); asegúrate de que DisableAppUpdate no está configurado.
• Los entornos de ejecución .NET reciben mantenimiento a través de Microsoft Update si los dispositivos pueden obtener actualizaciones de otros productos de Microsoft. En los anillos de actualización de Intune, es Microsoft product updates; en directiva de grupo, la opción "Install updates for other Microsoft products" de Configure Automatic Updates.

Comprueba qué hace el actualizador del fabricante cuando el usuario no tiene derechos de administrador. Algunos actualizadores instalan un servicio para todo el equipo que funciona para todo el mundo; otros fallan en silencio para los usuarios estándar, que es justo lo que quieres que sean todos después de retirar los derechos de administrador local.

Paso 4: cubre los huecos con winget

Para las aplicaciones sin un actualizador fiable, winget puede detectar e instalar actualizaciones desde su repositorio. El uso interactivo es sencillo:

winget upgrade                                  # enumera las actualizaciones disponibles
winget upgrade --id 7zip.7zip --silent --accept-package-agreements --accept-source-agreements
winget pin add --id Oracle.JavaRuntimeEnvironment   # excluye una aplicación que debe quedarse en una versión

Para usarlo en todo el parque, ejecútalo como SYSTEM desde una tarea programada, una corrección de Intune o tu RMM. winget forma parte del paquete App Installer y no está en el PATH de la cuenta SYSTEM, así que primero resuelve el ejecutable:

$winget = Resolve-Path "$env:ProgramFiles\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe\winget.exe" |
  Sort-Object Path | Select-Object -Last 1 -ExpandProperty Path

$approved = 'Google.Chrome', 'Mozilla.Firefox', '7zip.7zip', 'Adobe.Acrobat.Reader.64-bit'
foreach ($id in $approved) {
  & $winget upgrade --id $id --exact --silent --scope machine `
    --accept-package-agreements --accept-source-agreements --disable-interactivity
}

Usa una lista explícita de ID aprobados en lugar de winget upgrade --all. --all actualiza lo que winget reconozca, incluidas aplicaciones cuya nueva versión principal no has probado. El módulo de PowerShell Microsoft.WinGet.Client (Get-WinGetPackage, Update-WinGetPackage) ofrece una salida estructurada si prefieres objetos a analizar texto.

Los parques más grandes suelen pasar a una herramienta dedicada: Intune Enterprise App Management (una funcionalidad de Intune Suite, incluida en Microsoft 365 E5 desde julio de 2026), los catálogos de actualizaciones de software de terceros de Configuration Manager o un producto comercial de parches. Los pasos de priorización y verificación no cambian.

Paso 5: bloquea App Installer y winget

winget es también un canal de instalación, así que contrólalo con las directivas de App Installer en Computer Configuration > Policies > Administrative Templates > Windows Components > Desktop App Installer (registro: HKLM\SOFTWARE\Policies\Microsoft\Windows\AppInstaller):

Estos nombres coinciden con el DesktopAppInstaller.admx actual, e Intune expone las mismas opciones en el área DesktopAppInstaller del Policy CSP. A las plantillas antiguas les faltan algunas, así que usa la más reciente. En los dispositivos en los que los usuarios estándar no deberían instalar software en absoluto, el control real es App Control o AppLocker; la directiva de winget solo estrecha una vía.

Paso 6: elimina lo que no puedes parchear

Cada aplicación que eliminas es un flujo de actualizaciones menos. Cuando tengas el inventario, ordénalo por responsable y último uso, y cuestiona todo lo que no tenga ambos:

• Versiones sin soporte: el software que ha superado el fin de vida del fabricante (compilaciones antiguas de Java 8 sin contrato de soporte, versiones heredadas de Adobe Reader, Python 2, complementos abandonados) no recibe ninguna corrección. Sustitúyelo o desinstálalo.
• Duplicados: tres lectores de PDF o dos herramientas de compresión en el mismo dispositivo triplican la superficie de ataque sin ningún beneficio. Estandariza en uno por función.
• Las herramientas de acceso remoto que no instaló TI (AnyDesk, TeamViewer y similares) son a la vez un problema de parches y un método de persistencia habitual de los atacantes. Elimínalas y bloquéalas con control de aplicaciones.
• Extensiones de navegador y entornos de ejecución incluidos con aplicaciones de negocio antiguas. Pide al fabricante una versión con soporte y aísla la aplicación si no existe.

Desinstala con el desinstalador silencioso del fabricante o con winget uninstall --id <id> --silent, y registra cada eliminación. Eliminar es también la respuesta para el software que no tiene ninguna vía de actualización silenciosa.

Verificación

Vuelve a ejecutar el inventario y compara las versiones con la versión actual del fabricante. En un solo dispositivo:

winget upgrade --include-unknown           # no debería mostrar nada de tu conjunto aprobado

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MsiInstaller'; Id=1033,11707} -MaxEvents 20 |
  Format-Table TimeCreated, Id, Message -Wrap

Las instalaciones basadas en MSI registran el evento 11707 (instalación completada correctamente) y el 1033 (producto instalado, con su estado) en el registro Application con el origen MsiInstaller. Los registros propios de winget están en %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir de la cuenta que lo ejecutó (para SYSTEM, en la carpeta systemprofile).

A nivel de parque, sigue el porcentaje de dispositivos con la versión actual de cada aplicación de nivel 1 y la versión más antigua que sigue presente. La versión más antigua es la que encontrará un atacante.

Qué se rompe

• Actualizaciones que necesitan reiniciar la aplicación. Los navegadores descargan pero no aplican hasta que se reinician; sin notificaciones de reinicio, los dispositivos "actualizados" ejecutan el binario antiguo durante semanas.
• Saltos de versión principal. Java, los editores de PDF y los complementos de aplicaciones de negocio pueden romperse con una versión principal nueva. Fíjalos y pruébalos.
• Instalaciones por usuario y por equipo en paralelo. Una actualización para todo el equipo deja intacta una copia por usuario más antigua, y el usuario sigue abriendo esa.
• winget como SYSTEM no puede acceder a los paquetes del origen Microsoft Store y falla con algunos instaladores por usuario. Detéctalos y trátalos por separado.

Lista de comprobación

• Inventario de software que cubre las instalaciones por equipo y por usuario
• Aplicaciones de nivel 1 identificadas, con objetivos de parche en días
• Actualización automática del fabricante habilitada y notificaciones de reinicio impuestas en los navegadores
• .NET y otros productos de Microsoft reciben actualizaciones a través de Microsoft Update
• winget (o una herramienta de parches) actualizando una lista aprobada como SYSTEM
• Directivas de App Installer: sin invalidación de hash, sin manifiestos locales, solo orígenes aprobados
• Software sin responsable y al final de su vida útil eliminado
• Informe de versión más antigua por aplicación de nivel 1 revisado cada mes

Los parches de terceros cierran el mayor hueco que deja Windows Update. Para la parte de Microsoft del proceso, consulta directivas de Windows Update y el resto del área de parches y actualizaciones.