Capítulo 16 · Software, operaciones e incidentes

Seguridad de Aplicaciones y DevSecOps

Integrar seguridad en el ciclo de vida de desarrollo, entrega y operación de software mediante prácticas, controles y automatización DevSecOps.

Secure Software Development Lifecycle

La seguridad del software comienza cuando se definen requisitos, no únicamente cuando se ejecuta una prueba al final. El ciclo de desarrollo seguro incorpora riesgos desde el diseño, los integra en historias de trabajo y establece criterios de aceptación verificables. Una aplicación que permite consultar expedientes necesita requisitos sobre autorización, registro y conservación antes de elegir componentes. La deuda de seguridad surge cuando se posponen medidas que después son costosas de incorporar. El proceso debe reconocer prioridades y límites, evitando que cualquier alerta paralice el desarrollo. La seguridad por diseño exige revisión continua de decisiones y evidencia de que los requisitos se cumplen.

Conceptos de este apartado

  • Requisitos de seguridad
  • Abuse cases y security stories
  • Diseño y revisión temprana
  • Definición de criterios de aceptación
  • Gateways de seguridad
  • Gestión de defectos y deuda de seguridad

Principios de codificación segura

Escribir código seguro implica tratar datos y acciones de origen externo como potencialmente incorrectos. Validar entradas previene que un parámetro cambie indebidamente una consulta o una operación; controlar salidas reduce ciertos ataques en el navegador. La autenticación determina identidad, mientras que la autorización comprueba permisos en cada acción pertinente. Los secretos no deberían quedar incorporados en el código o registros. Los mensajes de error deben ser útiles para diagnosticar sin revelar datos sensibles. Una aplicación puede estar detrás de un firewall y seguir teniendo un fallo grave si permite a un usuario consultar archivos de otro sin autorización.

Conceptos de este apartado

  • Validación de entrada y salida
  • Manejo de errores
  • Gestión segura de sesiones
  • Autenticación y autorización en aplicaciones
  • Protección de secretos
  • Registro seguro sin exposición de datos

Vulnerabilidades de aplicaciones web

Los riesgos frecuentes en aplicaciones web incluyen inyección, ejecución de scripts en el navegador, controles de acceso defectuosos y solicitudes a servicios internos no previstos. OWASP ofrece referencias para reconocer estas debilidades, pero no sustituye pruebas contextualizadas. Una inyección SQL puede surgir cuando una aplicación construye consultas mezclando instrucciones y datos sin separación adecuada; el control de acceso roto aparece cuando una URL permite consultar recursos ajenos. La gravedad depende de datos, exposición y permisos efectivos. Aprender a explicar el mecanismo y el impacto es más útil que memorizar nombres de vulnerabilidades.

Conceptos de este apartado

  • Inyección
  • Control de acceso roto
  • XSS y riesgos del navegador
  • SSRF y abuso de servicios internos
  • Deserialización y errores de lógica
  • OWASP Top 10 como referencia

Pruebas de seguridad automatizadas

Las pruebas automáticas identifican problemas distintos. SAST analiza código sin ejecutar la aplicación; DAST observa comportamientos mientras funciona; SCA revisa componentes y dependencias. También se buscan secretos y configuraciones inseguras en infraestructura como código. Un resultado de herramienta no prueba automáticamente que una vulnerabilidad sea explotable. Los falsos positivos requieren validación, y los falsos negativos muestran que ninguna herramienta ofrece cobertura total. Una estrategia equilibrada combina automatización, revisión humana y criterios de priorización basados en contexto. Cada hallazgo debería poder rastrearse hasta una decisión de corrección o aceptación.

Conceptos de este apartado

  • SAST
  • DAST
  • SCA y dependencias
  • Secret scanning
  • IaC scanning
  • Priorización y gestión de falsos positivos

Pipelines CI/CD seguros

Un flujo CI/CD automatiza compilación, prueba y despliegue de versiones. Su seguridad depende de permisos en repositorios, revisión de cambios, custodia de credenciales y protección de los sistemas que ejecutan las tareas. Un atacante que modifica una dependencia o un runner puede afectar software legítimo sin comprometer directamente a todos los usuarios. Firmar artefactos y conservar información sobre su origen facilita verificar qué se distribuyó. Las puertas de control deben impedir entregas con fallos críticos conocidos cuando así se haya definido, pero también permitir procedimientos excepcionales documentados para situaciones urgentes.

Conceptos de este apartado

  • Protección de repositorios
  • Branch protection y code review
  • Runners y agentes
  • Firma de artefactos
  • Gestión de credenciales de pipeline
  • Promoción entre entornos

Operación y mejora continua

La seguridad continúa después del despliegue. Nuevas vulnerabilidades pueden afectar una versión antes aceptable; los cambios de configuración y los accesos operativos también alteran el riesgo. La telemetría permite observar fallos, mientras que mecanismos como rollback ayudan a revertir despliegues problemáticos. La coordinación entre desarrollo, seguridad y operación debe identificar responsables y tiempos de respuesta. Contar alertas de un escáner no mide por sí solo madurez del proceso; importa cuánto se tarda en validar, corregir y verificar. El cierre exige evidencias de que el problema fue tratado en el servicio real.

Conceptos de este apartado

  • Telemetría de aplicaciones
  • Gestión de vulnerabilidades post-despliegue
  • Feature flags y rollback
  • Coordinación con respuesta a incidentes
  • Métricas DevSecOps
  • Madurez y gobernanza del programa

Un caso para comprenderlo

Un usuario puede acceder al expediente de otra persona modificando un identificador de la URL. La aplicación funciona correctamente para la mayoría de acciones, pero falla una autorización fundamental. El caso muestra por qué las pruebas de seguridad deben cubrir lógica de negocio y permisos, además de buscar errores conocidos en bibliotecas.

Cómo aplicar estos conceptos

El punto de partida es describir el sistema o situación con precisión, distinguir hechos de suposiciones y seleccionar qué información permitiría comprobar una conclusión. A partir de ahí se identifican riesgos, controles, responsabilidades y evidencias posibles. La utilidad de estos conocimientos aumenta cuando se relacionan con otras áreas de la ciberseguridad y del Derecho informático.

Fuentes y lecturas de referencia

Lecturas relacionadas