OWASP Top 10

El OWASP Top 10 es el punto de partida estándar para cualquier desarrollador que quiera crear software seguro.

Lo esencial que a saber para el plan de desarrollo:

• ¿Qué es?: Es un documento de concientización que representa el consenso global sobre los diez riesgos de seguridad más críticos en aplicaciones web.
• Priorización estratégica: Permite enfocar los recursos en las amenazas más impactantes, como las inyecciones, los fallos criptográficos y el control de acceso roto, en lugar de perseguir miles de alertas de bajo impacto.
• Primer paso: Es ampliamente reconocido como el primer paso efectivo para cambiar la cultura de una organización hacia un desarrollo de software que produzca código inherentemente más seguro.
• Práctica real: Muchas de estas vulnerabilidades se pueden estudiar y practicar en entornos controlados como WebGoat, que alinea sus ejercicios con este listado.

La lista del OWASP Top 10 (versión 2021), es el estándar actual y el consenso global sobre los riesgos más críticos para las aplicaciones web:

1. A01: Control de Acceso Roto: Fallos donde se permiten a los usuarios acceder a recursos fuera de sus permisos.
2. A02: Fallos Criptográficos: Exposición de datos sensibles por falta de cifrado o uso de algoritmos débiles.
3. A03: Inyección: Incluye inyección SQL, XSS y otras, donde datos no confiables se envían a un intérprete.
4. A04: Diseño Inseguro: Defectos en el diseño y la arquitectura que no se pueden corregir solo con una implementación segura.
5. A05: Configuración Incorrecta de Seguridad: Ajustes de seguridad por defecto, incompletos o mal configurados.
6. A06: Componentes Vulnerables y Obsoletos: Uso de bibliotecas o frameworks con vulnerabilidades conocidas.
7. A07: Fallos de Identificación y Autenticación: Problemas para confirmar la identidad del usuario de manera segura.
8. A08: Fallos en la Integridad de Software y Datos: Suposiciones incorrectas sobre la integridad de actualizaciones de software o datos críticos.
9. A09: Fallos en el Registro y Monitoreo de Seguridad: Insuficiencia para detectar o responder a brechas de seguridad en tiempo real.
10. A10: Falsificación de Solicitudes del Lado del Servidor (SSRF): Un atacante obliga a la aplicación a realizar solicitudes a una ubicación no deseada.

A01: Control de Acceso Roto

Este riesgo ocurre cuando las restricciones sobre lo que los usuarios autenticados pueden hacer no se aplican correctamente. Esto permite a los atacantes acceder a cuentas de otros usuarios, ver archivos sensibles o modificar datos de terceros.

Puntos clave para el plan de desarrollo:

• Negar por defecto: Todo acceso debe estar prohibido a menos que se permita explícitamente.
• Validación en el servidor: Nunca confíes en los controles de acceso del lado del cliente; todas las solicitudes deben verificarse en el sistema confiable.
• Identificadores únicos: Evita el uso de identificadores predecibles en las URLs (como /user/123), lo cual previene ataques de IDOR (Insecure Direct Object Reference).

Recomendaciones de OWASP para mitigarlo

Para mitigar el riesgo de Control de Acceso Roto (A01), es necesario integrar estas recomendaciones técnicas en el plan de desarrollo:

• Negar por Defecto: Configura el sistema para que todo acceso esté prohibido a menos que se permita explícitamente.
• Centralización: Utiliza un único componente o biblioteca comprobada para verificar la autorización en toda la aplicación, evitando implementar lógica de acceso dispersa.
• Principio de Menor Privilegio: Restringe a los usuarios únicamente a las funciones, datos y recursos del sistema estrictamente necesarios para realizar sus tareas.
• Validación en cada Solicitud: Aplica controles de acceso en todas y cada una de las peticiones, incluyendo scripts del servidor, archivos incluidos y solicitudes AJAX o Flash.
• Prevención de IDOR: Restringe las referencias directas a objetos para asegurar que un usuario no pueda acceder a datos de otros simplemente cambiando un ID en la URL.
• Fallo Seguro: Si el mecanismo de control no puede acceder a su configuración de seguridad, debe denegar el acceso automáticamente.

Estas prácticas se alinean con la recomendación del NIST SSDF (PW.1.1) de realizar evaluaciones rigurosas en áreas de alto riesgo como el control de acceso y la gestión de credenciales.

A02: Fallos Criptográficos

El riesgo A02: Fallos Criptográficos ocurre cuando no se protegen adecuadamente los datos sensibles, lo que permite su exposición accidental o mediante ataques.

Para integrar este punto en el plan de desarrollo, considerar estos controles:

• Clasificación de Datos: Identificar y clasificar qué información es sensible (ej. datos personales, financieros) para determinar el nivel de protección necesario.
• Cifrado en Tránsito: Utilizar protocolos seguros como TLS para todas las comunicaciones que involucren datos sensibles.
• Protección en Reposo: Cifrar los datos sensibles almacenados utilizando algoritmos criptográficos robustos y actuales.
• Gestión de Claves: Implementar un ciclo de vida seguro para las claves criptográficas, incluyendo su generación, almacenamiento y rotación periódica.
• Uso de Estándares: Emplear bibliotecas y módulos criptográficos ya probados; evita el uso de algoritmos obsoletos o la creación de métodos de cifrado propios.

Algoritmos Obsoletos para con Fallos Criptográficos

En el contexto de A02: Fallos Criptográficos, se identifican principalmente los siguientes puntos sobre algoritmos obsoletos o débiles:

• MD5: Se menciona explícitamente que debe evitarse para funciones como el hashing de contraseñas.
• Algoritmos no estandarizados: Se desaconseja el uso de algoritmos personalizados o creados internamente; en su lugar, se deben utilizar módulos criptográficos que cumplan con estándares actuales como FIPS 140-2¹.
• Funciones de hashing vulnerables: El uso de funciones de hash débiles que no protejan adecuadamente la integridad de los datos o las credenciales se considera una falla crítica en esta categoría.

Para asegurar el plan de desarrollo, la recomendación general es utilizar siempre bibliotecas y algoritmos robustos y actualizados, verificando que no existan vulnerabilidades conocidas asociadas a ellos.

A03: Inyección

El riesgo A03: Inyección ocurre cuando se envían datos no confiables a un intérprete como parte de un comando o consulta, engañándolo para que ejecute órdenes involuntarias o acceda a datos sin autorización.

Lo fundamental para integrar en el plan de desarrollo:

• Tipos Comunes: Incluye la inyección SQL, NoSQL, de comandos del SO, LDAP y las Entidades Externas XML (XXE²).
• Mecanismo de Prevención Principal: La defensa más efectiva es el uso de consultas parametrizadas (o prepared statements), que mantienen los datos separados del comando SQL, impidiendo que el intérprete los ejecute como código,.
• Controles Complementarios: Implementar validación de entradas mediante “listas blancas” y asegurar que cualquier dato que se devuelva al usuario pase por un proceso de codificación de salida.
• Alineación con Estándares: Esta práctica cumple con la directriz PW.5.1 del NIST SSDF, que exige el uso de funciones y APIs seguras para reducir vulnerabilidades,.

A04: Diseño Inseguro

El riesgo A04: Diseño Inseguro se enfoca en las deficiencias de diseño y arquitectura. A diferencia de otros riesgos, un diseño inseguro no puede corregirse solo con una implementación perfecta, ya que el fallo está en la concepción misma de la aplicación.

Puntos clave para el plan de desarrollo:

• Diseño Seguro (Secure by Design): Identificar y evaluar los requisitos de seguridad desde el inicio para mejorar la eficiencia y reducir vulnerabilidades estructurales.
• Modelado de Amenazas: Utilizar el modelado de riesgos y el mapeo de la superficie de ataque para anticipar fallos lógicos antes de escribir código.
• Patrones de Diseño Estandarizados: Implementar bibliotecas de patrones de diseño seguros y componentes verificados en lugar de crear soluciones de seguridad propias.
• Casos de Abuso: Diseñar pensando en “casos de abuso” para entender cómo un atacante podría forzar a la aplicación a realizar acciones no deseadas.

Esta práctica cumple con la directriz PW.1 del NIST SSDF, que exige diseñar el software específicamente para mitigar riesgos identificados.

Fallos de Diseño Lógico

Un fallo de diseño lógico ocurre cuando la concepción misma de un proceso es defectuosa, permitiendo que un atacante manipule el flujo del negocio a pesar de que el código esté técnicamente “bien escrito”.

Ejemplos claros para El plan:

• Bypass de Doble Factor (2FA): Un caso real (como el que afectó a PayPal en 2016) permitía a un atacante autenticarse proporcionando usuario y contraseña, y luego, usando un proxy como Burp Suite, eliminar los parámetros de las preguntas de seguridad del mensaje POST. Al no encontrar los parámetros, la aplicación simplemente “saltaba” el paso de verificación y permitía el acceso.
• Interfaces de Prueba en Producción: Un fallo común es dejar rutas de “test” o código de depuración activos. Si un atacante descubre una ruta como /test/functions, podría ejecutar funciones internas del sistema que no requieren autenticación porque fueron diseñadas originalmente solo para pruebas locales.

Para prevenir esto, se deben documentar Casos de Abuso que desafíen las suposiciones del diseño y asegurar que la arquitectura siga el principio de “negar por defecto” para cualquier acción no permitida explícitamente.

Diferencia entre Diseño Inseguro e Implementación Pobre

La diferencia fundamental radica en dónde nace el error dentro del ciclo de vida del software:

• Diseño Inseguro (A04): Es un fallo en la concepción lógica o arquitectura de la aplicación. Ocurre cuando el plan mismo es defectuoso; por lo tanto, incluso si el código se escribe “perfectamente” y sin errores técnicos, la aplicación sigue siendo vulnerable porque el diseño permite un abuso.
• Implementación Pobre: Es un fallo técnico en la escritura del código. En este caso, el diseño puede ser robusto, pero el desarrollador cometió un error al ejecutarlo, como olvidar una validación de entrada o usar una función vulnerable.

En resumen, un diseño inseguro no se puede arreglar con una implementación perfecta, ya que el error está en la base.

A05: Configuración Incorrecta de Seguridad

El riesgo A05: Configuración Incorrecta de Seguridad ocurre cuando los ajustes de seguridad se definen de forma incompleta, incorrecta o se mantienen con valores por defecto.

Para integrar este punto en el plan de desarrollo, considerar estos controles:

• Endurecimiento (Hardening): Automatiza el proceso de asegurar el entorno para garantizar una configuración uniforme en todas las etapas.
• Reducción de Superficie: Deshabilita o elimina funciones, archivos, componentes y servicios innecesarios, incluyendo la desactivación de listados de directorios.
• Cambio de Valores por Defecto: Cambia inmediatamente todas las contraseñas y configuraciones de fábrica en sistemas y bases de datos.
• Gestión de Parches: Mantén actualizados todos los marcos de trabajo (frameworks) y componentes del sistema con las últimas versiones aprobadas.

Esta sección cumple con la práctica PW.9 del NIST SSDF, que exige configurar el software para que tenga ajustes seguros de forma predeterminada.

A06: Componentes Vulnerables y Obsoletos

El riesgo A06: Componentes Vulnerables y Obsoletos ocurre cuando utilizas bibliotecas, marcos de trabajo o módulos de terceros que tienen fallos de seguridad conocidos o ya no reciben mantenimiento. Dado que el código de terceros puede representar entre el 70% y el 90% de una aplicación moderna, una sola librería sin parches puede exponer todo tu sistema.

Aquí tienes los controles clave para integrar en tu plan de desarrollo:

• Mantener un Inventario (SBOM): Tener una visión actualizada de todos tus activos de software, incluyendo código abierto y dependencias, mediante una lista detallada llamada Software Bill of Materials.
• Análisis de Composición de Software (SCA): Automatizar la detección de vulnerabilidades conocidas integrando herramientas como Trivy, Nancy o npm-audit en tu flujo de trabajo.
• Gestión de Parches y Eliminación: Establece un proceso regular para actualizar componentes a versiones seguras y elimina cualquier función, archivo o dependencia que no sea necesaria.
• Verificación de Procedencia: Asegura la integridad de lo que descargas confirmando su origen y utilizando firmas digitales para evitar componentes manipulados.

Esta práctica cumple con la directriz PW.4 del NIST SSDF, que exige verificar que los componentes adquiridos cumplan con los requisitos de seguridad durante todo su ciclo de vida.

A07: Fallos de Identificación y Autenticación

El riesgo A07: Fallos de Identificación y Autenticación ocurre cuando las funciones relacionadas con la confirmación de la identidad del usuario se implementan incorrectamente, permitiendo que los atacantes comprometan contraseñas, tokens de sesión o exploten otras fallas para asumir identidades ajenas.

Controles esenciales a integrar en el plan de desarrollo:

• Autenticación Centralizada: Utiliza siempre servicios de autenticación estándar y probados en lugar de implementaciones propias, y ejecútalos en un sistema confiable (lado del servidor).
• Gestión Segura de Contraseñas: Cifra las contraseñas usando algoritmos de hash fuertes y con “sal” (salt), evitando el uso de algoritmos obsoletos como MD5.
• Protección contra Fuerza Bruta: Implementa bloqueos de cuenta tras un número específico de intentos fallidos y exige requisitos de complejidad y longitud (mínimo 8-16 caracteres).
• Mensajes de Error Genéricos: Ante un fallo, responde con mensajes que no revelen qué parte del dato fue incorrecta (ej. “Usuario y/o contraseña inválidos”).
• Doble Factor (MFA): Implementa autenticación de múltiples factores para cuentas altamente sensibles o transaccionales.
• Eliminar Valores por Defecto: Asegúrate de cambiar o deshabilitar todas las credenciales proporcionadas por el fabricante en cualquier componente.

Esta práctica se alinea con el NIST SSDF (PW.1.1), que recomienda evaluaciones rigurosas en el resguardo de la identificación y autenticación. En WebGoat, puedes practicar cómo un atacante usa proxies para intentar evadir el segundo factor de autenticación manipulando los parámetros de la solicitud.

Integración de A07 con la Gestión de Sesiones

El riesgo A07 y la Gestión de Sesiones están intrínsecamente ligados: mientras el A07 se asegura de que el usuario es quien dice ser (autenticación), la gestión de sesiones mantiene esa identidad protegida durante toda la navegación.

Su integración técnica en tu plan de desarrollo se basa en estos puntos críticos:

• Generación Post-Autenticación: Al confirmar la identidad (A07), el sistema debe invalidar cualquier identificador previo y generar uno nuevo, robusto y aleatorio únicamente en el servidor para evitar ataques de fijación de sesión.
• Protección de la “Prueba de Identidad”: Los tokens de sesión deben protegerse con los atributos HttpOnly (para evitar robos vía XSS) y Secure (para asegurar que solo viajen por HTTPS), además de no exponerse nunca en la URL.
• Ciclo de Vida: La sesión debe expirar tras un periodo corto de inactividad y destruirse completamente al cerrar sesión, obligando a una nueva autenticación bajo los controles del A07.
• Control de Riesgo: Según el NIST SSDF (PW.1.1), estas áreas de gestión de credenciales requieren evaluaciones rigurosas por ser objetivos de alto impacto para los atacantes.

A08: Fallos en la Integridad de Software y Datos

El riesgo A08: Fallos en la Integridad de Software y Datos ocurre cuando se asume la integridad del código o los datos sin verificar su procedencia o estado, permitiendo que atacantes inyecten actualizaciones maliciosas o manipulen el pipeline de desarrollo.

Aquí tienes los controles clave para integrar en tu plan:

• Verificación de Firmas: Usa firmas digitales y certificados para confirmar que el software, las actualizaciones y los datos provienen de una fuente legítima y no han sido alterados.
• Seguridad en el Pipeline³ (CI/CD⁴): Asegura el entorno de compilación y despliegue para evitar que se introduzca código malicioso durante el proceso de construcción.
• Gestión de Dependencias (SBOM): Mantén un inventario detallado (Software Bill of Materials) de todos los componentes y bibliotecas de terceros para rastrear su integridad.
• Deserialización Segura: Evita procesar datos no confiables que puedan contener objetos maliciosos, ya que esto puede llevar a la ejecución de código arbitrario.
• Actualizaciones Protegidas: Configura mecanismos de actualización automática que utilicen canales cifrados y verifiquen siempre la firma del paquete antes de instalarlo.

Esta sección se conecta directamente con el grupo Proteger el Software (PS) del NIST SSDF, específicamente las prácticas PS.2 (verificar integridad del release) y PS.3 (archivar y proteger los releases).

Implementación de una Firma de Código en el Software

La implementación de la firma de código se basa en el uso de criptografía para garantizar que el software sea legítimo y no haya sido alterado. Según el NIST SSDF, los pasos fundamentales son:

• Uso de Autoridades de Certificación (CA): Se debe emplear una CA establecida para firmar el código, permitiendo que los sistemas operativos y herramientas del usuario confirmen la validez de la firma antes de la ejecución.
• Firma en múltiples niveles: No solo se firman los ejecutables finales; también se recomienda el uso de firmas de commits en los repositorios para rastrear cambios con responsabilidad y firmar los datos de procedencia (como el SBOM).
• Distribución Segura: Publicar los hashes criptográficos de los archivos en sitios web seguros y configurar los clientes de descarga para que verifiquen automáticamente estas firmas antes de aplicar actualizaciones.
• Gestión del ciclo de vida: Establecer procesos para la renovación, rotación y revocación de certificados, asegurando que las claves de firma se guarden bajo el principio de menor privilegio.

Esto previene que actualizaciones maliciosas se infiltren en el sistema, una parte crítica del riesgo A08.

A09: Fallos en el Registro y Monitoreo de Seguridad

El riesgo A09: Fallos en el Registro y Monitoreo de Seguridad ocurre cuando una aplicación no registra, monitorea o responde adecuadamente a eventos críticos, lo que impide detectar intrusiones en tiempo real y permite que los atacantes mantengan su presencia en el sistema.

Para el plan de desarrollo, integrar estos controles fundamentales:

• Eventos Críticos a Registrar: Registrar fallas de validación de entradas, intentos fallidos de autenticación, errores de control de acceso y excepciones del sistema.
• Datos Esenciales por Evento: Asegúrate de que cada entrada incluya marca de tiempo, nivel de severidad, identidad del usuario, IP de origen y el resultado de la operación.
• Integridad de los Logs: Implementa mecanismos para evitar que los atacantes manipulen o eliminen los registros. Se recomienda el uso de hashes criptográficos para validar su integridad.
• Privacidad: Nunca almacenar información sensible en los registros, como contraseñas, tokens de sesión o datos personales innecesarios.
• Monitoreo y Alerta: Establece umbrales para eventos sospechosos y configura alertas automáticas para que el equipo de respuesta pueda actuar rápidamente.

Esta sección se alinea directamente con el grupo Responder a Vulnerabilidades (RV) del NIST SSDF, que exige identificar y confirmar incidentes de forma continua (RV.1).

A10: Falsificación de Solicitudes del Lado del Servidor (SSRF)

Para cerrar el OWASP Top 10, el riesgo A10: Falsificación de Solicitudes del Lado del Servidor (SSRF) ocurre cuando una aplicación web obtiene un recurso remoto sin validar la URL proporcionada por el usuario. Esto permite a un atacante obligar a la aplicación a enviar solicitudes a destinos no deseados, a menudo para evadir firewalls o acceder a servicios internos protegidos.

Controles clave para el plan de desarrollo:

• Listas Blancas (Allow-lists): Implementar una lista positiva de dominios, nombres de host o direcciones IP permitidas a los que la aplicación puede realizar peticiones.
• Validación de Entrada: Nunca confíar ciegamente en las URLs o parámetros proporcionados por el usuario; validar siempre el esquema, host y puerto.
• Aislamiento de Red: Segmentar y proteger los entornos para que los servidores de aplicaciones no tengan visibilidad innecesaria sobre servicios internos críticos (como bases de datos o APIs administrativas).
• Desactivar Redirecciones: Evitar que el servidor siga automáticamente redirecciones HTTP de forma predeterminada.

Esta práctica se alinea con el grupo Producir Software Bien Asegurado (PW) del NIST SSDF, específicamente PW.5.1, que exige el uso de funciones y APIs seguras para minimizar vulnerabilidades.

CWE Top 25

El CWE Top 25 (versión 2025) es una lista estratégica que identifica las debilidades de software más comunes e impactantes, basada en el análisis de casi 40,000 registros de vulnerabilidades reales (CVE). A diferencia del OWASP Top 10, que se enfoca en categorías de riesgo, el CWE Top 25 se centra en las causas raíz técnicas, como defectos de seguridad de memoria o fallos lógicos específicos.

Las debilidades más peligrosas según el CWE Top 25 (2025):

1. CWE-79 (Cross-site Scripting): No neutraliza entradas del usuario antes de colocarlas en páginas web enviadas a otros usuarios.
2. CWE-89 (Inyección SQL): Permite que datos externos modifiquen comandos SQL enviados a la base de datos.
3. CWE-352 (CSRF): La aplicación no verifica si una petición fue enviada intencionalmente por el usuario autenticado.
4. CWE-862 (Falta de Autorización): El sistema no realiza verificaciones de permisos cuando un actor intenta acceder a un recurso.
5. CWE-787 (Escritura fuera de límites): El producto escribe datos antes o después del final del búfer de memoria.
6. CWE-22 (Path Traversal): Utiliza entradas externas para construir rutas de archivos, permitiendo acceder a directorios restringidos.
7. CWE-416 (Uso después de liberación): Se hace referencia a memoria después de que ha sido liberada, lo que puede causar fallos o ejecución de código.
8. CWE-125 (Lectura fuera de límites): El producto lee datos fuera de los límites del búfer de memoria establecido.
9. CWE-78 (Inyección de comandos del SO): Neutralización inadecuada de caracteres especiales en comandos del sistema operativo.
10. CWE-94 (Inyección de código): Permite inyectar segmentos de código malicioso que el sistema ejecuta involuntariamente.
11. CWE-120 (Desbordamiento de búfer clásico): Copia datos a un búfer sin verificar si el tamaño de la entrada cabe en el destino.
12. CWE-434 (Subida de archivos peligrosos): Permite cargar archivos con extensiones peligrosas que luego se ejecutan en el servidor.
13. CWE-476 (Desreferencia de puntero NULL): El sistema intenta usar un puntero que espera que sea válido pero es nulo, causando un cierre inesperado.
14. CWE-121 (Desbordamiento de búfer en pila): Un desbordamiento donde el búfer afectado está en la pila de ejecución.
15. CWE-502 (Deserialización de datos no confiables): El sistema convierte datos serializados en objetos sin asegurar que el resultado sea válido.
16. CWE-122 (Desbordamiento de búfer en montón): Un desbordamiento que ocurre en la memoria dinámica o “heap”.
17. CWE-863 (Autorización incorrecta): El sistema realiza una verificación de permisos, pero lo hace de forma defectuosa.
18. CWE-20 (Validación de entrada inadecuada): Recibe datos pero no verifica que cumplan con las propiedades necesarias para procesarlos de forma segura.
19. CWE-284 (Control de acceso inadecuado): No restringe o restringe incorrectamente el acceso a recursos por parte de actores no autorizados.
20. CWE-200 (Exposición de información sensible): Revela datos confidenciales a actores que no deberían tener acceso a ellos.
21. CWE-306 (Falta de autenticación en funciones críticas): Permite ejecutar funciones importantes sin requerir una identidad de usuario comprobable.
22. CWE-918 (SSRF): Un servidor web recibe una URL y obtiene su contenido sin asegurar que el destino sea el esperado.
23. CWE-77 (Inyección de comandos): Similar al CWE-78, pero enfocado en la construcción general de comandos mediante entradas externas.
24. CWE-639 (Bypass de autorización vía clave de usuario): Un usuario accede a datos de otro modificando simplemente el identificador (ID) en la petición.
25. CWE-770 (Asignación de recursos sin límites): El sistema asigna recursos (memoria, CPU) sin imponer restricciones de tamaño o cantidad, facilitando ataques de denegación de servicio.

Herramientas SAST

Las herramientas SAST (Static Application Security Testing) funcionan analizando el código fuente, binarios o bytecode de una aplicación sin ejecutar el programa. Su objetivo es identificar fallos de seguridad y calidad en las primeras etapas del desarrollo, permitiendo a los desarrolladores corregir errores mientras el código aún está “fresco” en su mente.

Para lograrlo, estas herramientas emplean técnicas clave como:

• Análisis de Árbol de Sintaxis Abstracta (AST): Convierten el código en una estructura jerárquica para entender su lógica y aplicar reglas de coincidencia de patrones (pattern matching) que detectan funciones inseguras.
• Análisis de Flujo de Datos (Taint Analysis): Rastrean el camino de una entrada de usuario no confiable (fuente o source) hasta que llega a una función sensible (sumidero o sink), verificando si los datos fueron saneados o codificados correctamente en el trayecto.
• Análisis de Control de Flujo: Evalúan todos los caminos de ejecución posibles dentro del código para identificar fallos lógicos complejos.
• Integración en el Pipeline: A menudo realizan “escaneos diferenciales” que analizan solo los cambios en un Pull Request, enviando comentarios automáticos a los desarrolladores.

Para principiantes, las herramientas más recomendadas son:

• Semgrep: Es considerada la opción más “amigable para el desarrollador”. Su principal ventaja es que permite escribir reglas de seguridad usando la sintaxis del mismo lenguaje que estás programando, lo que la hace muy accesible para quienes no son expertos en seguridad. Además, su plan gratuito es muy generoso e incluye funciones de análisis avanzado que otras herramientas cobran.
• SonarQube (Community Build): Es excelente si tu objetivo inicial es aprender sobre calidad de código, “code smells” y deuda técnica. Sin embargo, debes considerar que su versión gratuita es limitada para detectar fallos de seguridad profundos, ya que carece de taint analysis (rastreo de datos no confiables), el cual solo está disponible en versiones de pago.
• Snyk Code: Se recomienda por su enfoque centrado en el desarrollador, ofreciendo una experiencia pulida a través de plugins para el editor de código (IDE) y la línea de comandos.

Integracion SAST en CI/CD

La integración de SAST en un flujo de CI/CD permite “desplazar la seguridad a la izquierda” (shift left), detectando vulnerabilidades en las primeras etapas del desarrollo, cuando el código aún está fresco en la mente del desarrollador.

Los pasos clave para esta integración son:

• Activación Automática: Las herramientas se configuran para realizar escaneos automáticos con cada commit o al abrir un Pull Request (PR).
• Comentarios en el PR: Los resultados se presentan directamente en el flujo de trabajo del desarrollador a través de comentarios en línea en plataformas como GitHub o GitLab, facilitando la corrección inmediata.
• Puertas de Calidad (Quality Gates): Se establecen criterios de aprobación que pueden ser informativos o bloqueantes; por ejemplo, impedir que un PR se fusione si contiene vulnerabilidades de severidad alta.
• Análisis Diferencial: Para optimizar tiempos, muchas herramientas analizan únicamente los cambios introducidos en el PR en lugar de todo el repositorio.

Esta automatización reduce significativamente los costos y la complejidad de la remediación.

Herramientas DAST

El DAST (Dynamic Application Security Testing) es una metodología de pruebas de seguridad que analiza la aplicación mientras está en ejecución. A diferencia del SAST, que examina el código fuente, el DAST adopta un enfoque de “caja negra”, evaluando el sistema desde el exterior como lo haría un atacante real.

¿Cómo funciona el análisis DAST?

• Interacción con la aplicación: El escáner interactúa con la aplicación desplegada (en un entorno de prueba o staging) enviando peticiones a través de sus interfaces, como formularios web y APIs.
• Simulación de ataques: La herramienta inyecta vectores de ataque conocidos (como inyecciones SQL o scripts de XSS) para observar cómo responde la aplicación en tiempo real.
• Identificación de fallos de tiempo de ejecución: Es especialmente efectivo para detectar problemas que no son visibles en el código estático, tales como:
  • Configuraciones incorrectas del servidor o del entorno.
  • Fallos lógicos en la autenticación y el control de acceso.
  • Vulnerabilidades que dependen de la interacción entre múltiples componentes del sistema.

En el ciclo de vida de desarrollo, el DAST se ubica típicamente en la fase de Testing, una vez que el software ha sido compilado y desplegado.

Para principiantes, la opción más recomendada es OWASP ZAP (Zed Attack Proxy):

• Comunidad y Costo: Es una herramienta gratuita y de código abierto que cuenta con una gran cantidad de guías y soporte para quienes están empezando,.
• Versatilidad: Permite realizar desde escaneos automáticos sencillos hasta pruebas manuales más profundas.
• Entornos de Práctica: Es ideal para usarla junto con aplicaciones de entrenamiento como WebGoat, lo que permite aprender a detectar vulnerabilidades en un entorno seguro y controlado,.

Integración DAST en un Flujo de DevSecOps

La integración de DAST en un flujo de DevSecOps ocurre principalmente en la fase de Pruebas (Testing), una vez que la aplicación ha sido compilada y desplegada en un entorno activo (como staging o testing),.

Detalle de cómo se lleva a cabo esta integración:

• Análisis de código en ejecución: A diferencia de SAST, que mira el código fuente, DAST interactúa con la aplicación funcionando para identificar fallos de lógica y controles de autenticación en tiempo de ejecución.
• Layered Testing (Pruebas por capas): Se integra como parte de un ecosistema de pruebas donde se combina con SAST (que detecta patrones de inyección) y fuzzing para cubrir debilidades mapeadas al CWE Top 25.
• Automatización en el Pipeline: Utilizando herramientas como OWASP ZAP, se pueden automatizar escaneos de integración de seguridad para componentes críticos, escalando desde niveles básicos hasta pruebas de regresión (smoke tests⁵) más complejas.
• Validación de infraestructura: Ayuda a detectar configuraciones inseguras que solo son visibles cuando el software interactúa con su entorno real.

---

1. Los módulos criptográficos que cumplen con estándares como FIPS 140-2 (y su sucesor FIPS 140-3) consisten en conjuntos de hardware, software y/o firmware que implementan funciones de seguridad criptográfica (como cifrado, firmas digitales y generación de claves) dentro de un límite de seguridad claramente definido. Estos módulos son validados oficialmente por el NIST y el Centro Canadiense de Ciberseguridad, garantizando los siguientes aspectos clave:
   – Algoritmos aprobados: Utilizan únicamente métodos de cifrado probados y seguros (como AES o RSA).
   – Seguridad física: Los módulos de hardware están diseñados para resistir, detectar o evidenciar manipulaciones físicas.
   – Gestión de claves: Cuentan con procesos seguros para la generación, almacenamiento y destrucción de claves criptográficas.
   – Autenticación: Verifican la identidad o el rol de los usuarios que acceden al sistema. ↩︎
2. La inyección XML, específicamente el ataque XXE (XML External Entities), ocurre cuando un procesador XML mal configurado evalúa referencias a entidades externas dentro de un documento XML enviado por el usuario.
   – En qué consiste: El atacante aprovecha que el analizador XML (parser) procesa definiciones externas para obligar al servidor a revelar archivos locales (como /etc/passwd), interactuar con sistemas internos o incluso realizar ejecuciones remotas de código.
   – Prevención: La defensa principal es configurar el procesador XML para que desactive por completo el uso de entidades externas y definiciones de tipo de documento (DTD). ↩︎
3. La Seguridad en el Pipeline (CI/CD), también conocida como DevSecOps, consiste en integrar prácticas, herramientas y controles de seguridad automatizados en todo el proceso de desarrollo, construcción y despliegue de software. Su objetivo principal es aplicar el concepto de “Shift Left” (Desplazamiento a la izquierda), que significa detectar y corregir vulnerabilidades en las etapas iniciales del código, en lugar de esperar a que el software esté en producción, cuando arreglarlo es mucho más costoso y peligroso ↩︎
4. CI/CD:
   – CI (Continuous Integration – Integración Continua): Práctica donde los desarrolladores suben sus cambios de código a un repositorio central varias veces al día. Cada subida activa pruebas automatizadas para detectar errores rápidamente.
   – CD (Continuous Delivery – Entrega Continua): Automatiza la preparación del código para su lanzamiento. El software aprobado se envía automáticamente a un repositorio, listo para ser desplegado en producción en cualquier momento con un clic manual.
   – CD (Continuous Deployment – Despliegue Continuo): Va un paso más allá de la entrega. Cada cambio que pasa las pruebas automatizadas se publica en producción de forma 100% automática, sin intervención humana. ↩︎
5. Los smoke tests (pruebas de humo) son un conjunto de pruebas rápidas y preliminares que se realizan para verificar que las funciones más críticas de una aplicación operan correctamente tras un despliegue o compilación. Sus puntos clave son:
   – Verificación Básica: Su objetivo es confirmar que los componentes esenciales y los controles de seguridad básicos no se han roto con los cambios recientes antes de proceder a pruebas más profundas.
   – Automatización: Se integran en el pipeline de CI/CD para proporcionar una respuesta inmediata sobre la estabilidad del sistema.
   – Madurez: El uso de smoke tests con alta cobertura de seguridad se asocia con niveles avanzados de madurez (como el Nivel 4 en el modelo DSOMM) ↩︎