{"id":194402,"date":"2026-05-25T14:16:03","date_gmt":"2026-05-25T17:16:03","guid":{"rendered":"https:\/\/www.itsitio.com\/mx\/?p=194402"},"modified":"2026-05-29T11:49:04","modified_gmt":"2026-05-29T14:49:04","slug":"el-apocalipsis-del-patching-ya-comenzo-y-estas-tres-excusas-de-it-ya-no-funcionan","status":"publish","type":"post","link":"https:\/\/www.itsitio.com\/mx\/columna-de-opinion\/el-apocalipsis-del-patching-ya-comenzo-y-estas-tres-excusas-de-it-ya-no-funcionan\/","title":{"rendered":"El apocalipsis del “patching” ya comenz\u00f3 y estas tres excusas de IT ya no funcionan"},"content":{"rendered":"

Por: Chris Goetti, Vicepresidente de Gesti\u00f3n de Producto para soluciones de seguridad en Ivanti<\/i><\/strong><\/p>\n

La gesti\u00f3n de parches est\u00e1 entrando en una nueva era. Para muchos equipos de IT y ciberseguridad, el desaf\u00edo ya no es solo detectar vulnerabilidades, sino reaccionar lo suficientemente r\u00e1pido antes de que sean explotadas.<\/div>\n

El detonante lleg\u00f3 el 7 de abril, cuando Anthropic anunci\u00f3 que su modelo de IA Claude Mythos Preview hab\u00eda identificado de manera aut\u00f3noma miles de vulnerabilidades cr\u00edticas y de d\u00eda cero en los principales sistemas operativos y navegadores del mercado. M\u00e1s del 99% permanec\u00edan sin parchear al momento de su divulgaci\u00f3n.<\/p>\n

Dos semanas despu\u00e9s, el 21 de abril, Mozilla confirm\u00f3 que utiliz\u00f3 el mismo modelo para encontrar y corregir 271 vulnerabilidades en la \u00faltima versi\u00f3n de Firefox. Su evaluaci\u00f3n fue directa: \u201cHasta ahora no hemos encontrado ninguna categor\u00eda o complejidad de vulnerabilidad que los humanos puedan detectar y que este modelo no pueda\u201d.<\/p>\n

Lo que est\u00e1 ocurriendo ya tiene nombre dentro de la industria: un \u201capocalipsis del patching\u201d, del tipo operativo, donde el volumen y la velocidad de vulnerabilidades p\u00fablicas con parches disponibles est\u00e1n a punto de superar la capacidad de respuesta de la mayor\u00eda de los equipos de IT y seguridad.<\/p>\n

NIST ya lo est\u00e1 sintiendo<\/b><\/span><\/h2>\n

El Reporte Global de Amenazas 2026 de CrowdStrike ya hab\u00eda documentado un aumento interanual del 89% en ataques habilitados por IA durante 2025, incluso antes de que modelos como Mythos entraran en escena.<\/p>\n

Al mismo tiempo, NIST, la agencia del gobierno de Estados Unidos que administra la base de datos global de vulnerabilidades conocidas, anunci\u00f3 que ya no puede procesar todo lo que recibe. Las presentaciones crecieron un 263% y la agencia tom\u00f3 una decisi\u00f3n sin precedentes: de ahora en adelante, solo analizar\u00e1 en detalle las vulnerabilidades que cumplan criterios de alto riesgo. El resto quedar\u00e1 sin evaluaci\u00f3n oficial. Es la primera vez que el sistema dise\u00f1ado para mantener el registro global de amenazas admite que el volumen ha superado su capacidad.<\/p>\n

Muchas organizaciones creen que ya est\u00e1n cubiertas: tienen un esc\u00e1ner de vulnerabilidades, un proceso de aprobaci\u00f3n y herramientas de gesti\u00f3n de dispositivos. El problema es que ninguna de esas piezas cierra el ciclo por s\u00ed sola. Los esc\u00e1neres detectan y enumeran, pero no despliegan ni verifican. Los procesos de aprobaci\u00f3n basados en tickets, dise\u00f1ados para otra velocidad, crean cuellos de botella que ahora pueden extenderse durante semanas. Y las herramientas de gesti\u00f3n de dispositivos tienen limitaciones de cobertura que dejan fuera servidores, endpoints de terceros y aplicaciones fuera de su ecosistema. Con ventanas de explotaci\u00f3n medidas ahora en horas, esas brechas ya no son detalles operativos: son riesgo acumulado.<\/p>\n

Lo que necesitan cambiar ahora los equipos de IT<\/b><\/span><\/h2>\n

La respuesta no es reemplazar lo que ya existe, sino conectarlo mediante automatizaci\u00f3n que cierre esas brechas. En la pr\u00e1ctica, eso significa tres cosas:<\/p>\n

1. Prioridad basada en riesgo, no en calendario.<\/p>\n

Las vulnerabilidades explotadas activamente no pueden esperar al ciclo mensual. Navegadores, aplicaciones de comunicaci\u00f3n y sistemas de usuario final deben ir primero. Todo lo dem\u00e1s sigue el calendario regular.<\/p>\n

2. Despliegue escalonado con rollback autom\u00e1tico.<\/p>\n

Comience con un grupo peque\u00f1o, exp\u00e1ndalo a uno m\u00e1s amplio y luego despliegue a todos. Cuando existe una vulnerabilidad activa, ese proceso debe comprimirse de semanas a d\u00edas. Y si algo falla, el sistema debe revertirse autom\u00e1ticamente.<\/p>\n

3. Un parche no cuenta hasta que se confirme instalado.<\/p>\n

La mayor\u00eda de los equipos cierran el caso cuando el parche es aprobado. El riesgo termina \u00fanicamente cuando se verifica que lleg\u00f3 a todos los dispositivos. Sin esa confirmaci\u00f3n, la evidencia de cumplimiento se convierte en una crisis antes de cada auditor\u00eda.<\/p>\n

Si un zero-day cr\u00edtico aparece el pr\u00f3ximo viernes por la tarde, \u00bfsu equipo podr\u00eda remediarlo completamente antes del lunes?<\/p>\n

M\u00eddalo desde el momento en que se publica la alerta hasta el instante en que el \u00faltimo dispositivo queda protegido. Si eso toma semanas, el apocalipsis del patching ya lo encontr\u00f3.<\/p>\n

Lee m\u00e1s:\u00a0<\/span><\/h3>\n