Cómo leer un informe de auditoría de seguridad sin ser desarrollador

Un informe de auditoría de seguridad informática tiene una estructura bastante estandarizada, especialmente cuando sigue el marco OWASP (Open Worldwide Application Security Project), que es el punto de referencia más utilizado para aplicaciones web en América Latina. El problema no es la estructura: es el vocabulario. Términos como «cross-site scripting», «inyección SQL», «CVSS score» o «superficie de ataque» aparecen sin definición en la mayoría de los informes porque se asume que quien los lee los conoce. Esa asunción falla con frecuencia en las organizaciones medianas, donde el informe llega al escritorio de un director de operaciones o un gerente general que debe decidir qué vulnerabilidades priorizar, qué presupuesto asignar y si el equipo técnico está recomendando correctamente. La primera sección que debe leer es el «Resumen ejecutivo». Todo informe serio lo incluye y está redactado en lenguaje menos técnico. Ahí encontrará el número total de vulnerabilidades encontradas clasificadas por severidad: crítica, alta, media y baja. El número que importa primero es el de severidad crítica: si hay más de dos o tres, es una conversación urgente con su equipo técnico. La segunda sección relevante para un lector no técnico es la «Tabla de hallazgos», donde cada vulnerabilidad tiene un nombre, una descripción breve, el componente afectado y una puntuación CVSS. El CVSS (Common Vulnerability Scoring System) va de 0 a 10: por encima de 7 es alta severidad; por encima de 9, crítica. Esos son los números sobre los cuales debe hacer preguntas concretas: ¿en cuánto tiempo se puede corregir?, ¿hay un parche disponible?, ¿está explotada activamente en otros sistemas? Las respuestas a esas tres preguntas le darán suficiente contexto para tomar decisiones informadas sin necesidad de entender el código subyacente.