Un informe de seguridad con ciento cuarenta hallazgos no es un plan de trabajo. Es una lista. La diferencia entre una organización que reduce su riesgo y otra que solo acumula informes está en el criterio con el que ordena esa lista.
OWASP Top 10 es un marco de referencia que agrupa las categorías de riesgo más frecuentes en aplicaciones web. No es una norma de cumplimiento ni una checklist de aprobación: es un lenguaje común para hablar de lo que suele fallar.
Por qué la severidad del escáner no basta
Las herramientas de análisis estático (SAST) y dinámico (DAST) asignan severidad según el tipo de falla, no según su contexto. Una inyección SQL marcada como crítica en un módulo interno, accesible solo desde la red administrativa y con dos usuarios, representa menos riesgo real que una exposición de datos «media» en el formulario público de solicitudes.
El escáner no sabe:
- Quién puede alcanzar el componente afectado.
- Qué datos hay detrás.
- Qué pasa operativamente si ese componente falla.
Esa información la tiene su organización, y es la que convierte una lista en una prioridad.
Tres preguntas para ordenar los hallazgos
1. Exposición: ¿desde dónde se alcanza?
Clasifique cada hallazgo en tres niveles: alcanzable desde Internet sin autenticación, alcanzable con una cuenta válida, o alcanzable solo desde la red interna. El primer nivel se atiende primero, siempre. Un atacante no necesita ser sofisticado si la puerta está en la calle.
2. Impacto: ¿qué queda comprometido?
No mida el impacto en términos técnicos («ejecución remota de código») sino en términos de la organización: datos personales de ciudadanos, credenciales que abren otros sistemas, capacidad de alterar registros oficiales, interrupción de un trámite. Un hallazgo que toca datos de terceros pesa más que uno que afecta solo información pública.
3. Esfuerzo: ¿cuánto cuesta cerrarlo?
Aquí aparece el matiz práctico. Entre dos hallazgos de riesgo similar, primero el que se cierra con un cambio de configuración y después el que exige refactorizar un módulo. Acumular victorias rápidas reduce la superficie de ataque mientras el equipo trabaja en lo estructural.
Una matriz simple
| Esfuerzo bajo | Esfuerzo alto | |
|---|---|---|
| Exposición e impacto altos | Inmediato (días) | Planificado con hito (semanas) |
| Exposición o impacto medios | Siguiente ciclo | Backlog con fecha |
| Ambos bajos | Cuando se toque el módulo | Documentar y aceptar |
La última celda es legítima. Aceptar un riesgo de forma explícita, documentada y con responsable asignado es una decisión de gestión; ignorarlo no lo es.
Falsos positivos: descártelos, pero por escrito
Entre el 20 % y el 40 % de los hallazgos automáticos de una primera pasada suelen ser falsos positivos o riesgos no aplicables al contexto. Descartarlos es correcto. Descartarlos sin dejar registro de quién lo hizo y por qué genera un problema en la siguiente auditoría, cuando nadie recuerda el razonamiento.
Qué debería recibir de una evaluación seria
Si contrata un análisis de seguridad, el entregable debería incluir, además de la lista:
- Cada hallazgo con evidencia reproducible, no solo la firma del escáner.
- La ruta de explotación descrita paso a paso cuando aplique.
- La corrección recomendada, concreta para su tecnología.
- Una priorización argumentada, no un ordenamiento automático por severidad.
- Una verificación posterior que confirme el cierre.
Sin la verificación posterior, no sabe si el trabajo sirvió.
El ciclo, no el informe
Una evaluación es una fotografía. El código cambia, las dependencias se actualizan, aparecen configuraciones nuevas. Lo que reduce riesgo de forma sostenida es el ciclo: evaluar, corregir, verificar, volver a evaluar en un plazo acordado. Para aplicaciones con cambios frecuentes, un ciclo semestral es un mínimo razonable; para las que manejan datos sensibles y despliegan a menudo, trimestral.