Gestión de parches de terceros: por qué es fundamental y cómo automatizar las tareas de TI
El panel de control 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 % corresponde únicamente al sistema operativo. El terminal que se encuentra bajo ese mosaico verde también ejecuta una versión de Chrome de finales de verano, una versión de Adobe Reader con tres vulnerabilidades (CVE) publicadas, 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 los últimos dieciocho meses. Nada de eso aparece reflejado en la puntuación.
Esa es la brecha que se supone que debe cubrir la gestión de parches de terceros y, para la mayoría de los equipos de TI y los MSP, es la parte del programa de aplicación de parches que, en silencio, cuenta con una financiación insuficiente en relación con el riesgo real que supone. El estudio comparativo empresarial de Qualys de 2026 situó el tiempo medio de corrección para aplicaciones complejas de terceros en cinco meses y diez días. Los atacantes actúan en un plazo que se mide en días, a veces en horas. Ambos plazos son incompatibles.
Las soluciones RMM de Kaseya gestionan la aplicación de parches en millones de terminales para proveedores de servicios de gestión (MSP) y equipos internos de TI de todo el mundo, lo que ofrece una visión operativa clara de en qué aspectos los programas de aplicación de parches de terceros resisten la presión y en cuáles fallan. Esta guía explica qué es la gestión de parches de terceros, por qué su funcionamiento es más complejo que el de los parches del sistema operativo, qué hay que priorizar, cómo desarrollar el programa desde el punto de vista operativo y qué debe aportar la automatización para seguir el ritmo de las nuevas versiones.
¿Qué es la gestión de parches de terceros?
La gestión de parches de terceros es la disciplina que consiste en identificar, evaluar, implementar y verificar las actualizaciones del software que se ejecuta en tus terminales y que no es suministrado por el proveedor del sistema operativo. Se trata de una categoría muy amplia: navegadores, lectores de PDF, clientes de videoconferencia, entornos de ejecución como Java y .NET, suites ofimáticas, herramientas de desarrollo, utilidades de compresión y toda la amplia gama de aplicaciones empresariales que se acumulan con el tiempo en cualquier entorno.
Se enmarca dentro de la misma disciplina general de gestión de parches que la aplicación de parches al sistema operativo, pero opera bajo unas limitaciones diferentes. Microsoft, Apple y las principales distribuciones de Linux distribuyen sus actualizaciones a través de canales estandarizados y bien equipados. Los proveedores externos no lo hacen. No existe un «Patch Tuesday» para Slack. No existe un catálogo central que vincule el calendario de lanzamientos de Adobe con el de Mozilla, con el de Oracle o con el de la aplicación especializada para el negocio que el equipo financiero instaló en 2019. Cada proveedor lanza sus actualizaciones a su propio ritmo, en su propio formato y a través de su propio canal, y alguien debe llevar un control de todas ellas a la vez.
El término «de terceros» abarca mucho en este contexto. Incluye desde un navegador que utilizan todos los usuarios de la empresa hasta una herramienta de ingeniería con una única finalidad instalada en tres equipos. Ambos entran dentro del mismo ámbito operativo y ambos pueden constituir un punto de entrada para una brecha de seguridad.
Por qué las actualizaciones de terceros son más importantes que nunca
Durante años, se ha considerado que las vulnerabilidades del sistema operativo eran la principal preocupación y que las aplicaciones eran una preocupación secundaria. Eso ya no es así desde hace tiempo. Los datos han ido confirmando progresivamente lo que los atacantes ya sabían.
La encuesta «Estado de la gestión de parches en 2025» de Adaptiva, realizada en colaboración 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. No se trata de un caso aislado, sino de la situación habitual en casi todos los entornos informáticos que utilizan software moderno.
El catálogo de vulnerabilidades explotadas conocidas (KEV) de la CISA cuenta la misma historia desde otra perspectiva. La lista KEV recoge las vulnerabilidades que los atacantes están utilizando activamente, no solo las teóricas clasificadas según el CVSS, y una proporción constante de las nuevas entradas corresponde a aplicaciones de terceros, más que a los sistemas operativos principales. Navegadores, lectores de documentos, herramientas de videoconferencia y bibliotecas de tiempo de ejecución aparecen mes tras mes. Están ampliamente implantados, lanzan actualizaciones de seguridad con frecuencia, y la brecha entre el lanzamiento del proveedor y la instalación por parte del usuario final es donde los atacantes hacen su trabajo.
El ritmo añade otra complicación. El «Patch Tuesday» de abril de 2026 de Microsoft solucionó 163 CVE solo en su propia pila de software. Si a eso le sumamos Adobe, Oracle, Google, Mozilla, Cisco, Atlassian y una docena más, el volumen mensual al que se supone que debe adaptarse cualquier programa de aplicación de parches empieza a parecer realmente abrumador. La revisión manual de un flujo de ese tamaño no es una estrategia.
El Informe de Investigaciones sobre Fugas de Datos de Verizon de 2025 reveló que el aprovechamiento de vulnerabilidades fue el vector de acceso inicial en el 20 % de las fugas, lo que supone un aumento del 34 % con respecto al año anterior. Ese crecimiento no se debe únicamente a los «zero-day» a nivel del sistema operativo, sino que refleja la creciente utilización de vulnerabilidades en software de terceros que las organizaciones, o bien no sabían que estaban utilizando, o bien aún no habían tenido tiempo de corregir.
Retos de la gestión de parches de terceros
Una vez que sabes que el riesgo es real, la pregunta lógica es por qué tantos programas dejan esa vulnerabilidad sin solucionar. La respuesta es de carácter técnico, no motivacional. La aplicación de parches de terceros resulta estructuralmente más difícil que la de los sistemas operativos por cuatro razones que se entrelazan entre sí.
Fragmentación de los proveedores
La infraestructura de actualizaciones de Microsoft se encarga del software de Microsoft. La de Apple se encarga de 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 distribución. Realizar un seguimiento manual de los lanzamientos de 50 o 100 aplicaciones de terceros implica suscribirse a docenas de fuentes distintas y traducir cada una de ellas en acciones concretas. Se trata de una función a tiempo completo para la que la mayoría de los equipos no cuentan con personal suficiente.
Variabilidad de la cadencia
El «Patch Tuesday» te ofrece un calendario fijo para Windows. Las actualizaciones de terceros no siguen uno. Una corrección crítica para un navegador puede llegar a mitad de semana. Una actualización de tiempo de ejecución puede publicarse sin previo aviso. Una herramienta de videoconferencias puede lanzar una versión de seguridad el mismo día en que un proveedor de controladores de impresora publique un CVE. Ni el volumen ni el momento de publicación son predecibles, lo que significa que un programa de aplicación de parches basado en una cadencia mensual, por su propia naturaleza, se perderá habitualmente las actualizaciones de terceros que requieren una respuesta rápida.
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, programas de actualización específicos de cada proveedor, instaladores basados en web y, en ocasiones, scripts de implementación personalizados. Cada formato tiene sus propios parámetros de instalación silenciosa, su propio comportamiento de reinicio, su propia lógica de detección de versiones y sus propios modos de fallo. Para automatizar de forma fiable toda esta variedad, se necesita o bien una herramienta con compatibilidad probada por el proveedor para cada aplicación, o bien scripts personalizados que su equipo deba mantener de forma indefinida.
Descubrimiento
No se puede aplicar un parche a algo que no se sabe que existe. Los usuarios instalan aplicaciones fuera de los canales aprobados por el departamento de TI. Las adquisiciones traen consigo un parque de software no gestionado. Los departamentos estandarizan el uso de herramientas de las que nadie ha informado al equipo de dispositivos finales. Sin una detección continua basada en agentes que identifique todas las aplicaciones y versiones instaladas en cada dispositivo gestionado, el programa de aplicación de parches se basa en un inventario que ya es erróneo antes incluso de empezar.
Estas cuatro limitaciones no desaparecen por mucho que nos esforcemos. Son características propias del ecosistema de software de terceros. Un programa que funcione es aquel que se diseña teniendo en cuenta estas limitaciones, en lugar de intentar combatirlos.
¿Qué aplicaciones conviene priorizar en primer lugar?
No todas las aplicaciones de terceros entrañan el mismo riesgo, y tratarlas como una lista homogénea es lo que hace que los programas acaben teniendo la misma vulnerabilidad que si no existieran. El enfoque adecuado consiste en clasificarlas por nivel según su alcance de implementación, su historial de vulnerabilidades y su proximidad al perímetro de la red, para luego centrar la cadencia y el SLA en el nivel superior.
Los navegadores ocupan los primeros puestos en casi todas las listas. Chrome, Edge, Firefox y Brave están instalados en todos los dispositivos finales, muestran, por definición, contenido no fiable procedente de Internet y reciben actualizaciones de seguridad varias veces al mes. Además, suelen posponer la aplicación de las actualizaciones hasta el reinicio, lo que significa que un parche disponible no se aplica hasta que el usuario cierra la ventana. Un acuerdo de nivel de servicio (SLA) de entre 24 y 48 horas para las actualizaciones críticas de los navegadores, con garantía de cumplimiento, es un punto de referencia razonable.
A continuación vienen los lectores de PDF y documentos. Adobe Acrobat y Reader cuentan con un extenso catálogo de vulnerabilidades CVE críticas y un largo historial de haber sido blanco de documentos maliciosos enviados por correo electrónico. Disponer de una versión actualizada en cada terminal es la forma más económica de reducir de manera significativa las tasas de éxito de las cargas maliciosas de phishing al alcance de la mayoría de los equipos.
Los entornos de ejecución constituyen el tercer grupo. Java, OpenJDK, los entornos de ejecución de .NET y diversos motores de JavaScript sirven de base para aplicaciones empresariales que quizá no sean visibles para las herramientas de seguridad como dependencias independientes. Una vulnerabilidad en un entorno de ejecución afecta a todas las aplicaciones creadas sobre él, y el alcance del impacto puede ser considerable incluso cuando el propio entorno de ejecución parezca poco conocido.
Las aplicaciones de videoconferencia y colaboración se sitúan en un cuarto nivel. Zoom, Teams (en su versión independiente), Slack y otras herramientas similares están instaladas en todas partes, interactúan con enlaces y archivos externos no fiables 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 archivado, las dependencias de los desarrolladores y la amplia gama de aplicaciones empresariales completan el resto. Cada una de ellas conlleva una parte significativa del riesgo, y el marco adecuado para clasificarlas es el mismo modelo basado en el riesgo que debería regir la aplicación de parches al sistema operativo: gravedad (CVSS), estado de explotación (listado KEV, fuentes de inteligencia sobre amenazas, exploits públicos) y contexto empresarial (conectado a Internet, datos sensibles, potencial de movimiento lateral). Para obtener más información sobre cómo integrar ese marco en el programa general, consulta las prácticas recomendadas para la gestión de parches.
Buenas prácticas para la aplicación de parches de terceros: cómo crear un programa
Un programa eficaz de aplicación de parches de terceros sigue la misma línea general que el proceso más amplio de gestión de parches, pero su implementación en cada fase debe tener en cuenta la complejidad adicional que conlleva el software de terceros.
La detección debe ser continua, impulsada por un agente y exhaustiva. No basta con una auditoría semanal del software en el registro de activos. El agente debe detectar todas las aplicaciones instaladas, todas las versiones y todas las instancias instaladas por los usuarios en cada terminal gestionada, con una actualización casi en tiempo real. Cada vez que se pierde esa visibilidad, el programa de aplicación de parches queda ciego en esa misma medida.
La supervisión se rige por el mismo principio. Una vez que sabes qué está instalado, necesitas una fuente de información que te indique cuándo cada proveedor lanza una actualización de seguridad, a ser posible clasificada por nivel de gravedad. Crear esa fuente de información internamente para cincuenta proveedores supone mucho trabajo. La solución más realista es una herramienta de aplicación 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 utilice una sola fuente de información en lugar de cincuenta.
La priorización es el aspecto en el que, en la práctica operativa, la aplicación de parches de terceros suele diferir más de la aplicación de parches del sistema operativo. La clasificación por niveles de riesgo anterior se integra directamente en la estructura de tu SLA, que debería quedar reflejada de forma explícita en tu política de gestión de parches. Una política que nombre las aplicaciones de terceros, las asigne a niveles de gravedad con SLA definidos y exija excepciones documentadas elimina la priorización implícita de «primero el sistema operativo, luego los de terceros», que es la que crea la brecha en primer lugar.
Las pruebas son realmente diferentes. Los parches del sistema operativo son validados por Microsoft, Apple o el responsable de mantenimiento de Linux correspondiente antes de su lanzamiento. Los parches de terceros son validados por el proveedor independiente de software (ISV) y, en el mejor de los casos, por el control de calidad del catálogo de tu plataforma de aplicación de parches. El riesgo restante es la interacción entre aplicaciones: una actualización del navegador que cambia el comportamiento de visualización y provoca fallos en una aplicación web interna, una actualización del entorno de ejecución de Java que pone de manifiesto problemas de compatibilidad con un paquete de software empresarial, o una versión de Teams que afecta a una integración personalizada. Un pequeño grupo piloto de terminales representativos, con un plazo de espera de entre 24 y 48 horas para las actualizaciones rutinarias y una prueba de fumigación acelerada para las vulnerabilidades explotadas activamente, detecta la mayor parte de estos problemas antes de que lleguen al entorno de producción.
La implementación traslada la actualización probada al resto del entorno según las ventanas de mantenimiento definidas, con una lógica de reintento para los terminales que estaban desconectados en el primer intento y rutas de reversión en caso de fallos. Esta es la parte del programa que falla de forma más evidente cuando se ejecuta manualmente, ya que el volumen de trabajo agota las horas disponibles y la gestión de excepciones resta tiempo al trabajo rutinario.
La verificación cierra el ciclo. El indicador de cumplimiento que te interesa es la versión instalada, no el estado de la implementación. Un informe de implementación puede indicar «enviado», mientras que un fallo silencioso del instalador 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 te indica si el parche se ha aplicado realmente.
La generación de informes se realiza por aplicación, no por dispositivo. Un dispositivo que tenga la versión actual de Chrome pero Java tres versiones atrasadas no cumple los requisitos en ningún sentido que un auditor pueda aceptar. Los informes deben desglosarse por aplicación, por nivel de gravedad y por incumplimiento del SLA, con los desgloses por cliente que los MSP necesitan para las certificaciones dirigidas a los clientes.
Por qué es esencial la gestión automatizada de parches de terceros
Sin ello, las cuentas no cuadran. Cincuenta aplicaciones de terceros, docenas de versiones al mes por cada proveedor importante, cientos o miles de terminales, calendarios de los proveedores que no coinciden y acuerdos de nivel de servicio (SLA) que se miden en horas para los parches de mayor riesgo. Ningún equipo va a poder mantener todo eso en marcha manualmente, y los que lo intentan se quedan atrás primero en lo que respecta al software de terceros, porque ahí es donde el coste de quedarse atrás resulta 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, obtener el paquete probado del catálogo, implementarlo mediante instalación silenciosa durante la ventana de mantenimiento acordada, gestionar los reinicios y reintentar los procesos fallidos. El personal humano sigue participando en la gestión de excepciones, en la aprobación de las ventanas de cambio para sistemas sensibles y en el pequeño porcentaje de aplicaciones que realmente requieren intervención manual.
Hay dos aspectos específicos de la automatización de terceros que merece la pena destacar, ya que no se les presta suficiente atención en el debate general sobre la automatización.
Lo primero es la calidad del catálogo. La automatización solo 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 ese lapso, el mismo valor de seguridad que si no existiera ninguna plataforma. Las preguntas que conviene plantearse al evaluar cualquier solución de aplicación de parches de terceros son: ¿cuántas aplicaciones son compatibles de serie?, ¿con qué rapidez refleja el catálogo los nuevos lanzamientos de los proveedores (especialmente en el caso de las actualizaciones de seguridad)? y ¿qué controles de calidad se aplican a cada paquete antes de que llegue a los terminales de producción?
El segundo es la superficie de dependencia. Un parche defectuoso del sistema operativo suele provocar fallos en este. Un parche defectuoso de terceros suele provocar fallos en la aplicación que depende de él, lo que puede afectar a un flujo de trabajo específico del negocio, a una integración o a una herramienta de productividad que utiliza toda la empresa. Las medidas de mitigación son las mismas que para cualquier programa de aplicación de parches: anillos de implementación, períodos de espera y reversión automática. Sin embargo, la tolerancia operativa ante los fallos es menor, ya que los usuarios se dan cuenta más rápidamente de un fallo en Adobe Reader que de una actualización del núcleo del sistema.
El aspecto del cumplimiento normativo
Los marcos de cumplimiento han dejado de considerar que el software de terceros sea una cuestión aparte. El requisito 6.3.3 de la norma PCI DSS 4.0 abarca todos los componentes del sistema, lo que incluye las aplicaciones, y no solo los sistemas operativos. El apartado 8.8 del anexo A de la norma ISO 27001:2022 aborda la gestión de vulnerabilidades técnicas sin excepciones. La Norma de Seguridad de la HIPAA se ha interpretado en las medidas de ejecución de manera que abarca la aplicación de parches a las aplicaciones como parte de las medidas de protección «razonables y adecuadas». La NIS2, en vigor en todos los Estados miembros de la UE, exige pruebas de la gestión oportuna de las vulnerabilidades, sin distinguir entre el sistema operativo y las aplicaciones. El criterio CC7.1 de los Servicios de Confianza de SOC 2 abarca la supervisión y la corrección de nuevas vulnerabilidades en todo el sistema.
Las implicaciones prácticas son las mismas en todos los casos. Una auditoría que examine tu programa de aplicación de parches y detecte navegadores sin gestionar, lectores de PDF sin parches o entornos de ejecución de Java al final de su ciclo de vida dará lugar a incidencias, independientemente de lo impecable que parezca tu informe de cumplimiento de Windows. La defensa frente a esa incidencia son las pruebas operativas: informes de cumplimiento por aplicación, registros de implementación con fecha, excepciones documentadas y acuerdos de nivel de servicio (SLA) que se cumplan en la práctica y no solo sobre el papel.
Cómo Kaseya simplifica 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 los proveedores de servicios gestionados (MSP) saben que hay que aplicar parches a las aplicaciones. Se trata de un problema operativo, y ese problema operativo es estructural: más proveedores, más frecuencias de actualización, más formatos de instalador, más superficie de detección y un flujo de trabajo predeterminado que da prioridad a la aplicación de parches al sistema operativo, ya que resulta más fácil de implementar.
La forma de resolverlo es dejar de tratar el catálogo de terceros como un programa paralelo e integrarlo en el mismo marco que el trabajo que ya se está ejecutando. Mismo inventario. Mismo nivel de riesgo. Mismos SLA en la política. Mismos anillos de implementación. Misma automatización. Mismos informes de cumplimiento por aplicación. Las herramientas subyacentes deben ser compatibles con un catálogo de terceros probado al ritmo al que los proveedores lanzan realmente sus versiones, pero el diseño del programa no es un programa diferente. Es el mismo programa, con un alcance completo.
Ese principio de diseño es la base sobre la que se asientan las soluciones RMM de Kaseya: la aplicación de parches del sistema operativo, de terceros y de firmware se lleva a cabo a través de un único agente, un único marco de políticas, un único conjunto de ventanas de mantenimiento y una única vista de cumplimiento normativo. El módulo «Advanced Software Management» de Datto RMMes la función de terceros mencionada, que amplía la cobertura de la aplicación de parches a más de 200 aplicaciones listas para usar, con un catálogo probado en millones de dispositivos antes de su lanzamiento y en constante crecimiento.
El módulo también permite instalar y desinstalar aplicaciones a través del mismo marco de políticas, lo que subsana una carencia que la mayoría de las herramientas de aplicación de parches dejan sin resolver: las aplicaciones al final de su ciclo de vida que deben eliminarse, y no solo actualizarse, antes de que sean objeto de ataques. Para los MSP, esto se traduce en la configuración de políticas y la generación de informes de cumplimiento por cliente desde una única consola. Para los equipos de TI internos, supone una visión unificada del estado de los parches del sistema operativo y de terceros, con el registro de auditoría que exigen los marcos de cumplimiento, generado como resultado natural del flujo de trabajo en lugar de como un ejercicio trimestral de recopilación de pruebas.
La alternativa es dejar expuesta una superficie de ataque documentada mientras el panel de control de parches del sistema operativo sigue en verde. Esa es precisamente la brecha en la que se basan los atacantes, y los datos actuales sobre exploits sugieren que tienen razón.
