Puesta en producción segura

¿Qué porcentaje representa las pruebas unitarias en la pirámide de pruebas?. 10%. 20%. 50%. 70%.

¿Qué porcentaje representa las pruebas de integración en la pirámide de pruebas?. 10%. 20%. 50%. 70%.

¿Qué porcentaje representa las pruebas de aceptación en la pirámide de pruebas?. 10%. 20%. 30%. 70%.

¿Qué comprueban las áreas V2–V3 del OWASP ASVS?. El uso de algoritmos criptográficos y la gestión de claves. Que la identificación de usuarios, el almacenamiento de contraseñas y el control de tokens sean seguros. Que cada acción del usuario esté autorizada de forma explícita. El uso correcto de protocolos TLS y la protección frente a suplantación.

¿Qué caracteriza al Nivel 1 del OWASP ASVS?. Exige pruebas manuales y revisión de diseño completa. Está reservado para sistemas críticos como banca o salud. Controles elementales como HTTPS y validación de entradas, verificables principalmente con herramientas automáticas, para aplicaciones de bajo riesgo. Incluye controles sobre autenticación, sesiones y cifrado para apps comerciales.

¿Qué caracteriza al Nivel 2 del OWASP ASVS?. Solo evalúa el uso de HTTPS y validaciones básicas de entradas. Exige pruebas manuales, revisión de diseño y trazabilidad completa. Controles sobre autenticación, sesiones, cifrado y prevención de inyecciones; recomendado por defecto para la mayoría de aplicaciones comerciales que manejan datos de usuario. Está reservado para prototipos o sistemas internos con exposición limitada.

¿Qué caracteriza al Nivel 3 del OWASP ASVS?. Se centra en controles elementales verificables con herramientas automáticas. Es el nivel recomendado por defecto para aplicaciones empresariales estándar. Solo requiere validación de entradas y uso de HTTPS. Exige pruebas manuales, revisión de diseño y trazabilidad completa; reservado para sistemas críticos como banca, salud o administración pública.

El NIST define el SSDLC como un conjunto de prácticas integradas en cada fase del ciclo de vida del software para que la seguridad sea: Una responsabilidad exclusiva del equipo de seguridad. Una comprobación posterior al desarrollo. Un resultado predecible del proceso de ingeniería. Un requisito opcional según el tipo de aplicación.

Según la norma ISO/IEC 27034-1:2011, ¿en cuántas grandes fases se divide el ciclo de vida del desarrollo de software seguro?. Tres. Cuatro. Cinco. Siete.

En la fase de Diseño del SSDLC, ¿cuál de los siguientes principios establece que, si algo falla, el sistema debe seguir siendo seguro?. Least privilege. Defense in depth. Fail-safe defaults. Separation of duties.

Según el informe State of DevSecOps 2024 de GitLab, integrar la seguridad en las primeras fases del desarrollo reduce los costes de corrección de vulnerabilidades en un: 30%. 40%. 60%. 80%.

El análisis estático (SAST) se diferencia del análisis dinámico (DAST) principalmente en que: SAST requiere acceso al entorno de producción; DAST no. SAST examina el código sin ejecutarlo; DAST evalúa la aplicación en ejecución. SAST solo detecta vulnerabilidades de red; DAST analiza el código fuente. SAST es más preciso que DAST en todos los casos.

¿Cuál es la característica principal del análisis interactivo (IAST) respecto a SAST y DAST?. Analiza únicamente el código fuente sin ejecutar la aplicación. Sustituye completamente a las revisiones manuales de código. Integra sensores dentro de la aplicación para analizar comportamiento durante las pruebas, combinando lo mejor de ambas técnicas. Solo puede ejecutarse tras el despliegue en producción.

En los lenguajes compilados, ¿cuál de los siguientes es el principal riesgo de seguridad asociado a lenguajes como C y C++?. Tipado dinámico que permite conversiones inseguras. Exposición del código fuente al entorno de ejecución. Gestión manual de la memoria, propensa a desbordamientos de búfer. Dependencia de un intérprete potencialmente vulnerable.

El proyecto OWASP Secure Coding Practices recomienda que «los lenguajes con gestión automática de memoria reducen el riesgo de vulnerabilidades, aunque…»: Los hacen incompatibles con entornos de producción. Requieren siempre compilación previa. No lo eliminan completamente. Solo funcionan correctamente en entornos sandbox.

¿Cuál de los siguientes mecanismos del compilador cambia la ubicación de los datos en memoria en cada ejecución para dificultar que un atacante sepa dónde atacar?. ASLR (Address Space Layout Randomization). Stack Canaries. Control-Flow Integrity. Sandboxing.

¿Qué propiedad define el sandbox de aplicaciones en Android?. Cada app comparte el mismo proceso con las apps del mismo desarrollador. El sistema operativo cifra automáticamente los datos de cada app. Cada app se ejecuta en su propio proceso con un identificador de usuario único, impidiendo el acceso al código o datos de otras apps salvo con permisos controlados. Las apps solo pueden comunicarse mediante HTTPS.

En el modelo de ejecución basado en contenedores, ¿cuál es el principal riesgo de seguridad que los diferencia de las máquinas virtuales?. Los contenedores no soportan cifrado de datos en reposo. No permiten el despliegue de múltiples servicios simultáneamente. Comparten el kernel del sistema operativo host, por lo que una vulnerabilidad en él puede afectar a todos los contenedores. No pueden integrarse con sistemas de orquestación como Kubernetes.

La pirámide de pruebas establece una proporción ideal de tipos de pruebas. ¿Cuál es el orden correcto de mayor a menor porcentaje recomendado?. Integración (50%) → Unitarias (30%) → Aceptación (20%). Aceptación (50%) → Integración (30%) → Unitarias (20%). Unitarias (70%) → Integración (20%) → Aceptación (10%). Unitarias (50%) → Aceptación (30%) → Integración (20%).

El estándar ISO/IEC/IEEE 29119-4:2021 define las pruebas unitarias como la verificación de componentes de software: En el nivel de integración con sistemas externos. Bajo condiciones reales de uso del usuario final. En el nivel más bajo de descomposición, comprobando que se comportan conforme a su especificación. Mediante simulación de ataques controlados sobre el sistema completo.

Según el OWASP API Security Top 10 (2023), ¿qué porcentaje de los fallos críticos detectados en pruebas de integración proceden de configuraciones incorrectas de autenticación y autorización entre servicios?. Más del 30%. Más del 50%. Más del 70%. Más del 90%.

El IEEE 829-2008 define las pruebas de aceptación como el proceso formal que determina si un sistema satisface sus criterios de aceptación y permite al cliente: Verificar la ausencia de vulnerabilidades técnicas. Comprobar la cobertura del análisis estático del código. Decidir su aprobación o rechazo. Autorizar el despliegue en el entorno de staging.

¿Cuál es el objetivo principal del SCA (Software Composition Analysis)?. Analizar el comportamiento de la aplicación durante las pruebas de carga. Sustituir al análisis estático en proyectos con componentes de terceros. Identificar vulnerabilidades en componentes de terceros, evaluar licencias y mantener el cumplimiento normativo. Generar automáticamente el artefacto de despliegue.

En el flujo DevSecOps automatizado, ¿en qué momento se ejecuta el análisis DAST?. Antes de la compilación, sobre el código fuente. Durante la compilación, sobre la aplicación desplegada temporalmente en un entorno staging. Después del despliegue en producción, como monitorización continua. Solo cuando se detectan vulnerabilidades críticas en el SAST.

El concepto de security gating en un pipeline CI/CD consiste en: Revisar manualmente el código antes de cada commit. Cifrar los artefactos generados durante el proceso de build. Detener la compilación cuando se supera un umbral de fallos críticos de seguridad. Registrar automáticamente todos los eventos de seguridad en un SIEM.

¿Cuál de los siguientes frameworks incluye protección XSS, validación de entradas, cifrado de configuración y autenticación integrada según la tabla de entornos de desarrollo del temario?. Express.js (Node.js). Django (Python). ASP.NET Core (C#). Flutter (Dart).

La norma ISO/IEC 27002:2022 define el código fuente como: El conjunto de binarios resultantes del proceso de compilación del software. Las especificaciones funcionales que describen el comportamiento del sistema. El código subyacente, las especificaciones y los planes utilizados para crear aplicaciones, programas y procesos. El historial de cambios registrado en el sistema de control de versiones.

El estándar OWASP ASVS (Application Security Verification Standard) se define principalmente como: Una herramienta de análisis dinámico para detectar vulnerabilidades en tiempo de ejecución. Un conjunto de reglas de firewall para proteger aplicaciones web. Un catálogo estructurado de requisitos de seguridad verificables organizados por niveles. Una metodología exclusiva para pruebas de penetración en entornos móviles.

Según el OWASP ASVS, ¿qué nivel está reservado para sistemas críticos como banca, salud o administración pública y exige pruebas manuales, revisión de diseño y trazabilidad completa?. Nivel 1. Nivel 2. Nivel 3. Nivel 4.

Una aplicación de gestión de microcréditos que procesa datos personales, económicos y documentos confidenciales adopta el nivel ASVS 3. ¿Cuál es la principal razón para elegir ese nivel y no el 2?. Porque utiliza frameworks de desarrollo modernos como Spring o Django. Porque está desarrollada con lenguajes compilados más seguros. Porque el impacto potencial de una brecha tiene consecuencias legales y económicas críticas que requieren trazabilidad completa y revisión manual. Porque el número de usuarios simultáneos supera el umbral establecido por OWASP.

En el OWASP Top Ten 2021, ¿qué categoría ocupa el primer puesto (A01)?. Inyección. Fallos criptográficos. Control de acceso roto (Broken Access Control). Fallos de identificación y autenticación.

La categoría A10 del OWASP Top Ten 2021 corresponde a: Fallos en el registro y monitoreo. Componentes vulnerables o desactualizados. Falsificación de solicitudes del lado del servidor (SSRF). Diseño inseguro.

¿Cuál de las siguientes describe correctamente la categoría A08 del OWASP Top Ten 2021?. Uso incorrecto o ausencia de cifrado y transmisión de datos sin protección TLS. Ajustes por defecto inseguros, cabeceras HTTP ausentes o servicios innecesarios activos. Falta de verificación en la cadena de suministro o ausencia de firmas digitales que aseguren la integridad del código desplegado. Errores en la gestión de contraseñas, tokens o sesiones.

¿Cuál de las siguientes novedades se incluye en los borradores del OWASP Top Ten 2024 que NO estaba presente con el mismo énfasis en la versión 2021?. La categoría de inyección SQL como principal vector de ataque. La importancia de validar entradas de usuario en el servidor. Controles específicos para entornos basados en contenedores y pipelines CI/CD, así como riesgos en la cadena de suministro. La necesidad de cifrar las comunicaciones mediante TLS.

El OWASP Mobile Top Ten identifica como uno de sus principales riesgos la «validación deficiente de la integridad del binario». ¿Qué consecuencia directa tiene este fallo?. Que la aplicación no pueda conectarse a servicios externos mediante HTTPS. Que los datos del usuario queden expuestos en el almacenamiento compartido del dispositivo. Que se permitan modificaciones o versiones falsificadas de la app sin ser detectadas. Que los permisos declarados en el manifiesto sean ignorados por el sistema operativo.

¿Cuál es la diferencia principal entre el enfoque de ISO/IEC 27034 y el de NIST SP 800-218 (SSDF)?. ISO/IEC 27034 se centra en aplicaciones móviles; NIST SP 800-218 se centra en aplicaciones web. ISO/IEC 27034 proporciona requisitos técnicos verificables; NIST SP 800-218 gestiona políticas organizativas. ISO/IEC 27034 aborda la seguridad desde la gestión organizativa; NIST SP 800-218 propone acciones concretas y verificables por fase del ciclo de vida. ISO/IEC 27034 es obligatorio en España; NIST SP 800-218 solo aplica en Estados Unidos.

El NIST SP 800-218 (SSDF) se estructura en cuatro funciones principales. ¿Cuál de las siguientes NO es una de ellas?. Preparar la organización mediante directivas y formación en seguridad. Proteger el software durante su desarrollo y mantenimiento. Certificar la conformidad con estándares ISO ante organismos externos. Responder y mejorar la seguridad a través de mecanismos de corrección continua.

El modelo OWASP SAMM en su grado de madurez intermedio se caracteriza por: Verificación manual y reactiva al final del proyecto. Integración de la verificación en flujos CI/CD con herramientas automáticas, reduciendo el tiempo de detección de semanas a horas. Implementación completa de métricas MTTR y tasas de reincidencia. Auditorías externas trimestrales sin automatización.

La fórmula del riesgo en el análisis de seguridad de aplicaciones es: Riesgo = Amenaza + Vulnerabilidad. Riesgo = Impacto / Probabilidad. Riesgo = Probabilidad × Impacto. Riesgo = Activo × Amenaza − Control.

En una matriz de riesgos estándar, ¿qué nivel de riesgo resulta de combinar probabilidad alta con impacto alto?. Alto. Medio. Crítico. Muy alto.

En el área V4 del OWASP ASVS, ¿qué aspecto de seguridad se verifica?. El uso correcto de protocolos TLS y protección frente a suplantación. El uso de algoritmos criptográficos y gestión de claves. Que cada acción del usuario esté autorizada de forma explícita (control de acceso). La validación de entradas y salidas para evitar inyecciones.

En el mapeo OWASP-ASVS, el riesgo A02 (Fallos criptográficos) se corresponde principalmente con el área: V4 – Access Control. V6 – Input and Output Validation. V7 – Cryptography. V10 – Logging and Monitoring.

Durante la fase de explotación controlada en un pentest, ¿cuál es el objetivo real?. Destruir datos para demostrar el impacto máximo del ataque. Identificar versiones obsoletas de software mediante escaneo pasivo. Intentar aprovechar las vulnerabilidades detectadas para comprobar si permiten acceso real, siempre de forma controlada y documentada. Recopilar información pública mediante técnicas de observación pasiva.

En el caso práctico del portal ciudadano, ¿por qué se decide elevar el módulo de pagos y tasas a nivel ASVS 3 y no mantenerlo en nivel 2?. Porque tiene más usuarios simultáneos que el resto del portal. Porque los pagos requieren siempre el nivel máximo según la norma ISO/IEC 27034. Porque el impacto de una brecha en integridad de transacciones y confidencialidad de datos económicos justifica controles avanzados con trazabilidad completa. Porque el ENS obliga a nivel 3 para cualquier componente de una administración pública.

Las medidas compensatorias en la selección de controles de seguridad se aplican cuando: El nivel de riesgo residual es cero tras aplicar los controles preventivos. Se decide sustituir permanentemente los controles ASVS por otros propios. Un control no puede implantarse por razones técnicas o de coste, y se establece una protección equivalente sujeta a revisión periódica. La organización alcanza el nivel de madurez avanzado según OWASP SAMM.

En España, la seguridad de proyectos vinculados a las administraciones públicas se rige principalmente por: ISO/IEC 27001 y NIST SSDF como marcos obligatorios. El ENS (RD 311/2022) y las guías CCN-CERT, complementados con MAGERIT como metodología de análisis de riesgos. Exclusivamente el RGPD (UE 2016/679) y la LOPDGDD. El OWASP ASVS nivel 3 como único estándar técnico reconocido legalmente.

¿Cuál de las siguientes herramientas se clasifica como plataforma de orquestación de resultados que agrega hallazgos de diferentes escáneres y genera informes consolidados?. OWASP ZAP. Burp Suite. SonarQube. DefectDojo.

En una aplicación Spring Boot, el siguiente código acepta @RequestBody Cliente cliente directamente desde el frontend. ¿Cuál es el principal riesgo de seguridad?. El repositorio no puede aplicar transacciones correctamente sin un DTO. Se pierde compatibilidad con el estándar Bean Validation. El cliente puede enviar campos que no debería controlar, como el rol, el saldo o los campos de auditoría. La anotación @PostMapping no es compatible con objetos JPA complejos.

¿Cuál es la solución correcta al problema de aceptar entidades JPA directamente desde el frontend?. Añadir la anotación @Secured al método del controlador. Cifrar el cuerpo de la petición HTTP con TLS antes de procesarla. Separar el modelo de entrada (DTO con validaciones) del modelo de persistencia, limitando explícitamente los campos admitidos. Validar los campos directamente en el repositorio antes de persistirlos.

En el contexto de la inyección SQL, ¿qué técnica elimina el riesgo de forma estructural?. Escapar manualmente los caracteres especiales antes de concatenarlos. Validar la longitud máxima de los campos del formulario en el cliente. Usar consultas parametrizadas (prepared statements), donde los datos nunca forman parte de la estructura de la consulta. Cifrar los valores enviados desde el frontend antes de insertarlos en la base de datos.

En una aplicación con MongoDB, un atacante envía el siguiente cuerpo JSON: {"filtro": {"$gt": ""}}. ¿Qué tipo de ataque representa?. Inyección SQL clásica sobre base de datos relacional. Cross-Site Scripting (XSS) almacenado en colección NoSQL. Inyección NoSQL mediante operadores de consulta que modifican el resultado esperado. SSRF que redirige la petición hacia un servidor interno.

En el ejemplo de control de acceso roto en PHP, el código de menu.php comprueba el rol del usuario para mostrar el enlace, pero admin/usuarios.php no realiza ninguna verificación. ¿Qué principio de seguridad se viola?. El principio de mínimo privilegio en la base de datos. La separación de responsabilidades entre frontend y backend. La verificación del control de acceso debe realizarse en el servidor, no solo ocultando elementos en la interfaz. El principio de fail-safe defaults en la configuración del servidor web.

La función exigir_rol('admin') en PHP devuelve un código HTTP 403 y termina la ejecución si el rol no coincide. ¿Qué característica aporta este enfoque respecto a la comprobación dispersa por el código?. Permite delegar la autorización al navegador del cliente. Reduce el número de peticiones al servidor de autenticación. Centraliza la verificación del acceso en un único punto, haciéndola auditable y consistente en todos los scripts. Elimina la necesidad de mantener sesiones en el servidor.

¿Cuál de los siguientes atributos de cookie impide que esta sea leída desde JavaScript, mitigando ataques XSS que intenten robar la sesión?. Secure. HttpOnly. SameSite=Strict. maxAge.

El atributo SameSite=Strict en una cookie de sesión tiene como efecto principal: Forzar el uso de HTTPS para el envío de la cookie. Impedir que la cookie sea accesible desde JavaScript en el navegador. Evitar que la cookie se envíe en peticiones que se originan desde un sitio externo, mitigando ataques CSRF. Establecer una fecha de expiración máxima de 20 minutos para la sesión.

En una aplicación Flask, el cierre de sesión borra la cookie en el navegador pero no invalida el estado en el servidor. ¿Cuál es la consecuencia directa de este error?. El usuario no puede volver a iniciar sesión hasta que expire el token. La cookie queda expuesta a ataques de fuerza bruta sobre el identificador. Un usuario que cierre la ventana sin usar el botón de logout puede dejar una sesión activa y reutilizable durante horas. El servidor genera un nuevo identificador de sesión en cada petición subsiguiente.

La instrucción session_regenerate_id(true) en PHP, ejecutada justo después de validar las credenciales del usuario, sirve para: Cifrar el identificador de sesión con AES-256 antes de almacenarlo. Ampliar el tiempo de vida de la sesión activa tras la autenticación. Invalidar la sesión previa y generar un nuevo identificador, previniendo ataques de fijación de sesión. Sincronizar la sesión del servidor con la cookie almacenada en el navegador.

En el modelo RBAC, ¿cuál es el principal problema de implementar comprobaciones de rol dispersas por el código (como if user.rol == 'admin') en lugar de un mecanismo centralizado?. Incrementan el coste criptográfico de la autenticación. Obligan a utilizar tokens JWT en lugar de sesiones tradicionales. Dependen de convenciones implícitas difíciles de mantener y auditar cuando el sistema crece o los equipos rotan. Son incompatibles con el estándar OAuth 2.0.

En una arquitectura basada en OAuth 2.0, ¿dónde debe realizarse la verificación de firma, audiencia, emisor y tiempos de validez de un token JWT?. En el frontend, antes de enviar la petición al backend. En la base de datos, mediante un trigger de validación automática. En el backend, nunca delegando esta responsabilidad al cliente. En el servidor de identidad (IdP), que revalida el token en cada petición.

El modelo ABAC (Attribute-Based Access Control) se diferencia del RBAC en que: Solo permite asignar permisos a grupos, no a usuarios individuales. Es incompatible con arquitecturas de microservicios y API Gateways. La decisión de acceso depende de atributos contextuales como el departamento, la ubicación o el nivel de riesgo, no solo del rol asignado. Requiere que todos los permisos estén definidos antes del despliegue, sin posibilidad de cambio en tiempo de ejecución.

¿Cuál es el objetivo principal de algoritmos como BCrypt o Argon2 para el almacenamiento de contraseñas?. Permitir la recuperación de la contraseña original en caso de olvido. Reducir el espacio de almacenamiento necesario en la base de datos. Cifrar la contraseña para que solo el servidor pueda descifrarla. Aumentar el coste computacional de los ataques por diccionario o fuerza bruta.

En Spring Security, la configuración NoOpPasswordEncoder.getInstance() es considerada insegura porque: No es compatible con el algoritmo BCrypt en versiones modernas de Spring. Almacena las contraseñas sin ningún tipo de transformación, en texto claro o sin coste computacional. No permite ajustar el factor de coste según el hardware del servidor. Genera hashes de longitud fija que son vulnerables a colisiones criptográficas.

El concepto de pepper en el almacenamiento seguro de contraseñas consiste en: Añadir un valor aleatorio único por usuario antes de calcular el hash (similar al salt). Concatenar un valor secreto almacenado fuera de la base de datos (en un almacén de claves o HSM) antes de calcular el hash, de forma que la exposición de la BD no sea suficiente para recuperar las contraseñas. Aplicar múltiples rondas de cifrado simétrico AES sobre el hash resultante de BCrypt. Usar un algoritmo de hash diferente para cada usuario según su nivel de privilegio.

En la configuración de Nginx para producción, la directiva server_tokens off tiene como efecto: Deshabilitar el soporte para cookies de sesión en el servidor. Bloquear peticiones sin cabecera de autenticación válida. Ocultar la versión del servidor en las cabeceras HTTP de respuesta, reduciendo la información disponible para un atacante. Forzar el uso exclusivo de TLSv1.3 en todas las conexiones entrantes.

El despliegue de la cabecera HSTS en dos fases (primero max-age=600, luego max-age=31536000) se recomienda para: Cumplir con el estándar PCI-DSS que exige un período mínimo de prueba antes de activar HSTS globalmente. Evitar que los motores de búsqueda indexen el sitio durante la transición a HTTPS. Poder revertir rápidamente si algún servicio interno aún depende de HTTP, antes de comprometer los navegadores con una retención de un año. Reducir la carga del servidor durante el período de migración a TLS.

La directiva Content Security Policy (CSP) en modo Content-Security-Policy-Report-Only tiene como propósito: Bloquear inmediatamente todos los recursos externos no autorizados. Activar el modo estricto de CSP sin necesidad de configurar un endpoint de reporte. Registrar las violaciones de la política en un endpoint sin bloquear el contenido, permitiendo ajustar la directiva antes de activarla en modo estricto. Sustituir al WAF durante el período de configuración inicial de la política.

En el contexto de la automatización de pruebas de seguridad con OWASP ZAP integrado en un pipeline GitLab CI, ¿cuál es el papel real de esta automatización respecto a las auditorías manuales?. Sustituirlas completamente, ya que ZAP detecta el 100% de las vulnerabilidades conocidas. Ejecutarse únicamente cuando se detectan fallos en las pruebas funcionales del pipeline. Detectar regresiones de seguridad de forma consistente en cada ciclo, complementando pero no reemplazando las auditorías manuales. Generar automáticamente los parches de código para las vulnerabilidades detectadas.

En Android, el riesgo de seguridad asociado a los permisos se introduce en el momento en que: El usuario concede el permiso en tiempo de ejecución. La aplicación invoca por primera vez una API protegida. La capacidad se declara en el manifiesto (AndroidManifest.xml), con independencia de si el usuario la concede posteriormente. La aplicación se publica en Google Play y supera la revisión automática.

¿Cuál es la diferencia fundamental entre el modelo de permisos de Android y el de iOS desde el punto de vista de la auditoría de seguridad?. Android usa certificados para controlar el acceso a recursos; iOS usa un manifiesto global. En Android el riesgo se concentra en la sobredeclaración de capacidades en el manifiesto; en iOS el riesgo deriva del uso indebido de capacidades legítimas ya concedidas por el usuario. iOS permite declarar permisos peligrosos sin aprobación del usuario; Android siempre requiere confirmación explícita. En Android los permisos se gestionan exclusivamente en tiempo de compilación; en iOS se gestionan en tiempo de ejecución.

Un permiso declarado en el manifiesto de Android que no está asociado a ningún comportamiento observable en la aplicación, frecuentemente heredado de plantillas o dependencias, se clasifica como: Permiso coherente pero peligroso. Permiso sobredimensionado. Permiso huérfano. Permiso implícito.

El permiso MANAGE_EXTERNAL_STORAGE en Android se considera de alto impacto en entornos corporativos principalmente porque: Permite a la aplicación enviar notificaciones push sin intervención del usuario. Habilita el acceso a la cámara y al micrófono del dispositivo simultáneamente. Concede acceso casi total al almacenamiento externo, superando el modelo de acceso mediado por colecciones de medios y permitiendo leer, modificar o borrar datos no relacionados con la app. Autoriza a la aplicación a establecer conexiones de red sin restricciones del sistema operativo.

La alternativa de diseño preferible al uso de MANAGE_EXTERNAL_STORAGE para una galería de imágenes en entornos corporativos restrictivos es: Solicitar el permiso READ_EXTERNAL_STORAGE con nivel de protección signature. Usar WRITE_EXTERNAL_STORAGE combinado con cifrado AES-256 en el almacenamiento. Usar MediaStore con READ_MEDIA_* para medios y SAF (ACTION_OPEN_DOCUMENT) para acceso puntual a archivos seleccionados por el usuario. Almacenar todos los archivos en el directorio interno de la aplicación sin declarar permisos adicionales.

La firma digital de un APK garantiza exclusivamente dos propiedades. ¿Cuáles son?. Ausencia de código malicioso y corrección funcional de la aplicación. Que el desarrollador es de confianza y que la app cumple las directivas corporativas. Integridad (el archivo no ha sido alterado desde que fue firmado) y origen criptográfico (el APK se firmó con una clave concreta). Que la app ha superado la revisión de la tienda y que sus permisos son mínimos.

En el proceso de verificación de un APK de F-Droid con GnuPG, ¿qué significa obtener el mensaje «La firma no es válida: firma mala»?. Que el certificado de F-Droid ha caducado y debe renovarse antes de continuar. Que el APK utiliza un algoritmo de firma obsoleto no soportado por GnuPG. Que el APK no se corresponde con el artefacto publicado por el repositorio y no debe analizarse. Que la clave pública de F-Droid no ha sido importada correctamente en el almacén de claves local.

¿Con qué comando se calcula el hash SHA-256 de un APK en un sistema Linux?. certutil -hashfile app.apk SHA256. gpg --verify app.apk.asc app.apk. sha256sum app.apk. openssl dgst -sha256 -verify app.apk.

En Android, el almacenamiento en SharedPreferences presenta un riesgo de seguridad porque: Solo permite almacenar datos de tipo String, lo que limita su uso a información poco sensible. Los archivos XML generados se sincronizan automáticamente con servidores externos. Los datos no se cifran por defecto y persisten en copias de seguridad y entornos de depuración, siendo accesibles si el dispositivo está comprometido. El sistema operativo puede revocar el acceso a estos archivos sin notificar a la aplicación.

¿Cuál de los siguientes patrones en el código descompilado con JADX indica escritura persistente en SharedPreferences?. rawQuery y execSQL. EncryptedFile y MasterKey. putString, putInt, apply o commit. KeyGenParameterSpec y setUserAuthenticationRequired.

En Android moderno, ¿qué combinación de APIs representa el enfoque recomendado para almacenamiento seguro de datos pequeños (configuraciones, tokens)?. SharedPreferences con cifrado manual mediante Cipher + clave hardcoded. SQLiteDatabase con consultas parametrizadas y nivel de protección signature. EncryptedSharedPreferences con MasterKey (Jetpack Security / androidx.security.crypto), que gestiona el cifrado AES-256-GCM con claves en Android Keystore. DataStore en modo Proto con serialización Protobuf y firma HMAC-SHA256.

La biometría en Android actúa como control de acceso local a la interfaz de la aplicación. ¿Cuál es su limitación crítica respecto a la protección de datos?. Solo funciona en dispositivos con Android 9 o superior, excluyendo una parte significativa del mercado. No es compatible con el sistema de permisos en tiempo de ejecución de Android 6+. No cifra ni protege el almacenamiento persistente; si los datos están en claro, pueden extraerse sin pasar por el control biométrico mediante copia de seguridad, depuración ADB o análisis forense. Requiere conexión a internet para validar la identidad del usuario contra un servidor de autenticación.

En el flujo de validación de compras integradas, el cliente envía el purchase_token al backend. ¿Por qué el backend no debe confiar directamente en este dato para conceder el derecho?. Porque el purchase_token puede estar caducado si han pasado más de 24 horas desde la compra. Porque Google Play y App Store no proporcionan tokens en formato estándar compatible con todos los backends. Porque el cliente puede enviar un token inventado, de otra compra o de otro usuario; el backend debe verificarlo con la API oficial de la tienda usando credenciales propias del servidor. Porque el token contiene datos cifrados que solo pueden descifrarse con la clave privada de la tienda.

El mecanismo de idempotencia en la validación de compras garantiza que: Cada usuario solo puede realizar una compra por sesión activa. El servidor rechaza automáticamente cualquier petición que llegue después de 60 segundos. Procesar el mismo token o identificador de transacción varias veces produce exactamente el mismo efecto que hacerlo una sola vez, evitando la doble concesión del derecho. La tienda (Google Play o App Store) impide automáticamente que el mismo recibo sea enviado dos veces al servidor.

En iOS, la clave utilizada para garantizar la idempotencia en compras integradas es: purchase_token, equivalente al usado en Android. transaction_id únicamente, que identifica de forma unívoca cada compra. original_transaction_id combinado con transaction_id, donde el primero es estable para toda la suscripción. signed_transaction_info, el objeto JWS firmado por Apple que actúa como identificador único.

En el análisis de tráfico de red de una app móvil con Wireshark, ¿qué hallazgo se considera suficiente por sí solo para declarar la app no apta para producción?. La negociación TLS 1.2 hacia endpoints esperados. El uso de bibliotecas OkHttp o Retrofit para las comunicaciones. La aparición de tráfico HTTP plano sin cifrar, independientemente del tipo de datos transmitidos. La presencia de cabeceras Authorization: Bearer en peticiones HTTPS.

Durante el análisis de tráfico, se observa que una aplicación envía tokens de sesión en cabeceras HTTP aunque las conexiones estén cifradas con TLS. ¿Cuál es el riesgo específico de este diseño?. Los tokens viajan sin cifrar y pueden ser interceptados en redes Wi-Fi públicas. TLS no protege las cabeceras HTTP, solo el cuerpo de la petición. Los tokens son reutilizables y permiten correlacionar sesiones, reconstruir la actividad del usuario o reutilizar credenciales si se obtienen por otros medios. El servidor no puede validar la firma del token al estar separada del cuerpo cifrado.

En el análisis estático con MobSF, ¿cuál de los siguientes hallazgos se clasificaría como fuga explotable y no como ruido técnico?. UUIDs públicos de estándares DRM como Widevine o ClearKey. Traducciones multilenguaje de cadenas de autenticación biométrica. Una clave API de Google Maps (AIzaSyC...) o un token Firebase embebido como constante estática en el código. Hashes criptográficos de bibliotecas de procesamiento multimedia.

¿Cuál de las siguientes acciones está dentro del alcance de control de una solución CASB en movilidad?. Corregir permisos excesivos declarados en el manifiesto de la aplicación. Cifrar automáticamente los datos que la aplicación almacena en el dispositivo. Bloquear descargas o imponer modo solo lectura en dispositivos no gestionados que acceden a servicios corporativos en la nube. Impedir que una app lea datos a los que ya tiene acceso local una vez descargados.

Una organización quiere apoyarse en un CASB para autorizar el uso de una app móvil que accede a datos corporativos. ¿Cuál de los siguientes requisitos es imprescindible para que el CASB aporte control efectivo?. Que la app haya superado previamente un análisis estático con MobSF con puntuación superior a 80/100. Que la app esté firmada con un certificado corporativo emitido por la PKI interna. Que existan directivas de acceso condicional documentadas y activas, registros verificables de actividad e integración con el proveedor de identidad corporativo (IdP/SSO). Que el dispositivo del usuario tenga instalado un agente MDM con acceso root para inspeccionar el tráfico local.

En un entorno de producción, ¿qué característica fundamental distingue a un despliegue seguro frente a una simple copia manual de archivos al servidor?. El uso de un lenguaje de programación compilado para generar los artefactos. La intervención de al menos dos administradores de sistemas durante el proceso. La publicación de una versión identificada mediante un proceso controlado que permite verificar qué cambios se introducen, cuándo y qué efectos producen. La ejecución del proceso de despliegue exclusivamente en horario de mantenimiento programado.

El principio de reproducibilidad en un despliegue seguro establece que: Cada desarrollador debe poder replicar el entorno de producción en su máquina local. El proceso de despliegue debe ejecutarse siempre por la misma persona para garantizar consistencia. El proceso de despliegue debe producir siempre el mismo resultado cuando se ejecuta con las mismas fuentes y configuraciones, evitando dependencias de ajustes manuales. El software desplegado debe poder ejecutarse en cualquier sistema operativo sin modificaciones.

Uno de los riesgos principales del despliegue manual en sistemas que han crecido o donde intervienen varios desarrolladores es: La imposibilidad de usar sistemas de control de versiones distribuidos como Git. El aumento del tiempo de compilación al no poder paralelizar el proceso. La dificultad para revertir cambios si una actualización provoca fallos, ya que restaurar el estado anterior puede ser complicado sin trazabilidad. La incompatibilidad con herramientas de análisis estático integradas en el IDE.

El término DevOps se define en el temario como: Una plataforma específica para la gestión de contenedores en entornos de producción. Un conjunto de herramientas de automatización para la compilación y el despliegue de software. Un conjunto de prácticas que integra el desarrollo de software con su operación en producción para que el software se construya teniendo en cuenta desde el inicio las condiciones reales de producción. Un modelo organizativo que separa los equipos de desarrollo y operaciones para evitar conflictos de responsabilidad.

En DevOps, ¿cuál de las siguientes afirmaciones describe correctamente el impacto de la automatización sobre la trazabilidad del software?. La automatización elimina la necesidad de mantener registros de cambios al hacer el proceso predecible. La automatización reduce la trazabilidad al eliminar la intervención humana documentada. Cada artefacto generado puede asociarse a una versión concreta del código, permitiendo reconstruir el estado del sistema en cualquier momento. La trazabilidad solo se consigue mediante auditorías manuales periódicas complementarias a la automatización.

Un commit en Git está compuesto por tres elementos esenciales. ¿Cuáles son?. Rama de origen, hash del artefacto y log de pruebas ejecutadas. Nombre del archivo modificado, diferencia del código y firma digital del desarrollador. Instantánea del estado del código, mensaje descriptivo del cambio, y autor con fecha. Identificador de la rama, referencia al commit anterior y checksum de integridad.

¿Por qué se recomienda usar git revert en lugar de otras operaciones que reescriben el historial cuando el código ya está en producción?. Porque git revert es el único comando que permite deshacer cambios en ramas protegidas. Porque git revert elimina permanentemente el commit problemático del historial. Porque git revert genera un nuevo commit que deshace los cambios sin alterar el historial existente, dejando constancia auditable de la operación. Porque git revert es compatible con todos los sistemas de integración continua, mientras que otras operaciones no lo son.

En un repositorio gestionado con Git, ¿qué rol tiene la capacidad de aprobar la integración de cambios en la rama principal según el modelo de control de acceso descrito en el temario?. Desarrollador. Revisor. Administrador. Auditor.

Un build reproducible garantiza que el artefacto generado es idéntico cuando se usa el mismo estado del repositorio y las mismas dependencias. ¿Cuál es el factor más difícil de controlar para garantizar esta propiedad?. Las versiones del código fuente identificadas mediante Git. Las dependencias externas fijadas mediante un lockfile. El entorno en que se ejecuta el proceso de construcción (sistema operativo, herramientas y versiones instaladas), que se resuelve habitualmente mediante contenedores o entornos virtuales. El número de núcleos de CPU disponibles durante la compilación.

En el archivo de configuración de GitHub Actions, la sección on: push: branches: [main] define: El entorno de ejecución donde se construirá el artefacto. Las pruebas automáticas que se ejecutarán tras la compilación. El disparador del pipeline: el build se ejecuta automáticamente cada vez que se registra un cambio en la rama principal. Las ramas que quedan excluidas del proceso de integración continua.

¿Cuál es la diferencia organizativa entre entrega continua (Continuous Delivery) y despliegue continuo (Continuous Deployment)?. La entrega continua automatiza las pruebas; el despliegue continuo automatiza solo la compilación. La entrega continua aplica a entornos cloud; el despliegue continuo aplica a servidores físicos. En la entrega continua el artefacto está listo para desplegar pero requiere aprobación explícita antes del paso final; en el despliegue continuo el despliegue a producción es automático si el pipeline supera todas las fases. La entrega continua incluye pruebas de seguridad; el despliegue continuo omite estas pruebas para reducir el tiempo de publicación.

En el contexto de la integración continua, ¿qué tipo de prueba verifica que el módulo de registro de incidencias se comunica correctamente con la base de datos y que los datos se almacenan en el formato esperado?. Prueba unitaria. Prueba de aceptación (UAT). Prueba de integración. Prueba de regresión de seguridad.

Un contenedor se diferencia de una máquina virtual principalmente en que: El contenedor incluye su propio sistema operativo completo, mientras que la máquina virtual comparte el kernel del host. La máquina virtual es más portable entre entornos que el contenedor. El contenedor no incluye un sistema operativo completo, sino que comparte el kernel del host, siendo más ligero; la máquina virtual dispone de su propio sistema operativo completo. Los contenedores solo pueden ejecutarse en entornos cloud, mientras que las máquinas virtuales funcionan en cualquier infraestructura.

¿Cuál es la principal ventaja de los contenedores respecto a la portabilidad del software?. Permiten ejecutar el software sin necesidad de ningún sistema operativo en el servidor anfitrión. Garantizan que cada instancia del servicio dispone de su propio hardware dedicado. Aseguran que el software se ejecutará de forma idéntica en cualquier entorno compatible, ya que encapsulan la app junto con todas sus dependencias. Eliminan la necesidad de definir dependencias externas durante el proceso de construcción.

Kubernetes como orquestador de contenedores proporciona tres funciones operativas esenciales. ¿Cuál de las siguientes NO es una de ellas?. Distribución de carga entre distintas instancias del servicio. Supervisión y reinicio automático de instancias que se detienen inesperadamente. Actualización progresiva del software sustituyendo gradualmente instancias antiguas por nuevas. Cifrado automático del tráfico entre contenedores mediante TLS sin configuración adicional.

El enfoque de Infraestructura como Código (IaC) resuelve principalmente el problema de: La falta de herramientas para automatizar el proceso de compilación del software. Las diferencias de configuración entre entornos (desarrollo, pruebas y producción) que provocan comportamientos inesperados al desplegar la aplicación. La imposibilidad de ejecutar pruebas automáticas directamente en el entorno de producción. La dificultad para gestionar el historial de cambios en el repositorio de código fuente.

¿Cuál de las siguientes herramientas de IaC está específicamente orientada al aprovisionamiento de infraestructura en entornos cloud y la gestión de su ciclo de vida?. Ansible. Puppet. Chef. Terraform.

La herramienta Chaos Monkey, desarrollada por Netflix, se utiliza para: Detectar vulnerabilidades de seguridad en imágenes de contenedores Docker. Simular ataques de denegación de servicio (DDoS) en entornos de preproducción. Detener aleatoriamente instancias del sistema para comprobar su capacidad de recuperación automática. Inyectar latencia de red controlada para medir el impacto en el rendimiento de la aplicación.

El indicador RPO (Recovery Point Objective) se define como: El tiempo máximo admisible para restablecer el servicio tras un incidente grave. El número máximo de peticiones perdidas durante el proceso de recuperación del sistema. La cantidad máxima de información que se puede perder, expresada en tiempo, definiendo hasta qué punto en el pasado debe poder recuperarse el sistema. El porcentaje mínimo de disponibilidad del servicio garantizado por el plan de recuperación.

Un sistema tiene un RTO de 4 horas y un RPO de 24 horas. ¿Cuál es la interpretación correcta de estos valores?. El sistema debe recuperarse en 24 horas y puede perder hasta 4 horas de datos. El sistema debe recuperarse en 4 horas sin pérdida de ningún dato. El sistema debe estar operativo en un máximo de 4 horas tras el fallo, y en el peor caso podrían perderse los datos generados durante las últimas 24 horas. El sistema puede estar caído hasta 24 horas y debe recuperar los datos de las últimas 4 horas.

¿Cuál de los siguientes modelos propios de grandes organizaciones adapta los principios del desarrollo seguro a distintos entornos tecnológicos y es desarrollado por Microsoft?. OWASP SAMM. Security Development Lifecycle (SDL). NIST SP 800-218 (SSDF). ISO/IEC 27034-1.

Según el OWASP Secure SDLC Quick Reference Guide, la mayoría de los fallos en la adopción del SSDLC no se deben a limitaciones técnicas, sino a: La falta de herramientas de análisis estático adecuadas para el lenguaje utilizado. La resistencia organizativa a modificar procesos ya establecidos. La incompatibilidad entre los frameworks modernos y los estándares de seguridad. El coste excesivo de las auditorías externas de seguridad.

Según el informe State of DevSecOps 2024 de GitLab, integrar la seguridad en las primeras fases del desarrollo reduce el tiempo de resolución de incidentes en un: 30%. 40%. 50%. 70%.

El patrón arquitectónico MVC (Modelo-Vista-Controlador) contribuye a la seguridad del software principalmente porque: Cifra automáticamente los datos transmitidos entre el cliente y el servidor. Impide el acceso no autorizado a los recursos del sistema operativo. Separa las funciones de la aplicación, la interfaz y el control de eventos, haciendo el código más fácil de comprender, modificar y auditar. Integra mecanismos de autenticación multifactor en la capa de presentación.

El patrón MVVM (Modelo-Vista-ViewModel) es especialmente útil en: Aplicaciones de servidor que procesan grandes volúmenes de peticiones concurrentes. Sistemas de autenticación federada basados en OAuth 2.0. Interfaces reactivas como las móviles, permitiendo que la pantalla se actualice automáticamente cuando cambian los datos. Pipelines de integración continua donde se requiere separación entre build y pruebas.

Según la Directiva NIS2 (UE, 2023), las organizaciones deben mantener un inventario actualizado de los componentes de software empleados. Este requisito se logra mediante la creación de: Un CVE (Common Vulnerabilities and Exposures) interno de la organización. Un SAST periódico sobre todas las dependencias del proyecto. Una SBOM (Software Bill of Materials), registro detallado de todos los componentes, versiones, proveedores y licencias. Un DAST continuo integrado en el pipeline de CI/CD.

¿Cuál de los siguientes gestores de paquetes corresponde al ecosistema de Python?. Maven. npm. pip / Poetry. Cargo.

En Android, el sistema de almacenamiento seguro de claves y certificados equivalente al Keychain de iOS se denomina: SecureVault. EncryptedStorage. Keystore. SafeBox.

La complejidad ciclomática de un código mide: El número de bibliotecas externas importadas en el proyecto. El porcentaje de código ejecutado por las pruebas automáticas. El número de caminos distintos que puede seguir el código al ejecutarse. El tiempo medio de ejecución de las pruebas unitarias del proyecto.

El framework Django (Python) incluye entre sus mecanismos de seguridad integrados: Gestión de certificados TLS y rotación automática de claves. Sistema de orquestación de contenedores con soporte nativo para Kubernetes. Validación de formularios, ORM seguro frente a inyecciones SQL y middleware de cabeceras seguras. Análisis estático del código fuente integrado en el proceso de build.

El framework Express.js (Node.js) se diferencia de Django o Spring Security en que: No soporta el protocolo HTTPS ni la gestión de certificados TLS. Incluye por defecto protección CSRF y filtros XSS sin configuración adicional. Requiere módulos externos como Helmet y CSURF para implementar las principales medidas de seguridad. Solo puede ejecutarse en entornos de contenedores Docker con configuración específica.

En el modelo sandbox aplicado a servicios cloud como AWS Lambda, ¿cuál es la característica de aislamiento principal?. Cada función Lambda comparte el sistema de archivos con otras funciones del mismo usuario. Las funciones Lambda se ejecutan siempre en el mismo servidor físico para garantizar consistencia. Cada función se ejecuta en un entorno aislado sin acceso directo al sistema operativo subyacente. AWS Lambda usa máquinas virtuales completas para aislar cada función, similar a un hipervisor.

¿Cuál de los siguientes principios de diseño seguro establece que cada componente debe operar con los permisos estrictamente necesarios?. Defense in depth. Fail-safe defaults. Least privilege (mínimo privilegio). Separation of duties.

En el año 2023 se registraron más de 200 incidentes de paquetes falsos con nombres similares a otros legítimos en repositorios públicos. ¿Qué técnica de ataque describe este fenómeno?. SQL injection sobre el gestor de paquetes. Man-in-the-middle durante la descarga de dependencias. Typosquatting o suplantación de paquetes mediante nombres similares a bibliotecas legítimas. Explotación de vulnerabilidades en el protocolo TLS del repositorio.

La cobertura de pruebas (test coverage) se define como: El número total de pruebas ejecutadas en el pipeline de CI/CD por versión. El porcentaje de código que ha sido ejecutado por las pruebas automáticas. La proporción entre pruebas de seguridad y pruebas funcionales en el plan de pruebas. El tiempo máximo permitido para ejecutar la suite completa de pruebas antes del despliegue.

Las herramientas Appium, Espresso y XCUITest se utilizan habitualmente para: Análisis estático de código fuente en aplicaciones móviles Android e iOS. Monitorización del tráfico de red generado por aplicaciones móviles en producción. Pruebas de aceptación (UAT) automatizadas en dispositivos o emuladores móviles. Gestión automatizada de certificados y firmas digitales en apps móviles.

En entornos móviles, herramientas como MobSF, QARK y Android Lint se utilizan en la fase de: Monitorización continua del tráfico en producción. Gestión de permisos en tiempo de ejecución durante las pruebas de usuario. Automatización de la seguridad en el entorno de compilación móvil (análisis de permisos, configuraciones de red y almacenamiento inseguro). Orquestación de contenedores para el despliegue de backends de aplicaciones móviles.

El CVE (Common Vulnerabilities and Exposures) es un sistema mantenido por: OWASP Foundation en colaboración con los principales fabricantes de software. El Instituto Europeo de Normas de Telecomunicaciones (ETSI). MITRE Corporation con apoyo del Departamento de Seguridad Nacional de EE.UU. El NIST, como parte del marco de ciberseguridad NIST CSF.

La Clean Architecture como modelo de organización del código promueve principalmente: La centralización de toda la lógica de negocio en una única capa monolítica para simplificar el mantenimiento. La eliminación de dependencias externas para garantizar la seguridad del software. Capas bien definidas y desacopladas que no mantienen dependencias directas entre sí, favoreciendo escalabilidad y facilidad de pruebas. La integración automática de mecanismos de cifrado en cada capa de la arquitectura.

Según el Microsoft SDL, la elección del lenguaje y las opciones de compilación deben revisarse en función de los requisitos de seguridad. Entre las buenas prácticas recomendadas se incluye: Preferir siempre lenguajes interpretados por su mayor flexibilidad y rapidez de desarrollo. Confiar en los valores por defecto del compilador sin necesidad de configuración adicional. Activar las protecciones del compilador (ASLR, Stack Canaries) y evitar constructos obsoletos o inseguros. Delegar toda la seguridad del binario a las herramientas de análisis dinámico en staging.

Según el OWASP ASVS, el Nivel 1 está orientado a: Sistemas críticos de banca y salud con datos altamente sensibles. Aplicaciones empresariales que manejan datos de usuario y requieren controles sobre autenticación y sesiones. Aplicaciones de bajo riesgo con controles elementales como validación de entradas y uso de HTTPS, verificables principalmente mediante pruebas automatizadas. Prototipos internos sin exposición al exterior que no manejan datos personales.

El estándar OWASP ASVS es descrito en el temario como «un lenguaje común entre desarrolladores y auditores». ¿Qué ventaja concreta aporta esta característica?. Permite automatizar completamente las auditorías sin intervención humana. Obliga a los desarrolladores a certificarse en seguridad antes de trabajar con el estándar. Facilita que cada control pueda vincularse a hallazgos de herramientas automáticas, aportando trazabilidad y facilitando auditorías externas. Reduce el número de herramientas de análisis necesarias al estandarizar los formatos de salida.

La categoría A03 — Inyección del OWASP Top Ten 2021 abarca: Exclusivamente inyecciones SQL sobre bases de datos relacionales. Inyecciones SQL y XSS como los dos únicos vectores reconocidos. Inyecciones SQL, LDAP, NoSQL e instrucciones del sistema, producidas cuando la aplicación inserta datos no validados en una consulta o instrucción. Solo inyecciones en plantillas web del lado del servidor (SSTI).

La categoría A04 — Diseño inseguro del OWASP Top Ten 2021 se diferencia de otras categorías en que: Se centra exclusivamente en errores de configuración del servidor web. Solo aplica a aplicaciones desarrolladas sin frameworks modernos. Refleja fallos de arquitectura o de lógica de negocio, como la falta de controles de flujo o validaciones insuficientes en procesos críticos. Está orientada a vulnerabilidades introducidas por componentes de terceros desactualizados.

La categoría A09 — Fallos en el registro y monitoreo del OWASP Top Ten 2021 describe: La ausencia de cifrado en los logs del sistema que expone datos sensibles. El exceso de información en los registros que facilita la ingeniería inversa. La ausencia de trazabilidad o la incapacidad para detectar ataques en curso debido a registros incompletos o no correlacionados. El acceso no autorizado a los registros de auditoría por parte de usuarios internos.

El estándar OWASP MASVS (Mobile Application Security Verification Standard) es: Una herramienta de análisis dinámico específica para aplicaciones Android. El equivalente móvil del OWASP Top Ten, con exactamente 10 categorías de riesgo. El equivalente móvil del ASVS, que proporciona requisitos específicos de seguridad para aplicaciones Android e iOS. Una guía de configuración segura para servidores que sirven aplicaciones móviles.

En el análisis de riesgos, los activos se evalúan según tres dimensiones clásicas de seguridad. ¿Cuáles son?. Autenticación, Autorización y Auditoría (las tres A). Prevención, Detección y Respuesta. Confidencialidad, Integridad y Disponibilidad (CIA). Identificación, Clasificación y Mitigación.

En el ciclo de mejora continua propuesto por el ASVS e ISO 27001, ¿cuál es el orden correcto de las cuatro etapas?. Ejecutar → Planificar → Actuar → Verificar. Verificar → Planificar → Ejecutar → Actuar. Planificar → Ejecutar → Verificar → Actuar. Planificar → Verificar → Actuar → Ejecutar.

El componente ONF (Organizational Normative Framework) de la norma ISO/IEC 27034 representa: Los controles concretos que deben aplicarse en cada proyecto de desarrollo. La documentación que justifica que las medidas implementadas cumplen los requisitos. El conjunto de políticas, estándares y procedimientos de seguridad definidos por la organización. El proceso de gestión de la seguridad de la aplicación a lo largo de su ciclo de vida.

La metodología MAGERIT se utiliza principalmente en: Organizaciones privadas del sector financiero para el cumplimiento de PCI-DSS. Empresas tecnológicas que adoptan el marco NIST Cybersecurity Framework. El sector público español como metodología de análisis de riesgos, complementando el ENS. Proyectos de desarrollo de software de código abierto bajo licencia GNU.

En el mapeo OWASP-ASVS, el riesgo A09 (Fallos de registro y monitoreo) se corresponde con el área: V4 – Access Control. V7 – Cryptography. V10 – Logging and Monitoring. V13 – Configuration and Deployment.

¿Cuál de las siguientes herramientas se clasifica como escáner dinámico (DAST) para detectar vulnerabilidades web y de API?. SonarQube. Semgrep. OWASP ZAP y Burp Suite. Dependency-Track.

Según el OWASP Mobile Top Ten, la «autenticación insuficiente» en aplicaciones móviles incluye: El uso de algoritmos de cifrado simétrico en lugar de asimétrico para proteger tokens. La posibilidad de eludir controles de acceso o reutilizar sesiones caducadas. La falta de ofuscación del código binario de la aplicación. El almacenamiento de credenciales en el almacén de claves del sistema operativo.

En la fase de reconocimiento inicial de un pentest, ¿cuál es la característica definitoria de las técnicas empleadas?. Se explotan activamente las vulnerabilidades detectadas para demostrar el acceso real. Se instalan herramientas de análisis en el sistema objetivo para acelerar la recopilación de datos. Son técnicas de observación pasiva (sin alterar el sistema) que recopilan información pública como dominios, IPs y servicios visibles. Se realizan escaneos activos con herramientas como Nmap para identificar puertos abiertos.

El riesgo residual tras aplicar controles de seguridad debe gestionarse de la siguiente manera si sigue siendo alto: Documentarse y aceptarse como parte inherente del negocio sin acciones adicionales. Transferirse completamente a un proveedor de seguros cibernéticos. Planificar acciones adicionales o revaluar la viabilidad del proyecto, integrando la revisión en los pipelines CI/CD para que cualquier cambio dispare una nueva evaluación. Reducirse automáticamente elevando el nivel ASVS del módulo afectado sin análisis adicional.

Según el temario, las pequeñas empresas suelen preferir OWASP ASVS frente a otros marcos porque: Es el único marco reconocido legalmente en la Unión Europea para aplicaciones web. No requiere ningún tipo de auditoría externa para demostrar su cumplimiento. Tiene aplicabilidad directa y un enfoque centrado en el código, siendo más accesible para equipos pequeños. Es el estándar con mayor número de controles automatizables mediante herramientas gratuitas.

El área V6 del OWASP ASVS verifica: El uso correcto de protocolos TLS y la protección frente a ataques de suplantación. Que cada acción del usuario esté autorizada de forma explícita en el backend. La validación de entradas y salidas para evitar inyecciones SQL o XSS mediante comprobaciones de datos. Los controles de permisos, versiones del software y dependencias del entorno de despliegue.

En el caso práctico del portal ciudadano descrito en el temario, ¿por qué la consola de administración interna se clasifica en nivel ASVS 3 y no en nivel 2?. Porque tiene más usuarios concurrentes que el portal web principal. Porque gestiona permisos de alto privilegio y el riesgo de escalada de privilegios o abuso interno justifica trazabilidad completa y revisión manual. Porque el ENS obliga a nivel 3 para cualquier interfaz de administración en AAPP. Porque la consola procesa pagos y transacciones económicas de los ciudadanos.

El escenario de «movimiento lateral» en las pruebas manuales adicionales de un pentest consiste en: Escalar los privilegios de un usuario estándar hasta obtener acceso de administrador del sistema. Interceptar el tráfico entre el cliente y el servidor para capturar tokens de sesión. Comprobar si un usuario con acceso legítimo a un módulo puede acceder a otros módulos internos sin autorización explícita. Forzar la ejecución de código malicioso en el servidor aprovechando una inyección SQL.

El informe de hallazgos generado al finalizar un pentest debe incluir obligatoriamente: El código fuente de los exploits utilizados durante las pruebas de penetración. La identidad completa de todos los usuarios cuyos datos fueron accedidos durante las pruebas. Las vulnerabilidades encontradas con su nivel de riesgo, ejemplos de explotación y recomendaciones prácticas para corregirlas. La certificación formal de que el sistema es seguro para su despliegue en producción.

En una plantilla Handlebars, ¿qué diferencia existe entre {{nombre}} y {{{nombre}}}?. {{nombre}} permite HTML; {{{nombre}}} escapa los caracteres especiales. No hay diferencia funcional; son sintaxis equivalentes en Handlebars moderno. {{nombre}} escapa automáticamente el contenido para el contexto HTML; {{{nombre}}} (triple mustache) inserta el contenido sin escape, permitiendo XSS. {{{nombre}}} solo funciona dentro de bloques {{#if}}; fuera de ellos se comporta igual que {{nombre}}.

En React, ¿qué mecanismo debe evitarse expresamente porque desactiva el saneamiento automático del framework y puede introducir XSS?. El uso de useState con valores iniciales provenientes de parámetros de URL. El uso indiscriminado de dangerouslySetInnerHTML para insertar contenido dinámico. La interpolación de variables dentro de atributos de clase CSS. El uso de useEffect con dependencias que incluyen datos del formulario.

En el modelo de control de acceso ABAC con JWT, si el campo departamento del token no coincide con el requerido, el servidor debe responder con: Código HTTP 401 (No autorizado) redirigiendo al formulario de login. Código HTTP 200 con un cuerpo vacío para no revelar información al atacante. Código HTTP 403 (Prohibido), indicando que la autenticación fue exitosa pero la autorización fue denegada. Código HTTP 404 (No encontrado) para ocultar la existencia del recurso protegido.

El decorador @permission_required('informes.puede_exportar') en Django, frente a usar solo @login_required, aporta: La capacidad de verificar la identidad del usuario mediante autenticación de doble factor. Granularidad en la autorización: verifica un permiso específico además de la autenticación, evitando que cualquier usuario autenticado acceda a funciones administrativas. La integración automática con sistemas OAuth 2.0 externos para la federación de identidad. El registro automático de todos los accesos al recurso protegido en el log de auditoría.

En la migración de contraseñas de SHA1 a BCrypt en Ruby on Rails descrita en el temario, ¿cuándo se actualiza el hash del usuario al nuevo algoritmo?. Mediante un script de migración masiva que se ejecuta una vez en la base de datos. Cuando el administrador fuerza el restablecimiento de contraseña de todos los usuarios. Automáticamente cuando el usuario inicia sesión correctamente, detectando el formato antiguo y recalculando el hash con BCrypt en ese momento. Al cabo de un período de gracia de 30 días desde la actualización del sistema.

En el contexto del almacenamiento seguro de contraseñas, ¿por qué un factor de coste demasiado alto en BCrypt puede ser problemático en producción?. Porque genera hashes de longitud variable incompatibles con algunas bases de datos. Porque aumenta el tamaño del hash almacenado, incrementando el uso de almacenamiento. Porque puede producir latencias notables en servidores con muchas autenticaciones simultáneas, afectando al rendimiento del sistema. Porque hace que el hash sea predecible para atacantes que conocen el factor de coste utilizado.

En Apache, el comando apache2ctl -M sirve para: Reiniciar el servidor Apache aplicando la nueva configuración sin interrupción del servicio. Verificar la sintaxis de los archivos de configuración antes de aplicarlos. Listar los módulos cargados actualmente, permitiendo identificar módulos heredados innecesarios que deberían deshabilitarse. Mostrar las métricas de rendimiento del servidor en tiempo real.

En la configuración de Apache descrita en el temario, la directiva Options -Indexes -FollowSymLinks tiene como efecto: Bloquear el acceso a archivos ocultos y deshabilitar el soporte para PHP. Deshabilitar el listado automático de directorios y la resolución de enlaces simbólicos, reduciendo la exposición de la estructura interna del servidor. Restringir el acceso al directorio solo a usuarios autenticados mediante certificado cliente. Forzar el uso de HTTPS en todas las peticiones al directorio configurado.

La regla personalizada de ModSecurity mostrada en el temario (SecRule ARGS:parametro...) actúa en: La fase 1 (recepción de cabeceras de la petición), antes de leer el cuerpo. La fase 2 (análisis del cuerpo de la petición), interceptando patrones de inyección en los parámetros antes de que lleguen al backend. La fase 4 (análisis de la respuesta del servidor), bloqueando respuestas que contengan datos sensibles. La fase 5 (registro de la transacción), solo para fines de auditoría sin bloqueo activo.

En AWS WAF, la regla AWSManagedBotControlRuleSet tiene como función principal: Cifrar automáticamente el tráfico HTTPS entre el balanceador y los servidores backend. Bloquear peticiones que superen el umbral de rate limiting configurado por el administrador. Bloquear automáticamente direcciones IP con mala reputación, crawlers agresivos y scripts automatizados sin modificar las aplicaciones. Validar los tokens JWT de autenticación en cada petición antes de enrutarla al backend.

La técnica del campo oculto firmado criptográficamente como alternativa al CAPTCHA en formularios corporativos funciona porque: El campo oculto cifra los datos del formulario impidiendo su interceptación por bots. El servidor puede identificar la IP del bot y bloquearla automáticamente. Los bots que replican formularios no pueden reproducir la firma válida al desconocer la clave del servidor, ni generar un token con la marca temporal y el identificador correctos. El campo oculto contiene un hash del User-Agent que permite distinguir navegadores reales de automatizados.

En IIS (Internet Information Services), la configuración de cabeceras de seguridad como X-Frame-Options o X-Content-Type-Options se realiza mediante: El archivo .htaccess en el directorio raíz de la aplicación web. El panel de control gráfico de IIS Manager, sin posibilidad de configuración por archivo. El archivo web.config, en la sección <system.webServer><httpProtocol><customHeaders>. El archivo nginx.conf, ya que IIS delega la gestión de cabeceras al proxy inverso Nginx.

En una aplicación Node.js con Express, la configuración de sesión con saveUninitialized: false tiene como efecto: Impedir que el servidor recuerde la sesión entre reinicios del proceso Node.js. Evitar que se cree y almacene una sesión para usuarios que no han iniciado sesión, reduciendo el uso de recursos y el riesgo de sesiones fantasma. Forzar la regeneración del identificador de sesión en cada petición HTTP. Cifrar automáticamente el contenido de la sesión almacenado en el servidor.

En el contexto de OAuth 2.0, ¿qué parámetros debe verificar el backend al recibir un token JWT, según el temario?. Longitud del token, algoritmo de cifrado y fecha de emisión. Nombre del usuario, lista de permisos y dirección IP del cliente. Firma del token, audiencia (audience), emisor (issuer) y tiempos de validez (iat, exp). Hash del cuerpo de la petición, cabecera de autorización y versión del protocolo OAuth.

En el pipeline de GitLab CI para OWASP ZAP mostrado en el temario, la fase zap-cli --port 8080 spider sirve para: Ejecutar un escaneo activo de vulnerabilidades sobre la aplicación objetivo. Iniciar el demonio ZAP en modo headless escuchando en el puerto especificado. Rastrear automáticamente la aplicación para descubrir las URLs y endpoints disponibles antes del escaneo activo. Generar el informe HTML con los hallazgos del análisis de seguridad.

La integración de Selenium con OWASP ZAP descrita en el temario es especialmente útil para: Ejecutar pruebas de carga y rendimiento simultáneamente con el análisis de seguridad. Analizar el código fuente de aplicaciones React, Angular o Vue sin necesidad de ejecutarlas. Detectar vulnerabilidades en aplicaciones modernas donde muchas rutas se generan dinámicamente y no son detectables mediante rastreo estático. Sustituir el análisis SAST en pipelines CI/CD donde el acceso al código fuente está restringido.

En el manifiesto de Kubernetes para un job de ZAP mostrado en el temario, restartPolicy: Never indica: Que el contenedor de ZAP debe ejecutarse de forma continua sin posibilidad de reinicio. Que el pod de ZAP solo puede ejecutarse en nodos con política de seguridad restrictiva. Que si el contenedor falla, Kubernetes no intentará reiniciarlo automáticamente, lo cual es el comportamiento correcto para un job de análisis puntual. Que el análisis de ZAP no puede interrumpirse una vez iniciado, incluso si se detectan vulnerabilidades críticas.

La práctica de normalizar cadenas antes de incluirlas en correos electrónicos generados por el servidor (eliminar \r, \n, limitar longitud) previene principalmente: Ataques de inyección SQL a través de los campos del formulario de contacto. La exposición de datos sensibles mediante cabeceras HTTP de respuesta mal configuradas. La inyección de caracteres de control o contenido inesperado que podría ser interpretado de forma anómala por el cliente de correo o por sistemas externos. El robo de sesión mediante la interceptación del correo en tránsito.

En el contexto de la codificación segura, el principio de separación entre datos y lógica aplicado a llamadas al sistema operativo implica: Que los datos del usuario deben cifrarse antes de ser procesados por el sistema operativo. Que las llamadas al sistema deben ejecutarse siempre con privilegios de administrador para garantizar su correcto funcionamiento. Que en lugar de construir comandos concatenando parámetros del usuario, se deben usar llamadas con argumentos separados y listas blancas de opciones permitidas. Que el sistema operativo debe validar todos los datos de entrada antes de pasarlos a la aplicación.

El bloque <queries> en el manifiesto de Android no concede permisos ni amplía el acceso a recursos del sistema, pero su relevancia en auditoría es que: Declara los servicios en segundo plano que la aplicación puede iniciar tras el arranque del dispositivo. Reduce el aislamiento por defecto del sistema al declarar reglas de visibilidad entre aplicaciones, permitiendo inferir información sobre el ecosistema de apps del dispositivo. Define los proveedores de contenido externos a los que la app puede acceder sin permisos explícitos. Especifica los dominios de red a los que la aplicación puede conectarse en texto claro.

El permiso ACCESS_MEDIA_LOCATION en Android introduce un riesgo adicional de privacidad porque: Permite a la app modificar los metadatos de localización de las fotos del usuario. Permite recuperar información de ubicación GPS asociada a archivos multimedia, posibilitando el perfilado del usuario e inferir ubicaciones sensibles. Concede acceso al sensor GPS del dispositivo en tiempo real durante la ejecución de la app. Habilita el envío automático de coordenadas de ubicación a servidores externos sin notificación.

La combinación de los permisos FOREGROUND_SERVICE y RECEIVE_BOOT_COMPLETED en una aplicación es especialmente relevante en auditoría porque: Permite a la app acceder al almacenamiento externo sin necesidad de permisos adicionales. Habilita el uso de biometría para desbloquear funciones sin interacción del usuario. Posibilita que la app se ejecute de forma persistente y se reactive automáticamente tras el arranque del dispositivo, ampliando el tiempo de exposición a los riesgos. Concede acceso a los contactos y al registro de llamadas del dispositivo en segundo plano.

En la cadena de confianza de F-Droid para la distribución de APKs, ¿en qué elemento se deposita la confianza para la verificación del paquete?. En el certificado del desarrollador original que publica el código fuente. En la firma embebida dentro del propio APK por el compilador de Android. En la firma PGP de F-Droid que firma el APK resultante del proceso de construcción reproducible del repositorio. En el hash SHA-256 publicado en la página de la aplicación en el repositorio de F-Droid.

Al verificar la firma PGP de un APK de F-Droid con Kleopatra, se muestra un aviso de caducidad del certificado aunque la firma sea correcta. Esto significa: Que el APK ha sido modificado después de la firma y no debe analizarse. Que la clave de F-Droid ha sido revocada y debe obtenerse una nueva versión del APK. Que la firma fue realizada cuando la clave aún era válida y el contenido coincide, pero Kleopatra advierte de la caducidad posterior de la clave; la firma sigue siendo válida si el contenido coincide. Que el repositorio de F-Droid ha cambiado su par de claves PGP y debe reimportarse la nueva clave pública.

En Android moderno (API 23+), ¿qué ventaja específica ofrece EncryptedSharedPreferences frente al uso directo de la clase Cipher con una clave generada manualmente?. EncryptedSharedPreferences usa AES-128 en lugar de AES-256, siendo más eficiente en dispositivos de gama baja. EncryptedSharedPreferences permite almacenar archivos binarios además de datos clave-valor. EncryptedSharedPreferences gestiona automáticamente las claves mediante Android Keystore (MasterKey), evitando la gestión insegura de claves que es el principal fallo del cifrado manual. EncryptedSharedPreferences es la única API que protege los datos frente a accesos de otras aplicaciones con permisos de sistema.

La directiva android:allowBackup="false" en el manifiesto de una aplicación Android tiene como efecto de seguridad: Impedir que la aplicación acceda al almacenamiento compartido de otras apps mediante backup. Excluir los datos de la aplicación de las copias de seguridad automáticas de Android, evitando que datos sensibles sean extraídos mediante ADB backup o servicios en la nube. Deshabilitar la posibilidad de restaurar la aplicación desde una copia de seguridad en un nuevo dispositivo. Forzar el cifrado de los datos de la aplicación antes de cualquier operación de sincronización.

En el flujo de validación de compras integradas, ¿qué campo específico de Android (Google Play) actúa como identificador principal para garantizar la idempotencia?. order_id. purchase_token. package_name. product_id.

En el control de fraude por vinculación de identidad en compras integradas, dado que Google y Apple no devuelven el user_id del comprador por privacidad, ¿cómo se detecta el uso de un recibo de otro usuario?. Comparando la dirección IP del cliente con la registrada en el momento de la compra original. Verificando que el signed_transaction_info contiene el email del comprador en el payload del JWT. Asociando el original_transaction_id (iOS) o linkedPurchaseToken (Android) a un único user_id la primera vez; si llega el mismo identificador con un user_id diferente, se marca como fraude. Consultando el historial de compras del usuario en la tienda mediante la API de reembolsos.

Cuando en el análisis de tráfico con Wireshark se observa que una app envía peticiones recurrentes a dominios no identificados en el análisis estático previo, esto se clasifica como: Un fallo crítico de configuración TLS que debe corregirse antes del despliegue. Una fuga de información explotable que expone tokens de sesión del usuario. Tráfico no justificado que amplía innecesariamente la superficie de ataque y dificulta la trazabilidad, requiriendo justificación técnica explícita. Una vulnerabilidad de tipo SSRF donde la app actúa como proxy hacia servicios internos.

En el análisis previo a la captura de tráfico, la búsqueda de referencias a android.webkit.WebView y loadUrl en el código descompilado con JADX es relevante porque: WebView es una biblioteca de análisis de imágenes que puede exponer metadatos EXIF. WebView puede encapsular comunicaciones web completas fuera del control directo del cliente HTTP, siendo un vector de comunicaciones que no aparece como una URL literal en el código. loadUrl es una API obsoleta de Android que introduce vulnerabilidades de desbordamiento de búfer. Las referencias a WebView indican que la app realiza scraping de páginas web externas.

En la inspección estática con MobSF, los UUIDs de estándares DRM como Widevine, ClearKey y PlayReady encontrados en el APK se clasifican como: Fugas explotables porque permiten identificar el proveedor de DRM y diseñar ataques específicos. Exposición informativa que revela la estrategia de protección de contenidos de la app. Ruido técnico (falsos positivos), ya que son constantes públicas estándar de procesamiento multimedia sin valor explotable. Secretos embebidos que deben eliminarse del binario antes del despliegue en producción.

La sección «Code Analysis» del informe de MobSF para la app Gallery advierte sobre llamadas a Log.d() y Log.e(). En el contexto analizado, esta advertencia se considera: Una fuga explotable crítica porque expone tokens de autenticación en el log del sistema. Una exposición informativa grave que revela la arquitectura interna de la aplicación. Un aviso informativo de bajo impacto en este caso concreto, ya que los registros proceden principalmente de bibliotecas externas y contienen mensajes genéricos de inicialización y errores de procesamiento. Ruido técnico sin ninguna relevancia para la seguridad, que puede ignorarse en todos los casos.

Un ejemplo típico de fuga explotable real mediante registros (logs) en código de producción sería: Log.d("Init", "Biblioteca Glide inicializada correctamente"). Log.e("Decoder", "Error al decodificar imagen HEIF: formato no soportado"). Log.d("UserSession", "Token: " + accessToken) o Log.e("Error", "Ruta foto: " + filePath). Log.i("Network", "Conexión establecida con servidor principal").

¿Cuál de las siguientes soluciones CASB comerciales está ampliamente integrada con Azure AD/Entra ID y entornos Microsoft 365?. Netskope. Zscaler. Microsoft Defender for Cloud Apps. Cisco Cloudlock.

Las herramientas CASB comerciales se diferencian de las herramientas de código abierto en que estas últimas: No pueden integrarse con proveedores de identidad corporativos ni con sistemas SSO. Solo soportan el control de aplicaciones móviles nativas, no de aplicaciones web. No integran capacidades completas como DLP en la nube, control granular por aplicación SaaS, análisis de comportamiento o gobierno centralizado de accesos móviles, que son propias de soluciones comerciales maduras. Requieren acceso root al dispositivo para inspeccionar el tráfico local de las aplicaciones móviles.

En el análisis de la app Gallery con JADX, ¿qué patrón de búsqueda permite confirmar que la aplicación no solo lee datos de SharedPreferences sino que también los escribe de forma persistente?. Buscar referencias a getSharedPreferences y PreferenceManager. Buscar referencias a EncryptedSharedPreferences y MasterKey. Buscar métodos de escritura como putString, putInt, apply y commit además de las referencias de lectura. Buscar referencias a SQLiteOpenHelper y SQLiteDatabase.

¿Desde qué versión de Android muchas galerías usan el permiso READ_MEDIA_VISUAL_USER_SELECTED combinado con Photo Picker para minimizar la concesión de permisos amplios?. Android 12 (API 32). Android 13 (API 33). Android 14 (API 34), especialmente desde Android 15. Android 11 (API 30).

El control de reembolsos y revocaciones en el sistema de compras integradas se implementa mediante: La verificación periódica del saldo de la cuenta bancaria asociada al método de pago del usuario. La invalidación automática del token de compra tras 24 horas desde la concesión del derecho. El registro del estado de la transacción y la revalidación periódica o mediante notificaciones del proveedor (Real-time developer notifications en Google; App Store Server Notifications V2 en Apple). La solicitud al usuario de reconfirmación biométrica cada vez que accede a funciones premium.

En el análisis de almacenamiento, la presencia de referencias a Room con @Database y @Entity en el código descompilado indica: Que la aplicación utiliza cifrado nativo de Android para proteger sus datos estructurados. Que la aplicación almacena datos exclusivamente en memoria sin persistencia local. Que la aplicación usa persistencia estructurada mediante SQLite a través del ORM Room, lo que obliga a evaluar si se aplica cifrado adicional como SQLCipher. Que la aplicación sincroniza automáticamente sus datos con Firebase Firestore en la nube.

¿Cuáles son los tres rasgos fundamentales que distinguen los sistemas en producción de los entornos de desarrollo y pruebas?. Rendimiento, compatibilidad y escalabilidad. Automatización, versionado y monitorización. Disponibilidad, estabilidad y trazabilidad. Seguridad, privacidad y cumplimiento normativo.

En el escenario de la aplicación de gestión de incidencias descrito en el temario, ¿cuál es el riesgo específico de añadir un nuevo campo «prioridad» al formulario mediante un despliegue manual?. Que el campo quede expuesto públicamente en internet sin autenticación previa. Que el campo no sea indexado correctamente por el motor de búsqueda interno de incidencias. Que el cambio genere incompatibilidades con la estructura de la base de datos, errores de configuración del servidor, mezcla de archivos de versiones distintas o interrupciones del servicio. Que el campo almacene datos sin cifrar si el servidor web no tiene TLS configurado correctamente.

En Git, el comando git checkout -b adjuntar-archivos realiza las siguientes acciones: Descarga la rama adjuntar-archivos del repositorio remoto y la fusiona con la rama actual. Elimina la rama adjuntar-archivos del repositorio local y crea una nueva con ese nombre. Crea una nueva rama llamada adjuntar-archivos a partir del estado actual y se posiciona en ella. Verifica la integridad de la rama adjuntar-archivos y la protege contra escrituras directas.

¿Cuáles son las tres ventajas principales de la automatización del proceso de construcción (build)?. Velocidad, compatibilidad y reducción de costes de infraestructura. Seguridad, portabilidad y eliminación de dependencias externas. Reproducibilidad, trazabilidad y capacidad de auditoría. Escalabilidad, disponibilidad y tolerancia a fallos del proceso de construcción.

En el archivo de configuración de GitHub Actions del temario, ¿qué define el valor ubuntu-latest en la sección runs-on?. La versión mínima de Ubuntu requerida en los servidores de producción. El sistema operativo del servidor donde se desplegará el artefacto final. El entorno exacto en que se ejecutará el proceso de build, garantizando la reproducibilidad al definir explícitamente el sistema operativo del runner. El sistema operativo base de la imagen Docker que se generará como artefacto del build.

¿Cuál de las siguientes herramientas de build está asociada al ecosistema JavaScript para la generación de bundles optimizados para producción?. Maven. Gradle. Webpack / Vite / Rollup. Make / CMake.

La revisión de código (code review) antes de integrar cambios en la rama principal aporta principalmente: La certificación formal de que el código no contiene vulnerabilidades de seguridad. La reducción de la probabilidad de introducir errores, la detección de cambios inseguros o inconsistentes y la mejora de la calidad del código mantenido en el repositorio. La automatización del proceso de despliegue al eliminar la necesidad de aprobación manual. La sincronización del repositorio local con el repositorio remoto antes de cada merge.

En el contexto de los contenedores, un Dockerfile es: Un log de todas las operaciones realizadas por el contenedor durante su ejecución. El archivo de configuración de red que define cómo se comunican los contenedores entre sí. El archivo de configuración que define la imagen del contenedor, especificando el entorno, las dependencias y los comandos necesarios para construirla. El manifiesto de Kubernetes que describe cómo debe desplegarse el contenedor en el clúster.

Podman se diferencia de Docker principalmente en que: Podman solo puede ejecutarse en sistemas Linux; Docker soporta Windows, macOS y Linux. Podman no soporta imágenes en formato OCI, mientras que Docker sí. Podman no requiere un proceso central (daemon) en ejecución, lo que lo hace más adecuado en entornos con requisitos estrictos de seguridad. Podman está orientado exclusivamente a entornos de desarrollo; Docker es la única opción válida para producción.

Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) y Red Hat OpenShift se clasifican como: Motores de contenedores autoalojados que permiten gestionar el orquestador en la propia infraestructura. Herramientas de gestión de configuración basadas en el paradigma de infraestructura como código. Servicios gestionados de orquestación de contenedores en la nube que reducen la complejidad operativa al delegar la gestión de la infraestructura del clúster al proveedor. Plataformas de integración continua especializadas en el despliegue de aplicaciones en contenedores.

Nomad se diferencia de Kubernetes como orquestador de contenedores en que: Nomad solo soporta contenedores Docker; Kubernetes soporta múltiples runtimes de contenedores. Nomad requiere un equipo de operaciones dedicado; Kubernetes puede gestionarse con un solo administrador. Nomad es una alternativa más ligera orientada a entornos de menor complejidad, mientras que Kubernetes está diseñado para la gestión de conjuntos de contenedores distribuidos a gran escala. Nomad no soporta actualizaciones progresivas del software; Kubernetes sí lo hace de forma nativa.

Ansible se diferencia de Puppet y Chef como herramienta de IaC principalmente en que: Ansible usa un lenguaje propietario de programación; Puppet y Chef usan YAML estándar. Ansible solo puede gestionar servidores Linux; Puppet y Chef soportan Windows y Linux. Ansible es declarativo y no requiere agente instalado en los servidores gestionados (agentless), mientras que Puppet y Chef requieren un agente en cada nodo. Ansible está orientado al aprovisionamiento de infraestructura cloud; Puppet y Chef solo gestionan configuración on-premise.

En el flujo DevOps completo descrito en el temario, ¿cuál es la consecuencia directa de que los despliegues dependan de operaciones manuales desde el punto de vista de la seguridad operativa?. Que el equipo de seguridad pierde visibilidad sobre los cambios introducidos en producción. Que las pruebas automatizadas no pueden ejecutarse en entornos manuales. Que es difícil saber qué versión del software está realmente instalada, qué configuraciones se han modificado y qué cambios se realizaron durante la resolución de incidencias, haciendo el entorno difícil de reproducir y asegurar. Que los contenedores no pueden desplegarse correctamente sin un pipeline automatizado.

Gremlin se diferencia de Chaos Monkey como herramienta de inyección de fallos en que: Gremlin es una herramienta de código abierto; Chaos Monkey es una plataforma comercial. Gremlin solo simula caídas de servicio; Chaos Monkey simula todo tipo de fallos de red y recursos. Gremlin es una plataforma comercial que permite simular distintos tipos de fallo de forma controlada; Chaos Monkey solo detiene aleatoriamente instancias. Gremlin está orientado a entornos Kubernetes; Chaos Monkey solo funciona en infraestructuras AWS.

Chaos Mesh se diferencia de Chaos Monkey y Gremlin en que: Es la única herramienta que permite simular fallos de hardware en servidores físicos. Es una solución de código abierto específicamente orientada a entornos Kubernetes, que permite inyectar fallos directamente en contenedores y servicios desplegados en el clúster. Solo puede ejecutarse en entornos de staging, no en producción. Requiere la instalación de un agente en cada nodo del clúster para funcionar correctamente.

La observabilidad de un sistema en producción se construye sobre tres tipos de información generada continuamente. ¿Cuáles son según el temario?. Commits, artefactos y versiones desplegadas. Reglas de firewall, políticas de acceso y certificados TLS. Registros de actividad (logs), métricas de rendimiento y trazas de ejecución. Reportes de vulnerabilidades, resultados de SAST y hallazgos de DAST.

El runbook como documento de procedimientos operativos debe incluir como mínimo: El diagrama de arquitectura completo del sistema y el inventario de todos los servidores. Los resultados de todos los pentests realizados y las vulnerabilidades pendientes de corrección. Los procedimientos para restaurar el sistema desde copias de seguridad, los pasos para verificar que el servicio quedó operativo tras la restauración y los criterios para escalar el incidente. El código fuente de los scripts de despliegue y los archivos de configuración de todos los entornos.

Si una organización tiene un RPO de cero horas, ¿qué implicación técnica tiene este objetivo?. Que el servicio debe restablecerse de forma instantánea sin ninguna interrupción perceptible. Que el sistema no necesita copias de seguridad al recuperarse automáticamente de cualquier fallo. Que no se admite ninguna pérdida de datos, lo que requiere replicación en tiempo real de todos los datos; pero no implica que el servicio se recupere instantáneamente (eso lo define el RTO). Que todas las transacciones deben procesarse en menos de un segundo para garantizar la consistencia.

Según el temario, ¿por qué las prácticas DevOps facilitan la elaboración de la documentación operativa (runbooks)?. Porque DevOps elimina la necesidad de documentación al automatizar todos los procesos operativos. Porque DevOps obliga a los equipos a documentar manualmente cada paso del proceso de despliegue. Porque la infraestructura como código, el control de versiones y los pipelines automatizados proporcionan una descripción precisa y actualizada del estado del sistema que puede incorporarse directamente a los procedimientos de recuperación. Porque las plataformas DevOps generan automáticamente runbooks en formato PDF tras cada despliegue exitoso.

El ciclo completo de DevOps concluye con que la información de observabilidad del sistema en producción: Se archiva en un repositorio de evidencias para auditorías de seguridad futuras. Se usa exclusivamente para facturar el uso de infraestructura cloud al equipo de operaciones. Alimenta las decisiones del equipo de desarrollo, que introduce nuevas modificaciones que vuelven a recorrer el pipeline completo, convirtiendo la fase de operación en el punto de partida de un nuevo ciclo. Se comparte automáticamente con el equipo de seguridad para actualizar el análisis de riesgos del sistema.

¿Qué sistemas se usan para garantizar la seguridad en el proceso de compra de las aplicaciones móviles?. Canales seguros de comunicación. HSTS. Software especifico. Cambios en el aplicativo.

¿Cuál de los siguientes no es un estándar de autenticación?. OAuth. Ninguno de los anteriores. JWT. Con certificados.

Indica la línea de comandos que hay que ejecutar para crear una imagen de nombre myapache con este archivo.

Indica cuál es el nombre habitual de este archivo en Docker.

¿Cuál de las siguientes no es un principio básico de las metodologías AGILE?. Equipos auto-organizados. Gran aceptación y respuesta al cambio de los requisitos definidos durante el proyecto. Ninguna de las anteriores. Trabajo conjunto entre el cliente y desarrolladores.

Para prevenir que un formulario sea un vector de ataque es importante que... Ninguna de las anteriores. La interacción con la base de datos sea a través de sentencias no parametrizadas. En el navegador se valide e higienice correctamente la entrada de datos para que los mismos no tengan que validarse en la parte servidora y así no sobrecargarla. En el servidor se valide e higienice correctamente la entrada de datos, aunque también se hagan en el navegador.

Indica que se debe escribir en la caja de texto para que cada vez que se cargue la página se muestre un mensaje con el contenido de las cookies.

¿Cuál de las siguientes no es una herramienta de gestión automatizada de configuración de sistemas?. Ansible. Selenium. Chef. Puppet.

Dada la siguiente línea de código... ¿Qué debería contener la variable $Clave para que devuelva registros la consulta?. OR '1'='1'. OR 1=1'. ' OR 1=1. ' OR '1'='1.

En iOS... Cada aplicación tiene un directorio de inicio único para sus archivos, que se asigna aleatoriamente cuando se instala la aplicación. Cada aplicación está funcionando con un usuario especifico que se crea para esa aplicación. Todas las anteriores. Todas las aplicaciones se ejecutan en un entorno compartido por todas.

¿Cuál de las siguientes pruebas verifica que distintos módulos que funcionan por separado funcionen de manera conjunta?. Ninguna de las anteriores. Examen de la unidad. Pruebas de aceptación. Pruebas funcionales.

El tampering consiste en... Ninguna de las anteriores. La manipulación no autorizada de aplicaciones móviles, lo que implica alterar el código binario o su entorno para afectar a su comportamiento. El proceso de analizar la aplicación compilada para extraer información sobre su código fuente. Las apps deben de estar firmadas por el desarrollador y si no lo están serán rechazadas por la tienda y además el instalador del dispositivo no permitirá instalarla.

DevOps... Es una metodología basada en la creación de software de forma continua y de mayor calidad mediante versiones más frecuentes. Es un equipo o departamento de la organización compuesto por desarrolladores. Ninguna de las anteriores. Es un estándar que define las herramientas a utilizar por los desarrolladores.

MDM... Se basan en la administración remota de los terminales corporativos de los empleados. Es una solución que solo controla lo que sucede en la nube. Son perfectos para los entornos BYOD. Todas las anteriores.

Indica la línea de comandos a ejecutar para lanzar un contenedor de nombre mysql-db1 basado en la imagen del servidor de base de datos mysql (la imagen se llama mysql), mapeando el puerto 3306 del contenedor al puerto 33060 del equipo donde va a lanzar el contenedor y ejecutándose en segundo plano. docker run --name mysql-db1 -p 33060:3306 -d mysql. docker run --name mysql-db1 -p 3306:33060 -d mysql. docker start --name mysql-db1 -p 33060:3306 -d mysql. docker run --name mysql-db1 -p 33060:3306 mysql.

¿Cuál de las siguientes no es una Vulnerabilidad del Top 10 de OWASP en aplicaciones móviles?. Insuficiente validación de entrada/salida. Controles de privacidad inadecuados. Falsificación de peticiones en el servidor. Almacenamiento de datos inseguro.

¿Cuál de las siguientes no es una vulnerabilidad del top 10 de OWASP en entornos web?. Componentes Vulnerables y Obsoletos. Fallos de Autenticación e Identificación. Ingeniería inversa. Diseño Inseguro.

En Android... Todas las aplicaciones se ejecutan en un entorno compartido por todas. Existen dos niveles de acceso: accesos estándar o los más especiales o peligrosos. Todas las aplicaciones se ejecutan con el mismo usuario ("mobile"). Todas las anteriores.

Indica qué hay que escribir en vez de # para actualizar la lista de paquetes de Ubuntu e instalar el servidor web apache.

En Git hay tres etapas primarias (condiciones) en las cuales un archivo puede estar: Ninguna de las anteriores. Estado inicial - Estado preparado - Estado aprobado. Estado inicial - Estado chequeado - Estado aprobado. Estado modificado - Estado preparado - Estado confirmado.

¿Cuál es el estándar que define un conjunto de orígenes pre-aprobados desde los que un navegador puede cargar recursos cuando un usuario visita un sitio web?. CSP. HSTS. Ninguno de los anteriores. SOAP.

¿Qué pasa con los contenedores docker al apagar el equipo?. Se quedan activos. Se descargan en el equipo local. Se pierden. Se quedan en un estado de hibernacion para ser reestablecidos.

¿Cuáles son algunas de las cosas que se pueden comprobar a través del análisis dinámico de una aplicación?. Si la aplicación tiene licencia para ser utilizada en el dispositivo. Si las transmisiones de red se realizan de manera segura. El número de líneas de código en el proyecto. Los comentarios que el desarrollador dejó en el código fuente.

¿Cuál no es uno de los principales elementos de docker?. rootpool. unionFS. namespaces. cgroups.

Tipo de almacenamiento-persistencia en docker: Todas son correctas. Bind. Tmpfs. Volume.

¿Qué hace el parámetro ENV de docker?. indica el ejecutable a usar. establece variables de entorno. guarda el estado anterior a la ejecución. crea un entorno de ejecución.

¿Cuál es el objetivo principal del análisis estático en el ámbito de la seguridad informática?. Realizar pruebas de penetración para identificar posibles vulnerabilidades en la aplicación. Ejecutar el código de la aplicación para identificar posibles problemas de seguridad. Identificar posibles problemas de seguridad en la infraestructura de red de la aplicación. Inspeccionar el propio binario de la aplicación para identificar vulnerabilidades y posibles problemas de seguridad antes de su ejecución.

¿Cuáles son los tipos de hipervisor que utilizan una máquina virtual?. Tipo 2. Tipo 3. Tipo 1 y 2. Tipo 1.

¿Qué NO podemos hacer con las imágenes de docker?. Copiar una imagen. Borrar una imagen. Eliminar una imagen. Crear una imagen.

¿Cuál NO es un tipo de persistencia de docker?. Tmpfs. Bind. Partition. Volume.

¿Qué contiene una imagen de docker?. la información necesaria para ejecutar la app correctamente. una captura de pantalla del momento de la ejecución. un registro del comando ejecutado. una instantánea del estado de su maquina anfitrión.

¿Qué elementos pueden ser renombrados en el código de una aplicación durante el proceso de ofuscación?. Los recursos utilizados por la aplicación. Las librerías nativas utilizadas. Las conexiones a bases de datos. Las variables, clases y métodos del código.

¿Qué es un contenedor de docker?. Son archivos inmutables que contienen todas los archivos necesarios para que se ejecute la aplicación correctamente. Archivos temporales que son prescindibles para el funcionamiento de las aplicaciones. Todas son incorrectas. Es un paquete que incluye todo lo necesario para que se pueda ejecutar la aplicación.

¿Qué parámetro de dockerfile establece el autor de la imagen?. Label. Maintaner. Expose. From.

¿Cuál No es un tipo de red en docker?. Bridge. Overlay. Host. NAT.

¿Qué NO se pude hacer mediante comandos con los contenedores docker?. Ejecutarlos. Eliminarlos. Listarlos. Depurarlos.

¿Cuál no es una caracteristica de las MV?. se ejecuta sobre un hipervisor. Limitación para crear varias de forma simultanea. crean un SO completo. es una arquitectura enfocada a microservicios.

¿Qué tipo de permiso tienen las imágenes Docker?. Ejecución. Sólo lectura. Escritura. Lectura y escritura.

¿En qué consiste el análisis dinámico?. Analizar el código de un programa sin ejecutarlo. Analizar el rendimiento de una base de datos. Analizar la aplicación durante su ejecución. Analizar la arquitectura de un sistema informático.

¿Qué se necesita para realizar un análisis dinámico?. Una copia del código fuente de la aplicación. Un dispositivo o emulador capaz de ejecutar la aplicación. Una copia... y Un dispositivo... son correctas. Permisos de superusuario.

¿Cual de estos es un elemento a analizar en el análisis estático de un programa?. metadatos. Recursos. Código de la app. Todas son correctas.

¿Sobre qué se ejecutan los contenedores?. Sobre un hipervisor. Sobre un motor de contenedor. Sobre un sistema operativo físico. Sobre un motor de virtualización.

¿Sobre qué se ejecutan las máquinas virtuales?. Sobre una máquina física. Sobre un sistema operativo físico. Sobre una infraestructura de red. Sobre un hipervisor.

¿Cuál es el objetivo principal de la ofuscación en el ámbito de la seguridad informática?. Acelerar la ejecución del código de la aplicación. Dificultar la comprensión del código de la aplicación para evitar posibles ataques. Facilitar la comprensión del código de la aplicación. Mejorar la compatibilidad de la aplicación con diferentes plataformas.

¿Qué es un dockerfile?. historial de contenedores creados. información de la versión de docker. archivo que contiene instrucciones para crear una imagen docker. archivo de configuración de docker.

¿Qué lenguaje se utiliza comúnmente para escribir código nativo?. JavaScript. Python. C/C++. Java.

¿Para qué se utiliza Docker-Compose?. Para ejecutar múltiples contenedores de manera sincronizada. Todas. En entornos de desarrollo. En entornos de producción.

¿Cuál es el principal objetivo del análisis estático (SAST)?. Evaluar la aplicación mientras se está ejecutando. Examinar el código fuente sin ejecutarlo para detectar problemas. Verificar la interacción entre componentes del sistema. Simular ataques externos para encontrar vulnerabilidades.

¿Cuál es un riesgo del modelo Sandbox?. Posible impacto en rendimiento y dificultad para depurar fallos. Configuraciones inseguras y exposición del núcleo del sistema. Vulnerabilidades en API y gestión de sesiones insegura. Separación clara de funciones y escalabilidad.

¿Qué técnica de análisis de seguridad evalúa la aplicación durante su ejecución simulando ataques?. Análisis estático (SAST). Análisis de dependencias (SCA). Análisis dinámico (DAST). Análisis de código manual.

¿Por qué los lenguajes interpretados pueden ser más propensos a errores derivados del control de tipos?. Debido a que muchos utilizan tipado dinámico. Debido a su tipado estático. Porque la verificación de tipos se realiza en tiempo de compilación. Porque requieren menos líneas de código.

¿Qué tipo de análisis de seguridad revisa el código fuente sin ejecutarlo para detectar errores?. Análisis estático (SAST). Análisis dinámico (DAST). Pentesting. Análisis interactivo (IAST).

¿Cuál es la diferencia principal entre SAST y DAST?. SAST requiere acceso al código fuente, mientras que DAST no. SAST se enfoca en vulnerabilidades de red, mientras que DAST se enfoca en errores lógicos. SAST es más adecuado para entornos de producción, mientras que DAST es para desarrollo. SAST analiza el código fuente, mientras que DAST analiza la aplicación en ejecución.

¿Cuál de los siguientes modelos de ejecución se utiliza comúnmente en navegadores para aislar pestañas y prevenir que una página maliciosa acceda a otros recursos?. Cliente-servidor. Microservicios. Sandbox. Contenedores.

¿Qué es un 'commit' en el contexto del desarrollo de software?. La acción de registrar cambios en el código dentro de un sistema de control de versiones como Git. Un error crítico en el código. El despliegue final de una aplicación. Una prueba de seguridad automatizada.

¿Qué se busca al aplicar el 'análisis de composición de software' (SCA)?. Identificar vulnerabilidades y problemas de licencias en componentes de terceros y de código abierto. Evaluar la calidad del código fuente escrito por el equipo. Probar la aplicación en un entorno de producción simulado. Realizar revisiones manuales detalladas del código.

El modelo MVVM (Model-View-ViewModel) es especialmente útil en: Interfaces reactivas, como las aplicaciones móviles. Herramientas de línea de comandos. Sistemas de gestión de bases de datos. Aplicaciones de servidor backend.

¿Qué herramienta se utiliza para la detección de librerías vulnerables en tiempo de compilación, dentro del flujo DevSecOps?. SonarQube. Docker Scout. OWASP Dependency-Check. OWASP ZAP.

¿Qué significa el acrónimo SSDLC?. Secure Software Development Life Cycle. Software Support Development Life Cycle. Software System Design Life Cycle. System Security Design Life Cycle.

¿Qué función principal cumple el modelo sandbox en la ejecución del software?. Aislar procesos para limitar los daños de un ataque. Mejorar el rendimiento del sistema. Sustituir el modelo cliente-servidor en entornos web. Permitir que una app acceda a los datos de otras.

¿Qué implica el concepto 'DevSecOps'?. Separar completamente los equipos de Desarrollo, Seguridad y Operaciones. Priorizar el desarrollo de nuevas funcionalidades sobre la seguridad. Realizar auditorías de seguridad únicamente al final del proyecto. Integrar la seguridad en todas las fases del ciclo de vida del software, uniendo Desarrollo, Operaciones y Seguridad.

Según el modelo de la pirámide de pruebas, ¿cuál es la proporción ideal recomendada para las pruebas de aceptación?. 20%. 50%. 70%. 10%.

¿Cuál de las siguientes afirmaciones describe correctamente el objetivo de las pruebas de aceptación (UAT)?. Comprobar que el software cumple los requisitos del usuario final en escenarios reales. Detectar vulnerabilidades en el código fuente antes de la compilación. Evaluar la interacción entre módulos internos y externos. Validar la integridad del binario y el cifrado del almacenamiento local.

¿Qué modelo de ejecución se aplica también en servicios en la nube como AWS Lambda?. Sandbox. Cliente-servidor. Peer-to-peer. Contenedores.

¿Cuál de los siguientes frameworks o lenguajes es conocido por su tipado fuerte y su enfoque en la seguridad de la memoria, siendo una alternativa moderna a C/C++?. Rust. Python. PHP. JavaScript.

¿Qué tipo de pruebas exige el Nivel 3 (avanzado) del OWASP ASVS?. Solo evaluación de protocolos HTTPS y cifrado básico. Verificaciones únicamente en la fase de despliegue. Pruebas manuales, revisión de diseño y trazabilidad completa. Pruebas automatizadas y validaciones básicas de entradas.

¿Qué tipo de aplicaciones se recomienda verificar con el Nivel 2 (estándar) del OWASP ASVS?. Aplicaciones de muy bajo riesgo o prototipos. Aplicaciones que solo utilizan HTTPS. Sistemas críticos como banca, salud o administración. La mayoría de las aplicaciones comerciales que manejan datos de usuario.

¿Qué herramientas se mencionan para el análisis estático (SAST) del código fuente?. OWASP ZAP y Burp Suite. Dependency-Track, Snyk o Trivy. SonarQube, Semgrep o Checkmarx. DefectDojo o Security Hub.

¿Qué verifica el área de Control de acceso (V4) del ASVS?. Que cada acción del usuario esté autorizada de forma explícita. La correcta implementación de algoritmos criptográficos. El uso de protocolos de seguridad como TLS. La validación de entradas y salidas de datos.

¿Qué estándar internacional se menciona como el más utilizado para la verificación de seguridad en aplicaciones web y móviles?. MAGERIT. NIST SP 800-218. ISO/IEC 27001. OWASP ASVS.

¿Qué controla el área de Configuración y despliegue (V13) del ASVS?. El diseño de la arquitectura y las estrategias de defensa. La integridad del software y los datos. Los permisos, las versiones del software y sus dependencias del entorno. La autenticación y gestión de sesiones de usuario.

¿Qué propone el NIST SP 800-218 (Secure Software Development Framework - SSDF)?. Acciones concretas y verificables para cada fase del ciclo de vida del software. Requisitos verificables y pruebas para validar la seguridad de la aplicación. Un modelo para medir la madurez de la organización en seguridad. Políticas, estándares y procedimientos de seguridad a nivel organizativo.

¿Qué enfoque ayuda a integrar las pruebas automáticas y revisiones de seguridad en los flujos de integración y entrega continua (CI/CD)?. DevSecOps. Lean Development. Agile Development. Waterfall Model.

¿Qué plataformas se utilizan para agregar resultados de diferentes escáneres y generar informes consolidados?. SonarQube, Semgrep o Checkmarx. DefectDojo o Security Hub. OWASP ZAP y Burp Suite. Dependency-Track, Snyk o Trivy.

¿Qué revisa el área de Comunicación segura (V10) del ASVS?. La validación de entradas y salidas de datos. La configuración y despliegue del software. El uso correcto de protocolos de seguridad como TLS y la protección frente a ataques de suplantación. El control de acceso de usuarios.

¿Qué área del ASVS exige definir amenazas y defensas desde la fase de diseño?. Autenticación y gestión de sesiones (V2-V3). Validación de entradas y salidas (V6). Arquitectura y diseño (V1). Control de acceso (V4).

¿Qué evalúa el área de Criptografía (V7) del ASVS?. Los permisos y versiones del software. El uso correcto de protocolos de seguridad como TLS. La protección frente a ataques de suplantación. El uso de algoritmos criptográficos y la gestión de claves.

¿Qué herramientas se mencionan para el análisis de composición de software (SCA)?. Dependency-Track, Snyk o Trivy. OWASP ZAP y Burp Suite. DefectDojo o Security Hub. SonarQube, Semgrep o Checkmarx.

¿Qué modelo de control de acceso utiliza la asignación de roles predefinidos como 'administrador', 'editor' o 'lector'?. ACL (Access Control List). RBAC (Role-Based Access Control). OAuth 2.0. ABAC (Attribute-Based Access Control).

¿Qué evita la cabecera X-Frame-Options: DENY?. Que se utilicen protocolos HTTP. Que el contenido de la página se muestre en iframes de otros sitios. Que se envíen cabeceras personalizadas. Que el navegador cargue imágenes externas.

¿Cuál es la ventaja de usar server_tokens off; en la configuración de Nginx?. Permite mostrar la versión exacta del servidor Nginx. Habilita protocolos de red obsoletos. Oculta la versión del servidor Nginx, reduciendo la información expuesta. Aumenta la velocidad de respuesta del servidor.

¿Qué es DevOps?. Herramienta concreta. Metodología que integra desarrollo y operación. Sistema operativo. Base de datos.

¿Qué problema soluciona DevOps?. Separación entre desarrollo y operación. Falta de hardware. Problemas de red. Falta de usuarios.

¿Qué elemento inicia el pipeline?. Cambio en repositorio. Usuario. Backup. Firewall.

¿Qué es un artefacto?. Log. Software preparado para despliegue. Código fuente. Configuración.

¿Qué herramienta automatiza build?. Wireshark. Excel. Jenkins. Paint.

¿Qué ocurre si falla el build?. Continúa el despliegue. Se reinicia. Se ignora. Se detiene el proceso.

¿Qué es orquestación?. Monitorización de Firewall. Informe interno. Gestión automática de contenedores. Compilación de Backups.

¿Qué es entrega continua?. Sin pipeline. Despliegue con aprobación. Despliegue automático siempre. Sin pruebas.