devsecops
|
|
Título del Test:
![]() devsecops Descripción: test devsecops digitech |



| Comentarios |
|---|
NO HAY REGISTROS |
|
¿Cuál es el principio rector y la filosofía fundamental de DevSecOps que integra la responsabilidad de seguridad al inicio del ciclo de vida del desarrollo de software?. Feedback Loop. Security Gating. Despliegue Continuo (CD). Shift Left. 2. Según la documentación vista en clase, ¿por qué la seguridad no puede ser un control de calidad al final de la entrega continua (Continuous Delivery)?. Porque la presión para lanzar rápido lleva a saltarse pasos de seguridad, resultando el software en producción con vulnerabilidades conocidas. Porque el equipo de operaciones (Ops) no tiene tiempo para desplegar los parches. Porque el Threat Modeling solo es relevante en las primeras fases. Porque el Software Composition Analysis (SCA) solo funciona en. 3. ¿Cuál es la principal desventaja del modelo de seguridad tradicional previo a DevSecOps que resulta en coste elevado para la corrección de fallos?. La falta de herramientas SAST y DAST. La ausencia de un Security Champion. El equipo de operaciones (Ops) no colaboraba con desarrollo (Dev). Es muchísimo más caro corregir una vulnerabilidad cuando el código está desplegado en producción que cuando se está escribiendo. 4. ¿Cuál es la diferencia fundamental entre SAST (Static Application Security Testing) y DAST (Dynamic Application Security Testing)?. SAST analiza el código en busca de vulnerabilidades mientras se está ejecutando la aplicación; DAST, no. SAST se realiza en producción; DAST en desarrollo. SAST detecta problemas de autenticación; DAST solo encuentra errores de buffer overflow. La diferencia radica en el momento en que se realiza la prueba; SAST es antes de la publicación (código fuente), y DAST es después de la publicación (aplicación en ejecución). 5. Un desarrollador realiza un commit de código y el pipeline de integración continua (CI) ejecuta una herramienta que escanea el código fuente sin ejecutarlo para buscar malas prácticas. ¿A qué herramienta se refiere esta descripción?. RASP. SAST. CIEM. DAST. 6. ¿Cuál es el propósito principal de SAST?. Simular ataques reales a la aplicación en ejecución. Reemplazar por completo la revisión manual de software. Analizar el comportamiento de la aplicación en producción. Detectar vulnerabilidades y errores en el código fuente sin ejecutar la aplicación. 7. ¿Qué herramienta combina los beneficios de SAST y DAST al instrumentar un agente en el entorno de ejecución para ver el código ejecutado y la línea afectada simultáneamente?. SAST. IAST. DAST. SCA. 8. Un ataque de inyección SQL se detecta en una aplicación en producción. ¿Qué herramienta de autodefensa se integra dentro de la propia aplicación como un agente para monitorizar la ejecución desde dentro y terminar la sesión de forma inmediata si detecta el ataque?. DAST. SIEM. Checkov. RASP (Runtime Application Self-Protection). 9. El análisis de composición de software (SCA) es crucial porque la mayoría del código de una aplicación moderna proviene de bibliotecas de código abierto. ¿Cuál es el riesgo de seguridad principal que aborda el SCA?. El riesgo de que las bibliotecas de terceros tengan vulnerabilidades conocidas (CVEs). La exposición de bases de datos por configuraciones erróneas en Infraestructura como Código. La detección de vulnerabilidades que solo se manifiestan en tiempo de ejecución. El incumplimiento de las directivas de codificación segura definidas por el equipo. 10. Este elemento del pipeline CI/CD obliga a que dicho pipeline falle si se detecta una vulnerabilidad que excede un umbral de severidad predefinido (por ejemplo, crítica o alta). ¿Cómo se denomina?. Security Gating. Interactive Application Security Testing (IAST). Runtime Application Self-Protection (RASP). Software Composition Analysis (SCA). 11. En la fase de operaciones y monitorización, ¿qué plataformas clave se utilizan para tomar todos los logs y eventos y correlacionarlos para identificar patrones que podrían indicar un ataque en curso?. SAST y DAST. RASP y SOC. Container Security y Zero Trust. SIEM y SOC. 12. En la fase de operación, una de las prácticas de seguridad continua consiste en escanear continuamente los registros y las máquinas virtuales. ¿Cuál es la principal justificación de esta práctica, incluso si la imagen del contenedor se desplegó de forma segura?. Para asegurar la integración continua de las confirmaciones de código. Para asegurar que DAST se ejecutó correctamente. Para detectar nuevas vulnerabilidades, CVEs o misconfigurations postdespliegue, ya que las imágenes pueden volverse vulnerables un mes después. Para determinar el tipo de autenticación utilizado en la aplicación. 13. Threat Modeling es una actividad clave que se realiza en la fase de planificación/diseño. ¿Cuál es el objetivo principal de esta práctica?. Simular ataques reales en un entorno staging para encontrar vulnerabilidades. Ejecutar análisis de composición de software (SCA) sobre bibliotecas de terceros. Implementar la protección RASP en entorno de producción. D. Identificar, comunicar y comprender las amenazas y vulnerabilidades potenciales en un diseño de sistema antes de escribir el código. 14. Microsoft recomienda como una de las primeras acciones en la fase de planeamiento y desarrollo, para detectar problemas de seguridad antes de que el código se confirme en el repositorio compartido: Ejecutar pruebas de penetración en un entorno activo. Implementar comprobaciones automatizadas, como complementos de seguridad del entorno de desarrollo integrado (IDE). Desactivar las funciones seguras solo en producción. Implementar security gating para fallar el build si la vulnerabilidad es alta. 15. La seguridad como código (Security as Code) es una parte de la fórmula de DevSecOps. ¿Cuál es la función del equipo de seguridad en el concepto de habilitación (Enabling) dentro de la cultura DevSecOps?. Ser el 'muro que revisaba al final' del proceso. Decidir si una aplicación debe ser desplegada o no. Proporcionar las herramientas, la formación y las políticas (el 'código' de seguridad) para que Dev y Ops puedan integrar la seguridad por sí mismos. Ejecutar las pruebas de seguridad que fallaron en la Integración Continua (CI). 16. En el modelo DevSecOps, el concepto de responsabilidad compartida implica que la seguridad deja de ser un asunto exclusivo del equipo de seguridad. ¿Quién se convierte en el primer responsable de escribir código seguro?. El equipo de operaciones (Ops). El desarrollador (Dev). El Security Champion. La plataforma SIEM. 17. ¿Cuál es el objetivo principal del bucle de retroalimentación (Feedback Loop) en DevSecOps?. Asegurar que las correcciones sean realizadas manualmente por el equipo de seguridad. Implementar políticas de Zero Trust únicamente en la arquitectura. Asegurar que los incidentes en producción generen un ticket o story de vuelta al backlog de desarrollo para su parcheo ágil. Proveer entrenamiento constante exclusivamente a los Security Champions. 18. Un ingeniero de DevSecOps está utilizando Terraform para definir la infraestructura y desea prevenir la configuración de un puerto SSH abierto a 0.0.0.0/0. ¿Qué tipo de herramientas debe utilizar para escanear estos archivos de configuración antes de su despliegue?. RASP en producción. SAST en la fase de Codificación. DAST en el entorno de staging. Herramientas de Escaneo de IaC (Checkov, Terrascan). |





