En este capítulo te adentrarás en uno de los pilares fundamentales del hacking ético y la seguridad del software: el ecosistema OWASP. Comprenderás cómo esta organización se ha convertido en el estándar mundial para evaluar, asegurar y mejorar la seguridad en aplicaciones web, móviles y de escritorio. Como futuro hacker o profesional de ciberseguridad, dominar OWASP no solo ampliará tu capacidad técnica, sino que te permitirá trabajar con metodologías reconocidas por empresas, gobiernos y auditorías internacionales.

A lo largo del capítulo aprenderás:

• Qué es OWASP y por qué es clave en el mundo del pentesting.
• Cómo funciona el OWASP Top 10 (2021 y 2025), su evolución y su importancia en el análisis de riesgos.
• Cómo integrar la seguridad en el ciclo de vida del software mediante SDLC/SSDLC.

Todo este conocimiento es esencial para tu carrera porque desarrolla un pensamiento crítico, metodológico y profesional: OWASP te enseña no solo a encontrar vulnerabilidades, sino a entender por qué existen, cómo prevenirlas y cómo mitigar su impacto real.

¿Qué es OWASP?

Significa Proyecto Abierto de Seguridad de Aplicaciones Web, una piedra angular vital del panorama de la seguridad cibernética. Esta organización internacional sin fines de lucro se dedica a mejorar la seguridad del software. Si está ejecutando Kali Linux, ya sea como máquina virtual o como sistema operativo principal , es probable que ya haya encontrado algunas herramientas OWASP como Zed Attack Proxy (ZAP), que viene preinstalado. Son recursos invaluables tanto para los recién llegados como para los profesionales experimentados en el campo del hacking y ciberseguridad.

La misión de OWASP se extiende más allá del desarrollo de herramientas. Están comprometidos a promover prácticas de codificación segura, proporcionar recursos sobre los riesgos de seguridad predominantes y fomentar una comunidad centrada en la seguridad de las aplicaciones web. Entre las muchas aportaciones de OWASP destaca el OWASP Top 10 . Es una lista actualizada periódicamente de los riesgos de seguridad más críticos para las aplicaciones web, que sirve como una guía de lectura obligada para cualquier persona encargada de proteger o mantener aplicaciones web.

En las próximas secciones, profundizaremos en el papel de OWASP en las pruebas de penetración. Analizaremos el OWASP Top 10, sus casos de uso, limitaciones y cómo se puede aprovechar de manera efectiva en su trabajo de ciberseguridad. Recuerde, OWASP es más que un recurso para identificar vulnerabilidades. Es su socio para comprenderlos y mitigarlos, ofreciéndole guías prácticas y recursos para reforzar su seguridad. 

El enfoque OWASP es abierto y colaborativo:

• Abierto: todo experto en seguridad puede participar con su experiencia en el proyecto. Todo es gratis.
• Colaborativo: se realiza una lluvia de ideas antes de escribir los artículos para que el equipo pueda compartir ideas y desarrollar una visión colectiva del proyecto. Eso significa un consenso aproximado, una audiencia más amplia y una mayor participación.

Este enfoque tiende a crear una Metodología de prueba definida que será:

• Coherente
• Reproducible
• Riguroso
• bajo control de calidad

Los problemas a abordar están completamente documentados y probados. Es importante utilizar un método para probar todas las vulnerabilidades conocidas y documentar todas las actividades de prueba de seguridad.

Las pruebas de seguridad nunca serán una ciencia exacta en la que se pueda definir una lista completa de todos los posibles problemas que deben probarse. De hecho, las pruebas de seguridad son solo una técnica adecuada para probar la seguridad de las aplicaciones web en determinadas circunstancias. El objetivo de este proyecto es recopilar todas las técnicas de prueba posibles, explicar estas técnicas y mantener la guía actualizada. El método de prueba de seguridad de aplicaciones web de OWASP se basa en el enfoque de caja negra. El pentester no sabe nada o tiene muy poca información sobre la aplicación a probar.

El modelo de prueba consta de:

• Pentester: Quién realiza las actividades de prueba
• Herramientas y metodología: el núcleo de este proyecto de Guía de Pruebas
• Aplicación: La caja negra para probar

OWASP: el mapa, el machete y la brújula del hacking moderno

Cuando empecé en esto, no existía OWASP. Aprendías rompiendo cosas, leyendo papers, o si tenías suerte, mirando a alguien más romperlas. Hoy todo cambió. Hay una comunidad entera que formalizó esa experiencia, la empaquetó en herramientas, estándares y prácticas. Y se llama OWASP. Si te interesa la seguridad de aplicaciones, no hay excusas: tenés que conocer este ecosistema. No es opcional, es parte de tu caja de herramientas. Es como decir que sos mecánico y no sabés usar un torquímetro.

OWASP no es solo una lista de riesgos. Es un marco completo para pensar, diseñar, testear y defender software. Empezás por el Top 10, sí, pero te das cuenta rápido que eso es solo la punta del iceberg. Detrás tenés una máquina de producir estándares, modelos de madurez, guías, herramientas automáticas, checklists, frameworks y prácticas. Y todo eso es gratuito, abierto y comunitario. Es el tipo de proyecto que solo puede nacer de gente que realmente quiere mejorar la seguridad del software a nivel global.

Lo primero que la mayoría conoce es el Top 10. Sirve para crear conciencia. Para mostrarle a un equipo de desarrollo, o a un cliente, o a un gerente, qué cosas suelen salir mal una y otra vez. Pero lo que te enseña el Top 10 no es solo una lista de bugs. Te enseña que hay patrones. Que los errores se repiten. Que si no entendés la causa raíz, el parche no sirve de nada. OWASP fue evolucionando esta lista desde 2003 y hoy ya está en la versión 2025. Y lo más interesante es cómo la lista se fue refinando: de problemas técnicos como XSS o CSRF, pasamos a fallos estructurales como diseño inseguro, fallas en cadena de suministro, y mal manejo de excepciones.

Pero OWASP no se queda en lo superficial. Ahí es donde entran proyectos como ASVS y SAMM. El primero, el Application Security Verification Standard, te da una hoja de ruta real para asegurar aplicaciones. Te dice qué verificar, cómo hacerlo y en qué nivel. Desde una app chica hasta un sistema bancario. Y SAMM va más arriba: te permite medir la madurez de tu organización en cuanto a seguridad de software. No solo de tu código, sino de tus procesos, tus prácticas, tus políticas. Y eso es oro cuando trabajás con clientes grandes o auditorías formales.

También hay herramientas. ZAP, el proxy más usado después de Burp. Threat Dragon para modelado de amenazas. Dependency-Check y Dependency-Track para controlar qué metés en tu código y no volverte víctima de tu propia cadena de dependencias. AppSensor para detección temprana. ESAPI para no reinventar la validación, el manejo de errores o la criptografía. Todo esto existe, lo mantiene una comunidad y está listo para ser usado ya mismo, sin pagar nada.

Y no olvidemos WSTG, la guía de pruebas de seguridad web. Es básicamente el manual del pentester moderno. Te dice cómo probar cada componente de una aplicación web, qué técnicas usar, qué errores buscar, y cómo reportarlos. Es el estándar que muchos usamos cuando hacemos auditorías serias. Con eso y el checklist oficial podés armar una metodología completa que va desde la enumeración inicial hasta el reporte final. Es sólido, reproducible y está alineado con el resto del ecosistema OWASP.

Todo esto se conecta con el concepto de SSDLC. Integrar la seguridad en cada fase del ciclo de vida del software. Desde el diseño, con modelado de amenazas, pasando por el desarrollo con prácticas de codificación segura, testing automatizado con herramientas como SAST o ZAP, hasta el despliegue y mantenimiento con controles de integridad, gestión de secretos y monitoreo activo. OWASP no solo te da teoría, te da implementaciones reales para cada parte del pipeline.

Cuando enseñás seguridad o cuando armás un equipo serio de desarrollo seguro, OWASP es el lenguaje común. Usás ASVS para definir requisitos, Proactive Controls para enseñar a programar bien, Top 10 para priorizar riesgos, WSTG para testear, SAMM para medir procesos, y herramientas como Dependency-Check para automatizar. Es un sistema completo, modular, escalable y, lo más importante, probado en el mundo real.

OWASP también entiende que no todas las organizaciones son iguales. Por eso SAMM es flexible, basado en el riesgo, y se puede adaptar a cualquier tamaño de empresa o madurez. Y sus herramientas están pensadas para integrarse en pipelines CI/CD modernos. Nada de procesos lentos y a mano. Hablamos de automatización, de alertas, de visibilidad constante. La seguridad no puede ser un cuello de botella. Tiene que estar embebida, distribuida, transparente.

Yo vi cómo OWASP cambió el juego. Vi empresas pasar de cero seguridad a tener pipelines con escaneo de dependencias, testing dinámico, verificación de controles y monitoreo en producción, todo gracias a OWASP. Y también vi lo contrario: empresas que ignoraron estas herramientas por años y terminaron explotadas por una librería vieja o una mala configuración. Porque no se trata de si te van a atacar, sino de cuándo. Y cuando pase, ¿vas a estar preparado o vas a parchar sobre el cadáver?

Este ecosistema no es opcional. Si querés trabajar en ciberseguridad, si querés hacer pentesting, si querés desarrollar aplicaciones sin abrirle la puerta al primer script kiddie, tenés que conocer OWASP. Tenés que leer, practicar, integrar y evangelizar. Porque esto no es solo una cuestión técnica. Es una cultura. Es un compromiso con hacer las cosas bien. Y es una comunidad que lleva años haciéndolo posible para todos.

En este capítulo veremos todo el ecosistema OWASP y nos centraremos fundamentalmente OWASP (WSTG), veremos el TOP 10  (más adelante profundizaremos en este tema) y sus herramientas. Mejora tus habilidades en seguridad de software con esta guía enfocada en OWASP. Esta guía este curso ofrece una comprensión sólida de los principios y prácticas de seguridad. Aprende a identificar y mitigar riesgos, implementar codificación segura, integrar la seguridad en el SDLC, y realizar pruebas efectivas. Explora herramientas y estrategias como OWASP Top Ten, SAMM, ASVS, y más. Gestiona vulnerabilidades de manera proactiva y asegura tus aplicaciones con un enfoque integral y práctico.

Guía OWASP para Gestión de Vulnerabilidades: Cómo integrar seguridad real en el ciclo de vida del software

Cuando hablamos de gestión de vulnerabilidades, muchos caen en la trampa de pensar que tener un escáner funcionando es suficiente. Eso es una ilusión peligrosa. La gestión real de vulnerabilidades va mucho más allá de ejecutar un par de herramientas. Lo que propone OWASP con su Vulnerability Management Guide (VMG) es justamente romper esa idea superficial y estructurar una estrategia integral, continua y madura, completamente alineada con las prácticas reales de DevSecOps.

Lo primero que me gusta aclarar es que ningún escáner va a reemplazar tu juicio. OWASP lo sabe, y por eso la guía está organizada en ciclos que reflejan cómo se trabaja en la práctica: detección, remediación y reporte, todos interconectados y alimentándose mutuamente. No hay recetas mágicas. Lo que sí hay es proceso.

En el Detection Cycle, el foco está en definir bien el alcance, elegir las herramientas correctas (manuales y automáticas), y confirmar que lo que encontrás es real. Porque si no validás los findings, terminás tapando falsos positivos o, peor, ignorando fallos críticos. Todo esto se refuerza con pruebas automatizadas en CI/CD usando herramientas como Dependency-Check, pero también con análisis manual cuando hace falta.

En el Remediation Cycle, la clave es priorizar. No todo se puede arreglar al mismo tiempo, y ahí entran tus políticas de riesgo. OWASP recomienda gestionar falsos positivos, controlar excepciones justificadas y aplicar los parches o configuraciones necesarias con agilidad. Este ciclo depende de datos concretos, no intuiciones. Y para eso, se apoya en el tercer eje: el Reporting Cycle.

Reportar no es solo generar PDFs. Es saber qué activos están en riesgo, tener trazabilidad, monitorear métricas y demostrar que tu estrategia de seguridad funciona. Estos reportes alimentan la toma de decisiones a nivel técnico y gerencial. La conexión entre estos ciclos es total: lo que detectás, impacta en cómo mitigás, y eso debe ser medido para mejorar.

Ahora, si querés pasar del marco teórico a lo práctico, ahí entra OWASP DefectDojo. Esta herramienta es una bestia cuando se trata de centralizar findings, eliminar duplicados y escalar la gestión de vulnerabilidades. Podés integrarlo con más de 200 herramientas, usarlo en CI/CD con GitLab, Jenkins o GitHub Actions, y automatizar flujos enteros de escaneo, remediación y reporte. Incluso podés importar resultados de ZAP, Nmap o Burp Suite y transformarlos en acciones concretas con un solo clic. Si trabajás con pipelines modernos, DefectDojo es indispensable.

Pero OWASP no se queda ahí. También te da AppSensor, una herramienta clave si querés implementar detección y respuesta a nivel de aplicación, en tiempo real. No reemplaza un WAF, lo complementa. AppSensor te permite definir puntos de detección directamente dentro del código de tu app, monitorear comportamientos anómalos y disparar respuestas automáticas según tus propias reglas. Todo eso sin intervención humana. Si tenés una app que maneja datos sensibles, AppSensor no es opcional, es obligatorio.

Por otro lado, si necesitás automatizar escaneos a nivel de red o infraestructura, OWASP Nettacker es tu aliado. Es una herramienta liviana, modular, fácil de correr con Docker y muy potente. Se integra bien con entornos DevSecOps y CI/CD. Su API y CLI la hacen flexible, y su capacidad para detectar servicios mal configurados o con credenciales por defecto te ahorra horas de análisis manual.

Y como siempre, OWASP tiene una joya que no puede faltar: ZAP (Zed Attack Proxy). A pesar de que no tiene toda la sofisticación de Burp Suite, es más que suficiente para detectar las vulnerabilidades más comunes del OWASP Top 10, automatizar escaneos activos y pasivos, interceptar tráfico y lanzar fuzzers con precisión. Su arquitectura modular permite integraciones profundas en pipelines de CI/CD, y su HUD directamente en el navegador convierte el análisis en una experiencia visual muy didáctica, perfecta tanto para training como para investigación seria.

¿Querés formar a tu equipo? Ahí tenés una artillería de laboratorios prácticos: OWASP WebGoat, Mutillidae II, Security Shepherd, Juice Shop y más. Estas plataformas están diseñadas para explotar vulnerabilidades reales en entornos controlados, con instalaciones rápidas vía Docker o como máquinas virtuales listas para usar. En ellas podés practicar desde SQLi hasta XSS, IDOR, CSRF y todo lo que vas a encontrar en aplicaciones reales. Incluso herramientas como Juice Shop tienen modo gamificado para incentivar a los desarrolladores a pensar como atacantes.

Toda esta infraestructura se puede (y debe) integrar en el ciclo de vida del software. Desde la planificación y el diseño con Threat Dragon y SAMM, pasando por el desarrollo con buenas prácticas y Dependency-Check, hasta la verificación con ZAP y Security Shepherd, y la implementación con AppSensor y DefectDojo. OWASP propone un enfoque completo que cubre todo el SDLC, y no solo con herramientas: también con guías, estándares, cheat sheets y documentación de alto nivel.

El resultado de todo esto no es solo un software más seguro. Es una cultura. Una mentalidad. Cuando integrás estas herramientas en cada etapa del desarrollo, estás construyendo seguridad desde la raíz. Ya no se trata de “parchar” después de que explotó todo. Se trata de anticipar, detectar, aprender y mejorar de forma continua.

Así que si sos desarrollador, pentester, devops o arquitecto, esta guía no es solo un recurso más. Es un mapa de ruta. Un marco operativo para construir sistemas robustos y defender lo que importa. Si no estás usando el stack de OWASP, estás dejando agujeros. Y en este juego, cada agujero puede costarte caro.

La misión de OWASP

La misión de OWASP es lograr un mundo con un software más seguro, proporcionando herramientas, estándares y educación que permitan a los desarrolladores crear aplicaciones confiables. Su visión es clara, no más software inseguro. Para lograr este objetivo, OWASP cuenta con miles de voluntarios y más de 250 capítulos locales distribuidos por todo el mundo.

OWASP también destaca por una serie de recursos y proyectos que cubren diferentes áreas en la seguridad del software. Los más importantes incluyen el OWASP Top 10, que es probablemente el proyecto más conocido de OWASP, publicado y actualizado cada año, y detalla las principales vulnerabilidades en aplicaciones web, como las inyecciones de código, las exposiciones de datos sensibles y los controles de acceso rotos. Este recurso es utilizado como estándar por organizaciones y gobiernos para implementar mejores prácticas de seguridad.

Herramientas

Por otro lado, tenemos el ZAP, Zed Attack Proxy, que es una herramienta gratuita de pruebas de penetración diseñada para identificar vulnerabilidades en aplicaciones web. ZAP es ampliamente utilizado, tanto por expertos en seguridad como por desarrolladores que están comenzando a explorar el ámbito de la ciberseguridad. Por otro lado, tenemos el ASVS, que es un estándar que guía a las organizaciones para verificar la seguridad de las aplicaciones a nivel de diseño y desarrollo. Este ayuda a los equipos de desarrollo a implementar controles de seguridad robustos desde las primeras fases del ciclo de vida del software. Finalmente, destaca también el Dependency-Check.

Esta herramienta permite analizar bibliotecas y componentes de software en busca de vulnerabilidades conocidas, ayudando a los equipos a identificar y mitigar riesgos asociados con dependencias externas. OWASP no solo ofrece herramientas, sino también amplios recursos de educación y formación para desarrolladores y profesionales de la seguridad. Además, es una de las mayores fortalezas de OWASP es su comunidad global, compuesta por voluntarios y profesionales que colaboran en proyectos de código abierto, herramientas y guías.

OWASP ha marcado un antes y un después en la seguridad de aplicaciones al proporcionar recursos esenciales para que organizaciones y desarrolladores se enfrenten a los desafíos de la seguridad del software. Al hacer que estos recursos sean accesibles para todos, OWASP no solo mejora la seguridad de las aplicaciones, sino también empodera a la comunidad global para que colabore y crezca en conjunto.

SDLC

El ciclo de vida del desarrollo del software es un marco estructurado que organiza las actividades necesarias para diseñar, desarrollar, probar y mantener aplicaciones de software. En un contexto estándar, el SDLC, tradicionalmente, enfoca la seguridad de las fases finales como las pruebas. Sin embargo, con el aumento de las amenazas cibernéticas, la necesidad de incluir prácticas de seguridad desde las primeras etapas del ciclo se ha vuelto indispensable. Aquí es donde entra el concepto de secure software development life cycles, o SSDLC, que busca integrar la seguridad en todas las fases de desarrollo del software.

Un flujo de trabajo típico de pruebas SDLC

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.

El costo de los errores a lo largo del ciclo de desarrollo

 

En la imagen podemos ver una representación clara de cómo el costo de corregir fallos aumenta conforme un proyecto avanza por sus distintas etapas. La gráfica muestra una curva ascendente que inicia de forma suave en la fase de diseño y se dispara de manera pronunciada cuando se llega a producción. Es una forma visual de recordar que mientras más tarde se descubra un problema, más caro será solucionarlo.

Al inicio, en la etapa de diseño, aparecen unos cuantos íconos sencillos como monedas y un plano técnico, simbolizando que en este punto los ajustes son relativamente económicos. Conforme la gráfica avanza hacia el desarrollo, ilustrado con engranajes, el costo empieza a elevarse, ya que cualquier cambio requiere modificar código y estructuras que ya están tomando forma. Más adelante, en la fase de pruebas, representada por una tabla de verificación, el gasto continúa creciendo porque aquí los errores implican retrabajar componentes completos antes de poder liberar el sistema.

Finalmente, en producción, la imagen muestra montones de sacos de dinero y servidores, dejando ver un salto enorme en los costos. Es en este momento donde cualquier vulnerabilidad, fallo de diseño o mala implementación no solo implica un esfuerzo técnico mayor, sino también un impacto directo en recursos, tiempo e incluso reputación. La ilustración refuerza la importancia de detectar fallos temprano, especialmente en el contexto del hacking y el pentesting, donde cada fase es una oportunidad para evitar que un pequeño error se convierta en un problema millonario.

 

El SSDLC

Integra las mismas fases del SDLC tradicional, pero con la inclusión de prácticas de seguridad en cada una de ellas.

• En la fase inicial, se definen los requerimientos funcionales y de seguridad. Es importante realizar un análisis de riesgo para identificar las posibles vulnerabilidades y establecer controles que mitiguen estos riesgos desde el principio.
• En la fase de análisis de requisitos, se documentan y analizan los requisitos de software. La seguridad también debe estar presente en cada requerimiento funcional, y herramientas como el OWASP SAMM ayudan a mapear los riesgos y definir los requisitos de seguridad para las aplicaciones, asegurando que los desarrolladores comprendan las amenazas potenciales y las mitiguen.
• En la fase de diseño, se crea la arquitectura del software. Es esencial también aplicar principios de diseño seguro, como el security by design, y realizar evaluaciones de la arquitectura para garantizar que los componentes sean resistentes a ataques. Aquí se considera también el uso de prácticas como el modelado de amenazas para identificar posibles puntos de fallo. Durante la implementación del código, se deben seguir prácticas de programación segura; esto incluye la validación de entradas, el saneamiento de datos y el uso de herramientas como SAST, es decir, static application security testing, para automatizar la revisión del código en busca de vulnerabilidades antes de que se integre con otros componentes.
• En la fase de pruebas y verificación, el software se somete a pruebas de seguridad rigurosas para identificar vulnerabilidades. Esta fase debe incluir herramientas como ZAP para realizar las pruebas de penetración automáticas y manuales. Además, esto asegura que la aplicación no tenga brechas de seguridad antes de su despliegue.
• La fase de despliegue debe estar acompañada de controles que verifiquen la integridad del software antes de entrar a producción. Automatizar este proceso ayuda a evitar errores manuales, además de incluir verificaciones de seguridad en la infraestructura.

Ciclo de vida del desarrollo de software

La imagen muestra un ciclo de vida del desarrollo de software representado como una espiral circular que avanza en sentido horario. Cada fase está claramente dividida en secciones coloreadas, lo que ayuda a visualizar cómo el proceso fluye de una etapa a la siguiente sin interrupción.

El ciclo comienza con la fase de Define, donde se establecen los requisitos, las necesidades del proyecto y las expectativas. Está ilustrada con un icono de un portapapeles, lo que transmite la idea de planificación y documentación inicial.

A continuación aparece la fase Design, representada con un icono de un monitor con herramientas. Esta parte simboliza la creación de la arquitectura del software, el diseño de sus componentes y la estructura que permitirá que la aplicación sea segura y eficiente desde sus cimientos.

Después sigue Develop, marcada con un icono relacionado con código o engranajes digitales. Esta sección refleja el proceso de programación, donde el diseño se convierte en una implementación real y donde las buenas prácticas de desarrollo seguro son cruciales para evitar vulnerabilidades desde el origen. La siguiente etapa es Deploy, ilustrada con un icono de un botón de despliegue. Aquí se muestra el momento en el que la aplicación se pone en producción o se libera para su uso, y donde cualquier error puede tener un impacto más costoso.

Finalmente, encontramos la fase Maintain, acompañada de un icono de herramientas. Esta etapa representa el mantenimiento continuo, la corrección de errores, actualizaciones de seguridad y ajustes necesarios para que el software siga funcionando de forma estable y segura con el tiempo. Un detalle importante es el texto que aparece en el borde derecho del círculo: Increasing costs to fix security bugs. Esto indica que cuanto más avanzas en el ciclo, más costoso resulta corregir fallos de seguridad, reforzando la idea clave de que la seguridad debe integrarse desde el inicio y no tratarse como un añadido de última hora.

En conjunto, la imagen comunica de forma simple y efectiva el flujo completo del ciclo de desarrollo y por qué es esencial integrar la seguridad en todas sus fases, algo fundamental para cualquiera que se inicie en hacking, pentesting o desarrollo seguro.

El flujo de trabajo SSDLC y sus herramientas clave

 

 

En la imagen podemos ver un flujo visual que resume cómo se integra la seguridad dentro del ciclo de vida del desarrollo de software, siguiendo un enfoque SSDLC. A través de distintos bloques numerados, se muestra de manera clara cómo cada fase incorpora prácticas y herramientas que ayudan a reducir riesgos y fortalecer la seguridad desde el inicio.

En la primera etapa, dedicada al diseño, aparece un dragón que simboliza las amenazas que deben modelarse usando herramientas como Threat Dragon, mientras que los requisitos de seguridad se definen con marcos como SAMM. Esta fase busca anticipar posibles vectores de ataque antes de escribir una sola línea de código. Más adelante, en la fase de desarrollo, se observan engranajes acompañando la idea de utilizar Proactive Controls y escanear dependencias mediante Dependency-Check, destacando la importancia de construir el software sobre cimientos limpios y bien controlados.

La tercera fase se centra en las pruebas, representada con un clip de escaneo y un icono de Juice Shop, reforzando cómo el uso de ZAP para identificar vulnerabilidades y el entrenamiento de equipos mediante aplicaciones inseguras preparadas ayuda a elevar el nivel de madurez del equipo. Después, el flujo avanza hacia el despliegue, donde un candado y engranajes ilustran la necesidad de aplicar configuraciones seguras y gestionar secretos de manera adecuada para evitar exposiciones innecesarias en entornos reales.

Finalmente, la imagen cierra con la fase de mantenimiento, destacada con un ojo vigilante y un insecto que simboliza los hallazgos. Aquí se menciona AppSensor para la monitorización y DefectDojo para la gestión de vulnerabilidades, mostrando que la seguridad no termina con el despliegue, sino que debe mantenerse activa y en constante evaluación. En conjunto, este flujo ilustra cómo un SSDLC integra prácticas de seguridad en cada paso para construir sistemas más robustos y resistentes. 

SSDLC efectivo

Una vez el software está en producción, es vital seguir monitorizando posibles nuevas amenazas o vulnerabilidades. Esto incluye aplicar actualizaciones de seguridad, gestionar incidentes y realizar auditorías regulares del sistema para mantener la seguridad a largo plazo. Adoptar un SSDLC trae consigo múltiples ventajas, como una mayor seguridad desde el inicio del ciclo del desarrollo y la reducción de costos, ya que los errores y vulnerabilidades se detectan más pronto cuando son mucho más fáciles de corregir. También contribuye al cumplimiento normativo al alinearse con estándares como NIST o ISO, que requieren la integración de la seguridad en el ciclo del desarrollo.

OWASP juega un papel clave en la implementación de un SSDLC efectivo, ya que proporciona una serie de recursos como el OWASP SAMM, que guían a las organizaciones en la integración de seguridad en cada fase del ciclo de desarrollo. OWASP también ofrece herramientas como ZAP, Dependency-Check y Security Shepherd, todas diseñadas para reforzar la seguridad desde el diseño hasta el mantenimiento de las aplicaciones.

El SSDLC representa un cambio de paradigma en cómo se abordan las amenazas de la seguridad en el desarrollo de software. Incorporar la seguridad en cada fase del SSDLC garantiza que las aplicaciones no solo cumplan con los requisitos funcionales, sino también sean resistentes a ataques y vulnerabilidades, e implementar un SSDLC con los recursos y guías proporcionados por OWASP asegura que el software desarrollado esté alineado con las mejores prácticas de seguridad, minimizando riesgos y mejorando la calidad global del producto final. 

OWASP TOP 10 

OWASP es popular por publicar el TOP 10 Owasp Web cada cuatro años. Este es un  documento que lista los diez riesgos más críticos en aplicaciones web, con el objetivo de  ayudar a las organizaciones a identificar y mitigar las vulnerabilidades asociadas con estos riesgos. https://owasp.org/Top10/es/ Cada uno de estos riesgos representa una debilidad común y significativa que a menudo se puede explotar para comprometer la seguridad de una aplicación web. OWASP proporciona información detallada sobre posibles vulnerabilidades y técnicas de ataque para cada riesgo.

El Top 10 de OWASP es una lista que se actualiza periódicamente de los riesgos de seguridad de las aplicaciones web más críticos. Lo mantiene el Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP), una organización sin fines de lucro centrada en mejorar la seguridad de las aplicaciones web. Sirve como una valiosa guía para que los desarrolladores, los expertos en pruebas de penetración de aplicaciones web y las organizaciones comprendan y prioricen los riesgos de seguridad comunes en las aplicaciones web.

El Top 10 de OWASP es una lista conocida de los diez riesgos de seguridad de aplicaciones web más críticos. Se actualiza periódicamente para garantizar que refleje el panorama actual de amenazas y los desafíos de seguridad en constante evolución que enfrentan las aplicaciones web. La primera versión del Top 10 de OWASP se publicó en 2003. Su objetivo era crear conciencia sobre los riesgos comunes de seguridad de las aplicaciones web y ayudar a los desarrolladores a priorizar los esfuerzos de seguridad. La lista incluía riesgos como secuencias de comandos entre sitios (XSS), inyección de SQL y problemas de gestión de sesiones. Cada lanzamiento del Top 10 de OWASP se basa en las versiones anteriores, mejorando su precisión, relevancia y practicidad.

Evolución de OWASP TOP 10

En el momento de crear este artículo coexiste las dos versiones 2021/2025.

	2003	2004	2007	2010	2013	2017	2021	2025
A1	Entrada no validada	Entrada no validada	XSS	Inyección	Inyección	Inyección	Broken Access Control	Broken Access Control
A2	Control de acceso interrumpido	Control de acceso interrumpido	Fallas de inyección	XSS	Autenticación y gestión de sesión rotas	Autenticación rota	Cryptographic Failures	Security Misconfiguration
A3	Autenticación y gestión de sesión interrumpida	Autenticación y gestión de sesión interrumpida	Ejecución de ficheros maliciosos	Autenticación y gestión de sesión rotas	XSS	Exposición de datos sensibles	Injection	Software Supply Chain Failures
A4	XSS (cross-site scripting)	XSS	Referencia directa insegura a objetos	Referencia directa insegura a objetos	Referencia directa insegura a objetos	Entidades Externas XML (XXE)	Insecure Design	Cryptographic Failures
A5	Desbordamiento de búfer	Desbordamiento de búfer	CSRF	CSRF	Configuración de seguridad incorrecta	Control de acceso roto	Security Misconfiguration	Injection
A6	Fallas de inyección de comandos	Fallas de inyección	Revelación de información / manejo de errores	Configuración de seguridad defectuosa	Exposición de datos sensibles	Configuración de seguridad incorrecta	Vulnerable and Outdated Components	Insecure Design
A7	Manejo inadecuado de errores	Manejo inadecuado de errores	Autenticación y gestión de sesión	Almacenamiento criptográfico inseguro	Falta de control de acceso a nivel de función	XSS	Identification and Authentication Failures	Identification and Authentication Failures
A8	Uso inseguro de criptografía / Almacenamiento inseguro	Almacenamiento inseguro	Almacenamiento criptográfico inseguro	Falla de restricción de acceso a URL	CSRF	Deserialización insegura	Software and Data Integrity Failures	Software and Data Integrity Failures
A9	Fallas de administración remota / Denegación	Denegación de servicio de aplicación	Comunicaciones inseguras	Protección insuficiente en la capa de transporte	Uso de componentes con vulnerabilidades conocidas	Componentes con vulnerabilidades conocidas	Security Logging and Monitoring Failures	Security Logging and Monitoring Failures
A10	Configuración indebida de servidor/app	Administración de configuración insegura	Falta de restricción de acceso a URL	Redirecciones y reenvíos no validados	Redirecciones y reenvíos no validados	Registro y monitoreo insuficientes	Server-Side Request Forgery (SSRF)	Mishandling of Exceptional Conditions

⚪No cambia

🟡Fusionado

🔵Cambia de posición

🟢Nuevo

OWASP Top 10 es un documento de concienciación estándar para desarrolladores y seguridad de aplicaciones web. Representa un amplio consenso sobre los riesgos de seguridad más críticos para las aplicaciones web. Reconocido mundialmente por los desarrolladores como el primer paso hacia una codificación más segura. Las empresas deben adoptar este documento y comenzar el proceso de garantizar que sus aplicaciones web minimicen estos riesgos. 

 

OWASP TOP 10  2021

Usar OWASP Top 10 es el primer paso para cambiar la cultura de desarrollo de software dentro de su organización a una que produzca código más seguro. Hay tres categorías nuevas, cuatro categorías con cambios de nombre y alcance, y cierta consolidación en el Top 10 para 2021. Esta sección describe la metodología de prueba de seguridad de la aplicación web OWASP y explica cómo probar la evidencia de vulnerabilidades dentro de la aplicación debido a deficiencias con los controles de seguridad identificados.

 A01 – Broken Access Control (Controles de acceso rotos)

Sube de la quinta posición a la categoría con el mayor riesgo en seguridad de aplicaciones web; los datos proporcionados indican que, en promedio, el 3,81% de las aplicaciones probadas tenían una o más Common Weakness Enumerations (CWEs) con más de 318.000 ocurrencias de CWEs en esta categoría de riesgo. Las 34 CWEs relacionadas con la Pérdida de Control de Acceso tuvieron más apariciones en las aplicaciones que cualquier otra categoría.

👉 Qué es: el usuario puede acceder a datos o funciones que no debería.

📌 Ejemplo: cambiar cuenta=123 por cuenta=124 y ver otra cuenta. Un usuario normal accede a /admin cambiando el ID en la URL.

⚠️ Consecuencia: robo de datos, transferencias no autorizadas.

🛡️ Defensa: validar permisos en el servidor, deny-by-default, RBAC/ABAC.

📝 Frase: Cuando puedes ver/hacer lo que no deberías.

A02 – Cryptographic Failures (Fallos criptográficos)

A02:2021 – Fallas Criptográficas sube una posición ubicándose en la segunda, antes conocida como A3:2017-Exposición de Datos Sensibles, que era más una característica que una causa raíz. El nuevo nombre se centra en las fallas relacionadas con la criptografía, como se ha hecho implícitamente antes. Esta categoría frecuentemente conlleva a la exposición de datos confidenciales o al compromiso del sistema.

👉 Qué es: los datos sensibles no están bien cifrados ni protegidos.

📌 Ejemplo: contraseñas en texto plano o con MD5sin salt; login por HTTP.

⚠️ Consecuencia: robo de credenciales, fuga de tarjetas, sanciones PCI DSS.

🛡️ Defensa: TLS 1.2/1.3, bcrypt/Argon2, AES-256, gestión segura de claves.

📝 Frase: Cuando los datos viajan o se guardan sin protección.

A03 – Injection (Inyecciones)

A03:2021 – Inyección desciende hasta la tercera posición. El 94% de las aplicaciones fueron probadas con algún tipo de inyección y estas mostraron una tasa de incidencia máxima del 19%, promedio de 3.37%, y las 33 CWEs relacionadas con esta categoría tienen la segunda mayor cantidad de ocurrencias en aplicaciones con 274.000 ocurrencias. El Cross-Site Scripting, en esta edición, forma parte de esta categoría de riesgo.

👉 Qué es: la app ejecuta input malicioso del usuario en un comando/consulta.

📌 Ejemplo: ‘ OR ‘1’=’1 en login; ; cat /etc/passwd; XXE.

⚠️ Consecuencia: robo/modificación de datos, RCE en el servidor.

🛡️ Defensa: consultas parametrizadas, validación estricta, ORMs seguros.

📝 Frase: Cuando el input del usuario se convierte en código.

A04 – Insecure Design (Diseño inseguro)

A04:2021 – Diseño Inseguro nueva categoría para la edición 2021, con un enfoque en los riesgos relacionados con fallas de diseño. Si realmente queremos madurar como industria, debemos «mover a la izquierda» del proceso de desarrollo las actividades de seguridad.  Necesitamos más modelos de amenazas, patrones y principios con diseños seguros y arquitecturas de referencia. Un diseño inseguro no puede ser corregida con una implementación perfecta debido a que, por definición, los controles de seguridad necesarios nunca se crearon para defenderse de ataques específicos.

👉 Qué es: la app fue mal diseñada desde el inicio, sin reglas seguras.

📌 Ejemplo: transferencias sin límite, login sin MFA, recuperación con DNI. App que no implementa MFA en un sistema crítico.

⚠️ Consecuencia: fraude financiero, bypass de controles de negocio.

🛡️ Defensa: seguridad por diseño, límites diarios, MFA, doble aprobación.

📝 Frase: Cuando el sistema está mal pensado desde el principio.

A05 – Security Misconfiguration (Mala configuración)

A05:2021 – Configuración de Seguridad Incorrecta asciende desde la sexta posición en la edición anterior; el 90% de las aplicaciones se probaron para detectar algún tipo de configuración incorrecta, con una tasa de incidencia promedio del 4,5% y más de 208.000 casos de CWEs relacionadas con esta categoría de riesgo. Con mayor presencia de software altamente configurable, no es sorprendente ver qué esta categoría ascendiera. El A4:2017-Entidades Externas XML(XXE), ahora en esta edición, forma parte de esta categoría de riesgo.

👉 Qué es: sistema con ajustes inseguros o por defecto.

📌 Ejemplo: admin/admin, debug activo, CORS *, directory listing. Panel /phpmyadmin expuesto con credenciales por defecto.

⚠️ Consecuencia: exposición de datos, acceso a paneles internos.

🛡️ Defensa: hardening, deny-by-default, headers de seguridad, revisión periódica.

📝 Frase: Cuando la app está mal configurada y abierta de más.

A06 – Vulnerable and Outdated Components (Componentes inseguros/desactualizados)

A06:2021 – Componentes Vulnerables y Desactualizados antes denominado como Uso de Componentes con Vulnerabilidades Conocidas, ocupa el segundo lugar en el Top 10 de la encuesta a la comunidad, pero también tuvo datos suficientes para estar en el Top 10 a través del análisis de datos. Esta categoría asciende desde la novena posición en la edición 2017 y es un problema conocido que cuesta probar y evaluar el riesgo. Es la única categoría que no tiene ninguna CVE relacionada con las CWEs incluidas, por lo que una vulnerabilidad predeterminada y con ponderaciones de impacto de 5,0 son consideradas en sus puntajes.

👉 Qué es: usar librerías o frameworks con vulnerabilidades conocidas.

📌 Ejemplo: Struts2 (Equifax), Log4j (Log4Shell), jQuery viejo. App usando jQuery 1.8 con vulnerabilidades conocidas.

⚠️ Consecuencia: RCE, robo masivo de datos, caída del sistema.

🛡️ Defensa: parches rápidos, SBOM, monitoreo CVEs, versiones soportadas.

📝 Frase: Cuando el software es viejo y tiene agujeros conocidos.

A07 – Identification and Authentication Failures (Fallos en auth)

A07:2021 – Fallas de Identificación y Autenticación previamente denominada como Pérdida de Autenticación, descendió desde la segunda posición, y ahora incluye CWEs que están más relacionadas con fallas de identificación. Esta categoría sigue siendo una parte integral del Top 10, pero el incremento en la disponibilidad de frameworks estandarizados parece estar ayudando. 

👉 Qué es: errores en login, sesiones y autenticación.

📌 Ejemplo: contraseñas débiles, sin rate-limiting, sesiones eternas, JWT alg:none. Permitir login con credenciales débiles o sin bloqueo tras 50 intentos.

⚠️ Consecuencia: toma de cuentas (ATO), fraude, robo de datos.

🛡️ Defensa: MFA, password policy, rate-limiting, sesiones seguras, bcrypt.

📝 Frase: Cuando cualquiera puede loguearse o robar sesiones.

A08 – Software and Data Integrity Failures (Fallas de integridad)

A08:2021 – Fallas en el Software y en la Integridad de los Datos es una nueva categoría para la edición 2021, que se centra en hacer suposiciones relacionadas con actualizaciones de software, los datos críticos y los pipelines CI/CD sin verificación de integridad. Corresponde a uno de los mayores impactos según los sistemas de ponderación de vulnerabilidades (CVE/CVSS, siglas en inglés para Common Vulnerability and Exposures/Common Vulnerability Scoring System). La A8:2017-Deserialización Insegura en esta edición forma parte de esta extensa categoría de riesgo

👉 Qué es: confiar en updates, librerías o datos sin verificar integridad.

📌 Ejemplo: updates sin firma, CI/CD inseguro, insecure deserialization. Cargar un script JS desde CDN sin verificar integridad.

⚠️ Consecuencia: supply chain attacks, fraude, manipulación de datos.

🛡️ Defensa: firmas digitales, hashes, SBOM, pipelines seguros, HMAC.

📝 Frase: Cuando aceptas software/datos sin comprobar que son legítimos.

A09 – Security Logging and Monitoring Failures (Fallos en registro y monitoreo)

A09:2021 – Fallas en el Registro y Monitoreo previamente denominada como A10:2017-Registro y Monitoreo Insuficientes, es adicionada desde el Top 10 de la encuesta a la comunidad (tercer lugar) y ascendiendo desde la décima posición de la edición anterior. Esta categoría se amplía para incluir más tipos de fallas, es difícil de probar y no está bien representada en los datos de CVE/CVSS. Sin embargo, las fallas en esta categoría pueden afectar directamente la visibilidad, las alertas de incidentes y los análisis forenses.

👉 Qué es: no hay logs completos, seguros ni alertas.

📌 Ejemplo: no registrar login fallido, logs sin IP/usuario, logs públicos. Ningún log al intentar 100 logins fallidos.

⚠️ Consecuencia: ataques no detectados, fraude prolongado, sin forense.

🛡️ Defensa: SIEM, alertas, logs detallados, integridad y retención legal.

📝 Frase: Cuando el ataque pasa y nadie se entera.

A10 – Server-Side Request Forgery (SSRF)

A10:2021 – Falsificación de Solicitudes del Lado del Servidor es adicionada desde el Top 10 de la encuesta a la comunidad (primer lugar). Los datos muestran una tasa de incidencia relativamente baja con una cobertura de pruebas por encima del promedio, junto con calificaciones por encima del promedio para la capacidad de explotación e impacto. Esta categoría representa el escenario en el que los miembros de la comunidad de seguridad nos dicen que esto es importante, aunque no está visualizado en los datos en este momento.

👉 Qué es: el servidor hace requests controlados por el atacante.

📌 Ejemplo: url=http://127.0.0.1:8080/admin o 169.254.169.254 (AWS). Parámetro url=http://interna/admin que permite pivotar hacia servicios internos.

⚠️ Consecuencia: acceso a intranet, robo de secretos cloud, pivoting.

🛡️ Defensa: listas blancas de URLs, bloquear localhost/red interna, filtrado egress.

📝 Frase: Cuando el servidor pide datos a donde el atacante diga.

OWASP TOP 10  2025

En la lista de los Diez Principales para 2025, se han incorporado dos categorías nuevas y una consolidada. Esta versión según OWASP está centrada en la causa raíz, más que en los síntomas, en la medida de lo posible. Dada la complejidad de la ingeniería y la seguridad del software, resulta prácticamente imposible crear diez categorías sin cierto grado de superposición.

A01:2025 – El control de acceso deficiente

Se mantiene como el riesgo de seguridad de aplicaciones más grave. Los datos aportados indican que, en promedio, el 3,73 % de las aplicaciones analizadas presentaban una o más de las 40 vulnerabilidades comunes (CWE) incluidas en esta categoría. Como se muestra en la figura anterior con la línea discontinua, la falsificación de solicitudes del lado del servidor (SSRF) se ha incorporado a esta categoría.

A02:2025 – La configuración errónea de seguridad

Pasó del puesto n.° 5 en 2021 al n.° 2 en 2025. Las configuraciones erróneas son más frecuentes en los datos de este ciclo. El 3,00 % de las aplicaciones analizadas presentaban uno o más de los 16 CWE de esta categoría. Esto no resulta sorprendente, ya que la ingeniería de software sigue incrementando la proporción del comportamiento de las aplicaciones que depende de las configuraciones.

A03:2025 – Fallos en la cadena de suministro de software

Es una ampliación de A06:2021 – Componentes vulnerables y obsoletos, que abarca un espectro más amplio de vulnerabilidades que se producen dentro o a través de todo el ecosistema de dependencias de software, sistemas de compilación e infraestructura de distribución. Esta categoría fue votada abrumadoramente como una de las principales preocupaciones en la encuesta de la comunidad. Cuenta con 5 CWE y una presencia limitada en los datos recopilados, pero creemos que esto se debe a dificultades en las pruebas y esperamos que estas mejoren en este ámbito. Esta categoría presenta la menor cantidad de ocurrencias en los datos, pero también las puntuaciones promedio más altas de exploits e impacto según las CVE.

A04:2025 – Fallos criptográficos

Baja dos puestos, del n.° 2 al n.° 4, en la clasificación. Los datos aportados indican que, de media, el 3,80 % de las aplicaciones presentan uno o más de los 32 CWE de esta categoría. Esta categoría suele provocar la exposición de datos confidenciales o la vulneración del sistema.

A05:2025 – La inyección de vulnerabilidades

Baja dos puestos, del n.° 3 al n.° 5, en la clasificación, manteniendo su posición relativa a fallos criptográficos y diseño inseguro. La inyección de vulnerabilidades es una de las categorías más analizadas, con el mayor número de CVE asociadas a las 38 CWE de esta categoría. Incluye una variedad de problemas, desde Cross-site Scripting (alta frecuencia/bajo impacto) hasta vulnerabilidades de inyección SQL (baja frecuencia/alto impacto).

A06:2025 – El diseño inseguro

Baja dos puestos, del n.° 4 al n.° 6, en la clasificación, ya que la mala configuración de seguridad y los fallos en la cadena de suministro de software lo superan. Esta categoría se introdujo en 2021 y hemos observado mejoras notables en el sector en lo relativo al modelado de amenazas y a un mayor énfasis en el diseño seguro.

A07:2025 – Fallos de autenticación

Mantiene su posición en el puesto n.° 7 con un ligero cambio de nombre (anteriormente era « Fallos de identificación y autenticación ») para reflejar con mayor precisión los 36 CWE de esta categoría. Esta categoría sigue siendo importante, pero el mayor uso de marcos estandarizados para la autenticación parece estar teniendo efectos beneficiosos en la frecuencia de los fallos de autenticación.

A08:2025 – Fallos en la integridad del software o los datos

Me mantiene en el puesto n.° 8 de la lista. Esta categoría se centra en la falta de mantenimiento de los límites de confianza y la verificación de la integridad del software, el código y los datos, a un nivel inferior al de los fallos en la cadena de suministro de software.

A09:2025 – Fallos en el registro y las alertas

Mantiene su posición en el puesto n.° 9. Esta categoría ha cambiado ligeramente de nombre (anteriormente, « Fallos en el registro y la monitorización de la seguridad ») para destacar la importancia de la funcionalidad de alertas necesaria para que se tomen las medidas adecuadas ante eventos de registro relevantes. Un buen registro sin alertas resulta de poca utilidad para identificar incidentes de seguridad. Esta categoría siempre estará infrarrepresentada en los datos y, una vez más, fue elegida para figurar en la lista por los participantes de la encuesta de la comunidad.

A10:2025 – Manejo inadecuado de condiciones excepcionales

Es una nueva categoría para 2025. Esta categoría contiene 24 CWE que se centran en el manejo inadecuado de errores, errores lógicos, fallos abiertos y otros escenarios relacionados derivados de condiciones anormales que pueden encontrar los sistemas.

OWASP SAMM

SAMM abarca todo el ciclo de vida del software y es independiente de la tecnología y los procesos . SAMM es evolutivo y esté basado en el riesgo , ya que no existe una fórmula única que funcione para todas las organizaciones.  El OWASP Software Assurance Maturity Model es un marco que permite a las organizaciones integrar la seguridad en sus procesos de desarrollo de software de forma progresiva y adaptada a sus necesidades específicas.

A través de evaluaciones periódicas, las organizaciones pueden mejorar sus prácticas de seguridad en cada fase del ciclo de vida del software, asegurando el cumplimiento de estándares y normativas relevantes. No es necesario que instales ningún software para utilizar SAMM, ya que es un marco conceptual disponible como documentación y recursos online. Las organizaciones, eso sí, pueden descargar guías que están en su repo de GitHub y que están disponibles en su web.

También pueden descargar herramientas de evaluación desde la página oficial de SAMM, y existen herramientas como SAMMY, que es un sistema de gestión gratuito que facilita la adopción del modelo SAMM para organizaciones. El uso típico de SAMM comienza con una evaluación del estado actual de las prácticas de seguridad de una organización. Esto se realiza mediante entrevistas, cuestionarios y análisis de procesos. Luego, se definen objetivos de madurez para mejorar las prácticas de seguridad. Las actividades se organizan en ciclos de mejora continua, donde las organizaciones establecen fases y plazos para implementar mejoras progresivas en áreas de seguridad.

Modelo de Madurez de Garantía de Software

La imagen muestra un marco muy completo que organiza las prácticas de seguridad dentro del ciclo de vida del software, dividiéndolas en funciones empresariales y áreas de seguridad. Es un esquema claro y estructurado que ayuda a entender cómo la seguridad no es un bloque aislado, sino un conjunto de procesos que deben integrarse en cada fase del desarrollo y operación del software.

En la parte superior se ven las Business functions, que representan las grandes áreas del ciclo de vida: Governance, Design, Implementation, Verification y Operations. Cada una marca un momento distinto del proceso, desde la planificación estratégica hasta el mantenimiento y operación de los sistemas una vez desplegados. Debajo aparecen las Security practices, que son las prácticas de seguridad concretas que se deben aplicar en cada función empresarial.

En la sección de Governance, encontramos tres pilares. El primero es Strategy & Metrics, donde se crean estrategias, se promueve la seguridad y se miden los avances. Luego está Policy & Compliance, que abarca la definición de políticas y la gestión del cumplimiento. Finalmente, Education & Guidance, centrado en la formación, la cultura de seguridad y la concienciación organizacional. Esta parte muestra que la seguridad empieza en la organización, no solo en la tecnología.

En la fase de Design, el enfoque se mueve hacia los riesgos del sistema. Aparece Threat Assessment, que incluye perfiles de riesgo y modelado de amenazas, mostrando cómo se anticipan posibles ataques antes siquiera de escribir código. Después está Security Requirements, donde se definen requisitos de seguridad tanto del software como de los proveedores involucrados. Y por último Secure Architecture, que se encarga del diseño seguro de la arquitectura técnica y la gestión de tecnologías.

En Implementation se representan las actividades ya ligadas directamente al desarrollo. Secure Build se centra en el proceso de compilación y las dependencias, algo crucial dado que muchas vulnerabilidades provienen de librerías externas. Secure Deployment cubre la seguridad en el proceso de despliegue y la gestión de secretos. Defect Management se enfoca en la identificación y seguimiento de fallos, así como en la retroalimentación continua, lo que ayuda a mejorar la seguridad de forma iterativa.

La fase de Verification incluye Architecture Assessment, donde se valida la arquitectura y se aplican medidas de mitigación. También está Requirements-driven Testing, que se enfoca en comprobar controles, verificar requisitos y detectar mal uso o abuso potencial. Y por último Security Testing, que profundiza en el testeo escalable y con comprensión detallada, lo que se alinea mucho con el trabajo de pentesters y auditores.

Finalmente, en Operations, la seguridad continúa después del despliegue. Incident Management cubre la detección y respuesta ante incidentes, mientras que Environment Management se encarga del endurecimiento de configuraciones y la gestión de parches. Operational Management incluye protección de datos y gestión de sistemas heredados, mostrando cómo incluso software antiguo necesita controles.  En conjunto, la imagen transmite una visión holística de la seguridad del software: desde la estrategia y el diseño, pasando por la construcción y validación, hasta la operación diaria.

Las herramientas SAMM

El Modelo de Madurez de Aseguramiento de Software (SAMM) es un marco abierto que ayuda a las organizaciones a formular e implementar una estrategia de seguridad de software adaptada a los riesgos específicos que enfrentan. SAMM le ayuda a:

• Evaluar las prácticas de seguridad de software existentes de una organización
• Construir un programa de garantía de seguridad de software equilibrado en iteraciones bien definidas
• Demostrar mejoras concretas en un programa de garantía de seguridad
• Definir y medir las actividades relacionadas con la seguridad en toda la organización.

https://owaspsamm.org/model

Las herramientas SAMM permiten realizar un seguimiento del proyecto y generar informes sobre los niveles de madurez alcanzados. En un ciclo de vida real, podemos automatizar algunas partes del trabajo. Por otro lado, podemos automatizar las pruebas de seguridad con OWASP ZAP, asegurando que las vulnerabilidades sean detectadas de forma temprana y también en la fase de verificación.

Por último, pero no menos importante, podemos automatizar la monitorización en tiempo real de actividades sospechosas con OWASP AppSensor, clave para la fase de monitoreo y respuesta en tiempo real. Implementar OWASP SAMM en el ciclo de vida de desarrollo de tu software mejora significativamente la postura de seguridad de la organización. Estos script permiten automatizar evaluaciones y medidas de seguridad en las fases del ciclo de vida del software, apoyando tu proceso de aplicación del modelo SAMM y garantizando así una protección continua y efectiva. 

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/

Owasp Checklist

La lista de verificación de pruebas de seguridad de aplicaciones web basada en OWASP  ayuda a gestionar el estado de las pruebas e incluye un marco de «mejores prácticas» que  los usuarios pueden implementar en sus propias organizaciones y una guía de pruebas de  penetración de «bajo nivel» que describe técnicas para probar la asignación de problemas de seguridad de aplicaciones web más comunes. Además, contiene la calculadora de evaluación de riesgos de OWASP y la plantilla de resumen de resultados https://github.com/tanprathan/OWASP-Testing-Checklist

OWASP Application Security Verification Standard (ASVS)

El Application Security Verification Standard, o ASVS, es un marco detallado de OWASP que guía la verificación de la seguridad en aplicaciones web y servicios. Está dividido en tres niveles de seguridad, comenzando por el nivel 1, que son controles básicos aplicables a aplicaciones con bajo riesgo de seguridad. El nivel 2 son controles avanzados para aplicaciones que manejan datos sensibles y el nivel 3 son controles completos para aplicaciones críticas, como aquellas en sectores de salud o finanzas. ASVS no es una herramienta o software que se instale, sino un conjunto de requisitos de seguridad que se deben seguir y verificar en las aplicaciones.

El estándar está disponible en formato PDF, Word y CSV y puede ser consultado por desarrolladores, equipos de seguridad y auditores. Además, tenemos muchos más recursos en el GitHub de OWASP, y las organizaciones pueden utilizar ASVS junto con otras herramientas de seguridad, como OWASP ZAP o análisis de código estático, para evaluar si las aplicaciones cumplen con los controles definidos. ASVS es ideal para integrarse durante las fases de diseño, desarrollo y verificación del ciclo de vida de tu software.

Puede ser utilizado para definir requisitos de seguridad desde el principio, garantizar la implementación de controles en el código y verificar que no existen vulnerabilidades antes de que las aplicaciones se pongan en producción. ASVS es ideal para integrarse durante las fases de diseño, desarrollo y verificación del ciclo de vida del software. Puede ser usado para definir requisitos de seguridad desde el principio, garantizar la implementación de controles en el código y verificar que no existen vulnerabilidades antes que las aplicaciones se pongan en producción.

También permite medir el progreso de la seguridad a lo largo del tiempo y, como siempre, podemos automatizar partes del trabajo con ASVS para hacer nuestra vida más divertida. Podemos scriptear desde la validación de entradas hasta la gestión de sesiones seguras alineándonos con los niveles de criticidad definidos por OWASP e integrar ASVS en el ciclo de vida de nuestro software haciéndolo totalmente robusto.

Una base para evaluar los controles técnicos de seguridad

El Proyecto Estándar de Verificación de Seguridad de Aplicaciones (ASVS) de OWASP establece una base para evaluar los controles técnicos de seguridad en aplicaciones web. Además, ofrece a los desarrolladores una lista de requisitos que facilita el desarrollo seguro de software. El objetivo del ASVS es normalizar la verificación de seguridad en el mercado mediante un estándar abierto y comercialmente viable. Proporciona una base para probar los controles técnicos que protegen contra vulnerabilidades como XSS, inyección SQL y fallas de autenticación.

Los objetivos principales del estándar son:

• Métrica: permitir a los desarrolladores y propietarios de aplicaciones evaluar el nivel de confianza en la seguridad de sus sistemas.
• Guía: ofrecer a los desarrolladores orientación sobre qué controles implementar para cumplir los requisitos de seguridad.
• Contratación: servir de base para especificar requisitos de seguridad en contratos o auditorías externas.

La última versión estable disponible es la ASVS 5.0.0, que puede descargarse desde la página oficial de OWASP.

Cómo consultar los requisitos de ASVS

Cada requisito sigue el formato <chapter>.<section>.<requirement>, donde:

• <chapter> indica el capítulo (por ejemplo, 1.#.# corresponde a “Codificación y Sanitización”).
• <section> identifica la sección dentro del capítulo (por ejemplo, 1.2.# corresponde a “Prevención de Inyecciones”).
• <requirement> señala el requisito específico (por ejemplo, 1.2.5 indica la protección contra inyección de comandos del sistema operativo).

El formato recomendado para referirse a requisitos específicos es:

v<version>-<chapter>.<section>.<requirement>

Por ejemplo: v5.0.0-1.2.5 indica el quinto requisito de la sección “Prevención de Inyecciones” del capítulo “Codificación y Sanitización” en la versión 5.0.0.

Nota: Si no se especifica la versión (por ejemplo, “v5.0.0”), se asume que se hace referencia a la versión más reciente, lo que puede generar confusión con el tiempo.

Las listas completas de requisitos de ASVS están disponibles en formatos CSV, JSON y otros, útiles para integraciones y automatización de verificaciones.

OWASP Cheat Sheet Series

Ahora veamos claramente la diferencia entre los principales estándares, índices y proyectos OWASP  —ASVS, MASVS, Proactive Controls, Top 10 y Cheat Sheet Series—, ya que todos pertenecen al ecosistema OWASP pero sirven a propósitos distintos dentro del ciclo de vida de la seguridad del software.

OWASP ASVS (Application Security Verification Standard)

Enfoque: Seguridad general de aplicaciones web.

Objetivo: Establecer un estándar de verificación formal para evaluar el nivel de seguridad de una aplicación.

• Define niveles de verificación (V1, V2, V3) según el riesgo o criticidad de la aplicación.
• Sirve como checklist técnica y metodológica para pentesters, auditores y desarrolladores.
• Organiza controles en áreas temáticas (por ej. autenticación, autorización, manejo de sesiones, criptografía, etc.).
• Se usa tanto para desarrollo seguro como para auditorías de conformidad.

Es un estándar formal de verificación, pensado para evaluar o certificar la seguridad de aplicaciones web completas.

OWASP MASVS (Mobile Application Security Verification Standard)

Enfoque: Seguridad de aplicaciones móviles (Android / iOS).

Objetivo: Versión equivalente al ASVS pero específica para apps móviles.

• Define niveles MASVS-L1, MASVS-L2 y MASVS-R (Resiliencia).
• Se complementa con el proyecto OWASP MSTG (Mobile Security Testing Guide), que describe cómo probar cada control.
• Cubre temas como almacenamiento de datos, autenticación, criptografía, comunicación segura, ingeniería inversa y más.

Es el ASVS del mundo móvil, centrado en la verificación y prueba de seguridad en apps Android/iOS.

OWASP Proactive Controls

Enfoque: Desarrollo seguro (Security by Design).

Objetivo: Enseñar a los desarrolladores qué controles deben implementar desde el código, antes de pensar en pruebas o auditorías.

• Es una guía práctica y preventiva, no un estándar de auditoría.
• Contiene 10 controles proactivos (por ejemplo: validar entradas, aplicar autenticación robusta, manejar errores con cuidado, etc.).
• Se alinea con el OWASP Top 10 y el ASVS, pero desde una perspectiva preventiva y de desarrollo.

Es un manual de buenas prácticas para programadores, centrado en cómo prevenir vulnerabilidades antes de que existan.

OWASP Top 10

Enfoque: Riesgos más comunes y críticos en seguridad web.

Objetivo: Concientizar y priorizar esfuerzos de seguridad.

• Lista de las 10 categorías de riesgos más importantes (por ejemplo: Inyección, Control de Acceso, Fallas Criptográficas…).
• Actualizado cada pocos años.
• No es un estándar ni una guía de prueba detallada, sino una lista de prioridades y riesgos clave.
• Muy usado en formación, auditorías básicas y compliance inicial.

Es una lista de los 10 riesgos más frecuentes y graves, pensada para concienciar y priorizar esfuerzos de mitigación.

OWASP Cheat Sheet Series

Enfoque: Guías técnicas y prácticas para implementación.

Objetivo: Proveer referencias cortas y accionables para desarrolladores y pentesters.

• Cada “cheat sheet” es una guía específica sobre un tema, por ejemplo:
  • SQL Injection Prevention Cheat Sheet
  • Password Storage Cheat Sheet
  • JWT Cheat Sheet
• Está pensado para el día a día del programador o auditor, con ejemplos de código y configuraciones seguras.
• Son complementarias al ASVS, Proactive Controls y Top 10.

Es un conjunto de guías técnicas breves, ideales para consultar rápidamente cómo implementar algo de forma segura.

🧠 Comparación Global

Proyecto OWASP	Enfoque	Tipo de recurso	Público objetivo	Nivel de detalle	Objetivo principal
ASVS	Aplicaciones web	Estándar de verificación	Auditores, pentesters, desarrolladores avanzados	Alto	Verificar seguridad formalmente
MASVS	Aplicaciones móviles	Estándar de verificación	Auditores y devs mobile	Alto	Verificar seguridad en apps móviles
Proactive Controls	Desarrollo seguro	Guía educativa	Desarrolladores	Medio	Prevenir vulnerabilidades desde el diseño
Top 10	Riesgos comunes	Lista de riesgos	Todos (gerencia, devs, testers)	Bajo	Concienciar y priorizar esfuerzos
Cheat Sheet Series	Temas específicos	Guías técnicas	Desarrolladores y pentesters	Muy alto (técnico)	Implementar prácticas seguras concretas

OWASP Secure Coding Practices

El desarrollo seguro es clave en cada etapa del ciclo de vida del software y OWASP proporciona guías valiosas para prevenir vulnerabilidades, como inyecciones SQL, cross-site scripting y errores en la autenticación. La guía OWASP Secure Coding Practices Quick Reference es un conjunto de prácticas agnósticas en cuanto a tecnología, diseñadas para integrarse fácilmente en cualquier etapa del ciclo del desarrollo del software.

Este recurso tiene un formato de lista de verificación que cubre los principios fundamentales de seguridad en áreas como la validación de entradas, la autenticación, manejo de sesiones y mucho más. Aunque el proyecto fue archivado, muchas de sus secciones han sido integradas en el OWASP Developer Guide, que sigue ofreciendo una referencia completa y actualizada.

Este tipo de prácticas deben integrarse desde el diseño hasta la implementación y mantenimiento de las aplicaciones para asegurar un ciclo de vida del software robusto y seguro. Realizar validaciones, cifrados y gestión de sesiones  es clave para evitar vulnerabilidades en producción. Siguiendo estas prácticas de OWASP y utilizando los ejemplos mejorados adaptándolos a ti, podrás reforzar la seguridad de tus aplicaciones y proteger mejor la información sensible y a tus usuarios.

https://owasp.org/www-project-secure-coding-practices-quick-reference-guide

OWASP ESAPI

El OWASP ESAPI es una biblioteca de código abierto que proporciona controles de seguridad reutilizable en aplicaciones web. Está diseñada para facilitar la implementación de medidas de seguridad, como validación de entradas, cifrado, autenticación y autorización, ahorrando a los desarrolladores tiempo al no tener que construir estos mecanismos desde cero.

Las características principales de ESAPI parten de la seguridad a nivel de código, ya que ESAPI proporciona controles predefinidos para abordar amenazas comunes, como la validación de entradas, el cifrado, el manejo de autenticación y autorización, el registro de eventos de seguridad y muchos más. Pero, además, tiene compatibilidad y mantenimiento, ya que, aunque esté principalmente disponible para Java, existen varias versiones o adaptaciones para otros lenguajes, como JavaScript o C++.

A pesar de algunas críticas sobre su arquitectura monolítica, que puede introducir dependencias innecesarias en ciertos casos, sigue siendo una herramienta muy útil y utilizada por muchas organizaciones. En tercer lugar, la facilidad de uso y modularidad destacan en ESAPI, ya que la estructura permite que sea fácilmente integrada en aplicaciones existentes, el retrofitting sin necesidad de reescribir grandes porciones de código y, además, la comunidad de OWASP sigue trabajando en mejoras, con planes para nuevas versiones que buscan reducir la complejidad y mejorar la modularidad, facilitando su uso.

Como todas las herramientas OWASP, el proyecto es free, open source y también está disponible en su web y en su propio repositorio de GitHub, donde cuentas no solo con el software, sino con muchísimos recursos extra. Es interesante, para la integración en el ciclo de vida del software, el uso de ESAPI, ya que puede integrarse en todas las fases del SDLC, es decir, del ciclo de vida. En la fase del diseño, utilizar ESAPI define cómo manejar la validación de entradas y el cifrado de datos.

En la fase de desarrollo, implementar ESAPI es útil para controlar la autenticación, la autorización y la validación en el código. En la fase de pruebas, ESAPI sirve para asegurarse de que los controles están funcionando correctamente mediante pruebas de seguridad automatizadas, y en la fase de mantenimiento, sirve para mantener actualizadas nuestras bibliotecas y protegernos contra nuevas vulnerabilidades. OWASP ESAPI es una herramienta muy poderosa para proteger aplicaciones web mediante controles de seguridad predefinido, y su modularidad y capacidad de ser utilizada en diferentes lenguajes la hacen una solución muy versátil para desarrollar aplicaciones seguras. Además, cuenta con muchísimos recursos y OWASP siempre estará trabajando en mejorar su propio software.

OWASP Vulnerability management guide

Es probable que los fallos de los programas de gestión de vulnerabilidades se deban a fallos de implementación causados ​​por la idea errónea de que un escáner de seguridad que funcione equivale a gestionar vulnerabilidades en entornos de TI

La gestión de vulnerabilidades no se puede externalizar a una única herramienta ni a un conjunto de herramientas muy buenas que puedan orquestar sin problemas un proceso en torno a “algunos hallazgos” y “algunos parches”.

Los procesos descritos en la guía implican la toma de decisiones basada en las prácticas de gestión de riesgos adoptadas por su organización. Si tiene la tarea de implementar un programa de gestión de vulnerabilidades, esta guía le ayudará a plantear las preguntas correctas. Si es gerente o CISO, la guía debería describir cómo integrar un programa de gestión de vulnerabilidades en su organización.

Independientemente de su función, el propósito de la Guía de gestión de vulnerabilidades de OWASP es explicar cómo los procesos continuos y complejos pueden dividirse en tres partes esenciales, que llamamos ciclos.

La OWASP Vulnerability Management Guide es un recurso esencial para ayudar a las organizaciones a implementar un programa sólido de gestión de vulnerabilidades. Ofrece un enfoque estructurado para identificar, clasificar y remediar vulnerabilidades en entornos empresariales con el fin de proteger los activos, reducir riesgos y cumplir con las normativas de seguridad. La guía está organizada en tres fases claves que garantizan un proceso continuo y eficiente para gestionar vulnerabilidades.

Fases

En primer lugar, la detección, que consiste en la identificación de vulnerabilidades a través de herramientas automatizadas o pruebas manuales. Se recomienda utilizar escáneres de vulnerabilidades integrados con sistemas de gestión de archivos para asegurar la cobertura completa de los entornos. Es útil en etapas de desarrollo para mantener las dependencias seguras.

La segunda parte es el informe, la creación de informes que prioricen las vulnerabilidades por severidad y riesgo para la empresa. Estos informes deben incluir recomendaciones de mitigación y asignación de responsabilidades para abordar las vulnerabilidades críticas de manera oportuna.

El tercer paso es la remediación, aplicar acciones correctivas, como parches, configuraciones seguras o actualizaciones de bibliotecas vulnerables. La guía sugiere un enfoque ágil y eficiente para la mitigación de riesgos.

Ventajas y beneficios

Esta guía resalta la importancia de no depender exclusivamente de herramientas automatizadas y, aunque estas son esenciales para detectar vulnerabilidades, es crucial que la organización mantenga una estrategia de gestión de riesgos continua con evaluaciones manuales para asegurar una cobertura total de los activos críticos. Por otro lado, tenemos la integración con escáneres y plataformas. La guía recomienda integrar los escáneres de vulnerabilidades con sistemas de gestión de activos y plataformas de información empresarial para asegurar una visión completa y actualizada de los riesgos.

Esto facilita la toma de decisiones rápida y precisa basada en la información de vulnerabilidades detectadas en tiempo real. Este ejemplo práctico es un pipeline CI/CD. En un pipeline de este tipo, herramientas como OWASP Dependency-Check se pueden integrar para escanear automáticamente las dependencias y generar informes detallados. Este script en concreto permite realizar análisis automáticos de las dependencias de un proyecto en plataformas como Jenkins o GitLab CI, generando un informe en formato HTML con las vulnerabilidades encontradas.

Esta guía, la OWASP VMG, está diseñada para un amplio público, desde profesionales técnicos hasta gerentes no técnicos involucrados en la seguridad de la información. La guía ofrece una hoja de ruta tanto para la implementación técnica de un programa de gestión de vulnerabilidades como para la toma de decisiones a nivel de gerencia. La OWASP Vulnerability Management Guide es una herramienta fundamental para cualquier organización que busque implementar un programa de gestión de vulnerabilidades eficiente y escalable. Su enfoque claro y estructurado ayuda a detectar, reportar y mitigar vulnerabilidades de manera proactiva, minimizando el impacto de ciberataques y asegurando el cumplimiento de normativas de seguridad, lo cual te será tremendamente útil en el ciclo de vida de tu software.

Vulnerability management

La imagen representa un diagrama complejo que muestra cómo se conectan los diferentes ciclos dentro de un proceso de gestión de vulnerabilidades o de un programa continuo de seguridad. Está estructurado mediante círculos de distintos colores, cada uno correspondiente a un ciclo específico, y líneas que reflejan cómo fluye la información y las acciones entre ellos. Aunque al principio parece caótico, la intención es mostrar que todos estos procesos están interrelacionados y que la seguridad no es lineal, sino un sistema dinámico donde cada fase retroalimenta a las demás.

En el centro destaca el Detection Cycle, que actúa como núcleo del diagrama. Este ciclo engloba todo lo relacionado con la detección de vulnerabilidades y hallazgos de seguridad. Alrededor de él aparecen nodos como Scope, Tools, Run tests y Confirm findings, que simbolizan las tareas necesarias para detectar problemas reales: definir el alcance, elegir las herramientas adecuadas, ejecutar pruebas y validar los resultados.

Conectado al ciclo de detección está el Remediation Cycle, que representa las etapas relacionadas con corregir las vulnerabilidades encontradas. Incluye acciones como Prioritize, donde se decide qué vulnerabilidades deben resolverse primero, Remediate, que simboliza la aplicación de parches o correcciones, y Investigate FP, que se refiere a la investigación de falsos positivos. También aparece Control exceptions, que representa las situaciones en las que un hallazgo no puede corregirse inmediatamente y se debe gestionar de forma controlada.

Junto a estos dos aparece el Reporting Cycle, que se encarga de transformar la información técnica en documentación útil para la toma de decisiones. Aquí vemos elementos como Reports, Metrics, Audit trail y Asset groups. Este ciclo aporta claridad sobre qué activos se ven afectados, cómo evolucionan las vulnerabilidades con el tiempo y qué evidencia se genera, lo cual permite medir la efectividad del programa de seguridad.

Cada uno de estos ciclos está interconectado mediante líneas curvas que recorren todo el diagrama, mostrando que nada funciona de manera aislada. Por ejemplo, las métricas del reporting influyen en la priorización del ciclo de remediación, y la confirmación de hallazgos del ciclo de detección alimenta tanto el reporte como los controles de excepción. Además, el alcance y las herramientas para pruebas dejan claro que la detección no es un proceso fijo, sino que se ajusta continuamente según lo que se aprende de los otros ciclos.

En resumen, esta imagen deja ver que detectar, corregir y reportar no son tareas separadas, sino partes de un engranaje que se mueve de forma constante y simultánea, tal como ocurre en equipos de seguridad modernos y maduros. Es un diagrama ideal para explicar la naturaleza cíclica, compleja y colaborativa de la seguridad continua.

Integración práctica en el SDLC de herramientas OWASP

El ciclo de vida del desarrollo del software define las fases claves para desarrollar software de manera eficiente y segura. Al integrar herramientas OWASP en cada etapa, se garantiza que el software esté protegido desde el diseño hasta el despliegue. Este ciclo comienza con la fase de requisitos y planificación. En esta fase, se identifican los objetivos de seguridad que debe cumplir la aplicación. Para establecer una base sólida, SAMM de OWASP nos permite evaluar la madurez de la seguridad en el desarrollo.

Podemos evaluar los requisitos de seguridad y definir un plan de seguridad utilizando SAMM y luego recogerlos en un script en YAML. Pasamos después a la fase de diseño. En esta fase, se crea la arquitectura del sistema considerando las amenazas posibles. Una vez utilizado el Threat Dragon de OWASP para modelar amenazas y anticipar vulnerabilidades desde el diseño, podemos modelarlas mediante diagramas de flujos de datos para identificar vulnerabilidades. Una vez hemos recogido toda la información previa y hemos desarrollado un diseño robusto y potente, podemos pasar a la fase de desarrollo.

En esta fase, es esencial aplicar prácticas de desarrollo seguro y realizar análisis estáticos de código para detectar vulnerabilidades tempranas. Con la Secure Coding Practices y el Dependency-Check de OWASP, podemos analizar la seguridad del código y las dependencias. Esto nos permitirá trabajar siguiendo las prácticas que hayamos aprendido y también utilizar el Dependency-Check para poder desarrollar nuestros productos. Pasamos, pues, a la fase de verificación y pruebas y, en esta fase, se realizan pruebas de seguridad para identificar vulnerabilidades en la aplicación.

ZAP se utiliza para realizar pruebas dinámicas de seguridad y OWASP Juice Shop se utiliza como entorno de prácticas para desarrolladores. En este caso, podríamos ejecutar ZAP para realizar un escaneo activo y utilizar Juice Shop para entrenar a nuestros desarrolladores instalándolo de manera rápida desde Docker. En la fase de implementación, es decir, durante el despliegue, es crucial implementar controles que aseguren la operación segura del software.

El AppSensor de OWASP se integra en la aplicación para detectar y responder a amenazas en tiempo real. Esto lo podemos hacer configurando puntos de detección en la aplicación para monitorizar intentos de ataques en tiempo real. La fase de mantenimiento y monitorización también es importante y en ella se utilizan herramientas de gestión de vulnerabilidades como el DefectDojo de OWASP para seguir los problemas de seguridad identificados y realizar un seguimiento. Integrar DefectDojo para gestionar vulnerabilidades detectadas en producción y mantener un seguimiento adecuado es, como ves, bastante simple.

El flujo de software development life cycles con herramientas de OWASP garantiza que la seguridad esté presente en cada fase del desarrollo, desde la planificación con SAMM, pasando por el diseño con Threat Dragon, el desarrollo con Secure Coding Practices y Dependency-Check, hasta las fases de prueba con OWASP ZAP y la implementación con AppSensor. Con ello se obtiene un ciclo de vida del software robusto y con el adecuado uso de herramientas como DefectDojo para la gestión de vulnerabilidades, conseguirás una operación continua sin comprometer la seguridad.

El ecosistema OWASP aplicado al ciclo de vida de desarrollo seguro

El ecosistema OWASP aplicado al ciclo de vida de desarrollo seguro, conectando cada fase del SDLC con recursos, herramientas, guías y metodologías del proyecto OWASP. Más que un simple diagrama, funciona como un mapa mental que ayuda a visualizar cómo se puede construir una estrategia integral de AppSec apoyándose exclusivamente en elementos del ecosistema OWASP.

En el centro aparece OpenCRE.org, que actúa como un nodo de referencia. OpenCRE es una iniciativa que relaciona controles, requisitos y recursos de múltiples estándares, permitiendo que todo el ecosistema se conecte de manera clara y rastreable. Desde ahí salen flechas hacia todas las fases de la seguridad del software.

A la derecha se encuentra la parte más clásica del SDLC. La fase de Requirements se vincula con estándares y guías como SKF, SecurityRAT, ASVS y MASVS, que sirven para definir requisitos de seguridad desde el inicio. Luego, en Design, se destaca el uso de técnicas de threat modeling mediante herramientas como Threat Dragon, PyTM y Cornucopia, además de charlas y recursos de modelado de amenazas.

La fase de Implementation aparece reforzada con Proactive Controls, Go Secure Coding Practices y la serie de Cheat Sheets, que ayudan a los desarrolladores a aplicar buenas prácticas. También se ve el uso de Dependency Check, Dependency Track y CycloneDX para gestionar dependencias e identificar vulnerabilidades en bibliotecas externas. Desde ahí se conecta con elementos de secure libraries como Secure Headers, ESAPI o CSRFGuard.

En la fase de Verification se sitúan guías como WSTG y MSTG, así como herramientas como Amass, ZAP, OWTF, Nertacker y Code Pulse, mostrando que OWASP cubre desde pruebas automatizadas y manuales hasta análisis profundos de aplicaciones y redes. La etapa final del lado derecho, Policy Gap Evaluation, integra guías como SAMM, ASVS y MASVS, que permiten evaluar la madurez del programa y detectar brechas entre política y práctica.

A la izquierda del diagrama, se representan las funciones más organizacionales. Operation se conecta con herramientas de seguridad defensiva como Coraza, ModSecurity CRS y nuevamente con ASVS y MASVS, demostrando que OWASP también cubre el runtime de las aplicaciones. En Culture Building & Process Maturing aparecen el Security Champions Playbook, SAMM, ASVS y MASVS, reflejando el enfoque en madurez cultural y desarrollo de equipos. Más abajo, Training/Education incluye recursos prácticos como Juice Shop, WebGoat, PyGoat, Security Shepherd, API Top 10, Mobile Top 10, y Snakes & Ladders, todos diseñados para entrenar a desarrolladores y equipos de seguridad en escenarios reales.

Finalmente, en la parte inferior está Metrics, que se conecta tanto con capacitación como con evaluación de políticas, demostrando la importancia de medir para mejorar. La idea es que las métricas retroalimenten todo el proceso, generando un ciclo iterativo donde cada fase influye en la siguiente.

En conjunto, la imagen transmite la idea de un AppSec Program maduro, donde OWASP no se limita a un Top 10, sino que ofrece un ecosistema completo de recursos para cada momento del desarrollo, desde el diseño hasta la operación, pasando por capacitación, métricas y mejora continua. Es una visión clara de cómo estructurar una estrategia de seguridad sólida usando únicamente herramientas abiertas y accesibles.

 

Resumen del capítulo

Este capítulo ofrece una visión completa del ecosistema OWASP y su importancia dentro del desarrollo seguro y el pentesting profesional. Comienza explicando qué es OWASP, su misión global y los principios de apertura, colaboración y comunidad que permiten construir herramientas, guías y estándares reconocidos mundialmente.

Luego se profundiza en:

1. OWASP Top 10 (2021 y 2025)

• Su importancia como índice de riesgos críticos para aplicaciones web.
• La evolución histórica desde 2003.
• Cambios clave en 2025: nuevas categorías, fusiones, énfasis en causas raíz y cadena de suministro.
• Explicación detallada de cada riesgo, su impacto y cómo mitigarlo.

2. SDLC / SSDLC

• Cómo integrar la seguridad en todas las fases del ciclo de vida del software.
• Herramientas OWASP relevantes en cada fase: SAMM, Threat Dragon, ZAP, Dependency-Check, DefectDojo, AppSensor.

3. Estándares y Proyectos Principales

• ASVS y MASVS: estándares de verificación de seguridad para aplicaciones web y móviles.
• Proactive Controls y Secure Coding Practices: guías de desarrollo seguro.
• Cheat Sheet Series: guías técnicas prácticas para implementación segura.

4. Herramientas OWASP

Se detalla el funcionamiento, propósito y uso de herramientas clave como:

• OWASP ZAP para pentesting web automatizado y manual.
• Dependency-Check para análisis de vulnerabilidades en dependencias.
• Dependency-Track para gestión avanzada de SBOM y cadena de suministro.
• ESAPI, Nettacker, AppSensor, entre otras.

5. Laboratorios y Plataformas Vulnerables

Se describen entornos pensados para practicar hacking ético:

• OWASP BWA
• Mutillidae
• Juice Shop
• WebGoat
• Security Shepherd
• WrongSecrets
• GoatDroid / iGoat

6. Gestión de vulnerabilidades

OWASP VMG enseña a estructurar procesos de detección, reporte y remediación alineados con modelos de riesgo.

7. Integración en DevSecOps

Cómo automatizar pruebas y controles de seguridad dentro de pipelines CI/CD utilizando herramientas de OWASP.

10 preguntas que pueden ser respondidas con lo aprendido en el artículo

1. ¿Qué es OWASP y cuál es su misión principal?
2. ¿Cuáles son las herramientas más representativas del ecosistema OWASP?
3. ¿Qué representa el OWASP Top 10 y qué utilidad tiene en el desarrollo seguro?
4. ¿Qué diferencia hay entre el SDLC y el SSDLC?
5. ¿Qué funciones cumple la herramienta OWASP ZAP y cómo se usa?
6. ¿Qué aporta el modelo OWASP SAMM a la seguridad del software?
7. ¿Qué categorías nuevas se incorporaron en el OWASP Top 10 del año 2025?
8. ¿Cómo contribuye el estándar OWASP ASVS en el desarrollo seguro?
9. ¿Qué es OWASP Threat Dragon y cómo ayuda al modelado de amenazas?
10. ¿Cuál es el propósito de herramientas como Dependency-Check y Dependency-Track?

10 ejercicios prácticos basados en el contenido

1. Describe el ciclo SSDLC utilizando herramientas de OWASP en cada fase.
2. Compara las categorías del OWASP Top 10 de 2021 vs. 2025 e identifica cambios clave.
3. Realiza un análisis con Dependency-Check sobre una aplicación e interpreta el resultado.
4. Explica el proceso de pruebas de penetración con OWASP ZAP en una app vulnerable (como Mutillidae).
5. Modela una amenaza usando OWASP Threat Dragon y describe las amenazas identificadas.
6. Usando SAMM, elabora un plan de madurez para una organización que apenas inicia en seguridad.
7. Configura un entorno Juice Shop y explota una vulnerabilidad del Top 10.
8. Elabora un informe ficticio de vulnerabilidades basado en una prueba con OWASP ZAP.
9. Utiliza DefectDojo para centralizar y priorizar las vulnerabilidades encontradas en un escaneo.
10. Realiza un mapeo de herramientas OWASP y su aplicación en cada fase del SDLC.

Respuestas a las 10 preguntas (detalladas)

1. ¿Qué es OWASP y cuál es su misión principal?

OWASP (Open Web Application Security Project) es una organización sin fines de lucro que busca mejorar la seguridad del software. Su misión es lograr un mundo donde el software sea seguro, ofreciendo herramientas, estándares, guías educativas y fomentando una comunidad activa y colaborativa.

2. ¿Cuáles son las herramientas más representativas del ecosistema OWASP?

Entre las principales herramientas se encuentran:

• ZAP (Zed Attack Proxy): para pruebas de penetración.
• Dependency-Check: análisis de vulnerabilidades en dependencias.
• SAMM: modelo de madurez para seguridad del software.
• Threat Dragon: modelado de amenazas.
• ASVS: estándar de verificación de seguridad.
• AppSensor: detección de amenazas en tiempo real.
• DefectDojo: gestión centralizada de vulnerabilidades.

3. ¿Qué representa el OWASP Top 10 y qué utilidad tiene?

El OWASP Top 10 es una lista actualizada periódicamente de las 10 principales vulnerabilidades críticas en aplicaciones web. Su propósito es concienciar y guiar a desarrolladores, testers y organizaciones sobre los riesgos más comunes y cómo mitigarlos. Es una referencia mundial en auditorías, formación y cumplimiento.

4. ¿Qué diferencia hay entre el SDLC y el SSDLC?

El SDLC (Software Development Life Cycle) tradicional no incluye seguridad desde el inicio. En cambio, el SSDLC (Secure SDLC) integra prácticas de seguridad en todas las fases del ciclo (requerimientos, diseño, desarrollo, pruebas, despliegue y mantenimiento), promoviendo software más seguro y reducción de costos.

5. ¿Qué funciones cumple la herramienta OWASP ZAP y cómo se usa?

ZAP es un escáner de seguridad que intercepta el tráfico HTTP/HTTPS, realiza escaneos activos/pasivos, pruebas de fuzzing, autenticación y reporta vulnerabilidades. Se usa en entornos manuales o CI/CD para identificar debilidades como inyecciones, XSS, CSRF, etc., presentes en el OWASP Top 10.

6. ¿Qué aporta el modelo OWASP SAMM?

SAMM (Software Assurance Maturity Model) permite evaluar y mejorar la madurez de las prácticas de seguridad en una organización. Es un marco de trabajo evolutivo, adaptable al contexto, que ayuda a definir objetivos, medir progreso, y aplicar mejoras de forma cíclica y progresiva.

7. ¿Qué categorías nuevas se incorporaron en el OWASP Top 10 del año 2025?

En OWASP Top 10 2025 se incluyen dos nuevas categorías:

• A10:2025 Manejo inadecuado de condiciones excepcionales.
• A03:2025 Fallos en la cadena de suministro (fusión con A06:2021).
  Además, SSRF fue absorbida por A01:2025 – Control de acceso deficiente.

8. ¿Cómo contribuye el estándar OWASP ASVS en el desarrollo seguro?

ASVS es un estándar que guía la verificación de seguridad en aplicaciones según tres niveles (bajo, medio, alto riesgo). Define requisitos de seguridad desde el diseño hasta la validación y permite auditar formalmente si una app cumple con estándares aceptables de seguridad.

9. ¿Qué es OWASP Threat Dragon y cómo ayuda al modelado de amenazas?

Threat Dragon es una herramienta de modelado de amenazas que permite visualizar el flujo de datos, identificar amenazas y aplicar contramedidas. Facilita la identificación temprana de riesgos en el diseño de una app, compatible con metodologías STRIDE, CIA, y LINDDUN.

10. ¿Cuál es el propósito de herramientas como Dependency-Check y Dependency-Track?

Ambas herramientas ayudan a gestionar la seguridad de componentes de terceros:

• Dependency-Check analiza el código y detecta librerías con vulnerabilidades (CVE).
• Dependency-Track permite gestionar riesgos de dependencias de forma continua, evaluando su impacto e integrándose con CI/CD.

Soluciones a los ejercicios (detalladas)

1. Describe el ciclo SSDLC utilizando herramientas OWASP

• Requisitos: SAMM.
• Diseño: Threat Dragon.
• Desarrollo: Secure Coding Practices, ESAPI.
• Verificación: ZAP, ASVS.
• Despliegue: AppSensor.
• Mantenimiento: DefectDojo, Dependency-Check.

2. Compara OWASP Top 10 de 2021 y 2025

• A01 se mantiene como “Broken Access Control”.
• A03:2025 expande “Componentes inseguros” a “Fallos en la cadena de suministro”.
• A10:2025 es nueva: “Manejo inadecuado de condiciones excepcionales”.
• “SSRF” se fusiona con A01:2025.
• Cambios reflejan enfoque en causas raíz y mejoras en categorización.

3. Realiza un análisis con Dependency-Check

• Ejecutar dependency-check –project «mi-proyecto» –scan ./src.
• El reporte muestra CVE, severidad, versión vulnerable.
• Evaluar riesgos y actualizar dependencias afectadas.

4. Pruebas con OWASP ZAP en Mutillidae

• Cargar la app vulnerable.
• Interceptar tráfico y escanear activamente.
• Revisar alertas por XSS, SQLi, CSRF.
• Generar reporte con soluciones recomendadas.

5. Modelado de amenazas con Threat Dragon

• Dibujar flujo de datos.
• Definir activos y usuarios.
• Threat Dragon sugiere amenazas: acceso no autorizado, interceptación de datos.
• Añadir controles: MFA, TLS, validación de input.

6. Plan de madurez con SAMM

• Entrevistas iniciales para evaluar prácticas.
• Resultado: nivel bajo en “Definición de requerimientos”.
• Objetivo: alcanzar nivel intermedio.
• Fase 1: capacitar, Fase 2: aplicar controles, Fase 3: automatizar.

7. Explota vulnerabilidad en Juice Shop

• Instalar: docker run -d -p 3000:3000 bkimminich/juice-shop
• Navegar a /login.
• Inyección SQL: ‘ OR ‘1’=’1 permite acceso no autorizado.
• Ganas puntos en el scoreboard.

8. Informe ficticio de ZAP

• Hallazgo: Inyección SQL.
• Severidad: Alta.
• CWE: 89.
• Recomendación: usar consultas parametrizadas.
• Evidencia: payload ‘ OR 1=1.

9. Prioriza vulnerabilidades en DefectDojo

• Importa resultados de ZAP.
• Deduplicación automática.
• Se prioriza por criticidad.
• Asignar responsables y definir tiempos de mitigación.

10. Mapeo herramientas OWASP vs fases del SDLC

Fase	Herramienta OWASP
Requisitos	SAMM, ASVS
Diseño	Threat Dragon
Desarrollo	Secure Coding Practices, ESAPI
Verificación	ZAP, ASVS, Juice Shop
Implementación	AppSensor
Mantenimiento	DefectDojo, Dependency-Track

Despedida del capítulo

¡Excelente trabajo llegando hasta aquí! En este capítulo aprendiste uno de los conjuntos de conocimientos más importantes para tu carrera como hacker ético: todo el ecosistema OWASP y cómo integrarlo en el ciclo de vida del software y en el pentesting profesional. Ahora comprendes los riesgos más críticos en aplicaciones modernas, conoces las metodologías de prueba más usadas a nivel global y dominas herramientas poderosas para análisis, diseño seguro, modelado de amenazas, automatización, gestión de vulnerabilidades y prácticas de desarrollo seguro.

Estas habilidades te acompañarán en cada auditoría, cada laboratorio, cada proyecto y cada entorno real al que te enfrentes. OWASP no es solo una referencia: es el lenguaje común del profesional de ciberseguridad. Dominarlo te abre puertas, te hace más competente y te permite trabajar con estándares internacionales con total confianza.

Navegar por el complejo panorama de las pruebas de penetración de aplicaciones web puede resultar un desafío. Aun así, con la ayuda de las estrategias, herramientas y técnicas detalladas en esta guía, especialmente aquellas alineadas con el Top Ten de OWASP, estará bien equipado para realizar auditorías de seguridad efectivas. 

Esta guía es sólo un trampolín en el vasto mundo de la seguridad de las aplicaciones. Es imperativo comprender estos conceptos y dominar estas herramientas, pero recuerde que la ciberseguridad es un campo en constante evolución. Requiere aprendizaje continuo y adaptación a nuevas amenazas y vulnerabilidades. Continúa avanzando, practicando y experimentando. Cada herramienta aprendida hoy será un arma clave mañana en tu camino como hacker profesional.