WSTG Guía de pruebas de seguridad web de OWASP

En este capítulo, WSTG Guía de pruebas de seguridad web de OWASP,  vas a explorar una de las piezas centrales del hacking ético profesional: la Guía de Pruebas de Seguridad Web de OWASP (WSTG) y todos los principios técnicos, metodológicos y estratégicos que la acompañan. Aquí no solo aprenderás cómo se prueba la seguridad de una aplicación web, sino por qué se prueba de esa forma y cómo se integra dentro del ciclo de vida de desarrollo moderno.

Comprenderás desde los fundamentos —la importancia del SDLC, los principios del testing, la mentalidad ofensiva, el análisis de riesgos y la medición de seguridad— hasta técnicas específicas como el modelado de amenazas, la revisión de código, las inspecciones manuales y el pentesting. Además, descubrirás cómo funciona un pipeline de AppSec profesional, desde pipelines tradicionales hasta arquitecturas modernas automatizadas basadas en contenedores.

Este conocimiento es esencial para tu carrera como hacker, porque te permitirá:

• Actuar con un método de prueba estandarizado, no improvisado.
• Entender cómo piensa un atacante y cómo se defienden las aplicaciones desde dentro.
• Saber qué revisar, cuándo probar y cómo medir riesgos con enfoque profesional.
• Dominar técnicas reales de testing usadas por pentesters, analistas AppSec y equipos DevSecOps.
• Diferenciarte del resto con una comprensión profunda del proceso, no solo de las herramientas.

En simple: este capítulo te enseña a pensar, trabajar y evaluar como un profesional de seguridad real.

WSTG OWASP: Pensar, Testear y Romper Como un Profesional

El OWASP Web Security Testing Guide (WSTG) no es un simple documento técnico más: es la Biblia del hacking ético web profesional. Si querés auditar, defender o atacar aplicaciones web como un verdadero profesional, esta guía te da la metodología, la estructura y las herramientas conceptuales necesarias para dejar de improvisar y empezar a actuar con precisión quirúrgica. Este no es un manual de paso a paso ni una lista de comandos para copiar y pegar: es un marco de pensamiento, de análisis profundo, que te entrena para detectar no solo vulnerabilidades, sino también las debilidades estructurales que las hacen posibles.

A diferencia del clásico “hackeo de un finde” con Burp y un par de scripts, el WSTG te entrena a pensar en términos de SDLC, threat modeling, ingeniería inversa, impacto de negocio y validación de controles. Porque un verdadero analista de seguridad no escanea. Analiza. Disecciona. Reconstruye mentalmente el flujo de una app y visualiza cómo y cuándo romperla. No ataca por instinto, ataca con datos, contexto y estrategia. Y para eso, el WSTG es una obra maestra.

Entenderlo a fondo no solo te da un esquema de pruebas de penetración bien armado, sino que también te enseña a pensar como los equipos más maduros de AppSec: los que integran seguridad desde el diseño, automatizan cada etapa, validan lo que importa y miden lo que impacta. Acá ya no hablamos de encontrar un XSS. Hablamos de cómo ese XSS se deriva de una ausencia de threat modeling, de un control mal implementado en una librería legacy que nadie audita hace tres años, que está en producción porque “nunca falló”. Esta guía te enseña a ir hasta ese nivel.

Una de las ideas clave que se repiten como un mantra en todo el WSTG es el “Shift Left”: llevar la seguridad hacia las primeras fases del ciclo de desarrollo. ¿Por qué? Porque corregir errores en producción cuesta 100 veces más que prevenirlos en diseño. Porque hacer pentesting cuando la app ya está en staging es como buscar escapes de gas después de haber encendido el horno. Y porque los atacantes no esperan al QA. El WSTG te educa para involucrarte desde el vamos: definir requisitos, entender los flujos de datos, inspeccionar arquitecturas, modelar amenazas, validar controles y recién ahí —recién ahí— explotar.

Además, el WSTG estructura las pruebas en técnicas y fases que abarcan todo el ciclo de vida. No se queda en la teoría. Te explica cómo inspeccionar documentación, cómo hacer walkthroughs con los devs, cómo derivar requisitos negativos desde casos de uso reales, cómo convertir amenazas en controles, cómo revisar código en serio, cómo evitar que una puerta trasera de 30 caracteres se te pase porque el escáner no pudo adivinarla. En un mundo donde muchos pentesters siguen midiendo resultados por cantidad de vulnerabilidades encontradas, el WSTG te enseña a medir por impacto, trazabilidad y profundidad. Y eso te coloca a otro nivel.

Uno de los aspectos más sólidos de esta guía es que es agnóstica al entorno. Podés aplicarla en una startup que deploya 20 veces por día o en una fintech regulada por PCI-DSS. Te da principios, no recetas cerradas. Por eso, está organizada de forma que puedas usarla como framework de auditoría, como check de aseguramiento de calidad, como guía para DevSecOps, o como plan de ataque completo. Las fases van desde la planificación hasta el mantenimiento, pasando por requisitos, diseño, desarrollo, despliegue y validación. En cada punto te dice qué buscar, por qué, con qué herramientas y cómo medir si algo es aceptable o no.

Hablando de herramientas, el WSTG no te ata a ninguna. Te sugiere lo que funciona: ZAP, Burp, Caido, Checkmarx, Veracode, Gitleaks, DefectDojo, pipelines con Docker, integración con Jira o Slack. Pero la lógica es clara: la herramienta es el medio, no el fin. No hay escáner mágico que haga el trabajo de un cerebro entrenado. Por eso se enfoca tanto en inspecciones manuales, modelado de amenazas y revisión de código. Porque ahí es donde ocurre el trabajo real. Y si el trabajo real no está automatizado, entonces tenés que hacerlo con el máximo criterio técnico posible.

El capítulo que acabás de leer es una joya porque aterriza el WSTG como algo práctico. Te da un recorrido realista de cómo se arma un flujo de AppSec profesional. Desde pipelines tradicionales (con tareas manuales, herramientas desconectadas y validación humana), hasta arquitecturas modernas que disparan análisis SAST y DAST con cada commit, todo orquestado por contenedores efímeros que escanean, reportan y asignan bugs automáticamente. Esa es la dirección: seguridad como parte integral del desarrollo. No como un checkpoint final. No como un castigo. Como una práctica continua, medible y evolutiva.

¿Y el pentesting? El WSTG no lo descarta, pero lo pone en su lugar. No como el fin, sino como una validación. Una auditoría posterior que confirma si todo lo anterior funcionó como debía. Si solo hacés pentesting al final, estás atrapado en un modelo reactivo. Si lo hacés después de haber modelado amenazas, revisado código, validado controles y documentado requisitos de seguridad, el pentest se convierte en una prueba de fuego con sentido. Es ahí cuando el bug que encontrás realmente importa.

A nivel estratégico, el WSTG también te cambia la cabeza. Te entrena a pensar como atacante, pero a medir como gestor de riesgo. Aprendés a mapear vulnerabilidades a métricas. A traducir un RCE en términos de impacto legal, reputacional y económico. A construir dashboards con métricas reales: falsos positivos, contención por fase, defectos por técnica, retorno de inversión en actividades de seguridad. Porque hoy el CISO necesita números, no capturas de pantalla de un XSS. Y vos, como profesional de AppSec, tenés que poder generar esos datos, interpretarlos y usarlos para mejorar.

En resumen, este capítulo es el comienzo de un camino real en seguridad ofensiva y defensiva. Es el paso de ser un pentester táctico a convertirte en un profesional completo, capaz de entender el proceso, de auditar con método, de aplicar controles adecuados, de comunicar resultados con claridad y de automatizar lo que realmente importa. Si internalizás este enfoque, nunca más vas a ver una app web como antes. Vas a ver su lógica, su estructura, sus debilidades, sus oportunidades de mejora, pensar como el atacante, evaluar como el defensor y vas a entregar como un ingeniero de seguridad.

Este conocimiento es tu nueva base. A partir de acá, todo lo que estudies (inyecciones, autenticación, lógica de negocio, APIs, criptografía, ingeniería inversa) se va a apoyar sobre estos fundamentos. Dominá la metodología. El resto es cuestión de práctica, obsesión y tiempo. Pero sin método, no hay carrera. OWASP WSTG es tu manual de guerra. Leelo, estudiá cada técnica, y llevá tus pruebas de seguridad a un nivel verdaderamente profesional. Porque los mejores hackers no improvisan. Diseñan. Y vos ya empezaste ese camino.

Guía de trabajo de OWASP

El marco del » Proyecto de seguridad de aplicaciones web abiertas » es un marco impulsado por la comunidad y actualizado con frecuencia que se utiliza únicamente para probar la seguridad de las aplicaciones y servicios web. La fundación  escribe periódicamente informes  que indican las diez principales vulnerabilidades de seguridad que puede tener una aplicación web, el enfoque de prueba y la solución.

La Guía de pruebas de seguridad web de OWASP (WSTG) es una guía completa centrada en las pruebas de aplicaciones web. Es una compilación de muchos años de trabajo de los miembros de OWASP. OWASP WSTG cubre las fases de alto nivel de las pruebas de seguridad de aplicaciones web y profundiza en los métodos de prueba utilizados. Por ejemplo, llega a proporcionar vectores de ataque para probar ataques de secuencias de comandos entre sitios (XSS), entidades externas XML (XXE), falsificación de solicitudes entre sitios (CSRF) y ataques de inyección SQL; así como también cómo prevenir y mitigar estos ataques. Aprenderá más sobre estos ataques en el Módulo 6, “Explotación de vulnerabilidades basadas en aplicaciones”. Desde una perspectiva de pruebas de seguridad de aplicaciones web, OWASP WSTG es la guía más detallada y completa disponible. Puede encontrar la OWASP WSTG e información relacionada con el proyecto en  https://owasp.org/www-project-web-security-testing-guide/ .

Ventajas

Fácil de aprender y comprender.

Se mantiene activamente y se actualiza con frecuencia.

Cubre todas las etapas de un compromiso: desde las pruebas hasta los informes y la remediación.

Se especializa en aplicaciones y servicios web.

Desventajas

Puede que no esté claro qué tipo de vulnerabilidad tiene una aplicación web (a menudo pueden superponerse).

OWASP no hace sugerencias sobre ningún ciclo de vida de desarrollo de software específico.

El marco no tiene ninguna acreditación como CHECK.

Guía de pruebas de seguridad web de OWASP (WSTG)

• La Guía de pruebas de seguridad web de OWASP (WSTG) es un recurso completo e impulsado por la comunidad, proporcionado por el Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP).
• La guía tiene como objetivo ayudar a los profesionales de la seguridad, desarrolladores y organizaciones a realizar evaluaciones efectivas de la seguridad de las aplicaciones web, proporcionando un enfoque estructurado y sistemático para probar las aplicaciones web en busca de vulnerabilidades de seguridad.
• Sirve como una referencia práctica y directa para planificar, ejecutar e informar sobre las actividades de pruebas de seguridad de aplicaciones web

https://github.com/tanprathan/OWASP-Testing-Checklist

Lista de verificación de OWASP WSTG

• La lista de verificación de pruebas de seguridad web de OWASP es una lista de verificación basada en una hoja de cálculo que se puede utilizar para ayudarle a realizar un seguimiento del estado de los casos de prueba completados y pendientes.
• Esta lista de verificación se basa en la Guía de pruebas de seguridad web de OWASP e incluye una metodología/marco integral de pruebas de penetración que los pentesters de aplicaciones web pueden implementar en sus pruebas de penetración o evaluaciones de seguridad.
• También proporciona un conjunto de pruebas de seguridad de aplicaciones web detalladas y granulares que describen las diversas técnicas que se pueden utilizar para probar las configuraciones incorrectas, los fallos y las vulnerabilidades más comunes de las aplicaciones web.
• Además, la lista de verificación también contiene la calculadora de evaluación de riesgos de OWASP y la plantilla de resumen de hallazgos.

OWASP Penetration Testing Cheklist: https://owasp.org/www-project-websecurity-testingguide/assets/archive/OWASP_Web_Application_Penetration_Checklist_v1_1.pdf

+ Additional Tools: Caido – Web Security Auditing Toolkit: https://caido.io/

Podes ver la última versión de esta metodología en: https://owasp.org/www-project-web-security-testing-guide/

De ahora en más me basaremos 100% en WSTG, hice un resumen en este capítulo de la primera parte de esta guía. Animo al lector a leer la original que, sin lugar a dudas es amplia, pero realmente agradable y no es tan densa como leer los RFC. Son este tipo de lecturas en profundidad las que te van a distinguir sobre la media =).

El documento total tiene 153 sub capítulos. Así que vamos por partes básicamente se divide en:

0. Prólogo de Eoin Keary lo obviaremos, esto es un resumen, pero podes leerlo desde el link

1. Frontispicio lo mismo

2. Introducción Iniciaremos desde aquí. lo veremos en este capítulo
3. El marco de pruebas de OWASP:  lo veremos en el próximo capítulo

4. Pruebas de seguridad de aplicaciones web  Son 122 sub capítulos y los veremos a lo largo del curso según corresponda

5. Informes Este capítulo lo veremos en la sección de informes de este curso

Apéndice Son solo 6 sub capítulos y los veremos a lo largo del curso según corresponda

El proyecto de pruebas OWASP

El Proyecto de Pruebas OWASP (WSTG) se desarrolló para ayudar a comprender cómo, cuándo, dónde y por qué realizar pruebas de seguridad en aplicaciones web. Su propósito no es ofrecer una simple lista de verificación, sino un marco integral que permita a las organizaciones crear sus propios programas de pruebas o evaluar los existentes. La guía aborda tanto los principios generales como las técnicas prácticas para implementarlos dentro del ciclo de vida del desarrollo de software (SDLC).

Vemos en esta imagen representa el ciclo de vida del desarrollo de software (SDLC), destacando cómo los costos de corregir errores de seguridad aumentan a medida que el proyecto avanza por sus diferentes etapas.

El ciclo se compone de cinco fases principales que forman un proceso continuo:

1. Define (Definir):
   En esta etapa se establecen los requisitos del sistema, tanto funcionales como de seguridad. Es donde se determinan los objetivos, las necesidades del usuario y los criterios de éxito del proyecto. Integrar la seguridad desde aquí —por ejemplo, definiendo políticas de acceso o cifrado— reduce el riesgo de vulnerabilidades futuras.
2. Design (Diseñar):
   En la fase de diseño se crean los planos del sistema, incluyendo la arquitectura, los flujos de datos y la estructura de la aplicación. Aplicar principios de seguridad en el diseño (como el principio de menor privilegio, segmentación o validación de entradas) es clave, ya que corregir fallos en esta etapa resulta mucho más barato que hacerlo en producción.
3. Develop (Desarrollar):
   Aquí los desarrolladores escriben el código siguiendo las especificaciones y aplicando prácticas seguras, como evitar inyecciones, usar autenticación fuerte o gestionar correctamente los errores. Cuanto antes se detecten los fallos en el código, menor será el costo de repararlos.
4. Deploy (Desplegar):
   En esta fase la aplicación pasa a un entorno de pruebas o producción. Se deben verificar configuraciones seguras en servidores, certificados y accesos. Implementar controles como análisis de vulnerabilidades o revisiones de configuración ayuda a evitar incidentes posteriores.
5. Maintain (Mantener):
   Una vez desplegado, el sistema necesita mantenimiento continuo. Esto incluye aplicar parches, monitorear incidentes, actualizar dependencias y realizar pruebas periódicas de seguridad.

La flecha exterior indica que los costos de corregir errores de seguridad aumentan con cada etapa, reforzando la importancia del enfoque “Shift Left”: integrar la seguridad desde el inicio del ciclo de desarrollo, no al final.

En resumen, esta imagen refleja la idea central de DevSecOps: la seguridad debe ser parte integral del proceso de desarrollo, acompañando al software en todas sus fases, desde la definición hasta el mantenimiento.

El desarrollo de la guía fue un desafío, ya que se buscó un consenso que permitiera aplicarla en distintos entornos y culturas. Además, implicó un cambio de paradigma: pasar de pruebas de penetración aisladas a pruebas de seguridad integradas en todo el ciclo de desarrollo. Hoy, el marco es validado por expertos y empresas líderes en seguridad, sirviendo como una herramienta para mejorar la confiabilidad del software más allá de solo detectar vulnerabilidades. OWASP busca con ello cambiar la cultura del desarrollo mediante la educación y la concienciación.

La guía está organizada en varios capítulos. Primero, explica los fundamentos, principios y mejores prácticas de las pruebas de seguridad. Luego, detalla el marco de pruebas OWASP y su aplicación dentro del SDLC, y finalmente aborda técnicas específicas para detectar vulnerabilidades como inyecciones SQL, revisiones de código y pruebas de penetración.

Uno de los principios clave es que no se puede controlar lo que no se puede medir. Medir la seguridad es complejo, pero necesario. No solo se deben evaluar las vulnerabilidades técnicas, sino también su impacto económico. Mientras muchos profesionales comprenden las fallas técnicas, pocos traducen esos riesgos en costos de negocio. Esto impide calcular el retorno de la inversión en seguridad y asignar presupuestos adecuados. El marco OWASP promueve medir la seguridad de forma continua, relacionando el costo del software inseguro con su impacto comercial.

Las pruebas se definen como el proceso de comparar el estado de una aplicación con un conjunto de criterios establecidos. En seguridad, esto implica superar la práctica común de usar criterios poco definidos, y estructurar pruebas confiables que permitan a cualquier organización mejorar su nivel de protección. El objetivo principal de realizar pruebas es ayudar a las empresas a construir programas modernos de seguridad, identificar brechas frente a las mejores prácticas del sector y prepararse para auditorías. No se centra en los detalles técnicos, sino en el marco organizativo necesario para un programa integral.

El momento adecuado para probar no debe ser al final del desarrollo, sino durante todo el SDLC. Incorporar la seguridad desde las etapas iniciales reduce costos y previene errores graves. OWASP enfatiza que cada empresa debe integrar la seguridad en todas las fases del ciclo de desarrollo y realizar pruebas constantes para garantizar la eficacia de los controles. Además, el marco sugiere adoptar un enfoque holístico, probando no solo la tecnología, sino también los procesos y las personas involucradas. Las pruebas deben evaluar si hay educación y concienciación adecuadas, si existen políticas claras y si la implementación técnica cumple con los estándares. Probar únicamente la aplicación en sí deja sin cubrir vulnerabilidades administrativas u operativas que pueden ser igual de críticas.

Para referenciar correctamente los escenarios del WSTG, cada uno tiene un identificador con el formato WSTG-<categoría>-<número>, que puede incluir la versión (por ejemplo, WSTG-v42-INFO-02). Esto facilita mantener la trazabilidad entre distintas versiones del documento. OWASP recomienda utilizar siempre enlaces versionados y estables, como los que se publican en su sitio oficial. Finalmente, OWASP invita a la comunidad a participar enviando comentarios y sugerencias, reforzando su compromiso de mantener el proyecto actualizado, preciso y útil para todos los profesionales de la seguridad.

Principios de las pruebas

Este capítulo explica los principios fundamentales de las pruebas de seguridad, aclarando errores comunes al desarrollar metodologías de prueba para detectar fallas en el software.

No existe una solución milagrosa

No hay herramientas ni productos que por sí solos resuelvan el problema del software inseguro. Aunque los escáneres de seguridad o los firewalls de aplicaciones pueden ser útiles, la seguridad no es un producto sino un proceso continuo. Las herramientas automatizadas suelen tener limitaciones y no reemplazan una estrategia de evaluación integral ni la intervención de expertos.

Piensa estratégicamente, no tácticamente

El modelo de “parchear y penetrar”, típico de los años noventa, ha demostrado ser ineficaz. Este enfoque se limita a corregir errores individuales sin atacar las causas raíz, dejando abierta la llamada ventana de vulnerabilidad: el período entre el descubrimiento de una falla y la aplicación de un parche. Dado que los atacantes actúan cada vez más rápido, este modelo resulta insuficiente.

La solución es integrar la seguridad dentro del ciclo de vida del desarrollo (SDLC), utilizando políticas, estándares y modelado de amenazas para enfocar los recursos donde exista mayor riesgo.

Esta imagen ilustra el ciclo de vida de una vulnerabilidad de seguridad, mostrando cómo evoluciona el nivel de riesgo a lo largo del tiempo desde su descubrimiento hasta que se aplica el parche en todos los sistemas afectados.

1. Descubrimiento de la vulnerabilidad

El ciclo comienza cuando un investigador o atacante descubre una vulnerabilidad en un software o sistema. En esta etapa inicial, el riesgo aún no es alto, ya que el problema no es ampliamente conocido.

2. La vulnerabilidad se hace pública

Cuando la vulnerabilidad se divulga públicamente —ya sea de manera responsable o filtrada sin control— el nivel de riesgo se eleva considerablemente. Ahora los atacantes tienen acceso a la información, mientras que los usuarios y administradores aún no cuentan con una solución disponible.

3. El proveedor es notificado

El fabricante o desarrollador del software afectado recibe la notificación oficial. En muchos casos, esto ocurre antes de la publicación, siguiendo el modelo de responsible disclosure. Sin embargo, si el hallazgo se difunde sin previo aviso, el proveedor puede enterarse al mismo tiempo que el público.

4. Notificación a los clientes

En esta fase, algunos proveedores comunican a sus clientes la existencia del problema y las posibles medidas temporales de mitigación. Aun así, el riesgo sigue siendo elevado, ya que el parche aún no está disponible.

5. Actualización de herramientas de seguridad

Los fabricantes de soluciones de ciberseguridad (como IDS/IPS, antivirus o escáneres de vulnerabilidades) actualizan sus firmas y módulos para detectar intentos de explotación. Esto ayuda a reducir parcialmente el riesgo, aunque la vulnerabilidad aún existe.

6. Publicación del parche

El proveedor finalmente lanza una actualización o parche que corrige la falla. A partir de este momento, la amenaza empieza a disminuir, aunque los sistemas que no actualicen seguirán siendo vulnerables.

7. Difusión del parche

Con el tiempo, la existencia del parche se hace ampliamente conocida y más organizaciones comienzan a aplicarlo. No obstante, los atacantes suelen aprovechar esta fase para atacar a quienes aún no han actualizado.

8. Instalación del parche

El ciclo culmina cuando el parche es implementado en todos los sistemas afectados. En este punto, el nivel de riesgo cae drásticamente y la vulnerabilidad deja de representar una amenaza práctica.

La gráfica demuestra que el riesgo máximo ocurre entre la divulgación pública y la publicación del parche, lo que resalta la importancia de aplicar actualizaciones de seguridad rápidamente y contar con políticas de vulnerability management efectivas. En ciberseguridad, el tiempo de reacción marca la diferencia entre prevenir un incidente o sufrir una brecha.

El SDLC es el rey

Integrar la seguridad en cada fase del SDLC —definición, diseño, desarrollo, implementación y mantenimiento— permite un enfoque global y rentable. Cada etapa debe incluir consideraciones de seguridad. Existen marcos descriptivos (como BSIMM) y prescriptivos (como OpenSAMM o la ISO/IEC 27034) que orientan sobre cómo aplicar seguridad dentro del SDLC. El primero muestra cómo se implementa en la práctica; el segundo, cómo debería hacerse idealmente.

Realice pruebas con anticipación y con frecuencia

Cuanto antes se detecte una falla en el SDLC, menor será el costo y el impacto de corregirla. Es esencial capacitar a los equipos de desarrollo y QA para identificar vulnerabilidades comunes y pensar como atacantes. La educación constante reduce errores, fortalece la mentalidad de seguridad y convierte a la seguridad en una responsabilidad compartida dentro del equipo.

Automatización de pruebas

Las metodologías modernas (Ágil, DevOps, DevSecOps o RAD) requieren integrar las pruebas de seguridad en los flujos CI/CD. Las pruebas automatizadas —como SAST, DAST o SCA— permiten identificar debilidades recurrentes, analizar dependencias y mantener una base de referencia de seguridad a lo largo del ciclo de desarrollo.

Comprender el alcance de la seguridad

Cada proyecto debe definir qué nivel de seguridad necesita según la sensibilidad de los activos (por ejemplo, confidencial, secreto, alto secreto). También deben considerarse las regulaciones legales aplicables: leyes estadounidenses como la Gramm-Leach-Bliley o la SB-1386, y normativas europeas como la Directiva 96/46/CE y el Reglamento General de Protección de Datos (GDPR). Cumplir estos requisitos garantiza una gestión adecuada de los datos personales.

Desarrollar la mentalidad correcta

Probar seguridad exige pensar como un atacante. Las pruebas funcionales evalúan el uso esperado, pero las de seguridad deben explorar lo inesperado. El pensamiento creativo permite detectar suposiciones erróneas de los desarrolladores y descubrir fallas que las herramientas automatizadas no pueden prever. Cada aplicación requiere un análisis único adaptado a su diseño y contexto.

Entender el tema

Una buena práctica de seguridad empieza por la documentación completa de la aplicación: arquitectura, diagramas de flujo de datos, casos de uso permitidos y prohibidos. Esta información permite entender cómo fluye la información y dónde existen riesgos. Además, es recomendable contar con una infraestructura de seguridad mínima, como sistemas de detección de intrusiones y monitoreo de ataques.

Utilice las herramientas adecuadas

Aunque no hay soluciones milagrosas, las herramientas de seguridad, tanto comerciales como de código abierto, son fundamentales para automatizar tareas repetitivas. Sin embargo, es importante conocer sus limitaciones y alcances para evitar un uso inadecuado o una falsa sensación de seguridad.

El diablo está en los detalles

Una revisión superficial puede generar una falsa sensación de seguridad. Es necesario analizar los hallazgos en profundidad, eliminar falsos positivos y validar cada sección de la lógica de la aplicación. Un informe incorrecto puede restar credibilidad a los resultados, por lo que la precisión y la exhaustividad son esenciales.

Utilice el código fuente cuando esté disponible

Las pruebas de caja negra son útiles para demostrar riesgos visibles, pero no bastan para asegurar una aplicación. Analizar el código fuente permite detectar vulnerabilidades ocultas que las pruebas dinámicas podrían pasar por alto, especialmente en estructuras complejas o con múltiples condiciones lógicas.

Desarrollar métricas

Un programa de seguridad efectivo requiere medir el progreso. Las métricas ayudan a identificar si la formación es suficiente, si hay mecanismos de seguridad mal comprendidos o si las vulnerabilidades disminuyen con el tiempo. Estándares como los del IEEE pueden servir como base para establecer indicadores claros y comparables.

Documentar los resultados de la prueba

El cierre del proceso de pruebas debe incluir un informe formal con las acciones realizadas, los responsables, las fechas y los hallazgos. El informe debe ser claro para todas las partes:

• Los propietarios del negocio deben comprender los riesgos y autorizar mitigaciones.
• Los desarrolladores deben recibir instrucciones precisas sobre las funciones afectadas y cómo corregirlas.
• Los evaluadores deben poder reproducir los resultados.

Usar plantillas estandarizadas simplifica la documentación, garantiza coherencia y evita omisiones. Una buena documentación convierte las pruebas en una herramienta de mejora continua y de aprendizaje para toda la organización.

Técnicas de prueba explicadas

Esta sección ofrece una visión general de las principales técnicas de prueba de seguridad utilizadas dentro de un programa de evaluación. No se describen metodologías específicas, sino los principios generales, ventajas y desventajas de cada enfoque. Estas técnicas —inspecciones manuales, modelado de amenazas, revisión de código y pruebas de penetración— sirven como base para el marco que se detalla en el capítulo siguiente.

Inspecciones y revisiones manuales

Las inspecciones manuales consisten en revisiones humanas destinadas a evaluar la seguridad de personas, políticas, procesos y decisiones tecnológicas, como diseños arquitectónicos. Se realizan mediante entrevistas, análisis de documentación o revisión de los procedimientos del ciclo de vida del desarrollo de software.

A pesar de su simplicidad, son una de las técnicas más poderosas y flexibles, ya que permiten detectar rápidamente inconsistencias o riesgos a través de la observación directa y el razonamiento humano. Este método también ayuda a verificar si el personal realmente comprende las políticas de seguridad y posee las competencias adecuadas.

Ventajas:

• No requiere tecnología especializada.
• Se adapta a diversas situaciones.
• Fomenta el trabajo en equipo y puede aplicarse desde las primeras fases del SDLC.

Desventajas:

• Requiere tiempo y documentación disponible.
• Su eficacia depende en gran medida del criterio y experiencia del evaluador.

Modelado de amenazas

El modelado de amenazas ayuda a los diseñadores de sistemas a anticipar los riesgos de seguridad que podrían afectar a una aplicación, funcionando como una evaluación de riesgos específica. Permite priorizar recursos y definir estrategias de mitigación basadas en las partes del sistema más expuestas. Debe realizarse al inicio del SDLC y actualizarse a medida que el desarrollo avanza.

Se recomienda seguir el estándar NIST 800-30, que incluye los pasos de descomponer la aplicación, clasificar activos, identificar vulnerabilidades y amenazas potenciales, y crear estrategias de mitigación. El resultado suele ser una combinación de diagramas y listas que reflejan los escenarios de ataque y sus contramedidas.

Ventajas:

• Permite ver el sistema desde la perspectiva de un atacante.
• Flexible y aplicable desde las primeras etapas del SDLC.

Desventajas:

• Un buen modelo de amenazas no garantiza, por sí solo, un software seguro.

Revisión del código fuente

La revisión del código fuente consiste en analizar manualmente el código de una aplicación para identificar vulnerabilidades. Es la técnica más precisa y completa para detectar problemas de seguridad, ya que toda la información sobre el comportamiento de la aplicación está contenida en el código.

Permite descubrir errores difíciles de detectar mediante otras pruebas, como defectos en la lógica de negocio, fallos de concurrencia, problemas de control de acceso o debilidades criptográficas. También puede revelar código malicioso oculto (puertas traseras, bombas lógicas o troyanos). Aunque requiere revisores expertos, es una de las herramientas más efectivas para lograr integridad y exactitud en los resultados.

Ventajas:

• Máxima precisión e integridad en la detección.
• Rápida cuando se realiza por personal experimentado.

Desventajas:

• Requiere desarrolladores con alta capacitación en seguridad.
• No detecta errores de ejecución en tiempo real.
• El código analizado puede diferir del realmente implementado.

Pruebas de penetración

Las pruebas de penetración (también conocidas como pentesting, pruebas de caja negra o hacking ético) consisten en simular ataques reales contra un sistema o aplicación, sin acceso al código fuente. El objetivo es detectar y explotar vulnerabilidades desde la perspectiva de un atacante.

Aunque son muy efectivas en entornos de red, su aplicación a las aplicaciones web es más compleja, dado que cada aplicación suele ser única. Las herramientas automatizadas pueden apoyar el proceso, pero no reemplazan la investigación manual ni la creatividad del evaluador.

El pentesting no debe ser la única técnica de seguridad, ya que solo revela una pequeña muestra de los posibles riesgos. Sin embargo, es útil para validar la corrección de vulnerabilidades previamente identificadas o comprobar la seguridad del código en producción.

Ventajas:

• Puede realizarse rápidamente y con menor costo.
• Requiere un nivel técnico más accesible que la revisión de código.
• Evalúa directamente el software en uso real.

Desventajas:

• Suele realizarse demasiado tarde en el SDLC.
• Solo mide el impacto superficial (ataques de “frente”) y no aborda causas estructurales.

En conjunto, estas técnicas deben complementarse entre sí dentro de un programa de pruebas integral. Las inspecciones y el modelado de amenazas aportan visión preventiva, la revisión de código ofrece precisión técnica, y el pentesting valida los resultados en un entorno real, garantizando una evaluación completa de la seguridad de las aplicaciones.

La necesidad de un enfoque equilibrado

No existe una técnica única que cubra todas las pruebas de seguridad. Aunque el pentesting ha sido históricamente el enfoque predominante, por sí solo llega tarde en el SDLC y no aborda muchos problemas. Lo adecuado es un enfoque combinado que abarque revisiones manuales, técnicas y automatizadas (incluidas en CI/CD), aplicadas en todas las fases del SDLC. Si solo puede aplicarse una técnica (p. ej., pentesting sin acceso a código), es mejor que nada, pero conviene cuestionar las restricciones y explorar pruebas más completas. La proporción del esfuerzo debe priorizar las primeras etapas del desarrollo y distribuirse también por tipo de técnica, ajustándose a la madurez del proceso y la cultura organizacional.

Proporción del esfuerzo de prueba en SDLC

La siguiente figura muestra una representación proporcional típica superpuesta a técnicas de prueba.

Proporción del esfuerzo de prueba según la técnica de prueba

Una nota sobre los escáneres de aplicaciones web

Los escáneres automatizados tienen un lugar claro, pero la caja negra automatizada no es completamente efectiva. Deben usarse conociendo sus límites y planificando el marco de pruebas en consecuencia. El OWASP Benchmark permite medir velocidad, cobertura y precisión de estas herramientas para entender su utilidad real.

Ejemplo 1: Parámetros mágicos

Imagine una aplicación web sencilla que acepta un par nombre-valor de «magic» y luego el valor. Para simplificar, la solicitud GET podría ser:http://www.host/application?magic=value

Para simplificar aún más el ejemplo, los valores en este caso solo pueden ser caracteres ASCII a – z (mayúsculas o minúsculas) y números enteros 0 – 9. Los diseñadores de esta aplicación crearon una puerta trasera administrativa durante las pruebas, pero la ofuscaron para evitar que un observador casual la descubriera. Al enviar el valor sf8g7sfjdsurtsdieerwqredsgnfg8d (30 caracteres), el usuario iniciará sesión y accederá a una pantalla administrativa con control total de la aplicación. La solicitud HTTP ahora es:http://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d

Dado que todos los demás parámetros eran campos simples de dos y tres caracteres, no es posible empezar a adivinar combinaciones de aproximadamente 28 caracteres. Un escáner de aplicaciones web tendría que forzar (o adivinar) todo el espacio de claves de 30 caracteres. Esto supone hasta 30\^28 permutaciones, o billones de solicitudes HTTP. Eso es un electrón en un pajar digital. El código para esta comprobación de parámetro mágico de ejemplo podría verse así:

Ejemplo 2: Criptografía incorrecta

Un esquema de inicio de sesión entre sitios basado en MD5(username:date) puede permitir suplantación si se comprende el mecanismo. Un escáner de caja negra solo ve un hash cambiante y no detecta el fallo de diseño. Inspecciones manuales/revisión de código lo descubren rápidamente.

Una nota sobre las herramientas de revisión de código fuente estático

El análisis estático es esencial, pero no basta por sí solo: no capta fallos de diseño ni contexto, y requiere validación manual de hallazgos. Es muy útil para errores de codificación, integrándose dentro de un programa de pruebas más amplio.

Derivación de requisitos de pruebas de seguridad

Un programa exitoso necesita objetivos claros expresados como requisitos de seguridad. Deben derivarse de normas y regulaciones, de requisitos positivos (lo que la app debe hacer) y negativos (lo que no debe ocurrir). Estos requisitos impulsan las pruebas a lo largo del SDLC y permiten gestionar riesgos con base en evidencia.

Objetivos de la prueba

1. Validar que los controles funcionan (confidencialidad, integridad, disponibilidad del dato y del servicio) conforme a los requisitos.
2. Verificar que se implementan sin vulnerabilidades, incluidas las comunes (p. ej., Top 10 de OWASP) y las identificadas previamente (modelado de amenazas, análisis de código, pentesting).

Documentación de requisitos de seguridad

Parten de los requisitos de negocio (propósito, datos a proteger, cumplimiento aplicable). Se listan regulaciones/estándares/políticas relevantes (p. ej., sectoriales o regionales) y se traducen en controles técnicos. Ejemplos:

• En finanzas, el FFIEC exige controles multicapa y MFA para mitigar autenticación débil.
• Para datos de tarjeta, PCI DSS prohíbe almacenar PIN/CVV2 y exige cifrado en reposo y tránsito, y enmascarado en visualización.
  También se incluyen normas internas (p. ej., complejidad de contraseñas). El cumplimiento debe documentarse y validarse con pruebas.

Validación de requisitos de seguridad

Desde funcionalidad, la validación es el fin de las pruebas; desde gestión de riesgos, es el objetivo de las evaluaciones. Se comprueba la presencia y eficacia de controles (autenticación, autorización, cifrado) y su alineación con estándares de algoritmos y claves (p. ej., SHA-256, RSA, AES; tamaños mínimos).

La validación ocurre en distintas fases con artefactos y métodos distintos: modelado de amenazas (diseño), revisión/ análisis de código (desarrollo) y pentesting (pruebas/validación). Combinar resultados mejora la calidad de los casos de prueba y la certeza del hallazgo (p. ej., inyección SQL detectada en caja negra y confirmada con lectura de código para construir el vector exacto).

Taxonomías de amenazas y contramedidas

Definir requisitos en términos de amenazas y causas raíz facilita verificar que los controles mitigan la exposición. STRIDE (spoofing, tampering, repudiation, information disclosure, DoS, elevation of privilege) clasifica amenazas; las causas raíz se categorizan como fallos de diseño, errores de codificación o configuraciones inseguras.

Esto aplica también a estándares de codificación segura: p. ej., prohibir hashes de contraseñas sin sal y validarlo en revisiones de código.

Pruebas de seguridad y análisis de riesgos

Mantener una base de conocimiento de vulnerabilidades (tipo, causa raíz, mitigación, apps afectadas) permite medir efectividad, calcular probabilidad/exposición y priorizar remediaciones (alto/medio vs. bajo). Asociar vulnerabilidades comunes (Top 10) con impactos (phishing, robo de identidad, compromiso, pérdidas financieras, daño reputacional) ayuda a diseñar baterías de pruebas por riesgo.

Derivación de requisitos de pruebas funcionales y no funcionales

Requisitos de seguridad funcional (positivos)

Definen qué debe hacer el control (p. ej., bloqueo tras N intentos, complejidad mínima, ocultar datos sensibles). Deben ser orientados a función y verificables (aprobado/reprobado).

Requisitos de seguridad basados en el riesgo (negativos)

Definen lo que no debe ocurrir (alteración de datos, transacciones no autorizadas). Son más difíciles de probar y se sustentan en análisis de riesgos y modelado de amenazas, documentando contramedidas (p. ej., cifrado en tránsito/almacenamiento, hash + sal, bloqueo de cuentas, mensajes de error genéricos, autenticación mutua).

Derivación de requisitos de pruebas de seguridad a través de casos de uso y mal uso

Los casos de uso describen el funcionamiento esperado; los casos de mal uso/abuso modelan usos maliciosos. Representarlos gráficamente ayuda a detectar fallos y derivar contramedidas.

Ejemplo (autenticación):

• Paso 1 (funcional): usuario ingresa usuario/contraseña; la app autentica y muestra errores específicos al fallar.
• Paso 2 (negativo): atacante realiza fuerza bruta y enumeración por mensajes de error; contraseñas cortas (p. ej., 4 dígitos) se quiebran con intentos limitados.
• Paso 3 (modelado): graficar acciones del usuario y del atacante para derivar acciones de mitigación de la aplicación.

Caso de uso y mal uso

• Paso 4 (requisitos): complejidad de contraseñas alineada a estándares, bloqueo tras cinco intentos, mensajes de error genéricos.
  Estos requisitos deben documentarse y probarse.

Esta imagen muestra un flujo de autenticación segura y cómo una aplicación puede protegerse frente a ataques comunes dirigidos al proceso de inicio de sesión.

El diagrama se divide en tres actores principales: Usuario, Aplicación/Servidor y Atacante (Hacker o usuario malicioso). Cada parte desempeña un papel dentro del proceso, y las líneas de color rojo y verde representan, respectivamente, amenazas y medidas de mitigación.

Acciones de mitigación

La estructura está organizada verticalmente, separando al usuario legítimo a la izquierda y al atacante a la derecha, mientras que en el centro se encuentran las acciones de la aplicación. El flujo comienza con el usuario ingresando su nombre de usuario y contraseña. Este es el punto de partida natural de cualquier sistema de autenticación. Inmediatamente después, la aplicación realiza el proceso de autenticación, comparando las credenciales recibidas con las almacenadas. Aquí aparece el primer riesgo representado por una flecha roja que se dirige hacia un atacante: los intentos de autenticación por fuerza bruta, donde un atacante prueba combinaciones repetidas hasta adivinar una contraseña válida.

Después de la autenticación, si los datos no son correctos, la aplicación muestra un mensaje de error genérico. Esta es una medida importante, porque evita dar pistas sobre si el usuario existe o si el error provino de la contraseña, mitigando así la capacidad de un atacante para identificar cuentas válidas. Esto está reforzado en el diagrama mediante flechas verdes, que muestran cómo esta práctica reduce ataques de harvesting o enumeración de usuarios, donde un atacante intenta adivinar qué cuentas existen basándose en mensajes del sistema.

A continuación, aparece la medida de bloquear una cuenta tras un número determinado de intentos fallidos. Esta mitigación está conectada directamente con las amenazas de fuerza bruta y ataques de diccionario. El objetivo es frenar la repetición masiva de intentos, haciendo que el atacante no pueda seguir probando combinaciones indefinidamente.

Finalmente se muestra la validación de la complejidad mínima de la contraseña, otro control fundamental para dificultar ataques de diccionario, ya que obliga a los usuarios a crear contraseñas menos predecibles y más resistentes.

El diagrama resume de manera muy pedagógica la interacción entre las acciones legítimas del usuario, el comportamiento de un atacante y las defensas que la aplicación debe implementar. Cada amenaza aparece en rojo y cada mitigación en verde, lo que facilita entender cómo cada medida refuerza un punto crítico del proceso de autenticación.

Etapas del proceso de autenticación

1. El usuario ingresa sus credenciales
   El proceso comienza cuando el usuario introduce su nombre de usuario y contraseña. Este es el punto de entrada donde los atacantes suelen intentar explotar vulnerabilidades, como el uso de contraseñas débiles o reutilizadas.
2. Autenticación del usuario
   La aplicación valida las credenciales frente a su base de datos.
   • Amenaza: Aquí se produce el riesgo de ataques de fuerza bruta, donde el atacante prueba múltiples combinaciones hasta acertar con la contraseña correcta.
   • Mitigación: Implementar políticas como bloqueo temporal tras varios intentos fallidos, uso de CAPTCHA o autenticación multifactor (MFA).
3. Mensajes de error genéricos
   Si el inicio de sesión falla, el servidor debe mostrar un mensaje genérico (“Credenciales inválidas”) sin indicar si el error fue por usuario o contraseña.
   • Mitigación: Esto previene la recolección de cuentas válidas, ya que los atacantes no pueden distinguir si un usuario existe o no en el sistema.
4. Bloqueo de cuenta tras múltiples intentos fallidos
   Después de un número determinado de intentos erróneos (N), la cuenta debe bloquearse temporalmente.
   • Mitigación: Esta medida frena los ataques por diccionario y la automatización de intentos de fuerza bruta.
5. Validación de contraseñas fuertes
   El sistema debe exigir contraseñas con una longitud mínima y un nivel de complejidad adecuado (letras, números, símbolos, mayúsculas).
   • Mitigación: Esto reduce la efectividad de ataques basados en listas de contraseñas comunes.

Ataques comunes representados

• Fuerza bruta: El atacante intenta adivinar contraseñas por repetición.
• Ataques por diccionario: Se usan listas de contraseñas comunes o filtradas previamente.
• Recolección de usuarios válidos: Se analizan mensajes de error o respuestas del sistema para identificar cuentas existentes.

El diagrama resume los principales controles de seguridad que toda aplicación debe implementar para proteger el proceso de autenticación. Al aplicar buenas prácticas como mensajes genéricos, bloqueos por intentos fallidos y contraseñas seguras, se mitiga significativamente el riesgo de accesos no autorizados. En pocas palabras, una autenticación segura no solo depende del usuario, sino de cómo el sistema responde a los intentos fallidos y protege la información sensible.

Pruebas de seguridad integradas en los flujos de trabajo de desarrollo y pruebas

Integrar la seguridad en los flujos de trabajo del SDLC permite verificar controles y vulnerabilidades desde el inicio hasta la validación final. Combina análisis estático y dinámico, revisiones formales y casos de prueba documentados, y establece decisiones de liberación basadas en evidencias y criterios de riesgo.

Pruebas de seguridad en el flujo de trabajo de desarrollo

Durante desarrollo, cada componente (funciones, clases, APIs, libs, binarios) debe someterse a análisis estático (cumplimiento de codificación segura y detección de fallos) y pruebas unitarias de seguridad (validación en tiempo de ejecución). Un desarrollador sénior lidera la revisión segura del código y decide su integración, registrando hallazgos y aprobaciones en herramientas de gestión de cambios/defectos.

Pruebas de seguridad en el flujo de trabajo de pruebas

Tras integrar componentes, las pruebas a nivel integrado/sistema validan funcionalidad de seguridad y exposición real a vulnerabilidades mediante enfoques caja blanca, gris y negra. Ingenieros de prueba especializados ejecutan casos documentados y, si la aplicación avanza a aceptación de usuario, se coordinan roles: QA para funcional y especialistas (internos o externos) para seguridad. Las recomendaciones pueden implicar cambios de código, diseño o configuración, y los riesgos se tratan según el proceso de gestión de riesgos (p. ej., corregir obligatoriamente los de alto riesgo).

Pruebas de seguridad del desarrollador

Pruebas de seguridad en la fase de codificación: pruebas unitarias

El objetivo del desarrollador es asegurar que el código cumple estándares de codificación segura y que las correcciones exigidas por revisiones/estático se implementan y funcionan. Se promueve un suite genérico de pruebas de seguridad integrado al framework de unit tests (JUnit/NUnit/CUnit) para controles como:

• Identidad, autenticación y autorización
• Validación/codificación de entrada
• Criptografía
• Gestión de usuarios/sesiones
• Manejo de errores/excepciones
• Auditoría y registro

Estas pruebas validan entradas/salidas, límites, comprobaciones de authZ, protección de datos, tratamiento seguro de excepciones (evitar DoS o escaladas), y logging sin fuga de información. Los escenarios de uso/abuso alimentan los casos de prueba (p. ej., bloqueo de cuenta y no eludible). Los resultados del análisis estático pueden bloquear commits con gravedad alta/media hasta su corrección; también se verifica la seguridad de dependencias de terceros antes de integrarlas.

Pruebas de seguridad de los probadores funcionales

Pruebas durante integración y validación: sistema integrado y funcionamiento

Se valida la defensa en profundidad y se simulan ataques realistas en el entorno de integración: primero con técnicas básicas (forzar estados de error, observar excepciones p. ej., indicios de SQLi), y luego con técnicas avanzadas (fuzzing, inyección de fallos, cobertura, ingeniería inversa), además de revisión de código y pentesting. La guía debe incluir procedimientos y herramientas y una checklist/cookbook de pruebas para amenazas comunes (spoofing, info-disclosure, buffer overflows, format strings, SQLi/XSS, XML/SOAP, canonicalización, DoS, .NET/ActiveX).

El siguiente nivel es UAT/aceptación, ambiente casi idéntico a producción (con datos de prueba), ideal para detectar fallos de configuración críticos (principio de mínimo privilegio, TLS/SSL válido, hardening de servicios, limpieza de contenido en el webroot). Validar aquí reduce el riesgo de promover a producción una versión con brechas explotables.

Análisis e informes de datos de pruebas de seguridad

Objetivos de las métricas y mediciones de pruebas de seguridad

Las métricas deben servir para analizar y gestionar riesgos: cuantificar la seguridad (p. ej., número total de vulnerabilidades), fijar objetivos medibles (reducir vulnerabilidades antes de producción) y comparar contra líneas base para evidenciar mejoras cuando se integran pruebas tempranas. Al igual que en calidad, pueden clasificarse por causa raíz (fallo de diseño vs. error de codificación) y por esfuerzo de remediación (horas, herramientas, costos).

En seguridad, además, los datos se categorizan por amenaza, exposición e impacto para estimar riesgo (alto/medio/bajo), combinando análisis estático y validación dinámica/pentesting. Deben apoyar puntos de control del SDLC, mostrar contención (detección y corrección en la misma fase) y justificar mayor frecuencia de pruebas en aplicaciones más grandes. Las metas deben ser concretas y con plazo (p. ej., “–30% vulnerabilidades” o “corregir antes de beta”). Las métricas pueden ser absolutas (hallazgos por revisión de código) o comparativas (revisiones vs. pentesting) y también apoyar cumplimiento, gestión de procesos, causas raíz y análisis costo–beneficio. Las preguntas a responder incluyen tendencia de vulnerabilidades, cumplimiento de requisitos, causas principales, efectividad por técnica/herramienta/equipo, porcentaje de alto riesgo y hallazgos por revisión de código o diseño.

Las herramientas deben seleccionarse con taxonomía clara y entendiendo su alcance: no prueban lo desconocido ni garantizan ausencia de fallos; depender solo de automatización genera falsa confianza. La experiencia del evaluador y la formación son determinantes para la calidad del análisis.

Requisitos de informes

La postura de seguridad se informa por efecto (número y severidad de vulnerabilidades) y causa (errores de codificación, fallos de arquitectura, configuraciones). La severidad suele medirse con CVSS. Un buen informe incluye:

• Tipo de vulnerabilidad y amenaza asociada.
• Causa raíz (p. ej., código infractor).
• Técnica de prueba utilizada (caja blanca/negra/gris, herramienta).
• Remediación/contramedida específica con ejemplos o cambios de configuración.
• Severidad/riesgo (alta/media/baja o puntuación CVSS).
  Además, debe indicar cómo revalidar: si fue caja blanca, qué análisis estático/revisión repetir; si fue caja negra, cómo reproducir desde el cliente/FRONT. Esta trazabilidad permite priorizar y asignar riesgos (aceptar, mitigar o transferir).

Casos de negocios

Las métricas deben aportar valor a cada parte interesada:

• Desarrolladores: evidencian codificación segura, justifican uso de análisis estático, estándares y formación.
• Gerentes de proyecto: controlan avance, recursos y mejoras sin afectar hitos.
• Responsables de seguridad (ISO): muestran que probar en el SDLC reduce trabajo posterior en producción.
• Auditores de cumplimiento: proporcionan garantía de que el estándar se aborda mediante revisiones.
• CIO/CISO: habilitan análisis costo–beneficio/ROI al cuantificar la reducción de riesgo lograda por actividades/herramientas frente a su costo.

Para derivar ROI, se compara el riesgo residual (exposición menos eficacia de pruebas) con el costo de las actividades/herramientas adoptadas, permitiendo decisiones informadas de inversión en seguridad.

El marco de pruebas de seguridad web

Fase 1 antes de que comience el desarrollo

Fase 1.1 Definir un SDLC

Antes de comenzar el desarrollo de la aplicación, se debe definir un SDLC adecuado donde la seguridad sea inherente a cada etapa.

Fase 1.2 Revisión de políticas y estándares

Asegúrese de que existan políticas, estándares y documentación adecuados. La documentación es fundamental, ya que proporciona a los equipos de desarrollo directrices y políticas que pueden seguir. Las personas solo pueden hacer lo correcto si saben qué es lo correcto.

Si la aplicación se va a desarrollar en Java, es fundamental contar con un estándar de codificación segura de Java. Si la aplicación va a utilizar criptografía, también es fundamental contar con un estándar de criptografía. Ninguna política ni estándar puede abarcar todas las situaciones a las que se enfrentará el equipo de desarrollo. Al documentar los problemas comunes y predecibles, se reducirán las decisiones que se deben tomar durante el proceso de desarrollo.

Fase 1.3 Desarrollar criterios de medición y métricas y garantizar la trazabilidad

Antes de comenzar el desarrollo, planifique el programa de medición. Al definir los criterios que deben medirse, se obtiene visibilidad de los defectos tanto del proceso como del producto. Es fundamental definir las métricas antes de comenzar el desarrollo, ya que podría ser necesario modificar el proceso para capturar los datos.

Fase 2 durante la definición y el diseño

Fase 2.1 Revisión de los requisitos de seguridad

Los requisitos de seguridad definen el funcionamiento de una aplicación desde una perspectiva de seguridad. Es fundamental probarlos. En este caso, probar significa comprobar las suposiciones formuladas en los requisitos y comprobar si existen lagunas en sus definiciones.

Por ejemplo, si existe un requisito de seguridad que exige que los usuarios se registren para acceder a la sección de documentación técnica de un sitio web, ¿significa esto que el usuario debe registrarse en el sistema o debe autenticarse? Asegúrese de que los requisitos sean lo más claros posible.

Al buscar brechas en los requisitos, considere observar mecanismos de seguridad como:

• Gestión de usuarios
• Autenticación
• Autorización
• Confidencialidad de los datos
• Integridad
• Responsabilidad
• Gestión de sesiones
• Seguridad del transporte
• Segregación del sistema por niveles
• Cumplimiento legislativo y de normas (incluidas las normas de privacidad, gubernamentales y de la industria)

Fase 2.2 Revisión del diseño y la arquitectura

Las aplicaciones deben contar con un diseño y una arquitectura documentados. Esta documentación puede incluir modelos, documentos textuales y otros elementos similares. Es fundamental probar estos elementos para garantizar que el diseño y la arquitectura garanticen el nivel de seguridad adecuado, según lo definido en los requisitos.

Identificar fallas de seguridad en la fase de diseño no solo es una de las maneras más rentables de identificarlas, sino también una de las más efectivas para implementar cambios. Por ejemplo, si se identifica que el diseño requiere que las decisiones de autorización se tomen en múltiples ubicaciones, puede ser conveniente considerar un componente de autorización central. Si la aplicación realiza la validación de datos en múltiples ubicaciones, puede ser conveniente desarrollar un marco de validación central (es decir, solucionar la validación de entrada en un solo lugar, en lugar de en cientos, es mucho más económico).

Si se descubren debilidades, deben comunicarse al arquitecto del sistema para que busque enfoques alternativos.

Fase 2.3 Crear y revisar modelos UML

Una vez completados el diseño y la arquitectura, cree modelos de Lenguaje Unificado de Modelado (UML) que describan el funcionamiento de la aplicación. En algunos casos, estos modelos podrían ya estar disponibles. Utilícelos para confirmar con los diseñadores de sistemas una comprensión precisa del funcionamiento de la aplicación. Si se detectan debilidades, se deben comunicar al arquitecto de sistemas para que considere alternativas.

Fase 2.4 Crear y revisar modelos de amenazas

Con las revisiones de diseño y arquitectura, y los modelos UML que explican exactamente el funcionamiento del sistema, realice un ejercicio de modelado de amenazas. Desarrolle escenarios de amenazas realistas. Analice el diseño y la arquitectura para garantizar que estas amenazas se hayan mitigado, aceptado por la empresa o asignado a un tercero, como una aseguradora. Si las amenazas identificadas no tienen estrategias de mitigación, revise el diseño y la arquitectura con el arquitecto de sistemas para modificarlos.

Fase 3 durante el desarrollo

En teoría, el desarrollo consiste en la implementación de un diseño. Sin embargo, en la práctica, durante el desarrollo del código se toman muchas decisiones de diseño. A menudo, se trata de decisiones menores, demasiado detalladas para ser descritas en el diseño, o de problemas para los que no se ofrecieron políticas ni directrices estándar. Si el diseño y la arquitectura no fueron adecuados, el desarrollador deberá tomar muchas decisiones. Si las políticas y los estándares fueron insuficientes, deberá tomar aún más decisiones.

Tutorial del código de la fase 3.1

El equipo de seguridad debe realizar un recorrido de código con los desarrolladores y, en algunos casos, con los arquitectos del sistema. Un recorrido de código es una revisión general del código durante la cual los desarrolladores pueden explicar la lógica y el flujo del código implementado. Permite al equipo de revisión de código obtener una comprensión general del código y a los desarrolladores explicar por qué ciertos elementos se desarrollaron de la forma en que se desarrollaron.

El propósito no es realizar una revisión de código, sino comprender a un alto nivel el flujo, el diseño y la estructura del código que compone la aplicación.

Revisiones de código de la fase 3.2

Armado con una buena comprensión de cómo está estructurado el código y por qué ciertas cosas se codificaron de la forma en que se codificaron, el evaluador ahora puede examinar el código real en busca de defectos de seguridad.

Las revisiones de código estático validan el código comparándolo con un conjunto de listas de verificación, que incluyen:

• Requisitos comerciales de disponibilidad, confidencialidad e integridad;
• Guía OWASP o listas de verificación de las 10 principales exposiciones técnicas (dependiendo de la profundidad de la revisión);
• Cuestiones específicas relacionadas con el lenguaje o el marco en uso, como el documento Scarlet para PHP o las listas de verificación de codificación segura de Microsoft para ASP.NET ; y
• Cualquier requisito específico de la industria, como Sarbanes-Oxley 404, COPPA, ISO/IEC 27002, APRA, HIPAA, pautas para comerciantes de Visa u otros regímenes regulatorios.

En términos de retorno de la inversión (principalmente tiempo), las revisiones estáticas de código generan resultados de mucha mayor calidad que cualquier otro método de revisión de seguridad y dependen menos de la habilidad del revisor. Sin embargo, no son una solución milagrosa y deben considerarse cuidadosamente dentro de un régimen de pruebas de espectro completo.

Para obtener más detalles sobre las listas de verificación de OWASP, consulte la última edición de OWASP Top 10 .

Fase 4 durante el despliegue

Fase 4.1 Pruebas de penetración de aplicaciones

Tras probar los requisitos, analizar el diseño y realizar la revisión del código, se podría asumir que se han detectado todos los problemas. Ojalá así sea, pero realizar pruebas de penetración en la aplicación tras su implementación proporciona una comprobación adicional para garantizar que no se haya pasado nada por alto.

Fase 4.2 Pruebas de gestión de la configuración

La prueba de penetración de la aplicación debe incluir un análisis de cómo se implementó y protegió la infraestructura. Es importante revisar los aspectos de configuración, por pequeños que sean, para garantizar que no queden valores predeterminados que puedan ser vulnerables a la explotación.

Fase 5 Durante el Mantenimiento y las Operaciones

Fase 5.1 Realizar revisiones de gestión operativa

Es necesario que exista un proceso que detalle cómo se gestiona el aspecto operativo tanto de la aplicación como de la infraestructura.

Fase 5.2 Realizar controles de salud periódicos

Se deben realizar controles de salud mensuales o trimestrales tanto en la aplicación como en la infraestructura para garantizar que no se hayan introducido nuevos riesgos de seguridad y que el nivel de seguridad siga intacto.

Fase 5.3 Garantizar la verificación del cambio

Tras la aprobación y prueba de cada cambio en el entorno de control de calidad y su implementación en el entorno de producción, es fundamental verificarlo para garantizar que el nivel de seguridad no se haya visto afectado. Esto debe integrarse en el proceso de gestión de cambios.

Un flujo de trabajo típico de pruebas SDLC

La siguiente figura muestra un flujo de trabajo de pruebas SDLC típico.

La imagen muestra un diagrama muy limpio y estructurado que explica cómo se integra la seguridad dentro del ciclo de vida del desarrollo de software, siguiendo un enfoque claro por etapas. Está organizada verticalmente, comenzando antes del desarrollo y avanzando hasta la fase de mantenimiento, mientras una flecha a la derecha acompaña todo el recorrido indicando que métricas, criterios, mediciones y trazabilidad deben estar presentes durante todo el proceso.

En la parte superior aparece la etapa Before Development, donde se representa el primer paso: revisar el proceso SDLC existente. Esto sirve como punto de partida para entender cómo se trabaja actualmente y qué ajustes serán necesarios para integrar seguridad. Justo debajo se separan dos actividades fundamentales, la revisión de políticas y la revisión de estándares, que funcionan como la base para definir correctamente las reglas y expectativas del desarrollo seguro.

Más abajo llegamos a la fase de Definition and Design, donde el diagrama muestra varias actividades paralelas que ayudan a construir un diseño seguro desde el principio. Ahí se incluyen la revisión de requisitos, la revisión de diseño y arquitectura, la creación o revisión de modelos UML y la creación o revisión de modelos de amenazas. Cada uno de estos pasos permite comprender el sistema, visualizar su funcionamiento y detectar posibles riesgos incluso antes de escribir una línea de código.

En la fase de Development se representan tres actividades clave: la revisión de código, los code walkthroughs y las pruebas unitarias y de sistema. Estas etapas buscan asegurar que la implementación respete los estándares definidos, detectar errores temprano y validar el comportamiento del software a medida que se desarrolla.

Después aparece la sección de Deployment, que introduce actividades orientadas a asegurar que el sistema se despliegue correctamente sin abrir nuevas vulnerabilidades. Se incluyen pruebas de penetración, revisión de gestión de configuraciones, nuevas pruebas de unidad y sistema, y finalmente pruebas de aceptación. Esto confirma que el sistema no solo funciona, sino que está preparado para ser puesto en producción de forma segura.

Por último, en la fase de Maintenance, se muestran tareas continuas como la verificación de cambios, los health checks, las revisiones operativas y las pruebas de regresión. Esta parte del diagrama enfatiza que la seguridad no termina con el despliegue, sino que requiere monitoreo y validación constante para mantener la integridad del sistema frente a cambios, actualizaciones o nuevas amenazas.

En conjunto, la imagen transmite que un SDLC seguro es un proceso continuo y estructurado, donde cada etapa del desarrollo incorpora actividades específicas orientadas a la seguridad. La flecha lateral recuerda de manera visual que medir, evaluar y mantener trazabilidad son prácticas transversales indispensables para lograr un software verdaderamente robusto.

Mejores prácticas para las pruebas de penetración OWASP

Ahora que hemos revisado algunas de las herramientas, también vale la pena considerar los aspectos estratégicos del pentesting. Asegurarse de cumplir con las mejores prácticas establecidas ayudará a agilizar el proceso de prueba, maximizar la eficiencia de sus esfuerzos y, en última instancia, generar aplicaciones más seguras. Profundicemos ahora en algunas de las mejores prácticas clave para las pruebas de penetración de OWASP.

Establecer objetivos y alcance claros:

es esencial definir los objetivos de una prueba de penetración, incluidos los sistemas que se probarán, los métodos de prueba que se utilizarán y los tiempos de prueba permitidos. Todas las partes involucradas deben acordar el alcance, incluido el evaluador y la organización que se está probando, para garantizar que la prueba no dañe inadvertidamente los sistemas o los datos.

Mantener consideraciones éticas y cumplimiento legal.

Los pentester siempre deben cumplir con un código de ética para realizar pruebas de manera responsable. Esto incluye respetar la privacidad de la organización, obtener la autorización adecuada antes de realizar pruebas y cumplir con todas las leyes y regulaciones pertinentes.

Actualizar periódicamente conocimientos y habilidades.

La seguridad cibernética evoluciona constantemente, por lo que los pentester deben actualizar continuamente sus conocimientos y habilidades. Deben mantenerse informados sobre las últimas vulnerabilidades, técnicas de ataque y medidas defensivas. El OWASP Top 10, por ejemplo, es un recurso clave que se actualiza periódicamente para reflejar los riesgos de seguridad de aplicaciones web más críticos.

Colaborar con equipos de desarrollo para una mejor seguridad

Los pentesters deben trabajar en estrecha colaboración con los equipos de desarrollo para ayudarlos a comprender los resultados de las pruebas e implementar las mejoras de seguridad necesarias. Por ejemplo, el kit de pruebas de penetración de OWASP proporciona herramientas como R-Builder y R-Attacker para ayudar a los evaluadores y desarrolladores a identificar y abordar vulnerabilidades como la inyección SQL y XSS.

Programas de recompensas por errores

Estos programas alientan a los investigadores independientes a encontrar e informar fallas de seguridad en el software de una organización. Luego, la organización puede corregir estas fallas antes de que actores malintencionados puedan explotarlas. El propio OWASP tiene una variedad de proyectos y herramientas que pueden ayudar a ejecutar un programa de recompensas por errores exitoso.

Huellas digitales de aplicaciones web

La toma de huellas digitales de aplicaciones web es una técnica que se utiliza para identificar el tipo y la versión de un servidor web que aloja una aplicación. Esta información puede ser crucial para identificar posibles vulnerabilidades, especialmente si los servidores ejecutan software desactualizado o sin parches. Las técnicas van desde la captura de banners, donde se realiza una solicitud HTTP y se analiza el encabezado de respuesta del servidor, hasta el uso de solicitudes con formato incorrecto y herramientas automatizadas como Netcraft, Nikto y Nmap.

RESUMEN COMPLETO DEL CAPÍTULO

Este capítulo introduce de manera profunda el marco OWASP WSTG, una guía completa para realizar pruebas de seguridad en aplicaciones web. Explica que OWASP no busca ser solo una checklist, sino un marco metodológico integral, capaz de adaptarse a distintos entornos y madurez organizacional. Presenta además las ventajas y limitaciones del enfoque.

1. OWASP WSTG y su propósito

La guía sirve como referencia práctica para planear, ejecutar y documentar pruebas de seguridad. Proporciona casos de prueba, metodologías, vectores de ataque y criterios de verificación. También incluye una checklist, una plantilla de reportes y una calculadora de riesgos.

2. Importancia del SDLC y del enfoque “Shift Left”

OWASP remarca que la seguridad debe integrarse en todas las etapas del desarrollo. Detectar fallos temprano es más barato, más eficiente y reduce el riesgo. Se explica cómo los costos aumentan a medida que la vulnerabilidad avanza por el SDLC y por qué la seguridad debe comenzar en la definición de requisitos.

3. Principios fundamentales del testing

El capítulo establece principios clave:

• No existe herramienta milagrosa.
• Pensar estratégicamente, no tácticamente.
• Integrar seguridad en el SDLC.
• Probar temprano y continuamente.
• Automación inteligente dentro de CI/CD.
• Entender el contexto del proyecto y su nivel de riesgo.
• Documentar todo y medir resultados.
• Pensar como un atacante, no como un QA tradicional.

También se explica el ciclo de vida de una vulnerabilidad y por qué el mayor riesgo ocurre entre la divulgación pública y el parche.

 

4. Técnicas de prueba

Se detallan las técnicas principales utilizadas en un programa de evaluación:

• Inspecciones manuales
• Modelado de amenazas
• Revisión de código fuente
• Pruebas de penetración (pentesting)

Cada una incluye ventajas, limitaciones y cuándo utilizarla.

5. Derivación de requisitos de seguridad

El capítulo enseña cómo transformar requisitos funcionales, no funcionales, regulaciones, casos de uso y casos de abuso en requisitos de prueba. Incluye mapeos a controles como autenticación, autorización, cifrado, manejo de errores, gestión de sesiones, etc.

Se explican taxonomías como STRIDE y cómo utilizarlas para definir amenazas y controles.

6. Pruebas de seguridad integradas en el flujo de desarrollo

El capítulo muestra cómo integrar pruebas de seguridad:

• En desarrollo (unit tests de seguridad, SAST, validación de dependencias).
• En integración y QA (DAST, fuzzing, revisión manual híbrida, hardening).
• En UAT (validación previa a producción).

7. Métricas, mediciones e informes

Se explica cómo medir:

• Tendencias de vulnerabilidades.
• Eficacia de pruebas.
• Riesgo residual.
• Causas raíz.
• ROI del programa de seguridad.

El informe debe incluir tipo de vulnerabilidad, causa raíz, técnica usada, evidencia reproducible y remediación.

8. El Marco de Pruebas OWASP

Se describe el proceso paso a paso, dividido en fases:

1. Antes del desarrollo: definir SDLC, políticas y métricas.
2. Definición y diseño: revisar requisitos, arquitectura, modelos UML y modelado de amenazas.
3. Desarrollo: walkthroughs, revisiones de código, estándares y listas de chequeo.
4. Despliegue: pentesting, pruebas de configuración, aceptación.
5. Mantenimiento: health checks, validación de cambios y revisiones operativas.

9. Pipelines de AppSec

Se presentan tres niveles:

• Primera generación: procesos manuales, herramientas aisladas, alto ruido.
• Pipelines modernos (rugged DevOps): orquestación, validación de falsos positivos, repositorio de vulnerabilidades.
• Pipelines avanzados (gasp-docker): ejecución desacoplada mediante contenedores, arquitectura basada en eventos, escalabilidad y facilidad de integración.

10. Mejores prácticas de pentesting

Incluye:

• Definir alcance y objetivos.
• Ética y cumplimiento legal.
• Actualización continua del conocimiento.
• Colaboración con desarrollo.
• Uso de bug bounty.
• Técnicas de fingerprinting y reconocimiento.

Este capítulo ofrece una visión completa, sistemática y profesional de cómo se estructura un programa de pruebas de seguridad moderno basado en OWASP.

10 preguntas que se pueden responder con lo aprendido

1. ¿Qué es el OWASP WSTG y cuál es su objetivo principal?
2. ¿Cuáles son las fases del SDLC y cómo se integra la seguridad en cada una?
3. ¿Por qué es importante aplicar el enfoque “Shift Left” en seguridad?
4. ¿Cuáles son las principales técnicas de pruebas de seguridad descritas en la guía?
5. ¿Qué papel cumple el modelado de amenazas en el ciclo de desarrollo seguro?
6. ¿Cuál es la diferencia entre pruebas de caja blanca, negra y gris?
7. ¿Qué beneficios aporta un pipeline automatizado de AppSec?
8. ¿Por qué las métricas y mediciones son fundamentales en un programa de seguridad?
9. ¿Qué prácticas deben seguirse para realizar pruebas de penetración éticas y efectivas?
10. ¿Qué componentes incluye una validación completa de requisitos de seguridad?

10 ejercicios prácticos basados en el contenido

1. Enumera las fases del SDLC e indica una actividad de seguridad clave para cada una.
2. Realiza un cuadro comparativo entre técnicas de inspección manual, revisión de código, modelado de amenazas y pentesting.
3. Simula un flujo de autenticación inseguro y propón medidas de mitigación basadas en el artículo.
4. Diseña un caso de mal uso (misuse case) y sus respectivos controles para una funcionalidad de login.
5. Elabora un checklist con al menos 5 requisitos de seguridad funcionales y no funcionales.
6. Explica cómo se validaría una vulnerabilidad detectada con pentesting desde el punto de vista organizativo y técnico.
7. Describe el ciclo de vida de una vulnerabilidad según el artículo y ejemplifícalo.
8. Crea una tabla con herramientas automáticas (SAST, DAST, SCA) y su aplicación dentro de un pipeline CI/CD.
9. Redacta un ejemplo de informe de seguridad para una falla de inyección SQL incluyendo CVSS, causa raíz y remediación.
10. Diseña una estrategia de seguridad para una app basada en el modelo WSTG y aplica una técnica distinta por etapa del SDLC.

Respuestas a las 10 preguntas

1. OWASP WSTG es la Guía de Pruebas de Seguridad Web, un marco completo que ayuda a evaluar la seguridad de aplicaciones web mediante una metodología sistemática. Su objetivo es ofrecer prácticas detalladas y medibles que cubran todo el SDLC.

1. Las fases del SDLC son:
   • Definir: requisitos funcionales y de seguridad.
   • Diseñar: arquitectura segura y modelado de amenazas.
   • Desarrollar: codificación segura y revisión de código.
   • Desplegar: configuración segura y pruebas de penetración.
   • Mantener: gestión de cambios, monitoreo y parches.
2. El enfoque Shift Left propone integrar la seguridad desde las primeras fases del SDLC. Detectar y corregir errores temprano reduce costos y aumenta la efectividad.
3. Técnicas clave:
   • Inspección manual
   • Modelado de amenazas
   • Revisión de código fuente
   • Pruebas de penetración
     Cada técnica cubre aspectos distintos del desarrollo seguro y se recomienda combinarlas.
4. El modelado de amenazas permite anticipar vulnerabilidades desde el diseño, priorizando riesgos y estableciendo controles antes de implementar.
5. Caja blanca: acceso al código y arquitectura.
   Caja negra: sin conocimiento interno, simula un atacante externo.
   Caja gris: combinación de ambas, acceso parcial.

1. Un pipeline automatizado de AppSec integra herramientas de análisis (SAST, DAST, SCA) en flujos CI/CD, permitiendo escaneo continuo, validación y remediación rápida.
2. Las métricas ayudan a evaluar avances, justificar inversiones, medir riesgos y tomar decisiones basadas en datos. Ejemplo: reducción del 30% de vulnerabilidades antes del despliegue.
3. Buenas prácticas en pentesting incluyen:
   • Definir objetivos y alcance.
   • Obtener autorizaciones legales.
   • Colaborar con desarrolladores.
   • Documentar hallazgos y usar herramientas de OWASP.
   • Ética profesional.
4. La validación completa de seguridad incluye:
   • Verificar controles técnicos.
   • Confirmar ausencia de vulnerabilidades.
   • Revisión de requisitos regulatorios.
   • Confirmación de mitigaciones efectivas.

Respuestas a los ejercicios

Fases del SDLC y actividad de seguridad:

Fase	Actividad de seguridad
Definir	Establecer requisitos de seguridad
Diseñar	Modelado de amenazas
Desarrollar	Revisión de código fuente y pruebas unitarias
Desplegar	Pruebas de penetración y configuración segura
Mantener	Monitoreo continuo, parches, gestión de cambios

Cuadro comparativo de técnicas:

Técnica	Ventajas	Desventajas
Inspección manual	Flexible y sin herramientas complejas	Requiere experiencia y tiempo
Modelado de amenazas	Prevención desde el diseño	No garantiza detección completa
Revisión de código	Alta precisión, descubre fallos lógicos	Requiere acceso al código y expertos
Pentesting	Simula ataques reales	Tarde en el SDLC, no ve causas raíz

Flujo de autenticación inseguro:

• Usuario introduce login → Error específico si usuario no existe.
• Atacante hace enumeración → Detecta usuarios válidos.
• Mitigaciones:
  • Mensajes genéricos.
  • Bloqueo tras 5 intentos.
  • Contraseñas fuertes.
  • MFA.

Caso de mal uso (login):

• Mal uso: Ataques de fuerza bruta.
• Controles:
  • Captcha.
  • Bloqueo temporal.
  • Tiempos aleatorios de respuesta.
  • Detección de IPs sospechosas.

Checklist de requisitos:

• Funcionales:
  • Bloqueo tras N intentos.
  • Uso obligatorio de HTTPS.
  • Validación de contraseñas.
  • MFA activado.
  • Timeout de sesión.
• No funcionales:
  • Cifrado en reposo con AES.
  • Log de accesos.
  • Escaneo SAST semanal.
  • Cumplimiento con GDPR.
  • Protección contra inyecciones.

Validación de vulnerabilidad:

• Técnico: reproducir con pentesting + revisión de código.
• Organizativo:
  • Registrar en DefectDojo.
  • Asignar a desarrollador.
  • Establecer CVSS.
  • Aprobar fix y volver a probar.

1. Ciclo de vida de una vulnerabilidad:

1. Descubrimiento → riesgo bajo.
2. Divulgación pública → riesgo alto.
3. Notificación al proveedor.
4. Alertas a clientes.
5. Actualización de herramientas.
6. Publicación del parche.
7. Difusión del parche.
8. Instalación → riesgo desaparece.

Herramientas en CI/CD:

Herramienta	Tipo	Uso en pipeline
Checkmarx	SAST	Revisión de código
ZAP	DAST	Pruebas dinámicas en staging
OWASP DC	SCA	Análisis de dependencias
DefectDojo	GESTIÓN	Repositorio de hallazgos

Informe de seguridad: Inyección SQL

• Vulnerabilidad: SQLi en /login.
• CVSS: 9.0 (Crítica).
• Causa raíz: concatenación directa de input.
• Reproducción: ‘ OR 1=1 –.
• Remediación: uso de consultas parametrizadas.

Estrategia basada en WSTG + técnica por fase:

Fase	Técnica aplicada
Definir	Revisión de requisitos + modelado
Diseñar	Inspección de arquitectura + UML
Desarrollar	Revisión de código + pruebas unitarias
Desplegar	Pentesting + revisión configuración
Mantener	Health checks + regresión

¡Llegaste al final!

Aquí no solo aprendiste técnicas, sino algo todavía más valioso: cómo piensa, evalúa y trabaja un profesional real de seguridad. Ya no ves las pruebas de seguridad como simples ataques aislados, sino como parte de un proceso estructurado, medible y orientado a riesgos.

Ahora comprendés:

• Qué es WSTG y cómo usarlo como marco profesional.
• Cómo integrar seguridad durante todo el SDLC.
• Qué técnicas existen, cuándo aplicarlas y cómo combinarlas.
• Cómo funcionan pipelines de AppSec modernos y automatizados.
• Cómo documentar, medir y mejorar continuamente.

Este conocimiento te acompañará durante toda tu carrera. Cada pentest, cada auditoría, cada revisión de código o pipeline que construyas estará influenciado por estos fundamentos. Dominar la metodología es lo que diferencia a un hacker improvisado de un profesional completo y competente.

Seguí avanzando. Cada capítulo te acerca más a convertirte en un verdadero especialista en seguridad ofensiva y defensiva.