Hay una conversación que ocurre en prácticamente todos los equipos de ingeniería con cierta madurez en seguridad. El equipo de seguridad presenta los resultados del último ciclo de escaneo: 47 hallazgos críticos, 183 altos, 291 medios. El equipo de ingeniería pregunta qué se corrige primero. Empieza un debate sobre puntuaciones CVSS, sobre qué dependencias son más críticas, sobre qué tiene exploit público conocido. Cuarenta minutos después hay un consenso aproximado. Nadie está del todo seguro de que sea el correcto.
El problema no es falta de información — es que la información está en el formato equivocado. Los ingenieros razonan en términos de deuda técnica y coste de oportunidad. Los managers razonan en términos de deadlines y recursos. Los directivos razonan en términos de dinero. CVSS es un lenguaje de seguridad pura. No traduce a ninguno de esos otros lenguajes.
El problema estructural de CVSS
CVSS (Common Vulnerability Scoring System) es una herramienta útil para lo que hace: asignar una puntuación de gravedad técnica a una vulnerabilidad en una escala del 0 al 10, basada en características como vector de ataque, complejidad de explotación, privilegios requeridos e impacto potencial. Es un estándar del sector. La mayoría de bases de datos de vulnerabilidades lo usan. Muchas herramientas de escaneo lo reportan como métrica principal.
El problema es que CVSS mide la vulnerabilidad en abstracto — no en el contexto de tu codebase específica. Un CVE con puntuación 9.8 en una dependencia de logging que solo se usa en un servicio de debugging interno tiene un perfil de riesgo completamente diferente al mismo CVE en una dependencia de autenticación que procesa sesiones de usuario en producción. CVSS los trata exactamente igual.
Hay otro problema menos obvio: CVSS no habla de dinero. Y las decisiones de priorización de seguridad son, en última instancia, decisiones de asignación de recursos. Decidir qué se corrige en el próximo sprint es decidir qué no se corrige. Sin una estimación de coste, esa decisión se toma con intuición — y la intuición en seguridad tiene un sesgo conocido hacia lo que parece grave en lugar de lo que realmente lo es.
Cómo funciona el modelo de impacto financiero
El Financial Impact Engine de Gerion calcula el coste estimado de remediación de cada hallazgo a partir de tres variables que reflejan el contexto real de ese hallazgo en tu codebase.
Tipo de hallazgo y coste base
Cada categoría de vulnerabilidad tiene un rango de coste base derivado de benchmarks de la industria — principalmente el IBM Cost of a Data Breach Report, el Verizon DBIR, y datos de coste de remediación de incidentes reales. Ese rango refleja el coste de remediación completa: tiempo de ingeniería, coordinación de despliegue, rotación de credenciales si aplica, y revisión forense cuando hay ventana de exposición.
Una credencial expuesta en producción tiene un coste base alto porque la remediación implica identificar todos los servicios que la usan, coordinar una rotación en un entorno en vivo sin causar tiempo de inactividad, revisar los logs de acceso para entender qué ocurrió durante la ventana, y potencialmente notificar a clientes si hubo acceso a datos personales. Un CVE en una dependencia de producción tiene un coste base moderado porque requiere actualización de dependencia, pruebas de regresión y despliegue coordinado — más complejo que una actualización normal pero sin el componente forense. Una misconfiguration de IaC en una rama de feature tiene un coste base bajo porque se puede corregir en el ciclo normal de desarrollo antes de que llegue a producción.
El multiplicador de rama de producción
La variable más importante del modelo es la rama en la que vive el hallazgo. Un hallazgo en main, master, release/* o hotfix/* recibe un multiplicador de coste de 10×. El mismo hallazgo en cualquier otra rama recibe multiplicador 1×.
La lógica detrás del multiplicador es concreta. Un hallazgo en una rama de feature todavía no existe en producción — se puede corregir en el ciclo normal de desarrollo, con el tiempo que haga falta, sin presiones de coordinación. Un hallazgo en main ya está en el entorno de producción en este momento. Remediarlo requiere un parche de urgencia, una ventana de mantenimiento, posiblemente un incidente declarado. El coste de esa diferencia operativa es, históricamente, alrededor de un orden de magnitud.
# Ejemplo con el mismo CVE en dos contextos
CVE-2022-23529 en jsonwebtoken@8.5.1 rama: feature/new-auth-flow coste base: 1.400€ × multiplicador 1× = 1.400€
CVE-2022-23529 en jsonwebtoken@8.5.1 rama: main coste base: 1.400€ × multiplicador 10× = 14.000€Ese CVE es exactamente el mismo en ambos casos. La diferencia de coste refleja la diferencia de contexto — cuánto va a costar realmente resolverlo en la situación en la que está ahora mismo.
Severidad como factor secundario
Dentro de cada categoría de hallazgo, la puntuación CVSS sigue siendo relevante — no como métrica principal, sino como factor de ajuste dentro del rango de coste base. Un CVE con puntuación 9.8 y exploit público conocido cae en el extremo alto del rango de su categoría. Un CVE de 6.5 sin exploit público cae en el extremo bajo. La severidad sigue importando; simplemente no es la variable que determina si un hallazgo es urgente — eso lo decide la combinación de tipo y contexto de rama.
Cómo cambia la priorización del trabajo
El cambio más inmediato que el modelo de coste financiero produce en los equipos no es técnico — es en la calidad de las conversaciones de priorización.
Con CVSS puro, la lista de prioridades está dominada por los hallazgos de puntuación más alta, independientemente de su contexto. El equipo dedica tiempo a evaluar CVEs críticos que están en dependencias de herramientas de desarrollo internas — hallazgos que nunca llegarán a producción y cuya remediación tiene un impacto de seguridad real mínimo. Mientras tanto, un CVE de puntuación media en la dependencia de autenticación de producción aparece en la página dos de la lista.
Con el modelo de coste financiero, los primeros puestos de la lista son los hallazgos con mayor coste estimado: los que están en ramas de producción, en repositorios activos, en componentes con mayor impacto si se explotan. El debate de priorización se vuelve más concreto — “este hallazgo representa 18.000€ de exposición en producción, ese representa 800€ en una rama de feature” — y más fácil de comunicar fuera del equipo técnico.
Un equipo de cuatro ingenieros con capacidad para un sprint de seguridad de dos semanas no va a corregir 230 hallazgos. Va a corregir los 15–20 que representan el mayor coste acumulado. El Financial Impact Engine hace esa selección objetiva, reproducible y auditada.
Lo que ve el dashboard ejecutivo
El Financial Impact Engine alimenta directamente las métricas del dashboard ejecutivo de Gerion, diseñado para comunicar el estado de seguridad a audiencias no técnicas sin perder precisión.
Security Debt — la suma de los costes estimados de todos los hallazgos abiertos en todos los repositorios conectados. No un número de hallazgos — una cifra en euros. El número que responde a la pregunta que hace el CFO: “¿cuánto estamos expuestos ahora mismo en términos financieros?” Al contrario de lo que puede parecer, un número concreto de deuda — aunque sea una estimación — es más accionable que “tenemos 47 críticos”. Permite comparar períodos, medir tendencias, y justificar inversión.
Savings Realized / Fix Rate — la suma de los costes estimados de los hallazgos cerrados en el período seleccionado (semana, sprint, trimestre). Es la métrica de progreso que transforma “cerramos 23 hallazgos este sprint” en “redujimos la deuda de seguridad en 67.000€ este sprint”. La diferencia entre las dos formulaciones no es cosmética — una permite comparar sprints, justificar el ritmo de trabajo al board, y demostrar ROI de las inversiones en seguridad.
Security Health Grade — una puntuación compuesta que combina el nivel actual de deuda, la velocidad de cierre de hallazgos (Fix Rate) y la distribución de hallazgos por criticidad y rama. Es la métrica de una sola cifra útil para comparaciones rápidas entre repositorios o entre períodos — no como sustituto del análisis detallado, sino como indicador de primer nivel para saber dónde hay que mirar.
La deuda de seguridad como métrica de negocio
La analogía entre seguridad y deuda técnica es más precisa de lo que parece. La deuda técnica es trabajo acumulado que eventualmente habrá que hacer — cuanto más se acumula, más caro resulta porque el código circundante continúa evolucionando y hace más difícil la remediación. La deuda de seguridad funciona igual, con una variable adicional: el coste puede materializarse de forma abrupta a través de un incidente, no gradualmente a través de velocidad de desarrollo reducida.
Medir la deuda de seguridad en términos financieros — en lugar de en número de hallazgos o puntuaciones CVSS — permite integrarla en las conversaciones de planificación de ingeniería donde ya se habla de deuda técnica. No es un dashboard separado para el equipo de seguridad. Es una métrica de salud de la plataforma que cualquier engineering manager puede leer en el mismo contexto que las métricas de calidad de código, cobertura de tests o velocidad de despliegue.
Esa integración es el objetivo: que la seguridad no sea una conversación que ocurre en paralelo a la ingeniería, sino parte del mismo lenguaje con el que los equipos razonan sobre el estado de sus sistemas.