Controles proactivos de OWASP leídos como requisitos

OWASP publica los Top 10 Proactive Controls (edición 2024) como una lista de técnicas de seguridad que todo equipo de desarrollo debería aplicar, de C1 a C10. Son deliberadamente generales: cada uno resume lo que hay que construir. ASVS, en cambio, se concibe para verificar: sus requisitos deben poder resolverse en pasa o falla.

Leer un control proactivo como requisito consiste en bajarlo a una frase concreta para tu aplicación, con un criterio que cualquiera pueda ejecutar y obtener el mismo resultado. «Se validarán las entradas» es una intención; «el teléfono acepta solo dígitos y el signo más, hasta quince caracteres, y lo demás devuelve un error de petición» es un requisito.

Abre proactivos/proactivos-2024.txt y proactivos/borrador-de-requisitos.txt. La frase B-4 pide que el servidor no haga peticiones a direcciones internas que le indique el cliente. Busca, en la lista oficial, el control proactivo que trata de eso y anota su identificador.

El borrador del equipo tiene ocho frases y una columna de criterio de prueba. Una frase sin criterio es una frase que nadie podrá declarar cumplida ni incumplida. Cuenta las que tienen la columna vacía (marcada con guiones).

El equipo de seguridad reescribió cuatro frases con su control de origen y su prueba, en proactivos/reescritos.txt. Un buen requisito reescrito dice qué se observa y dónde. Busca el que se comprueba mirando un registro con usuario, acción, recurso y hora, y anota el control del que viene.

Al reescribir, cada frase gana un objeto concreto, un umbral o una condición y un resultado que se puede ver. Compara «los componentes se mantendrán actualizados» con «la integración continua falla si una dependencia directa trae una vulnerabilidad conocida crítica sin excepción vigente».