01El mapa de vulnerabilidades: el CWE Top 25 (edición 2025)
El CWE Top 25 de MITRE clasifica las clases de debilidades de software más peligrosas; la edición 2025 se basa en 39.080 registros CVE del periodo de junio de 2024 a junio de 2025, ponderados por frecuencia y severidad CVSS media. En cabeza figuran Cross-Site Scripting (CWE-79), la inyección SQL (CWE-89) y Cross-Site Request Forgery (CWE-352): patrones conocidos desde hace décadas que, aun así, siguen siendo las causas más frecuentes de CVE reales. Destacan además dos bloques: los errores de memoria como Out-of-bounds Write/Read y Use After Free (sobre todo en bases de código C/C++), así como nada menos que cuatro debilidades de autorización (CWE-862, CWE-863, CWE-284, CWE-639). Para el secure coding esto significa: la mayoría de las vulnerabilidades siguen patrones conocidos y evitables, y pueden abordarse de forma dirigida.
02OWASP Top 10:2025 – categorías de riesgo para aplicaciones web
El OWASP Top 10 agrupa debilidades individuales en categorías de riesgo; la edición 2025 es la versión publicada vigente y se apoya en datos de pruebas de unos 2,8 millones de aplicaciones. Broken Access Control se mantiene en el primer puesto y ahora incluye también Server-Side Request Forgery; como novedades figuran A03 «Software Supply Chain Failures», ampliación de la antigua categoría «Vulnerable and Outdated Components», y A10 «Mishandling of Exceptional Conditions». Injection (A05), Security Misconfiguration (A02) y Cryptographic Failures (A04) siguen teniendo un peso destacado. El Top 10 resulta muy útil para la concienciación y la priorización, pero no sustituye un catálogo completo de requisitos para el desarrollo.
03El OWASP ASVS 5.0 como marco de requisitos
El OWASP Application Security Verification Standard traduce el secure coding en requisitos verificables. La versión 5.0.0 (publicada en mayo de 2025) comprende alrededor de 350 requisitos en 17 capítulos: desde encoding y sanitization, pasando por autorización, gestión de sesiones y criptografía, hasta Secure Coding and Architecture. Los tres niveles se han redefinido respecto a la 4.x y están ordenados por prioridad: L1 reúne como punto de partida alrededor del 20 por ciento de los requisitos (primera línea de defensa crítica), L2, el nivel objetivo para la mayoría de las aplicaciones, añade aproximadamente otro 50 por ciento, y L3 agrupa las medidas restantes de defensa en profundidad. En la práctica, el ASVS sirve como marco de requisitos para el desarrollo y las compras, así como de referencia de verificación para revisiones de código y pruebas de penetración.
04Prácticas clave: validación, encoding, autorización, secretos
Cuatro prácticas cubren gran parte del mapa de vulnerabilidades. Primero, la validación de entradas: comprobar todas las entradas en el servidor contra listas de valores permitidos (tipo, longitud, rango de valores, sintaxis admitida); esto reduce la superficie de ataque, pero no sustituye el encoding. Segundo, el output encoding específico del contexto y las consultas parametrizadas: neutralizan de raíz las clases de inyección como XSS y la inyección SQL. Tercero, la autorización según el principio «deny by default»: cada comprobación de acceso a objetos y funciones realizada en el servidor y de forma centralizada (policy o middleware) en lugar de verificaciones aisladas dispersas, precisamente contra las clases CWE-862 y CWE-639, tan presentes en el ranking CWE. Cuarto, la gestión de secretos: nada de credenciales ni claves en el código fuente o en los repositorios, sino almacenes de secretos centralizados con rotación y permisos mínimos, complementados con secret scanning en la pipeline.
05Anclaje en el SDLC: revisión de código, SAST y DAST
El secure coding solo es eficaz si está anclado en el proceso de desarrollo. SAST analiza el código fuente ya en la pull request y detecta patrones como puntos de inyección o secretos codificados en duro; DAST prueba la aplicación en ejecución y detecta problemas de configuración y de tiempo de ejecución: ambos se complementan, pero no se sustituyen. Las revisiones de código de seguridad manuales siguen siendo imprescindibles para las debilidades de lógica, como la ausencia de autorización, porque las herramientas automatizadas apenas detectan este tipo de errores. El marco organizativo lo aporta el NIST Secure Software Development Framework (SP 800-218, versión 1.1) con cuatro grupos de prácticas, desde la preparación de la organización hasta la respuesta a vulnerabilidades; los niveles del ASVS y las clases CWE proporcionan la vara de medir de contenido para los quality gates y las métricas.
06Capacitación de desarrolladores: formación, champions, «paved road»
Los estándares y las herramientas fracasan sin desarrolladoras y desarrolladores capaces de aplicarlos. Una capacitación eficaz es específica por rol y por stack: formaciones alineadas con las clases de vulnerabilidades realmente encontradas en el propio código en lugar de cursos anuales genéricos, complementadas con security champions en los equipos como primer punto de contacto. Igual de importante es la idea de la «paved road»: bibliotecas verificadas, valores por defecto seguros en los frameworks y plantillas que convierten la opción segura en la más sencilla; los OWASP Top 10 Proactive Controls 2024 (C1–C10) ofrecen para ello una lista de prioridades compacta y cercana al desarrollador. El programa se vuelve medible mediante indicadores como la tasa de recurrencia de cada clase de vulnerabilidad y el tiempo hasta la corrección.
