Cómo priorizar 300 findings de código con un sprint de dos semanas

Cuando el análisis devuelve 300 problemas y el sprint ya ha empezado

Imagina esta situación: tu equipo acaba de recibir el informe de análisis estático y de seguridad de una aplicación bancaria. El cliente espera resultados en dos semanas. El informe tiene 312 hallazgos. Los hay de todos los tipos: inyecciones SQL potenciales, dependencias con CVEs conocidos, código duplicado, endpoints sin autenticar, configuraciones por defecto sin cambiar, y una larga lista de “mejoras recomendadas” que nadie sabe muy bien cómo clasificar.

La reacción más habitual en ese momento no es técnica. Es humana: parálisis.

¿Por dónde empezamos? ¿Lo más grave primero? ¿Lo más rápido de resolver? ¿Lo que el cliente verá antes? Sin un marco claro, los equipos tienden a atacar los findings por orden de aparición en el informe, por intuición, o directamente a dividirlos en cuatro y repartirlos sin criterio. El resultado, casi siempre, es el mismo: al final del sprint se han cerrado muchos tickets, pero el riesgo real del sistema apenas ha bajado.

Este artículo propone una metodología concreta para convertir ese caos en decisiones claras, aplicables en un sprint real.

El problema no es el número, es la falta de contexto de negocio

Recibir 300 findings no es el problema en sí. El problema es que la mayoría de los informes de análisis de código —sean de herramientas de análisis estático como SonarQube, de escáneres de dependencias como OWASP Dependency-Check, o de pruebas dinámicas con OWASP ZAP— tratan todos los hallazgos con la misma estructura: severidad técnica, descripción, localización en el código.

Lo que esos informes no dicen es: ¿este endpoint sin autenticar lo usa un usuario final o es un endpoint interno de monitorización? ¿Esa dependencia vulnerable con CVSS 9.1 está en el módulo de pagos o en una utilidad de logging que solo se ejecuta en local?

La severidad técnica es necesaria, pero insuficiente. Un finding con CVSS 6.5 en el flujo de checkout de una plataforma de pagos es infinitamente más urgente que un CVSS 8.0 en una herramienta de administración interna sin exposición a internet.

Esto tiene consecuencias directas para el negocio: en el sector financiero, una vulnerabilidad no resuelta en un flujo crítico puede derivar en sanciones regulatorias (DORA, PCI-DSS), pérdida de confianza del usuario y, en los peores casos, brechas con coste promedio superior a los 4,5 millones de dólares según el informe Cost of a Data Breach 2024 de IBM. Para el usuario final, el impacto es aún más inmediato: interrupciones de servicio, exposición de datos personales o transacciones fallidas.

El marco de priorización: cuatro ejes, una decisión

Para abordar este volumen de forma sistemática, proponemos un marco basado en cuatro ejes de evaluación que, combinados, generan una puntuación de prioridad accionable:

1. Impacto de negocio

¿El finding afecta a un flujo crítico para el usuario o para los ingresos? En una aplicación bancaria digital, los flujos de máxima criticidad son: autenticación, transferencias, consulta de saldo y notificaciones regulatorias. Un fallo en cualquiera de estos tiene impacto directo en el cliente final y en los compromisos contractuales.

2. Severidad técnica

La escala CVSS sigue siendo una referencia válida, pero debe contextualizarse. Un finding crítico en un componente que no está desplegado en producción no compite en prioridad con un finding medio en un módulo activo con miles de usuarios diarios.

3. Esfuerzo de resolución

No todos los fixes son iguales. Actualizar una dependencia vulnerable puede costar dos horas. Refactorizar un módulo con inyección SQL estructural puede requerir tres días y pruebas de regresión completas. El sprint tiene capacidad finita: conocer el esfuerzo real permite distribuir el trabajo de forma realista.

4. Exposición real

¿El componente afectado está en producción y accesible desde internet? ¿Tiene tráfico real de usuarios? ¿Está detrás de una VPN o en un entorno de staging? La superficie de ataque activa manda.

De la teoría al tablero: cómo distribuir el sprint

Con los cuatro ejes valorados —puede hacerse en una sesión de una hora con el equipo técnico y un representante del cliente— la distribución del sprint sigue una regla sencilla que hemos llamado regla 60/30/10:

• 60 % de la capacidad del sprint → Findings críticos con alta exposición real. Son los que, si se explotan mañana, tienen consecuencias inmediatas. En nuestro escenario de banca digital, esto incluía 18 findings de los 312 iniciales. Solo el 6 % del total, pero el 80 % del riesgo real.
• 30 % → Findings medios con alto retorno de resolución. Aquí entran los quick wins: vulnerabilidades de severidad media que se resuelven en pocas horas y reducen significativamente la deuda técnica acumulada. La agrupación por patrón es clave: si hay 40 findings del mismo tipo de inyección en distintos módulos, un fix transversal los cierra todos a la vez.
• 10 % → Deuda técnica estructural. Al menos una historia del sprint debe dedicarse a avanzar en issues de fondo que, si se ignoran, generarán más findings en el siguiente análisis.

Caso de referencia: plataforma de pagos digitales

Tomemos como referencia un escenario representativo: una plataforma de pagos digitales con stack Java en backend y Angular en frontend recibe un análisis combinado de análisis estático, revisión de dependencias y pruebas de seguridad dinámicas. El resultado: 312 findings.

Aplicando el marco de los cuatro ejes, el equipo identifica en la sesión de priorización inicial:

Categoría	Findings	% del total	Acción en sprint
Críticos con alta exposición	18	6 %	Resolución inmediata (sprint 1)
Medios agrupables	74	24 %	Quick wins + fix transversal
Bajos o sin exposición activa	153	49 %	Backlog priorizado
Informativos / mejora futura	67	21 %	Backlog no urgente

Al final del sprint de dos semanas, el equipo había cerrado 92 findings y, lo más relevante, había eliminado el 87 % de la superficie de riesgo real. No se resolvió todo. Se resolvió lo que importaba primero.

Lo que el cliente gana, más allá del número de tickets cerrados

Un informe de cierre que diga “hemos cerrado 92 de 312 findings” puede parecer un resultado mediocre. Un informe que diga “hemos eliminado el 87 % de la superficie de riesgo activa, incluyendo el 100 % de los vectores de ataque sobre los flujos de pago” es una historia completamente diferente.

Esa diferencia —técnicamente pequeña, comunicativamente enorme— es lo que una metodología de priorización bien aplicada permite contar.

Para el equipo de desarrollo, el impacto también es tangible: menos tiempo en reuniones de triaje interminables, menos decisiones basadas en intuición y más capacidad para justificar las prioridades con criterios objetivos. Para el usuario final de la aplicación, el resultado es un producto más estable, con menos interrupciones de servicio y con sus datos mejor protegidos.

Conclusión: el volumen no es el enemigo, la falta de criterio sí

Gestionar 300 findings en dos semanas no es un problema de capacidad, es un problema de criterio. Los equipos que aplican un marco claro de priorización no solo resuelven más riesgo real por sprint: desarrollan una capacidad organizativa que mejora con cada iteración.

En Babel trabajamos con equipos de desarrollo en proyectos de alta complejidad técnica y exigencia regulatoria. Hemos aprendido que la diferencia entre un análisis de código que genera valor y uno que genera ansiedad no está en la herramienta que lo produce, sino en el proceso que lo convierte en decisiones. Si tu equipo se enfrenta a este tipo de retos, estaremos encantados de contarte cómo lo abordamos.