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 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 proveedores de servicios gestionados (MSP), es la parte del programa de aplicación de parches que, en la práctica, cuenta con una financiación insuficiente en comparación con el riesgo real que supone. El estudio comparativo de Qualys sobre empresas 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 gestión de parches en millones de terminales para proveedores de servicios de gestión (MSP) y equipos de TI internos de todo el mundo, lo que ofrece una visión operativa clara de en qué aspectos los programas de gestión de parches de terceros se mantienen a la altura bajo 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é aspectos deben priorizarse, cómo desarrollar el programa desde el punto de vista operativo y qué debe aportar la automatización para mantenerse al día con el ritmo de lanzamiento de 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 los dispositivos finales y que no ha sido 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, paquetes ofimáticos, herramientas de desarrollo, utilidades de compresión y la larga lista 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 condiciones diferentes. Microsoft, Apple y las principales distribuciones de Linux distribuyen sus actualizaciones a través de canales estandarizados y bien estructurados. Los proveedores externos no lo hacen. No existe un «Patch Tuesday» para Slack. No hay un catálogo central que vincule el calendario de lanzamientos de Adobe con el de Mozilla, el de Oracle o el de la aplicación de nicho para el sector empresarial 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. Abarca desde un navegador que utilizan todos los usuarios de la empresa hasta una herramienta de ingeniería específica 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 dado por sentado 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 poco a poco 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 aquellas teóricas con puntuación CVSS, y una proporción constante de las nuevas entradas corresponde a aplicaciones de terceros, más que a los sistemas operativos básicos. 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 complica aún más las cosas. El «Patch Tuesday» de abril de 2026 de Microsoft solucionó 163 vulnerabilidades (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 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 viable.
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 de datos, lo que supone un aumento del 34 % con respecto al año anterior. Ese aumento no se debe únicamente a los «zero-day» a nivel del sistema operativo. 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 parchear.
Retos de la gestión de parches de terceros
Una vez que se sabe que el riesgo es real, la pregunta lógica es por qué tantos programas siguen dejando esa vulnerabilidad sin resolver. La respuesta es de carácter técnico, no motivacional. La aplicación de parches a aplicaciones de terceros es, por su propia naturaleza, más difícil que la aplicación de parches al sistema operativo, debido a cuatro razones que se entrelazan entre sí.
Fragmentación de 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 canales de información distintos y traducir cada uno de ellos en acciones concretas. Se trata de una tarea 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 el navegador puede llegar a mitad de semana. Una actualización de tiempo de ejecución puede lanzarse sin previo aviso. Una herramienta de conferencias puede lanzar una versión de seguridad el mismo día que un proveedor de controladores de impresora publica un CVE. El volumen no es predecible y el momento tampoco, lo que significa que un programa de parches diseñado en torno a una cadencia mensual se perderá habitualmente, por diseño, las actualizaciones de terceros que requieren una respuesta rápida.
Diversidad de instaladores
Los parches del sistema operativo se distribuyen 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 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 este proceso de forma fiable con 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 parques de software no gestionados. Los departamentos adoptan 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 funciona 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 si fueran todas iguales es lo que hace que los programas acaben teniendo la misma vulnerabilidad que si no existieran. El enfoque adecuado consiste en clasificarlas por nivel en función de su alcance de implementación, su historial de vulnerabilidades y su proximidad al perímetro de la red, para luego centrar la frecuencia de las actualizaciones y el acuerdo de nivel de servicio (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, muestran por definición contenidos no fiables procedentes 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 medidas de cumplimiento, constituye un punto de referencia razonable.
A continuación vienen los lectores de PDF y documentos. Adobe Acrobat y Reader cuentan con un extenso historial de vulnerabilidades CVE críticas y han sido objeto de ataques mediante documentos maliciosos enviados por correo electrónico durante mucho tiempo. Disponer de una versión actualizada en todos los dispositivos 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 sustentan aplicaciones empresariales que pueden pasar desapercibidas 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.
Los clientes de videoconferencia y colaboración se sitúan en un cuarto nivel. Zoom, Teams (en su versión de instalació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 en el 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 confidenciales, potencial de movimiento lateral). Para obtener más información sobre cómo integrar ese marco en un programa más amplio, consulte 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 el mismo esquema general que el proceso global 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 agentes y exhaustiva. Una auditoría semanal del software en el registro de activos no es suficiente. El agente debe identificar 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 se sabe qué está instalado, se necesita una fuente de información que indique cuándo cada proveedor publica una actualización de seguridad, a ser posible clasificada por nivel de gravedad. Crear esa fuente de información internamente para cincuenta proveedores supone un gran 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 mencionada anteriormente se integra directamente en la estructura de los SLA, que debe quedar reflejada de forma explícita en la política de gestión de parches. Una política que identifique 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 terceros», que es precisamente la causa de esa brecha.
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 de software independiente (ISV) y, en el mejor de los casos, por el control de calidad del catálogo de su 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 renderizado y daña 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 línea de negocio, una compilación de Teams que afecta a una integración personalizada. Un pequeño grupo piloto de terminales representativos, con una retención de 24 a 48 horas para las actualizaciones rutinarias y una prueba de humo comprimida para las vulnerabilidades explotadas activamente, detecta la mayor parte de esto antes de que llegue a producción.
La implementación aplica la actualización probada al resto del entorno dentro de 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 círculo. La señal 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.
Los informes se elaboran 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 es ahí 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, descargar 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 se encarga de gestionar las excepciones, aprobar las ventanas de cambio para los sistemas críticos y ocuparse del pequeño porcentaje de aplicaciones que realmente requieren intervención manual.
Hay dos aspectos específicos de la automatización de terceros que conviene destacar, ya que no se les presta la atención suficiente 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, mientras dura ese lapso, el mismo valor en materia de seguridad que si no existiera ninguna plataforma. Las preguntas que vale la pena plantearse al evaluar cualquier capacidad de aplicación de parches 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 en el caso de 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 dependencia. Un parche defectuoso del sistema operativo suele provocar fallos en el propio sistema. Un parche de terceros defectuoso suele provocar fallos en la aplicación que depende de él, lo que puede afectar al flujo de trabajo de una línea de 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, periodos de espera y reversión automática. Sin embargo, la tolerancia operativa al fallo es menor, ya que los usuarios se dan cuenta antes de un fallo en Adobe Reader que de una actualización del kernel.
El aspecto del cumplimiento normativo
Los marcos de cumplimiento han dejado de considerar el software de terceros como una cuestión aparte. El requisito 6.3.3 de la norma PCI DSS 4.0 abarca todos los componentes del sistema, incluidas las aplicaciones, y no solo los sistemas operativos. El punto 8.8 del anexo A de la norma ISO 27001:2022 trata 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 seguridad «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.
La consecuencia práctica es la misma en todos los casos. Una auditoría que examine su 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 su 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 de carácter estructural: hay más proveedores, más frecuencias de actualización, más formatos de instaladores, una mayor 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 admitir un catálogo de terceros probado al ritmo al que los proveedores realmente lanzan 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 para el sistema operativo, de terceros y de firmware se gestiona 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 específica para 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 vista unificada del estado de los parches del sistema operativo y de terceros, con el registro de auditoría que exigen los marcos de cumplimiento, generada como un subproducto 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 indican que tienen razón.
