Gestión de parches de terceros: por qué es fundamental y cómo automatizar las tareas de TI
El panel de cumplimiento de parches indica un 96%. Windows está actualizado, macOS está actualizado, el equipo de seguridad da el visto bueno y el informe se envía al auditor. El problema es que ese 96% refleja únicamente la situación del SO. El endpoint que se encuentra bajo esa casilla verde también ejecuta una compilación de Chrome de finales de verano, una versión de Adobe Reader con tres CVE publicadas en su contra, un cliente de Zoom anterior al último aviso de seguridad y un entorno de ejecución de Java en el que nadie del equipo ha pensado en dieciocho meses. Nada de eso se refleja en la puntuación.
Esa es la brecha que la gestión de parches de terceros debe cerrar y, para la mayoría de los equipos de TI y MSP, representa la mitad del programa de parches que se encuentra discretamente desfinanciada en relación con su riesgo real. El punto de referencia empresarial de 2026 de Qualys situó el tiempo medio de reparación para aplicaciones de terceros complejas en cinco meses y diez días. Los atacantes operan en un margen medido en días, a veces horas. Ambas escalas temporales no son compatibles.
Las soluciones RMM de Kaseya gestionan la administración de parches en millones de endpoints para MSPs y equipos de TI internos en todo el mundo, proporcionando una visión operativa clara de dónde resisten los programas de parches de terceros bajo presión y dónde fallan. Esta guía abarca qué es la gestión de parches de terceros, por qué su mecánica es más compleja que la de los parches del SO, qué priorizar, cómo estructurar el programa a nivel operativo y qué debe ofrecer la automatización para seguir el ritmo de lanzamientos.
¿Qué es la gestión de parches de terceros?
La gestión de parches de terceros es la disciplina de identificar, evaluar, implementar y verificar las actualizaciones del software que se ejecuta en sus endpoints y que no proviene del proveedor del sistema operativo. Es una categoría amplia: navegadores, lectores de PDF, clientes de conferencias, entornos de ejecución como Java y .NET, suites de productividad, herramientas de desarrollo, utilidades de compresión y la gran variedad de aplicaciones empresariales que se acumulan en cualquier entorno con el tiempo.
Forma parte de la misma disciplina general de gestión de parches que los del SO, pero opera bajo restricciones diferentes. Microsoft, Apple y las principales distribuciones de Linux lanzan sus actualizaciones a través de canales estandarizados y bien instrumentados. Los proveedores externos no lo hacen. No existe un Patch Tuesday para Slack. Ningún catálogo centralizado vincula el calendario de lanzamientos de Adobe con el de Mozilla, el de Oracle o la aplicación especializada de la línea de negocio que el departamento financiero instaló en 2019. Cada proveedor publica según su propio ritmo, en su propio formato y a través de su propio canal, y alguien debe realizar un seguimiento de todos ellos simultáneamente.
El término «terceros» abarca mucho terreno. Engloba desde un navegador utilizado por todos los usuarios de la empresa hasta una herramienta de ingeniería de uso específico instalada en tres equipos. Ambas caen bajo el mismo paraguas operativo y ambas pueden ser el punto de entrada de una brecha de seguridad.
Por qué la aplicación de parches de terceros es más importante que nunca
Durante años, el discurso se centraba en que las vulnerabilidades del sistema operativo eran la principal preocupación y las aplicaciones pasaban a un segundo plano. Hace tiempo que eso dejó de ser cierto. Los datos han confirmado de manera constante lo que los atacantes ya sabían.
La encuesta de Adaptiva de 2025 sobre el estado de la gestión de parches (*State of Patch Management*), realizada junto con Demand Metric, reveló que el 87 % de las organizaciones se enfrentó a vulnerabilidades en aplicaciones de terceros que requirieron la aplicación de parches durante el año anterior. Eso no es un caso aislado; es la situación predeterminada en casi cualquier entorno de TI que ejecute software moderno.
El catálogo de vulnerabilidades explotadas conocidas de la CISA (*CISA Known Exploited Vulnerabilities catalog*) cuenta la misma historia desde otra perspectiva. La lista KEV cataloga las vulnerabilidades que los atacantes están utilizando activamente, más allá de las valoraciones teóricas según la escala CVSS, y una proporción constante de las nuevas incorporaciones corresponde a aplicaciones de terceros en lugar de a los sistemas operativos principales. Navegadores, lectores de documentos, herramientas de videoconferencia y bibliotecas de ejecución aparecen mes tras mes. Tienen un despliegue masivo, lanzan actualizaciones de seguridad con frecuencia y es precisamente en el intervalo entre el lanzamiento del proveedor y la instalación por parte del usuario final donde los atacantes actúan.
El ritmo actual añade otro desafío. El *Patch Tuesday* de Microsoft de abril de 2026 abordó 163 CVE solo en su propio ecosistema de software. Si a eso le sumamos Adobe, Oracle, Google, Mozilla, Cisco, Atlassian y una docena más, el volumen mensual que cualquier programa de parches debe gestionar empieza a ser realmente exigente. La revisión manual de un flujo de información de ese tamaño no es una estrategia viable.
El informe de investigación de violaciones de datos de Verizon de 2025 (*2025 Verizon Data Breach Investigations Report*) indicó que la explotación de vulnerabilidades fue el vector de acceso inicial en el 20 % de las brechas, lo que representa un aumento interanual del 34 %. Ese crecimiento no proviene únicamente de las vulnerabilidades de día cero a nivel de sistema operativo. Refleja la creciente mercantilización de vulnerabilidades en software de terceros que las organizaciones o bien no sabían que estaban ejecutando, o bien no habían tenido tiempo de parchear.
Desafíos de la gestión de parches de terceros
Una vez que se asume que el riesgo es real, la pregunta lógica es por qué tantos programas siguen dejando esta brecha abierta. La respuesta es de carácter operativo, no de falta de voluntad. Gestionar los parches de terceros es estructuralmente más complejo que los del sistema operativo por cuatro motivos interconectados.
Fragmentación de proveedores
La infraestructura de actualización de Microsoft gestiona el software de Microsoft; la de Apple, macOS. No existe un canal unificado equivalente para el resto. Cada proveedor independiente de software (ISV) mantiene su propio portal de lanzamientos, su propio formato de avisos y su propio mecanismo de entrega. Realizar un seguimiento manual de los lanzamientos de entre 50 y 100 aplicaciones de terceros implica suscribirse a decenas de fuentes independientes y traducir cada una en acciones concretas. Es una tarea a tiempo completo para la que la mayoría de los equipos no dispone de personal suficiente.
Variabilidad en la frecuencia de lanzamiento
El *Patch Tuesday* ofrece un ritmo previsible para Windows, pero los lanzamientos de terceros no siguen un patrón fijo. Una corrección crítica para un navegador puede llegar a mitad de semana; una actualización de *runtime* puede publicarse sin previo aviso; una herramienta de videoconferencia puede lanzar una compilación de seguridad el mismo día en que un fabricante de controladores de impresoras publica un CVE. El volumen no es previsible ni tampoco lo es el calendario, lo que significa que un programa de parches configurado en función de un ciclo mensual pasará por alto de forma sistemática las actualizaciones de terceros que requieren atención urgente.
Diversidad de instaladores
Los parches del sistema operativo llegan a través de mecanismos estandarizados. Las aplicaciones de terceros utilizan MSI, EXE, MSIX, App-V, actualizadores propios del fabricante, instaladores basados en web y algún que otro script de despliegue a medida. Cada formato cuenta con sus propios parámetros de instalación silenciosa, su propio comportamiento de reinicio, su propia lógica de detección de versiones y sus propias formas de fallo. Automatizar este proceso de manera fiable ante tanta variedad requiere una herramienta con soporte verificado por el fabricante para cada aplicación o bien scripts personalizados que su equipo deba mantener indefinidamente.
Descubrimiento
No se puede parchear lo que no se sabe que existe. Los usuarios instalan aplicaciones al margen de los canales aprobados por TI; los procesos de adquisición heredan infraestructuras de software no gestionadas; los departamentos se estandarizan con herramientas de las que el equipo de terminales no tenía conocimiento. Sin un descubrimiento continuo basado en agentes que identifique todas las aplicaciones y versiones instaladas en cada dispositivo gestionado, el programa de parches operará sobre un inventario que ya es erróneo desde el principio.
Estas cuatro limitaciones no desaparecen por mucho empeño que se ponga; son características inherentes al propio ecosistema de software de terceros. Un programa eficaz es aquel que se diseña teniendo en cuenta estas restricciones en lugar de luchar contra ellas.
¿Qué aplicaciones merece la pena priorizar primero?
No todas las aplicaciones de terceros conllevan el mismo nivel de riesgo, y tratarlas como una lista indiferenciada es la vía directa para que los programas tengan el mismo nivel de exposición que si no existieran. El enfoque adecuado consiste en clasificarlas por niveles según su presencia en el despliegue, su historial de explotación y su proximidad al perímetro de la red, para después concentrar la frecuencia de actualización y los SLA en el nivel superior.
Los navegadores deben situarse en la parte superior de prácticamente cualquier lista. Chrome, Edge, Firefox y Brave están instalados en todos los terminales, procesan contenido no confiable procedente de internet por definición y reciben actualizaciones de seguridad varias veces al mes. Asimismo, suelen posponer la aplicación de las actualizaciones hasta el reinicio, lo que significa que un parche disponible no es un parche aplicado hasta que el usuario cierra la ventana. Establecer un SLA de 24 a 48 horas para las actualizaciones críticas de navegadores, con mecanismos de cumplimiento, es una directriz básica razonable.
Los lectores de PDF y documentos ocupan el siguiente lugar. Adobe Acrobat and Reader cuentan con un extenso catálogo de CVE críticas y un largo historial de ser el objetivo de documentos maliciosos enviados por correo electrónico. Mantener una versión actualizada en cada terminal es la forma más económica y eficaz de reducir las tasas de éxito de las cargas útiles de *phishing* de las que disponen la mayoría de los equipos.
Los entornos de ejecución (*runtimes*) constituyen el tercer grupo. Java, OpenJDK, los entornos de ejecución de .NET y varios motores de JavaScript sustentan aplicaciones empresariales que quizás no sean visibles para las herramientas de seguridad como dependencias independientes. Una vulnerabilidad en un entorno de ejecución afecta a todas las aplicaciones desarrolladas sobre él, y el radio de impacto puede ser muy amplio, incluso cuando el propio componente pueda parecer secundario.
Los clientes de conferencias y colaboración se sitúan en un cuarto nivel. Zoom, Teams (en su formato de instalación independiente), Slack y herramientas similares están instaladas en todas partes, interactúan con enlaces y archivos externos no confiables y se actualizan con frecuencia. Su superficie de ataque es similar a la de un navegador, aunque su visibilidad en el inventario de activos sea diferente.
Las utilidades de compresión, las herramientas de archivo, las dependencias de desarrollo y el gran volumen de aplicaciones empresariales completan el resto. Cada una de ellas conlleva una parte significativa del riesgo, y el marco adecuado para priorizarlas es el mismo modelo basado en el riesgo que debe regir la gestión de parches del sistema operativo: gravedad (CVSS), estado de explotación (listas KEV, fuentes de inteligencia sobre amenazas, exploits públicos) y contexto empresarial (exposición a internet, datos confidenciales, potencial de movimiento lateral). Para obtener más información sobre cómo integrar este marco en un programa más amplio, consulte las mejores prácticas de gestión de parches.
Mejores prácticas para la aplicación de parches de terceros: cómo estructurar un programa
Un programa eficaz de parches de terceros sigue la misma trayectoria general que el proceso de gestión de parches en general, pero la implementación en cada etapa debe absorber la complejidad adicional que aporta el software de terceros.
El descubrimiento debe ser continuo, exhaustivo y basado en agentes. Una auditoría de software semanal en el registro de activos no es suficiente. El agente debe detectar cada aplicación instalada, cada versión y cada instancia instalada por el usuario en cada terminal administrado, con actualizaciones casi en tiempo real. Siempre que falle esa visibilidad, el programa de parches estará totalmente a ciegas.
La monitorización amplía el mismo principio. Una vez que sabe lo que está instalado, necesita un canal de información que le avise cuando cada proveedor publique una actualización de seguridad, idealmente clasificada por gravedad. Crear ese canal de información internamente para cincuenta proveedores es una tarea ardua. La solución realista es utilizar una herramienta de parches cuyo proveedor añada las nuevas versiones a un catálogo probado a las pocas horas de su publicación, de modo que el equipo consuma un único canal en lugar de cincuenta.
La priorización es donde la aplicación de parches de terceros suele diferir más de la del sistema operativo en la práctica operativa. La clasificación de riesgos mencionada anteriormente alimenta directamente su estructura de SLA, que debe codificarse explícitamente en su política de gestión de parches. Una política que nombre las aplicaciones de terceros, las asigne a niveles de gravedad con SLA establecidos y exija excepciones documentadas elimina la priorización implícita de «primero el SO, después los terceros» que crea la brecha en primer lugar.
Las pruebas son genuinamente diferentes. Los parches del SO son validados por Microsoft, Apple o el responsable de Linux correspondiente antes de su lanzamiento. Los parches de terceros son validados por el ISV y, de forma ideal, por el control de calidad del catálogo de su plataforma de parches. El riesgo restante es la interacción entre aplicaciones: una actualización del navegador que cambia el comportamiento de renderizado y rompe una aplicación web interna, una actualización del entorno de ejecución de Java que genera problemas de compatibilidad con un paquete empresarial, o una compilación de Teams que afecta a una integración personalizada. Un pequeño grupo piloto de terminales representativos, con un período de retención de 24 a 48 horas para las actualizaciones rutinarias y una prueba rápida comprimida para las vulnerabilidades explotadas activamente, permite detectar la mayoría de estos problemas antes de que lleguen a producción.
El despliegue traslada la actualización probada al resto de la infraestructura respetando las ventanas de mantenimiento definidas, con lógica de reintento para los terminales que estaban desconectados en el primer intento y rutas de reversión en caso de errores. Esta es la parte del programa que falla de forma más evidente cuando se ejecuta manualmente, ya que el volumen absorbe las horas disponibles y la gestión de excepciones desplaza el trabajo rutinario.
La verificación cierra el ciclo. La métrica de cumplimiento que le importa es la versión instalada, no el estado del despliegue. Un informe de despliegue puede mostrar «enviado» mientras que un fallo de instalación silenciosa deja la versión antigua en el dispositivo. La verificación por aplicación y por dispositivo de la versión en ejecución es lo que le indica si el parche se ha aplicado realmente.
La generación de informes se centra en cada aplicación y no en cada dispositivo. Un dispositivo con Chrome actualizado pero con Java tres versiones desfasadas no cumple con ninguna normativa que un auditor pueda aceptar. Los informes deben segmentarse por aplicación, nivel de gravedad e incumplimiento de SLA, incluyendo los desgloses por cliente que los MSP necesitan para las certificaciones destinadas a los clientes.
Por qué la gestión automatizada de parches de terceros es fundamental
Los números no salen sin ella. Cincuenta aplicaciones de terceros, docenas de lanzamientos al mes por cada proveedor principal, cientos o miles de terminales, calendarios de proveedores que no coinciden y SLA medidos en horas para los parches de mayor riesgo. Ningún equipo va a mantener eso en marcha manualmente; y los que lo intentan son los primeros en quedarse atrás con el software de terceros porque es ahí donde el coste de quedarse atrás es menos visible en el día a día.
La gestión automatizada de parches libera al equipo de las tareas rutinarias: detectar que una aplicación necesita una actualización, extraer el paquete probado del catálogo, desplegarlo mediante una instalación silenciosa durante la ventana de mantenimiento acordada, gestionar los reinicios y reintentar en caso de fallo. Las personas siguen interviniendo en la gestión de excepciones, las aprobaciones de ventanas de cambio para sistemas sensibles y el pequeño porcentaje de aplicaciones que realmente requieren intervención manual.
Hay dos aspectos específicos de la automatización de terceros que vale la pena destacar porque no reciben la atención suficiente en el debate general sobre la automatización.
El primero es la calidad del catálogo. La automatización es tan buena como el catálogo de aplicaciones que la alimenta. Una plataforma que tarda dos semanas en empaquetar una actualización crítica del navegador tiene, durante la duración de esa brecha, el mismo valor de seguridad que ninguna plataforma. Las preguntas que vale la pena plantearse al evaluar cualquier capacidad de parcheo de terceros son: ¿cuántas aplicaciones son compatibles de forma nativa, con qué rapidez refleja el catálogo los nuevos lanzamientos de los proveedores (especialmente para las actualizaciones de seguridad) y qué control de calidad se aplica a cada paquete antes de que llegue a los terminales de producción?
El segundo es la superficie de dependencias. Un parche de SO defectuoso suele dañar el SO. Un parche de terceros defectuoso tiende a dañar la aplicación que depende de él, lo que puede significar un flujo de trabajo empresarial, una integración o una herramienta de productividad que utiliza toda la empresa. La mitigación es la misma que para cualquier programa de parches: anillos de despliegue, periodos de retención y reversión automatizada. Sin embargo, la tolerancia operativa a los fallos es menor porque los usuarios notan un fallo en Adobe Reader mucho antes que una actualización del núcleo (kernel).
El aspecto del cumplimiento normativo
Los marcos normativos de cumplimiento han dejado de fingir que el software de terceros es una cuestión independiente. El requisito 6.3.3 de PCI DSS 4.0 abarca todos los componentes del sistema, lo que incluye las aplicaciones y no solo los sistemas operativos. El anexo A 8.8 de la norma ISO 27001:2022 abarca la gestión de vulnerabilidades técnicas sin excepciones. La norma de seguridad de la ley HIPAA se ha interpretado en acciones de ejecución para incluir la aplicación de parches de aplicaciones como parte de las salvaguardas «razonables y apropiadas». La directiva NIS2, en vigor en todos los Estados miembros de la UE, exige pruebas de una gestión oportuna de las vulnerabilidades que no distinga entre el SO y las aplicaciones. Los Criterios de Servicios de Confianza CC7.1 de SOC 2 cubren la supervisión y corrección de nuevas vulnerabilidades en todo el sistema.
La implicación práctica es la misma en todos los casos. Una auditoría que examine su programa de parches y encuentre navegadores no gestionados, lectores de PDF sin actualizar o entornos de ejecución de Java obsoletos generará incidencias, independientemente de lo impecable que parezca su informe de cumplimiento de Windows. La defensa ante dicha incidencia son las pruebas operativas: informes de cumplimiento por aplicación, registros de despliegue fechados, excepciones documentadas y SLA que se cumplan en la práctica y no solo sobre el papel.
Cómo simplifica Kaseya la aplicación de parches de terceros
La aplicación de parches de terceros no es un problema de conocimientos. Todos los equipos de TI y MSP saben que las aplicaciones necesitan parches. Es un problema operativo, y el problema operativo es estructural: más proveedores, más calendarios, más formatos de instalador, mayor superficie de descubrimiento y un flujo de trabajo predeterminado que favorece la aplicación de parches del SO porque estos son más fáciles de instrumentar.
La forma de solucionarlo es dejar de tratar a los terceros como un programa paralelo e integrarlos en el mismo marco de trabajo que ya está en funcionamiento. El mismo inventario. La misma clasificación de riesgos. Los mismos SLA en la política. Los mismos anillos de despliegue. La misma automatización. Los mismos informes de cumplimiento por aplicación. Las herramientas subyacentes deben admitir un catálogo de terceros probado al ritmo en que los proveedores realmente lo lanzan, pero el diseño del programa no es un programa diferente. Es el mismo programa, con su alcance completo.
Ese principio de diseño es sobre el que se construyen las soluciones RMM de Kaseya: parches de SO, de terceros y de firmware ejecutados a través de un único agente, un marco de políticas unificado, un conjunto de ventanas de mantenimiento y una vista de cumplimiento consolidada. El módulo Advanced Software Management de Datto RMM es la funcionalidad específica de terceros, que amplía la cobertura de parches a más de 200 aplicaciones nativas con un catálogo probado en millones de dispositivos antes de su lanzamiento y en constante crecimiento.
El módulo también es compatible con la instalación y desinstalación de aplicaciones a través del mismo marco de políticas, lo que cierra una brecha que la mayoría de las herramientas de parches dejan abierta: las aplicaciones obsoletas que deben eliminarse, y no solo actualizarse, antes de que sean explotadas. Para los MSP, esto se traduce en una configuración de políticas por cliente y en informes de cumplimiento por cliente desde una única consola. Para los equipos de TI internos, ofrece una vista unificada del estado de los parches del SO y de terceros con la pista de auditoría que los marcos normativos exigen, generada como un subproducto del flujo de trabajo en lugar de una tarea trimestral de recopilación de pruebas.
La alternativa es dejar expuesta una superficie de ataque documentada mientras el panel de control de parches del SO se mantiene en verde. Esa es exactamente la brecha en la que confían los atacantes, y los datos actuales sobre explotación sugieren que están en lo cierto.
