Gestión de vulnerabilidades

Un informe de escaneo es el comienzo de una decisión. Identifica posibles debilidades en activos concretos; un analista comprueba esos hallazgos, los pone en contexto y hace un seguimiento del trabajo hasta verificar el resultado. Este proceso repetitivo es la gestión de vulnerabilidades.

Identifica el problema con precisión

Una vulnerabilidad es una debilidad del software, el hardware, la configuración o un proceso. Una amenaza es una persona, un grupo o un evento que podría causar daños. Un código o técnica de explotación aprovecha una debilidad. El riesgo combina la probabilidad de daño con su impacto en la confidencialidad, la integridad o la disponibilidad. Una actualización pendiente es una vulnerabilidad; los atacantes que la utilizan para robar registros son la amenaza que actúa mediante un código o técnica de explotación.

Los hallazgos también incluyen contraseñas predeterminadas, almacenamiento público, configuraciones de cifrado obsoletas y productos al final de su vida útil que ya no reciben actualizaciones de seguridad. Una vulnerabilidad de día cero aún no tiene corrección porque el proveedor no ha tenido tiempo de responder. Un ataque de día cero utiliza ese fallo; su divulgación por sí sola no demuestra que se hayan producido ataques. Hasta que existan comprobaciones y correcciones, las mitigaciones y la detección ayudan a proteger los sistemas afectados.

Avanza desde el descubrimiento hasta el cierre

1. Identifica los activos: determina qué existe y quién es su propietario.
2. Descubre las debilidades: escanea los activos y recopila otros informes.
3. Analiza y valida: comprueba que cada hallazgo sea aplicable.
4. Prioriza: combina la gravedad técnica, las evidencias de amenaza y el contexto del negocio.
5. Trata: elimina la debilidad, reduce su riesgo u obtén la aceptación formal del riesgo.
6. Verifica e informa: confirma el resultado, registra las evidencias de cierre y mide el trabajo.

Supón que un escáner señala un servicio desactualizado en un portal de empleados. El analista comprueba la compilación instalada y el aviso del proveedor. El propietario del portal explica su función para el negocio. Un desarrollador actualiza el servicio mediante la gestión de cambios. Una nueva comprobación confirma la compilación corregida y el funcionamiento del portal. Si los nuevos servidores siguen restableciendo la compilación antigua, esa evidencia lleva al programa a revisar el inventario de despliegue y las plantillas.

Interpreta los identificadores

Las autoridades de numeración CVE asignan identificadores como CVE-2014-0160, el fallo Heartbleed en OpenSSL. El año forma parte del identificador, no es una fecha fiable de descubrimiento o corrección. Los fallos internos y las configuraciones incorrectas pueden requerir acción sin tener un CVE.

Asigna una tarea clara a cada función

El equipo de seguridad descubre, valida, prioriza y hace el seguimiento. Los administradores y desarrolladores aplican los cambios; los propietarios de los activos responden por el riesgo de los sistemas. Las autoridades de cambios aprueban los cambios en producción, mientras que los responsables del riesgo autorizados aprueban las excepciones. Una evaluación amplia de vulnerabilidades, una prueba de penetración autorizada que demuestra el impacto y los informes válidos de programas de recompensas por errores alimentan este mismo proceso de tratamiento. Un escaneo sin hallazgos solo describe las comprobaciones que se ejecutaron correctamente; los activos omitidos y los fallos desconocidos siguen necesitando atención.

Un inventario indica al programa qué debe evaluar y da sentido a las cifras de cobertura. Incluye servidores, portátiles, equipos de red, aplicaciones, recursos en la nube y dominios y certificados expuestos a internet. El software y las bibliotecas importan tanto como las máquinas.

Registra la identidad y la importancia para el negocio

Cada registro necesita un identificador estable, nombre de host, direcciones, propietario, equipo de soporte, ubicación o cuenta de nube, versiones del sistema operativo y del software, función para el negocio, clasificación de datos, criticidad, exposición y estado del ciclo de vida. Utiliza un identificador de instancia en la nube o de agente para seguir una máquina cuando cambien sus direcciones. Una dirección IP por sí sola puede señalar otro dispositivo después de que cambie una concesión DHCP.

Asigna un nivel de criticidad junto con el propietario. En un esquema de ejemplo, el nivel 1 cubre los servicios de pago y los sistemas de identidad, el nivel 2 cubre los servicios internos importantes y el nivel 3 cubre los laboratorios de bajo impacto. El nivel describe el daño causado por la pérdida de confidencialidad, integridad o disponibilidad. Un sistema difícil de parchear no es menos crítico porque resulte incómodo corregirlo.

Concilia varias fuentes

Una base de datos de gestión de la configuración (CMDB) registra los activos gestionados, pero el descubrimiento suele revelar recursos que no contiene. Compárala con agentes de dispositivos finales, servicios de directorio, DNS y DHCP, registros de compras, observaciones pasivas de la red y API de nube. Compara los registros individuales antes de interpretar las diferencias entre los totales. Investiga un activo que solo aparezca en una fuente: puede ser nuevo, estar retirado, duplicado o ser desconocido para el área de TI.

El descubrimiento activo envía sondas para encontrar equipos que responden. En una red autorizada, nmap -sn 10.20.0.0/24 realiza el descubrimiento de equipos en un rango que contiene 256 direcciones. La identificación mediante huellas infiere detalles del dispositivo o del sistema operativo a partir de las respuestas; -O de Nmap solicita la detección del sistema operativo. Trata una identidad inferida como una evidencia que debes confirmar. El descubrimiento pasivo observa el tráfico existente y ayuda a encontrar dispositivos frágiles sin enviarles sondas, aunque puede omitir los dispositivos que no generan tráfico.

Calcula la brecha real

Una ejecución de descubrimiento encuentra 212 equipos activos. La CMDB contiene 195 registros y la comparación equipo por equipo confirma que los 195 están en el conjunto descubierto. Por tanto, hay 17 equipos activos sin registrar. Asigna a cada uno un propietario y un registro, o retíralo mediante el proceso adecuado.

El escaneo de vulnerabilidades comprueba 180 de esos 212 equipos activos en la misma semana:

Los 32 equipos no comprobados siguen siendo una brecha de cobertura. Si algunos equipos de la CMDB hubieran estado ausentes del descubrimiento, restar simplemente los totales habría ocultado parte de la discrepancia. Mantén la coherencia del período y la población al comparar la cobertura.

Detecta los recursos que aparecen y desaparecen

La tecnología de la información no supervisada es tecnología instalada sin conocimiento del área de TI. Puede quedar fuera de la aplicación normal de parches y los escaneos. Las instancias y los contenedores en la nube pueden existir durante minutos, por lo que un escaneo de red mensual puede omitir toda su vida útil. Alimenta el inventario con las API del proveedor y exige etiquetas de recursos útiles, incluidos el propietario, el entorno y la clasificación de datos. Evalúa las imágenes y plantillas utilizadas para iniciarlos.

Para una aplicación, una lista de materiales de software (SBOM) enumera sus componentes y bibliotecas. Cuando se divulgue un fallo de una biblioteca, relaciona las versiones afectadas del componente con las aplicaciones que las contienen. Mantén las actualizaciones del inventario a medida que los recursos se crean, trasladan y retiran; una hoja de cálculo creada una sola vez no puede describir durante mucho tiempo un entorno cambiante.

Una política útil indica a los equipos qué debe hacerse, quién decide y cuándo vence el trabajo. Relaciona los hallazgos de seguridad con las prioridades de negocio de la organización. La dirección la aprueba y el programa mide si se cumple.

Distingue los términos de riesgo

El riesgo inherente es el riesgo anterior a los controles. El riesgo residual permanece después de los controles. El apetito de riesgo es la cantidad y el tipo de riesgo que la dirección está dispuesta a aceptar para alcanzar sus objetivos. Las decisiones sobre una excepción utilizan el riesgo restante, no solo la puntuación de gravedad original.

Un modelo cualitativo sencillo multiplica la probabilidad y el impacto, cada uno valorado del 1 al 5:

Un servicio expuesto a internet con un fallo de ejecución remota de código recibe una probabilidad de 4 y un impacto de 5, lo que da 20 sobre 25. Una regla probada de cortafuegos de aplicaciones web reduce la probabilidad evaluada a 2 mientras el impacto sigue siendo 5, lo que da un riesgo residual de 10. Según una política de ejemplo que exige la corrección en un plazo de 30 días cuando el riesgo residual supera 8, el servicio sigue necesitando una corrección en 30 días. El control redujo el riesgo sin alcanzar el umbral de aceptación de esa política.

Estas valoraciones organizan los juicios; no son probabilidades medidas. Registra los motivos de las valoraciones de probabilidad e impacto para que quien revise la decisión después pueda entenderla.

Redacta reglas medibles

La política define el alcance de los activos, la frecuencia de escaneo, las responsabilidades, las reglas de gravedad y prioridad, los plazos de corrección, las excepciones, el escalamiento de la respuesta y los informes. Los estándares especifican los requisitos técnicos y los procedimientos describen cómo los aplican los equipos. La gobernanza consiste en aplicar, medir y revisar estas reglas.

Un calendario ilustrativo de SLO es: Crítica 15 días, Alta 30, Media 90 y Baja 180. Indica cuándo empieza a contar el plazo. Los contratos y los requisitos aplicables pueden establecer plazos más estrictos. Añade reglas de explotación y exposición para que un fallo de pasarela con explotación conocida pueda activar trabajo de emergencia en lugar de esperar al plazo habitual de gravedad Alta.

Planifica el trabajo que se bloquea

Una corrección puede interrumpir un proceso de negocio, romper una dependencia o requerir la certificación del proveedor. Los productos heredados pueden no tener parche, mientras que un SLA o un memorando de entendimiento puede limitar cuándo se realizan cambios. La política necesita vías para ventanas de mantenimiento adicionales, controles compensatorios verificados y excepciones de duración limitada. Un plazo incumplido se comunica al propietario del activo, después a su responsable y luego al comité de riesgos, según la vía de escalamiento definida.

Relaciona la política con marcos establecidos

El control 8.8 del anexo A de ISO/IEC 27001:2022 aborda la gestión de vulnerabilidades técnicas. El control 7 de CIS Critical Security Controls v8.1 cubre la gestión continua de vulnerabilidades; los controles 1 y 2 respaldan los inventarios de activos y software. El requisito 11.3 de PCI DSS v4.0.1 aborda los escaneos de vulnerabilidades en el entorno de tarjetas de pago, y NIST SP 800-40 Rev. 4 orienta la planificación de parches en la empresa. Haz un seguimiento del cumplimiento de los plazos y de los riesgos vencidos para que la revisión de la política se base en el desempeño real.

Cada tipo de escaneo describe una parte diferente de la evaluación. La ubicación, el acceso, el despliegue y la actividad son elecciones separadas: un escaneo interno puede ser autenticado y sin agentes, mientras que un agente puede evaluar un portátil fuera de la oficina. Selecciona una combinación adecuada para el activo y la información necesaria.

Decide dónde y cómo buscar

Utiliza tanto la perspectiva interna como la externa. Un escaneo externo muestra la exposición inicial; la evaluación interna ayuda a encontrar vías disponibles después de un compromiso o para una persona interna. Las comprobaciones autenticadas suelen reducir los falsos positivos y los falsos negativos porque inspeccionan directamente las compilaciones de paquetes y la configuración. Utiliza cuentas dedicadas al escaneo con los mínimos privilegios que permitan una evaluación exhaustiva. Almacena las credenciales en la bóveda del escáner, supervísalas y rótalas.

Adapta el despliegue al activo

Los agentes envían a una consola información recopilada localmente. Son adecuados para portátiles que rara vez se conectan a la red corporativa y equipos en la nube compatibles. Desplegar, actualizar y supervisar los agentes sigue siendo parte del programa.

Los escaneos de red sin agentes no necesitan software instalado y son adecuados para dispositivos como impresoras y conmutadores. Necesitan conectividad de red y, para obtener evidencias locales, credenciales. Algunas herramientas de nube también evalúan instantáneas de disco mediante las API del proveedor sin agentes en los equipos. Comprueba el acceso realmente conseguido, no solo la etiqueta del escaneo elegido.

Distingue la actividad y el propósito

Los escaneos activos envían sondas y analizan las respuestas. La evaluación pasiva observa el tráfico existente mediante un puerto de duplicación o un dispositivo de copia pasiva de tráfico de red. La observación pasiva evita la carga de las sondas en sistemas frágiles, pero omite los servicios que no generan tráfico durante el período de observación.

Un escaneo de descubrimiento mapea equipos, puertos, servicios y posibles sistemas operativos. Un escaneo de vulnerabilidades comprueba si hay debilidades conocidas. Un escaneo de conformidad con la línea base compara la configuración con un requisito como un CIS Benchmark o un estándar interno de endurecimiento. Por ejemplo, puede informar de que la longitud mínima de contraseña es 8 mientras que la línea base aprobada exige 14. Encontrar un puerto abierto por sí solo no demuestra que exista una vulnerabilidad.

En el software, el análisis estático inspecciona el código fuente o los binarios sin ejecutarlos. El análisis dinámico observa un programa en ejecución. El escaneo web y las pruebas con entradas malformadas o variables son dinámicos; estas pruebas introducen datos malformados o aleatorios y buscan fallos como cierres inesperados. La ingeniería inversa estática puede utilizar un desensamblador para examinar el código compilado.

Aplica las opciones

Un sitio web público necesita una perspectiva de red externa y pruebas web autenticadas de sus funciones de usuario. Los agentes son adecuados para portátiles que suelen estar fuera de las instalaciones. Las comprobaciones internas autenticadas son adecuadas para servidores Linux de centros de datos. Para los controladores de fábrica, empieza con supervisión pasiva y coordina con ingeniería cualquier comprobación activa previamente probada. El informe más breve puede deberse simplemente a una menor visibilidad: compara el alcance y la autenticación antes de interpretar su tamaño como una buena noticia.

Un plan de escaneo debe producir evidencias útiles sin interrumpir los sistemas que evalúa. El alcance, el momento, el acceso y los límites de carga de trabajo deben estar en el plan antes de ejecutar el escáner. Evalúa solo los sistemas y las cuentas cubiertos por una autorización escrita y sigue las reglas de pruebas del proveedor de alojamiento.

Establece el alcance y los límites operativos

Registra los rangos de direcciones, nombres de host, cuentas de nube, aplicaciones, contactos, ventanas aprobadas y comprobaciones peligrosas excluidas. Coordínate con los operadores de sistemas y el equipo de operaciones de seguridad para que esperen las alertas del escaneo. Restringe el acceso al escáner y a sus informes: contienen credenciales y un mapa detallado de las debilidades.

Actualiza la fuente de vulnerabilidades o los complementos antes de cada ejecución. Limita los objetivos y las comprobaciones simultáneos para evitar saturar las conexiones o las CPU. Las credenciales incorrectas pueden bloquear cuentas, las sondas llenan los registros y activan las defensas, y las comprobaciones intrusivas pueden provocar fallos en servicios frágiles. Utiliza perfiles seguros para producción, desactiva las comprobaciones de denegación de servicio y escalona el trabajo de mayor carga fuera de las horas punta.

La profundidad del escaneo es una elección. Un perfil de descubrimiento tiene menos impacto operativo que un perfil profundo e intrusivo, pero también responde a menos preguntas. Prueba un perfil nuevo en sistemas representativos antes de ampliar su alcance. La frecuencia debe reflejar los cambios y la exposición: el escaneo interno mensual es una opción mínima habitual para un programa, mientras que la evaluación semanal o continua ofrece evidencias más actuales. Los cambios significativos y los avisos urgentes pueden requerir ejecuciones adicionales.

Llega a cada segmento de red

Un escáner central detrás de un cortafuegos puede llegar a casi ningún equipo de una subred aislada. Coloca escáneres distribuidos o agentes en los segmentos pertinentes, o utiliza un acceso de escaneo de alcance restringido y duración limitada. Conserva la segmentación fuera de lo necesario y aprobado. Comprueba los equipos alcanzados y la autenticación correcta después de la ejecución para que las sondas bloqueadas no parezcan resultados sin hallazgos.

Aplica los requisitos de escaneo para tarjetas de pago

Para el entorno de datos del titular de la tarjeta, PCI DSS v4.0.1 exige escaneos internos al menos una vez cada tres meses. Los hallazgos de alto riesgo y críticos, según la clasificación de la entidad, deben resolverse y comprobarse mediante nuevos escaneos; la herramienta de escaneo debe utilizar información actualizada sobre vulnerabilidades. También se realizan escaneos internos después de cambios significativos.

El escaneo interno autenticado del requisito 11.3.1.2 es obligatorio desde el 31 de marzo de 2025. Utiliza privilegios de escaneo suficientes; documenta los sistemas que no pueden aceptar credenciales. El requisito de escaneo autenticado no se aplica a los escaneos separados tras cambios significativos del requisito 11.3.1.3. Los escaneos externos se realizan al menos una vez cada tres meses mediante un proveedor de escaneo aprobado por PCI SSC (ASV), con nuevos escaneos según sea necesario para obtener resultados satisfactorios. Los cambios significativos también requieren una evaluación externa conforme a la disposición separada del estándar sobre escaneos tras cambios.

Protege los procesos físicos

La tecnología operacional (OT) incluye sistemas que controlan equipos físicos. Los sistemas de control industrial (ICS) y los sistemas SCADA, de control de supervisión y adquisición de datos, suelen priorizar la seguridad física y la disponibilidad por encima de la profundidad del escaneo. Los controladores antiguos pueden responder mal a paquetes desconocidos. Prefiere la supervisión pasiva y las herramientas aprobadas por el proveedor; prueba en una réplica y obtén la aprobación de ingeniería para el trabajo activo durante las paradas planificadas.

Un plan de ejemplo escanea 10.20.0.0/24 con credenciales los sábados de 01:00 a 05:00, limita la concurrencia a 10 equipos, actualiza las fuentes el viernes y exporta los hallazgos a solicitudes. Añade escaneo externo semanal y supervisión pasiva de la fábrica. Los contactos de los operadores y las condiciones de parada permiten utilizar el plan cuando cambia el rendimiento durante una ejecución.

Empieza por la pregunta y después selecciona la herramienta. Mapear un rango de direcciones, evaluar una dependencia y comprobar si una defensa detecta un ataque son tareas diferentes. Los resultados de una herramienta necesitan validación aunque el nombre del producto sea conocido.

Encuentra equipos, servicios y debilidades conocidas

Nmap mapea puertos y servicios; -sV solicita la detección de versiones de servicios, -O solicita la detección del sistema operativo y el motor de scripts de Nmap permite comprobaciones adicionales. Angry IP Scanner ofrece un descubrimiento sencillo de equipos y puertos. Masscan escanea rápidamente grandes rangos de direcciones en busca de puertos abiertos, con pocos detalles sobre los servicios.

Nessus utiliza comprobaciones mediante complementos para evaluar vulnerabilidades conocidas. OpenVAS de Greenbone informa de debilidades con una calificación de calidad de la detección. Nuclei ejecuta plantillas YAML para comprobaciones específicas, incluidas las de servicios web y CVE. La selección de plantillas importa porque las comprobaciones difieren en su propósito y su impacto operativo.

Evalúa el comportamiento web

Un escáner de red puede encontrar un servidor web y problemas conocidos en sus componentes, mientras que las pruebas web autenticadas examinan el comportamiento de la aplicación. Los problemas de lógica de negocio siguen necesitando una validación cuidadosa del flujo de trabajo real.

Inspecciona recursos en la nube y artefactos de software

Prowler y ScoutSuite consultan la configuración de la nube mediante API e informan de problemas de postura de seguridad. Checkov analiza infraestructura como código, como definiciones de Terraform o Kubernetes. Trivy evalúa artefactos, incluidas imágenes de contenedores y repositorios, en busca de componentes vulnerables, configuraciones incorrectas y secretos expuestos, y puede generar SBOM.

Por ejemplo, un puerto de gestión abierto en una regla de Terraform requiere Checkov o Trivy antes del despliegue. Un depósito de almacenamiento público ya desplegado requiere una evaluación de la postura de seguridad en la nube. Una biblioteca incluida en un contenedor requiere un escaneo de la imagen o de la composición. Estos hallazgos pueden compartir propietario, pero necesitan evidencias diferentes.

Reconoce las funciones de las pruebas especializadas

Maltego construye grafos de relaciones a partir de datos de fuentes abiertas mediante transformaciones; Recon-ng organiza el reconocimiento modular. Ambos ayudan a descubrir la superficie de ataque externa. Metasploit Framework incluye módulos de explotación y evaluación auxiliar; Pacu se centra en pruebas de ataque en AWS. Las pruebas especializadas autorizadas pueden confirmar la explotabilidad, mientras que los analistas que realizan el trabajo habitual siguen necesitando evidencias y un registro del tratamiento.

GDB e Immunity Debugger inspeccionan programas en ejecución, memoria y registros. Ayudan a explicar los fallos encontrados mediante pruebas con entradas malformadas o variables. Atomic Red Team proporciona pequeñas pruebas vinculadas a MITRE ATT&CK y Caldera de MITRE automatiza la emulación de adversarios. Estas herramientas de simulación de intrusiones y ataques comprueban si los controles detectan o bloquean técnicas. Una prueba de detección satisfactoria aporta información sobre ese control; no demuestra que los paquetes instalados estén actualizados.

La gravedad ayuda a ordenar un informe, pero la evidencia explica por qué el escáner generó un hallazgo. Lee el activo afectado y la versión, configuración o respuesta detectada antes de asignar el trabajo. Una solicitud útil debe dar a su responsable suficiente detalle para reproducir y corregir el problema.

Lee el hallazgo como un registro

Busca el título, el identificador del complemento o de la comprobación, las referencias CVE, la gravedad, la versión y el vector CVSS, el activo, el puerto, el protocolo, el servicio, la evidencia de detección, la solución recomendada y las fechas de primera y última detección. Un identificador de complemento identifica la comprobación del escáner; no es intercambiable con un identificador CVE.

Para un problema web, inspecciona la URL, el parámetro, la solicitud, la respuesta y la confianza. Un informe como «Secuencias de comandos entre sitios reflejadas en el parámetro q de /search» identifica una entrada de la aplicación que se debe investigar. Un resultado de nube necesita la cuenta, la región, el identificador del recurso, el identificador de la comprobación y PASS o FAIL, para que el propietario correcto del recurso pueda actuar.

Interpreta con precisión los estados de los puertos

Considera estos resultados de detección de servicios:

22/tcp   open     ssh    OpenSSH 7.4
80/tcp   open     http   Apache httpd 2.4.6 ((CentOS))
443/tcp  closed   https
3306/tcp filtered mysql

SSH y HTTP están expuestos a este escáner. Según esta observación, nada escucha en 443. El puerto 3306 sigue siendo incierto porque un filtro bloquea la evidencia necesaria. Los banners sugieren un entorno CentOS antiguo; confirma el sistema operativo y su estado de soporte con datos autenticados antes de registrar un hallazgo de fin de vida útil. CentOS Linux 7 llegó al final de su vida útil el 30 de junio de 2024; también es necesario comprobar si hay acuerdos de soporte ampliado.

Utiliza la confianza para planificar la validación

La calidad de la detección de Greenbone (QoD) califica la evidencia que respalda un resultado. Por ejemplo, 97 % para comprobaciones autenticadas de paquetes, 80 % para banners que informan del nivel de parche y 30 % para banners que no lo hacen. Los informes suelen ocultar por defecto los resultados inferiores al 70 %. Burp clasifica la confianza como cierta, firme o tentativa. Un hallazgo grave con evidencias débiles necesita validación rápida; la confianza y la gravedad responden a preguntas distintas.

Convierte filas repetidas en trabajo útil

Una actualización del proveedor puede corregir muchos CVE. Si 900 de 1240 filas de hallazgos se resuelven mediante cinco actualizaciones, agrupa las solicitudes por actualización, responsable y lista de equipos afectados. Conserva los vínculos a los hallazgos individuales para que la validación pueda confirmar cada instancia afectada.

Compara los escaneos con estados como nuevo, corregido, reabierto y persistente. Antes de aceptar una gran caída de los hallazgos, compara los equipos accesibles, la autenticación correcta y la duración del escaneo. Una rotación de contraseña que impide al escáner iniciar sesión puede eliminar hallazgos locales del informe sin eliminar ninguna debilidad. Los resultados informativos también pueden revelar servicios desconocidos o certificados próximos a vencer, así que inclúyelos en la revisión.

Un resultado positivo y una vulnerabilidad real son dos cosas distintas. La validación comprueba si el hallazgo es aplicable al activo. Revisar el estado operativo del escaneo también ayuda a encontrar debilidades que el escáner no notificó.

Clasifica los cuatro resultados

Los falsos negativos dejan debilidades reales fuera de la lista de trabajo. Entre las causas habituales están la autenticación fallida, las sondas bloqueadas, los equipos apagados, las omisiones en el alcance, las fuentes desactualizadas, el software personalizado no reconocido y los fallos sin una comprobación disponible. Contrasta el inventario, la cobertura de escaneo, los registros de autenticación y las fuentes independientes cuando un informe parezca inesperadamente libre de hallazgos.

Valida desde la evidencia hasta la conclusión

1. Lee la evidencia de la comprobación y la condición que indica como vulnerable.
2. Obtén la compilación real del paquete o la configuración mediante acceso autenticado.
3. Compárala con el aviso pertinente del proveedor y la compilación corregida.
4. Comprueba si están presentes la función afectada y las condiciones correspondientes.
5. Correlaciona las evidencias de los agentes o dispositivos finales y registra la conclusión.

Un banner puede estar desactualizado o incompleto, y un proxy puede responder por otra máquina. Una identificación incorrecta del sistema operativo mediante huellas puede llevar a realizar comprobaciones para el producto equivocado. La confirmación manual, cuando sea necesaria, corresponde a pruebas autorizadas con un plan operativo adecuado.

Reconoce una corrección adaptada a una versión anterior

Una distribución puede corregir una rama antigua del software y conservar su número de versión del proyecto original. Esto es una adaptación de una corrección a una versión anterior. Supón que un banner muestra OpenSSH_7.4, mientras que la corrección del proyecto original apareció en la versión 7.7. Esa comparación por sí sola pasa por alto las correcciones específicas de la distribución.

En una distribución de ejemplo, una comprobación autenticada devuelve la compilación del paquete openssh-7.4p1-23, y el aviso del proveedor indica que openssh-7.4p1-21 es la compilación corregida para la misma versión con soporte. La compilación 23 contiene la corrección adaptada, por lo que el hallazgo específico del CVE es falso. Si las evidencias autenticadas también confirman un sistema operativo sin soporte, su hallazgo de fin de vida útil sigue siendo real. Cerrar una afirmación no elimina todos los riesgos del equipo.

Suprime de forma acotada y revisa

Para un falso positivo confirmado, registra la comprobación, el activo, el motivo, las evidencias que lo respaldan y la fecha de revisión. Limita la supresión a esa comprobación concreta en ese activo concreto. Una desactivación global podría ocultar hallazgos reales en otros lugares, y un cambio posterior de configuración podría invalidar la conclusión anterior.

Una afirmación como «ya aplicamos el parche» necesita verificación: puede haber un reinicio pendiente o quedar una segunda copia instalada. Comprueba la versión o la configuración efectiva en lugar de aceptar una acción de mantenimiento que alguien recuerda.

Utiliza el denominador correcto

Si 6 de 50 hallazgos notificados son falsos, el 12 % de la muestra notificada es falso. La tasa estadística de falsos positivos, en cambio, divide los falsos positivos entre todos los casos realmente negativos:

La muestra de informes positivos no proporciona un recuento de verdaderos negativos, por lo que no puede establecer esa tasa. Indica exactamente qué mide una métrica; mejorar las credenciales, el alcance, las fuentes de actualización y la ubicación de los escáneres mejora las evidencias que respaldan tanto los resultados positivos como los negativos.

El Sistema común de puntuación de vulnerabilidades (CVSS) describe la gravedad técnica en una escala de 0,0 a 10,0. Registra la fuente, la versión y el vector de la puntuación para que su significado quede claro. FIRST mantiene CVSS; la prioridad para el negocio sigue necesitando la exposición, las evidencias de explotación y el contexto del activo.

Interpreta la explotabilidad y el impacto

Un escape de una máquina virtual puede cruzar desde la autoridad de seguridad del sistema invitado hasta el hipervisor. Las secuencias de comandos entre sitios pueden afectar a la autoridad del navegador de la víctima. El alcance no significa el número de máquinas incluidas en el escaneo.

El vector de Heartbleed es CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Describe acceso por red, complejidad baja, ausencia de privilegios o interacción requeridos, alcance sin cambios e impacto alto en la confidencialidad. Su puntuación base es 7,5. AV:N describe el método de acceso al fallo; no indica si tu servidor concreto está expuesto a internet.

Utiliza las ponderaciones para el alcance sin cambios

Las ponderaciones de AV son N 0,85, A 0,62, L 0,55, P 0,20. AC es L 0,77 o H 0,44; UI es N 0,85 o R 0,62. PR es N 0,85, L 0,62 o H 0,27 para el alcance sin cambios; el alcance cambiado utiliza 0,68 para L y 0,50 para H. Cada ponderación de impacto es Alta 0,56, Baja 0,22 o Ninguna 0.

Cuando el impacto es positivo, limita la suma a 10 y redondea hacia arriba a una cifra decimal. Un impacto cero da una puntuación base de cero. Para AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, ISS es 0,914816, el impacto es aproximadamente 5,8731 y la explotabilidad es aproximadamente 3,8870. La suma es aproximadamente 9,7602, por lo que la puntuación base es 9,8.

El alcance cambiado utiliza una expresión de impacto diferente y un multiplicador de 1,08 para la puntuación base:

Utiliza la calculadora específica de la versión para aplicar estas reglas sin mezclar fórmulas.

Interpreta el resultado

Los intervalos de gravedad son Ninguna 0,0, Baja 0,1–3,9, Media 4,0–6,9, Alta 7,0–8,9 y Crítica 9,0–10,0. Exigir privilegios bajos cambia el ejemplo de 9,8 con alcance sin cambios a 8,8; añadir acceso local da 7,8; cambiar solo la complejidad del ataque a Alta da 8,1. Estos valores describen diferencias técnicas, no probabilidades de explotación. Si dos fuentes discrepan, compara los vectores y los juicios de las fuentes antes de elegir qué puntuación registrar.

Una puntuación base describe las características técnicas del fallo. La información sobre amenazas cambia con el tiempo y el mismo fallo puede tener una importancia distinta en dos despliegues. CVSS proporciona grupos de métricas separados para estos ajustes, con reglas diferentes en las versiones 3.1 y 4.0.

Ajusta v3.1 según el tiempo

El grupo Temporal de v3.1 contiene la madurez del código de explotación, el nivel de corrección y la confianza en el informe. Sus multiplicadores son:

No definida cuenta como 1. Multiplica la puntuación base por los tres valores y redondea hacia arriba a una cifra decimal. Para una puntuación base de 9,8 con E:U, RL:O, RC:C:

Si la madurez de la explotación pasa a Alta mientras la corrección oficial sigue disponible, el producto pasa a ser 9,31 y se redondea hacia arriba a 9,4. Los ajustes temporales pueden reducir la puntuación base o dejarla sin cambios; sus multiplicadores no pueden aumentarla por encima de la base.

Describe el entorno local

Las métricas del Entorno de v3.1 incluyen los requisitos de confidencialidad, integridad y disponibilidad (CR, IR, AR), además de métricas base modificadas como MAV y MPR. Las ponderaciones de los requisitos son Alto 1,5, Medio 1,0, Bajo 0,5 y No definido 1,0. Documenta las evidencias del despliegue que respaldan cada ajuste.

En el ejemplo de Heartbleed, el requisito de confidencialidad Alto da una puntuación del entorno de 9,3, mientras que Bajo da 5,7. Un fallo con puntuación base de 9,8 y vector de ataque modificado a Adyacente da 8,8. Utiliza la calculadora completa del entorno; su cálculo no consiste en multiplicar la puntuación base por la ponderación de un requisito.

Interpreta los cambios de CVSS 4.0

La versión 4.0 añade requisitos del ataque (AT) para condiciones de despliegue o ejecución, como una condición de carrera. La interacción del usuario pasa a ser Ninguna, Pasiva o Activa. El alcance se sustituye por impactos separados en la confidencialidad, la integridad y la disponibilidad del sistema vulnerable (VC, VI, VA) y de los sistemas subsiguientes (SC, SI, SA).

Los grupos son Base, Amenaza, Entorno y Suplementarias. La madurez de la explotación del grupo Amenaza puede ser Atacada, Prueba de concepto, Sin informar o No definida; No definida se puntúa como Atacada. Los requisitos del entorno toman por defecto el valor Alto cuando están No definidos, y las métricas modificadas de integridad y disponibilidad de sistemas subsiguientes pueden identificar impactos en la seguridad física. Los campos suplementarios, como Seguridad física, Automatizable, Recuperación, Densidad de valor, Esfuerzo de respuesta y Urgencia del proveedor, añaden contexto sin cambiar la puntuación.

Conserva las etiquetas

Utiliza CVSS-B, CVSS-BT, CVSS-BE o CVSS-BTE para mostrar los grupos de puntuación utilizados. La versión 4.0 calcula las puntuaciones mediante tablas de consulta, así que utiliza la calculadora de FIRST. El ejemplo de Heartbleed de FIRST es 8,7 CVSS-BT, frente a 7,5 en v3.1; su ejemplo de XSS reflejadas en Zimbra es 5,1 en v4.0 y 6,1 en v3.1. Un cambio de versión puede cambiar la cifra sin cambiar el software ni su despliegue.

La gravedad describe el daño potencial en determinadas condiciones técnicas. Las evidencias de explotación indican si los atacantes están utilizando un fallo o es probable que lo utilicen pronto. Estas señales complementan CVSS y el contexto del negocio; ninguna lista por sí sola describe todas las vulnerabilidades.

Distingue la evidencia de la predicción

La Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos (CISA) mantiene el catálogo de vulnerabilidades explotadas conocidas (KEV). La inclusión requiere un CVE asignado, evidencias fiables de explotación en situaciones reales e instrucciones claras de corrección. Las entradas también identifican el uso conocido en campañas de ransomware. La ausencia de KEV deja abierto el estado de explotación; los nuevos ataques o las debilidades sin CVE pueden no aparecer allí.

El Sistema de puntuación de predicción de explotación (EPSS) de FIRST estima la probabilidad de que se observe actividad de explotación de un CVE publicado en los próximos 30 días. Las puntuaciones van de 0 a 1 y se actualizan diariamente. El percentil indica la posición relativa entre los CVE puntuados.

En un registro diario ilustrativo, EPSS 0,10 y percentil 0,88 significan una probabilidad estimada del 10 % de actividad de explotación y una puntuación igual o superior a la del 88 % de los CVE puntuados. El percentil no es una probabilidad de explotación del 88 %, y la puntuación no es la probabilidad de que tu propio servidor se vea comprometido.

Evalúa la solidez de la señal

Una prueba de concepto publicada muestra que existe un método de explotación. La preparación de recursos de ataque convierte un método en herramientas fiables y utilizables. La explotación confirmada en situaciones reales, incluido su uso en campañas de ransomware, es una evidencia más sólida de que hay que actuar ahora. Sigue los avisos de proveedores, la inteligencia de amenazas, los centros de intercambio y análisis de información y las actualizaciones del catálogo. Una puntuación EPSS baja puede cambiar cuando llega nueva información.

Supón que el hallazgo A tiene CVSS 9,8, EPSS 0,004 y no figura en KEV, y afecta a un servidor de pruebas interno. El hallazgo B tiene CVSS 7,5, EPSS 0,94 y figura en KEV, y afecta a una pasarela VPN expuesta a internet. Prioriza B: combina ataques confirmados, acceso directo y una función de acceso crítica. Programa A dentro del plazo de la política en lugar de retirarlo de la lista de trabajo.

Utiliza árboles de decisión para actuar

La categorización de vulnerabilidades específica para las partes interesadas (SSVC) procede del Instituto de Ingeniería de Software de la Universidad Carnegie Mellon. El árbol de CISA considera la explotación, el impacto técnico, la posibilidad de automatización, la prevalencia para la misión y el impacto en el bienestar público. Sus decisiones son Seguimiento, Seguimiento, Atención y Actuación*, desde el seguimiento normal hasta la acción coordinada urgente. Aplica el árbol real; conocer una sola entrada no basta para inventar su resultado.

La Directiva Operativa Vinculante 26-04 de CISA, emitida el 10 de junio de 2026, sustituyó a la BOD 22-01. Obliga a las agencias civiles del poder ejecutivo federal de Estados Unidos respecto de los sistemas incluidos en su alcance y basa los plazos en la exposición pública, la presencia en KEV, la automatización de la explotación y el control técnico parcial o total. Otras organizaciones pueden utilizar KEV voluntariamente. La transición de la directiva exige que las agencias comiencen a aplicar sus nuevos plazos de evaluación y corrección a más tardar el 7 de diciembre de 2026.

Responde cuando no existe un parche

Para una vulnerabilidad de día cero, aplica las mitigaciones del proveedor, restringe el servicio afectado y aumenta la detección y la supervisión. Cuando aparezca una corrección, priorízala según la gravedad, la exposición y las evidencias de explotación. Si se notifican ataques, escala la respuesta rápidamente e investiga un posible compromiso mediante el proceso de respuesta a incidentes. EPSS cubre CVE; evalúa los fallos del código desarrollado internamente y las configuraciones incorrectas mediante sus propias evidencias.

Una prioridad indica a un responsable con qué rapidez debe actuar y por qué. Comienza con un hallazgo validado y después combina la gravedad técnica, las evidencias de explotación, la accesibilidad, el valor del activo, los controles existentes y la disponibilidad del tratamiento. Una puntuación por sí sola no puede describir las consecuencias de un fallo para el negocio.

Evalúa el activo y su vía de ataque

Los activos externos son accesibles desde internet. A los activos internos puede acceder un atacante después de entrar en la red o una persona interna. Los activos aislados tienen menos vías de acceso, pero los dispositivos de mantenimiento y las conexiones de soporte aún pueden cruzar la separación.

El valor del activo incluye el nivel de criticidad, la clasificación de datos, el alcance normativo y las dependencias. Un proveedor de identidad puede contener directamente pocos datos de clientes, pero controlar el acceso a muchos otros sistemas. Revisa los efectos en los servicios que dependen del activo vulnerable, no solo en el propio equipo.

Considera eficaz un control compensatorio solo cuando bloquee la vía pertinente y se haya probado. Un cortafuegos de aplicaciones web en modo de solo detección registra los ataques, pero no los detiene. Una regla de segmentación que sigue permitiendo el acceso al servicio vulnerable desde las redes de usuarios deja esa vía abierta.

Aplica una política en orden

Considera esta política de ejemplo, aplicada desde P1 hacia abajo:

F1 es un fallo de 9,8 en una máquina virtual de laboratorio aislada, sin explotación conocida y con EPSS 0,02. No cumple P1 ni P2, por lo que es P3. F2 es un fallo de 7,5 en un servidor web externo y figura en KEV: P1. F3 es un fallo de inyección de 6,5 en un portal externo de nivel 1, con una prueba de concepto pública y EPSS 0,20: P2 por el umbral de EPSS. F4 tiene 8,8 en un servidor de archivos interno, con EPSS 0,15 y un parche: también es P2 por EPSS.

Trabaja primero en F2. Dentro de P2, la exposición externa a clientes de F3 lo sitúa antes que F4 en este ejemplo. F1 sigue programado. Una ordenación numérica por CVSS habría seleccionado primero el fallo de laboratorio de baja exposición y retrasado un servicio público con explotación conocida.

Elige una acción disponible

Un parche permite programar la corrección. Si no existe una corrección, reduce la exposición y supervisa mientras haces un seguimiento de la corrección pendiente. Los productos al final de su vida útil necesitan un plan de sustitución y protección provisional. La falta de un parche cambia el tratamiento; no elimina la prioridad.

Considera las combinaciones en el mismo activo. Una fuga de información que expone nombres de usuario, controles de inicio de sesión débiles y un complemento antiguo pueden formar una vía más grave que cualquiera de las filas consideradas por separado. Revisa los hallazgos relacionados en conjunto antes de establecer el orden de trabajo.

Explica la decisión en la solicitud

Incluye la identidad del activo, el propietario, las evidencias del hallazgo, el tratamiento recomendado, la prioridad, el plazo y el motivo. Por ejemplo: «P1: el fallo confirmado tiene explotación conocida y el portal está expuesto a internet; completa la corrección dentro de la ventana de 3 días de la política de ejemplo». Conserva el razonamiento cuando el trabajo se agrupe entre varios equipos. Un probable falso positivo pasa por una validación rápida antes de basar en él una decisión firme de tratamiento.

Un tratamiento cambia la debilidad, la exposición o la decisión de negocio sobre el riesgo. Elige el tratamiento que aborde el hallazgo real y después planifica quién lo implementará y cómo se comprobará su efecto. La corrección es la opción predeterminada cuando es viable.

Distingue las opciones de tratamiento

Un control compensatorio cumple el propósito de un control exigido cuando este no puede aplicarse. Debe abordar el mismo riesgo, documentarse y verificarse. Una lista de conexiones permitidas en la segmentación puede proteger un servicio heredado al que no se pueden aplicar parches; una regla de cortafuegos de aplicaciones web puede proporcionar aplicación de parches virtuales contra un patrón de explotación conocido. La detección por sí sola sigue dejando abierta la vía de ataque.

Clasifica los controles de dos maneras

El tipo de control describe su implementación: los controles administrativos o de gestión incluyen políticas y decisiones de riesgo; los operativos son procesos humanos diarios como la gestión de cambios; los técnicos incluyen MFA y cortafuegos; los físicos incluyen cerraduras y lectores de tarjetas.

La función del control describe su tarea: los controles preventivos detienen eventos, los detectivos los encuentran, los correctivos eliminan debilidades o reparan daños y los de respuesta contienen un incidente mientras ocurre. Un escaneo de vulnerabilidades es detectivo. Un parche es correctivo. El aislamiento automatizado de dispositivos finales puede ser de respuesta. Una medida puede cumplir más de una función; el tipo y la función son clasificaciones separadas.

Planifica el cambio como una secuencia

1. Prueba la actualización o la configuración en un entorno parecido al de producción.
2. Implementa mediante un cambio aprobado y una ventana de mantenimiento.
3. Prepara las evidencias y los pasos de reversión, como una copia de seguridad o una instantánea, antes de cambiar producción.
4. Valida que el servicio funcione y que la debilidad original haya desaparecido.

Un fallo explotado activamente puede necesitar la aprobación de un cambio de emergencia. Una ventana de mantenimiento trimestral no puede sustituir sin más un plazo de 15 días de la política. Negocia una ventana adicional, utiliza actualizaciones graduales cuando la redundancia lo permita u obtén una excepción de duración limitada con controles verificados.

Gestiona una actualización bloqueada

Un módulo web tiene un fallo crítico de ejecución remota de código. El parche está disponible, pero la certificación de la aplicación tardará tres semanas y el plazo es de 15 días. Desactiva el módulo si no se utiliza. De lo contrario, prueba un parche virtual, restringe el acceso a las redes de socios necesarias y aumenta la supervisión. Registra el riesgo restante y obtén la excepción requerida; después instala la actualización certificada y vuelve a escanear.

Reduce también la superficie de ataque: descubre activos externos mediante escaneos del perímetro, DNS y registros de certificados; elimina los servicios no utilizados y los sistemas retirados. Las pruebas de controles de seguridad, las pruebas de penetración, la emulación de adversarios y los informes de recompensas por errores pueden revelar vías que necesitan atención. Eliminar un componente innecesario evita que se acumulen futuros hallazgos sobre él.

Algunos hallazgos reales no pueden corregirse dentro del plazo de la política. Una excepción hace visible el riesgo resultante y asigna la decisión a un responsable autorizado. Es una decisión controlada con fecha de finalización, no una forma de eliminar el trabajo difícil del panel de control.

Elige la estrategia de riesgo

La aceptación mantiene conscientemente el riesgo cuando el negocio necesita la actividad o los costes del tratamiento superan el beneficio previsto. La mitigación reduce la probabilidad o el impacto. La evitación pone fin a la actividad de riesgo. La transferencia traslada algunas consecuencias financieras mediante un contrato o un seguro, mientras que la responsabilidad permanece en la organización.

Un contrato o una póliza de seguro no impide que un código de explotación alcance un servicio sin parche. Revisa su alcance por separado de los controles técnicos. Una excepción rechazada sigue dejando una decisión pendiente: reforzar los controles, corregir o detener la actividad.

Redacta el registro de la excepción

Registra el activo y el hallazgo específicos, la justificación de negocio, el análisis de riesgos, los controles compensatorios, el riesgo residual, la persona autorizada que aprueba, la fecha de vencimiento y los hechos que activan una revisión anticipada. Vincula el registro al trabajo de corrección para que la solución permanente prevista siga siendo visible.

Un falso positivo significa que la debilidad notificada está ausente y se cierra con evidencias. Una excepción significa que la debilidad es real y que su riesgo residual se mantiene temporalmente. Suprimir un hallazgo verdadero como falso eliminaría precisamente el riesgo que la dirección necesita aprobar.

Ajusta la aprobación al riesgo restante

El responsable del riesgo aprueba en un nivel adecuado para el riesgo residual. Una excepción de riesgo bajo puede estar dentro de la autoridad de un propietario de activo, mientras que un riesgo residual alto puede requerir a la alta dirección o al responsable de seguridad de la información. El administrador que solicita retrasar el trabajo no aprueba esa solicitud por sí solo. El equipo de seguridad evalúa las evidencias y recomienda controles.

Compara el riesgo restante con el apetito de riesgo de la organización. Una decisión que supere la autoridad delegada debe elevarse o rechazarse. El hecho de que un sistema sea difícil de sustituir explica la solicitud; no demuestra que su riesgo sea aceptable.

Sigue un caso de sistema heredado

Un instrumento de laboratorio utiliza un controlador con Windows 7 cuyo software del proveedor no puede ejecutarse en un sistema más reciente. El soporte estándar finalizó el 14 de enero de 2020 y se ha presupuestado su sustitución para el próximo año. El equipo registra el controlador sin soporte como un hallazgo real y propone una red aislada, almacenamiento USB desactivado, una lista de aplicaciones permitidas y supervisión adicional.

La jefatura del departamento y la dirección de seguridad revisan el riesgo residual evaluado. La excepción vence después de seis meses o cuando se instale el reemplazo, lo que ocurra primero. El proyecto de sustitución sigue teniendo un responsable y unos hitos, aunque la fecha de revisión de la excepción llegue antes de su finalización prevista.

Reabre cuando cambien las condiciones

Un nuevo código de explotación, una entrada en KEV, un control compensatorio fallido o un cambio de exposición pueden invalidar la evaluación anterior antes del vencimiento. Revisa el riesgo en ese momento, no solo en la fecha prevista. Haz un seguimiento del número y la antigüedad de las excepciones, los vencimientos próximos y las correcciones permanentes pendientes. Evita las excepciones generales para entornos completos: los activos pueden tener distintas vías de ataque, responsables y consecuencias.

Una actualización instalada es una acción; una corrección verificada es un resultado. Cierra un hallazgo solo cuando las evidencias muestren que la debilidad original ha desaparecido y el servicio sigue funcionando. Haz un seguimiento del tiempo y la cobertura que respaldan esas evidencias para que los responsables puedan ver dónde permanece el riesgo.

Verifica la condición original

Vuelve a escanear los activos afectados con el mismo tipo de escaneo pertinente y credenciales operativas, o inspecciona directamente la compilación efectiva del paquete o la configuración. Confirma que la comprobación se ejecutó correctamente. Un inicio de sesión fallido no puede demostrar que se haya corregido una vulnerabilidad local. Valida también los controles compensatorios: comprueba que la nueva regla de acceso o el parche virtual realmente bloquee la vía pertinente.

Una corrección puede fallar porque hay un reinicio pendiente, solo se actualizó un nodo del clúster, una aplicación incluye su propia biblioteca antigua o un despliegue sobrescribe la configuración. Si las instancias de reemplazo vuelven a introducir el fallo repetidamente, actualiza la imagen maestra aprobada o la plantilla que las crea. Trata las reaperturas repetidas como evidencia de una causa raíz en el proceso de compilación o despliegue.

Utiliza estados de flujo de trabajo claros

Haz pasar el trabajo por estados como abierto, en curso, mitigado, riesgo aceptado, resuelto pendiente de verificación y cerrado. «Mitigado» significa que un control redujo el riesgo; «cerrado» necesita la evidencia de cierre pertinente. La integración del escáner con el sistema de solicitudes puede reducir los duplicados, pero los cambios de estado automatizados deben seguir las reglas de verificación satisfactoria y de excepciones.

Interpreta las métricas conjuntamente

Cinco hallazgos críticos se cierran después de 4, 9, 12, 20 y 30 días:

Con un SLO de 15 días, solo tres se cerraron a tiempo:

El promedio cumple los 15 días mientras que el 40 % de estos hallazgos incumplió el objetivo. Informa también de los hallazgos vencidos que siguen abiertos: un promedio del trabajo completado no indica la antigüedad que ha alcanzado un elemento sin resolver.

Escala el trabajo que necesita una decisión

Los intervalos de antigüedad, como 0–30, 31–60, 61–90 y más de 90 días, muestran el trabajo estancado. Compara la antigüedad de cada elemento con su propio plazo y después sigue la política desde el propietario hasta su responsable y el comité de riesgos. Un fallo cuya explotación acaba de comenzar puede necesitar un escalamiento inmediato antes de cualquier umbral de antigüedad.

Los equipos técnicos necesitan listas de equipos, evidencias y correcciones. Los responsables necesitan tendencias, los principales riesgos, el trabajo vencido y los recursos o decisiones necesarios. Una caída del total puede deberse a escaneos fallidos o al cierre rápido de elementos de bajo impacto, así que compara la cobertura y la antigüedad de los elementos de alta prioridad antes de considerarla un avance.

Los hallazgos de aplicaciones describen fallos en la forma en que el software gestiona datos, memoria, identidad o errores. Adapta la corrección al mecanismo. El OWASP Top 10:2025 es una lista de sensibilización: Control de acceso defectuoso, Configuración de seguridad incorrecta, Fallos en la cadena de suministro de software, Fallos criptográficos, Inyección, Diseño inseguro, Fallos de autenticación, Fallos de integridad del software o los datos, Fallos de registro y alerta de seguridad y Gestión incorrecta de condiciones excepcionales.

Evita que los datos se conviertan en instrucciones

La inyección ocurre cuando una entrada no fiable pasa a formar parte de una consulta o un comando. Utiliza consultas parametrizadas, validación mediante listas de valores permitidos y cuentas con el mínimo privilegio; evita las llamadas al intérprete de comandos construidas a partir de entradas del usuario. Las secuencias de comandos entre sitios (XSS) ejecutan un script suministrado por un atacante en el navegador de otro usuario. Las XSS reflejadas vuelven en una respuesta inmediata, las almacenadas se guardan para quienes las vean después y las basadas en DOM surgen en el código del lado del cliente. Utiliza codificación de salida adaptada al contexto y plantillas seguras, respaldadas por una política de seguridad de contenido. Las cookies HttpOnly limitan el acceso de los scripts a las cookies, pero no reparan una salida insegura.

Distingue las solicitudes y el acceso a archivos

SSRF puede alcanzar los metadatos de la nube en 169.254.169.254. La inclusión de archivos puede divulgar el contenido o ejecutar código, según cómo gestione la aplicación el archivo.

Protege la memoria y los permisos

Un desbordamiento de búfer escribe fuera de la memoria asignada en la pila o el montículo. Un desbordamiento de enteros supera el rango de un tipo; la aritmética sin signo de 8 bits puede pasar de 255 más 1 a 0. Utiliza comprobaciones de límites, funciones seguras y lenguajes con seguridad de memoria. ASLR, DEP/NX y los valores de protección de pila dificultan la explotación mientras el fallo de programación permanece.

El control de acceso defectuoso permite a los usuarios superar sus permisos, por ejemplo, leer la factura de otro cliente cambiando su identificador. Comprueba la autorización en el servidor para cada solicitud y deniega el acceso por defecto. La escalada vertical de privilegios obtiene permisos superiores; la horizontal alcanza los permisos de otro usuario. Las correcciones de autenticación y sesión incluyen MFA, identificadores de sesión aleatorios, renovación al iniciar sesión y caducidad.

Aborda el diseño y los servicios de apoyo

Los fallos criptográficos incluyen datos sin cifrar, claves codificadas directamente y hashes rápidos de contraseñas. Utiliza TLS 1.2 o posterior, claves gestionadas y funciones lentas de hash de contraseñas como Argon2 o bcrypt. Elimina las cuentas predeterminadas, las funciones innecesarias, el listado de directorios y los errores detallados. Valida los fallos específicos de componentes por separado del riesgo de soporte por fin de vida útil.

El diseño inseguro necesita cambios en el diseño y la implementación, con modelado de amenazas para identificar los controles que faltan. La ejecución remota de código permite a un atacante provocar la ejecución remota del código elegido; la ejecución local de código tiene un requisito de acceso distinto. El envenenamiento de datos corrompe datos de confianza o de entrenamiento: controla las fuentes y haz un seguimiento de su procedencia. Cuando ocurran errores, deniega el acceso ante fallos para que las condiciones excepcionales no concedan acceso. Un cortafuegos de aplicaciones web puede reducir la exposición mientras se corrige el código, pero el código inseguro sigue necesitando reparación.

El software seguro necesita comprobaciones en varias etapas porque ninguna prueba ve todo el sistema. Añade requisitos de seguridad, modelado de amenazas, revisión de código, pruebas automatizadas, comprobaciones de despliegue y mantenimiento al ciclo de vida de desarrollo de software (SDLC). Adelantar las comprobaciones adecuadas se denomina desplazamiento a la izquierda.

Compara los métodos de prueba

SAST puede señalar un valor de solicitud concatenado en una consulta. DAST puede aportar evidencias de respuesta de la aplicación de pruebas en ejecución. Valida las evidencias combinadas antes de elegir la corrección del código. Las pruebas con entradas malformadas o variables añaden pruebas de entradas malformadas para encontrar cierres inesperados y otros fallos. La autenticación y la cobertura del rastreo importan: una ejecución de DAST que nunca llega a una página administrativa no ha evaluado sus entradas.

Encuentra las dependencias afectadas

SCA lee manifiestos de paquetes, archivos de bloqueo o binarios para identificar los componentes incluidos. Por ejemplo, log4j-core 2.14.1 está afectado por Log4Shell, CVE-2021-44228, con CVSS v3.1 10,0. La corrección requiere una versión corregida adecuada y volver a desplegar todas las aplicaciones que incluyen el componente. La versión histórica de referencia para la corrección en Java 8, 2.17.1, aborda los fallos relacionados con ese incidente; para trabajos nuevos, selecciona una versión con soporte actual recomendada por el proveedor.

Una SBOM registra componentes, versiones, proveedores y relaciones de dependencia en un formato legible por máquina como SPDX o CycloneDX. Responde dónde se utiliza un componente. Una declaración VEX, intercambio de información sobre la explotabilidad de vulnerabilidades, de un proveedor indica si un producto está No afectado, Afectado, Corregido o En investigación respecto de una vulnerabilidad. Valida que el producto y la versión coincidan con la declaración VEX y revisa el motivo que la respalda antes de cambiar el estado de un hallazgo.

Protege la cadena de suministro

Los canales de actualización comprometidos, los paquetes maliciosos con nombres similares y las dependencias abandonadas pueden introducir riesgos a través de proveedores de confianza. El compromiso de SolarWinds Orion en 2020 ilustra un ataque al canal de actualización. Evalúa las prácticas de los proveedores; acuerda las expectativas sobre parches y divulgación; solicita SBOM; verifica hashes o firmas; fija las versiones de las dependencias; y utiliza registros internos aprobados. Fijar versiones permite controlar los cambios, pero una dependencia fijada y desactualizada sigue necesitando revisión y actualizaciones.

Incorpora la seguridad al programa

El modelado de amenazas utiliza el diseño para preguntar qué podría salir mal. STRIDE cubre suplantación de identidad, manipulación, repudio, divulgación de información, denegación de servicio y elevación de privilegios. Convierte las amenazas identificadas en controles y casos de prueba.

El modelo de madurez de aseguramiento del software (SAMM) de OWASP organiza la mejora del programa en Gobernanza, Diseño, Implementación, Verificación y Operaciones: tres prácticas en cada función, 15 en total, con niveles de madurez del 1 al 3. Utilízalo para planificar capacidades, mientras que la programación segura diaria mantiene los datos separados de los comandos, codifica la salida, protege las credenciales y sesiones, limita los privilegios y gestiona los errores sin exponer detalles internos.

La seguridad en la nube depende del trabajo tanto del proveedor como del cliente. Identifica el modelo de servicio antes de asignar un hallazgo y después evalúa la configuración desplegada, así como las imágenes, el código y las plantillas que la crean. Los recursos en la nube pueden cambiar más rápido de lo que detecta un escaneo de red periódico.

Asigna responsabilidades según el modelo de servicio

En todos los modelos, los clientes siguen siendo responsables de sus datos y de quién puede acceder a ellos. Una base de datos gestionada puede eliminar el trabajo de aplicar parches al sistema operativo, pero dejar permisos excesivos o exposición pública que el cliente debe corregir.

Interpreta los hallazgos de postura por recurso

La gestión de la postura de seguridad en la nube (CSPM) comprueba las configuraciones mediante las API del proveedor, habitualmente con acceso de solo lectura. Prowler y ScoutSuite informan de hallazgos por recurso y línea base, como las líneas base de fundamentos de nube de CIS. Repite las comprobaciones porque la configuración de las cuentas, las identidades y las reglas de red cambian con frecuencia.

Los hallazgos habituales incluyen almacenamiento público, permisos de identidad demasiado amplios como "Action": "*", volúmenes o instantáneas sin cifrar, registro desactivado, claves de acceso incorporadas al código, usuarios privilegiados sin MFA, interfaces de gestión expuestas y acceso SSH o RDP desde todo internet. 0.0.0.0/0 abarca todas las direcciones IPv4; una regla que lo permita hacia el puerto 22 o 3389 expone el servicio de gestión allí donde el recurso sea accesible.

Corrige el origen del despliegue

La infraestructura como código (IaC) describe recursos en plantillas. Checkov o Trivy pueden señalar una regla de Terraform que contiene cidr_blocks = ["0.0.0.0/0"] para SSH antes del despliegue. Restringe el acceso al rango administrativo necesario o utiliza un bastión aprobado o un servicio de gestión de sesiones.

Corrige tanto la configuración desplegada como su plantilla. De lo contrario, el siguiente despliegue puede restablecer la exposición. Las diferencias entre la configuración declarada y la real son deriva de configuración. Una reparación solo en la consola puede ser temporal aunque la comprobación inmediata sea satisfactoria.

Reconstruye imágenes y cubre el trabajo de corta duración

Escanea las imágenes de contenedores en busca de paquetes y bibliotecas del sistema operativo en la canalización de compilación y en el registro. Reconstruye a partir de una imagen base actualizada y vuelve a desplegar; no dependas de aplicar parches a contenedores individuales en ejecución. Las imágenes base mínimas reducen los componentes innecesarios. Inspecciona también las definiciones de Kubernetes en busca de configuraciones de riesgo, como la ejecución privilegiada.

Utiliza las API del proveedor y las etiquetas de recursos para inventariar las instancias de corta duración. Evalúa sus imágenes maestras aprobadas, plantillas y dependencias; utiliza agentes compatibles o evaluación de instantáneas cuando sea adecuado. En los entornos de ejecución gestionados sin servidor, las actualizaciones del proveedor siguen la configuración de actualización del servicio. Los clientes mantienen el código y las bibliotecas de las funciones, reconstruyen las funciones basadas en contenedores y actualizan los entornos de ejecución personalizados.

Gestiona un hallazgo de postura hasta su verificación

Una evaluación encuentra almacenamiento público de datos personales, acceso raíz sin MFA y RDP accesible desde todo internet. Restringe de inmediato los datos expuestos y aborda urgentemente la identidad privilegiada y la vía de gestión. Corrige las reglas del depósito y de la red en los recursos desplegados y en IaC. Configura la MFA del usuario raíz de AWS mediante la consola de administración; las API ordinarias y la IaC no permiten habilitarla. Vuelve a ejecutar las comprobaciones pertinentes, verifica que el acceso de la aplicación siga funcionando y comprueba que un despliegue posterior conserve la corrección.