Por qué una debilidad técnica y un riesgo de negocio no son la misma cosa.
Una vulnerabilidad es una debilidad. Un riesgo es un escenario que puede producir un impacto. La diferencia parece pequeña, pero cambia por completo la forma de priorizar.
Un ejemplo cotidiano
Supongamos que una aplicación tiene una versión antigua de una librería. Eso puede ser una vulnerabilidad. Para convertirla en riesgo necesitamos entender si la aplicación está expuesta, si la vulnerabilidad es explotable en esa configuración, qué privilegios tendría un atacante y qué podría afectar.
Vulnerabilidad = debilidad. Riesgo = escenario + probabilidad o plausibilidad + impacto + contexto.
Por qué importa
Si tratamos todas las vulnerabilidades como riesgos máximos, terminamos agotando recursos. Si ignoramos el contexto, también podemos subestimar un problema aparentemente pequeño que afecta un proceso crítico.
Un caso para situar el problema
En un inventario aparecen dos fallos: una versión antigua en un sistema aislado y un permiso excesivo en el repositorio central de documentos. El primero puede tener mayor severidad técnica; el segundo puede afectar información crítica y estar expuesto a más personas.
Qué permite comprender este caso
Para ordenar prioridades conviene separar el hallazgo técnico de su escenario de riesgo. Se describe el activo, la vía de explotación, las condiciones que harían posible el daño y el impacto esperable.
La consecuencia práctica
Una decisión defendible puede priorizar el permiso excesivo incluso si su puntuación técnica parece menor. Debe quedar registrada la razón y la evidencia que permitió decidir.