En el primer semestre de 2026 se publicaron 35.853 CVE, aproximadamente un 49% más que el año anterior. Sin embargo, solo 495 fueron catalogados como explotados en la naturaleza durante ese mismo periodo, y 116 ya estaban bajo ataque el día en que se hicieron públicos. Además, los datos de divulgación de Anthropic muestran que los modelos de clase Mythos detectaron 26.153 candidatos a vulnerabilidad en software de código abierto, de los cuales solo 421 llegaron a parchearse upstream.
Ese pequeño subconjunto realmente explotado es clave: tratar cada vulnerabilidad con puntuación CVSS alta o crítica como una emergencia no solo es imposible, sino que es un modelo equivocado. La tarea crítica de los equipos de seguridad es decidir qué exposiciones, en qué activos, requieren acción inmediata, especialmente cuando crece el número de hallazgos y se estrecha la brecha entre divulgación y explotación.
El CVSS por sí solo no puede decirte qué importa en tu entorno
Un mismo CVE puede afectar a cientos de activos, pero el impacto rara vez es uniforme. Algunas instancias son inalcanzables; otras están detrás de controles que interrumpen las técnicas necesarias para la explotación; y otras están expuestas en sistemas críticos para el negocio donde la prevención falla y la detección nunca se activa. El CVSS proporciona una base de gravedad común, pero no el contexto que determina el impacto real para la organización. Por eso los defensores necesitan evidencia de su propio entorno para determinar si la exposición es realmente explotable, qué activos afecta y si esos activos son accesibles e importantes para el negocio.
El pentesting automatizado por sí solo no puede validar toda exposición
Más allá de las puntuaciones de gravedad, el pentesting automatizado proporciona algunas de las evidencias más sólidas: puede ejecutar exploits reales, demostrar que una exposición es explotable en tu entorno, encadenar vulnerabilidades, credenciales y configuraciones erróneas en rutas de ataque, y mostrar hasta dónde podría avanzar un atacante. Sin embargo, la cobertura sigue siendo limitada. La investigación de Omdia encontró que, aunque el 95% de las organizaciones considera el pentesting una prioridad alta o máxima, solo el 32% de su superficie de ataque promedio se prueba cada año. Los enfoques agénticos y automatizados pueden ampliar esa cobertura, pero no eliminan todas las restricciones de la explotación en vivo. Para la explotación basada en CVE, aún debe existir un exploit funcional y el objetivo debe ser seguro de probar. Los CVE recién divulgados pueden no tener exploit disponible, y puede que no sea posible probar un exploit en activos críticos, restringidos o aislados. Esas exposiciones aún necesitan un veredicto de explotabilidad, incluso cuando no hay nada que un pentesting automatizado pueda ejecutar de forma segura. Esta es la brecha que el pentesting automatizado no puede cerrar por sí solo.
Todos para uno. Uno para todas las exposiciones.
Aquí es donde las piezas encajan:
- La validación de explotabilidad determina si una exposición es realmente explotable en tu entorno, incluidos los CVE sin exploit funcional y los activos que la explotación en vivo no puede alcanzar de forma segura.
- La validación de controles de seguridad comprueba si tus controles de prevención y detección realmente bloquean, detectan o pasan por alto el ataque.
- El pentesting agéntico ejecuta exploits reales de forma segura y encadena exposiciones para mostrar hasta dónde puede progresar un atacante en tu entorno específico.
Estos métodos responden a preguntas diferentes en condiciones de exposición distintas. La preparación ante Mythos requiere las tres capacidades, integradas en una única plataforma con el mismo objetivo: validar exposiciones en tu entorno único. Esto no significa que debas usar siempre las tres contra cada exposición, sino aplicar cada método donde mejor encaje y dejar que la evidencia contribuya al mismo proceso de decisión. Estas tres piezas se vuelven aún más potentes cuando operan como un único programa: un hallazgo puede desencadenar el paso de validación que realmente necesita, la nueva evidencia puede cambiar la prioridad de remediación y las correcciones pueden revalidarse en lugar de desaparecer en un ticket cerrado. Así se mantienen conectadas la explotabilidad, la eficacia de los controles y la evidencia de rutas de ataque, en lugar de dejarlas en flujos de trabajo separados. Esto también apunta a la nota de investigación de Gartner de mayo: hacia rutas de ataque validadas, respuesta basada en decisiones y reducción de exposición integradas en flujos de trabajo operativos. Este es también el modelo de trabajo detrás de nuestro Validation Summit '26.
Qué ven los expertos en seguridad y cómo las empresas líderes ponen en práctica la validación
El 14 y 15 de octubre, Picus Security organizará The Validation Summit '26 para reunir una visión independiente de lo que ha cambiado, nuestro enfoque de validación y lecciones de líderes de seguridad que ya lo han puesto en práctica. Mikko Hyppönen abrirá explicando por qué este cambio es diferente a los anteriores. Luego, el CTO de Picus, Volkan Ertürk, expondrá cómo debe ser la validación de seguridad cuando los atacantes impulsan sus ataques con IA, y por qué la validación de explotabilidad, la validación de controles de seguridad y el pentesting agéntico funcionan mejor juntos que por separado. Después, el equipo de Picus mostrará el flujo de validación en vivo con una vulnerabilidad recién divulgada: comienza sin parche y sin exploit funcional, pasa por la validación antes de que exista un PoC, prueba el exploit contra controles en vivo una vez que aparece, y luego revalida después de la corrección. A continuación, líderes de seguridad de Chanel, Atlassian y la NFL debatirán cómo se ve esto dentro de entornos empresariales reales: cómo los equipos de seguridad maduros están adaptando sus programas de validación, qué han cambiado y los éxitos y fracasos que han experimentado en el camino. Dos horas. Un plano de validación. Únete a nosotros en el Picus Validation Summit '26.
Nota: Este artículo fue escrito por Sila Ozeren Hacioglu, ingeniera de investigación de seguridad en Picus Security.
Deja una respuesta