Financial Impact Engine: la seguridad en números que entiende el negocio
Por Equipo Gerion 9 min de lectura
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 con una fórmula deliberadamente simple, a partir de tres variables: el tipo de análisis, la severidad y la rama en la que vive el hallazgo.
Horas por tarifa: el coste de desarrollo
Para cada combinación de tipo de análisis (SAST e IaC, SCA, secretos) y severidad, el modelo define unas horas medias de remediación y una tarifa horaria. Su producto es el coste de desarrollo; multiplicado por el factor de rama, el coste de producción:
coste_dev = horas_medias × tarifa_horariacoste_prod = coste_dev × multiplicador (por defecto, 10)Estos son los valores por defecto:
| Tipo | Severidad | Horas × tarifa | Coste dev | Coste prod (×10) |
|---|---|---|---|---|
| SAST / IaC | CRITICAL | 1 h × 80 € | 80 € | 800 € |
| SAST / IaC | HIGH | 1 h × 60 € | 60 € | 600 € |
| SAST / IaC | MEDIUM / LOW | 1 h × 40 € | 40 € | 400 € |
| SCA | CRITICAL | 2 h × 80 € | 160 € | 1.600 € |
| SCA | HIGH | 1,5 h × 60 € | 90 € | 900 € |
| SCA | MEDIUM / LOW | 1 h × 40 € | 40 € | 400 € |
| Secretos | CRITICAL | 0,5 h × 80 € | 40 € | 400 € |
| Secretos | HIGH | 0,5 h × 60 € | 30 € | 300 € |
| Secretos | MEDIUM / LOW | 0,5 h × 40 € | 20 € | 200 € |
Horas, tarifas y multiplicador son configurables por organización: los valores por defecto son un punto de partida, y lo razonable es ajustarlos a lo que cuesta de verdad corregir en tu equipo. Con esta configuración, el máximo por hallazgo es de 1.600 € (un SCA crítico en producción).
La lógica de la tabla es la de las horas de ingeniería. Un hallazgo de SCA lleva más tiempo que uno de SAST porque exige actualizar la dependencia, pasar las pruebas de regresión y desplegar de forma coordinada. Un secreto, en cambio, se estima en media hora: es el tiempo de rotarlo. Conviene ser claro con el alcance: el modelo estima horas de ingeniería, no el coste de un incidente. No incluye revisión forense, notificaciones ni daño reputacional.
El multiplicador de rama de producción
La variable más importante del modelo es la rama en la que vive el hallazgo. En main, master o cualquier rama cuyo nombre empiece por release, el coste de producción se calcula con un multiplicador de 10× (el valor por defecto). Un hallazgo activo en una de esas ramas cuenta como deuda por su coste de producción completo.
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. Remediarlo requiere un parche de urgencia, una ventana de mantenimiento, posiblemente un incidente declarado. Gerion modela esa diferencia operativa con el multiplicador, que es una estimación y no una medición.
Si el hallazgo está en cualquier otra rama, cuenta como deuda solo su coste de desarrollo, y su coste de producción se registra aparte como riesgo de pipeline: lo que costaría si llegara a producción sin corregirse.
# El mismo hallazgo SCA de severidad CRITICAL (2 h × 80 € = 160 € de coste de desarrollo)
jsonwebtoken@8.5.1 rama: feature/new-auth-flow deuda: 160 € riesgo de pipeline: 160 € × 10 = 1.600 €
jsonwebtoken@8.5.1 rama: main deuda: 160 € × 10 = 1.600 €El hallazgo es exactamente el mismo en ambos casos. La diferencia refleja el contexto: cuánto va a costar resolverlo en la situación en la que está ahora mismo.
Mitigado: el coste de producción evitado
Cuando un hallazgo deja de aparecer en un escaneo posterior, Gerion lo da por mitigado. Su coste de producción pasa de la deuda al ahorro realizado: el coste de producción evitado. Ese es el número que convierte “hemos cerrado hallazgos” en euros.
Severidad: qué fila de la tabla se aplica
El modelo no aplica la puntuación CVSS como factor de ajuste. La severidad del hallazgo (CRITICAL, HIGH, MEDIUM o LOW) selecciona la fila de la tabla, y de ahí salen las horas y la tarifa. La severidad sigue importando; simplemente no es la variable que decide si un hallazgo es urgente — eso lo decide la combinación de tipo, severidad y 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 CVE 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 y los de mayor severidad. El debate de priorización se vuelve más concreto — “este hallazgo SCA crítico son 1.600 € de deuda en main, ese otro son 160 € 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 y reproducible.
Lo que ven los dashboards
El Financial Impact Engine alimenta directamente las métricas de los dashboards Executive y Governance de Gerion, diseñados para comunicar el estado de seguridad a audiencias no técnicas sin perder precisión.
Security Debt — la suma de la deuda de todos los hallazgos activos (según la rama, su coste de producción o su coste de desarrollo, como se ha visto arriba) 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 hacer seguimiento y justificar inversión.
Savings Realized — el ahorro realizado acumulado en el año: la suma del coste de producción evitado de los hallazgos mitigados. Es la métrica de progreso que transforma “cerramos 6 hallazgos SCA críticos” en “evitamos 9.600 € de coste de producción” (6 × 1.600 €). La diferencia entre las dos formulaciones no es cosmética — una permite justificar ante el board el ritmo de trabajo y el esfuerzo dedicado a seguridad.
Security Grade — una nota de A a F por repositorio, en el dashboard Governance. Es la métrica de una sola letra útil para comparaciones rápidas entre repositorios — 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.