Existen diversas herramientas que se pueden integrar con algo grado de automatización en el desarrollo de software. Algunas trabajan durante la codificación y otras durante el testing, pero todas tienen como objetivo producir soluciones digitales más seguras, eliminando vulnerabilidades conocidas. Esto reduce considerablemente los costos y los riesgos en la entrega de software.

Este proceso se puede medir, de diferentes formas, no solo para monitorear el rendimiento del equipo de desarrollo, sino para monitorear y comprobar que se está desarrollando lo que los usuarios necesitan.

Muchas veces, la seguridad es abordada en una instancia avanzada del SDLC, generalmente en la de pruebas o aceptación. Inclusive, algunas veces, una vez que la aplicación está en producción. Esto genera enormes sobrecostos y riesgos, no solo es necesario mucho retrabajo, sino que estamos hablando de soluciones operativas con diversas vulnerabilidades que expone a toda la organización a posibles ataques. Como si esto no fuera poco, analizar la seguridad en etapas de testing o producción limita mucho la visión sobre la seguridad ya que pueden existir vulnerabilidades a nivel de arquitectura o de codificación de la solución que pueden no ser detectados en estas etapas.

Un ciclo de vida de desarrollo de software seguro (SSDLC) contempla la seguridad en todas las etapas del desarrollo. Es clave contemplar la seguridad desde el diseño de la aplicación. A continuación, se presentan algunas recomendaciones para embeber seguridad en cada etapa del SDLC:

Planificación: Identificar y analizar riesgos relativos a la seguridad que tendrá la nueva aplicación.

Análisis de Requerimientos: Incluir requerimientos de seguridad. El CISO debe contar con un catálogo (en continua evolución) de requerimientos de seguridad y debe determinar cuáles aplican para cada caso y con qué grado de prioridad. Modelar casos de mal uso y casos de abuso puede ser una forma efectiva de especificar requerimientos de seguridad a nivel funcional.

Diseño: Modelado de amenazas y análisis de riesgos a nivel de arquitectura.

Desarrollo: Capacitar a los desarrolladores y aplicar prácticas de codificación seguras. Analizar si existen vulnerabilidades conocidas en librerías o componentes de terceros utilizados para el desarrollo. Utilizar herramientas de análisis de código estático (SAST, Static application security testing), también conocidas como “white-box”. Estas herramientas se pueden integrar al entorno de desarrollo de forma de lograr un alto grado de automatización. Detectan vulnerabilidades conocidas en el código fuente, pero no puede descubrir problemas relativos al ambiente de ejecución.

Documentación: Contemplar la seguridad en la documentación técnica de modo de guiar al equipo de operación para mejorar la seguridad en ambiente de producción y a lo largo de su vida.

Pruebas: Verificar que el software cumple con los requisitos definidos. Es importante que los requerimientos determinen claramente cómo se debe verificar su cumplimiento. Utilizar herramientas de análisis dinámico de aplicaciones (DAST, Dynamic Application Security Testing), también conocidas como “black-box”. Este tipo de herramientas, que no accede al código fuente por lo que no dependen del lenguaje de programación, se integran al proceso de testing y buscan vulnerabilidades en tiempo de ejecución, incluyendo el entorno, interactuando con las aplicaciones como si fueran un atacante. Pueden detectar malas configuraciones en el entorno, vulnerabilidades en APIs, entre otros. Son un muy buen complemento para las herramientas SAST. Utilizar herramientas de análisis interactivo de aplicaciones (IAST, Interactive Application Security Testing), también conocidas como “gray-box”. Funcionan en base a agentes que interactúan con la aplicación en tiempo de ejecución, pero también logran analizar el código fuente. Esto permite detectar vulnerabilidades en las interacciones y llegar hasta el origen con mayor profundidad. Existen diferentes tipos de herramientas IAST.

Implementación: Realizar hardening en los ambientes productivos, utilizar herramientas de análisis de vulnerabilidades y llevar a cabo actividades de tests de penetración o ethical hacking.

Mantenimiento: Revisar y evolucionar continuamente los requerimientos de seguridad. Revisar y aplicar nuevos controles, implementar un Web Applicaction Firewall (WAF), implementar herramientas y procedimientos para análisis y detección de incidentes, entre otros.

Contemplar la seguridad a lo largo de todo el ciclo de vida de las aplicaciones es clave para reducir costos y riesgos, además de posicionarse mejor en el mercado ofreciendo servicios que construyan aplicaciones más seguras. Evolucionar hacia un SSDLC es un desafío totalmente realizable y sumamente necesario para cualquier equipo de desarrollo de software. Se puede realizar en forma gradual e independiente del enfoque. Desde enfoques predictivos hasta enfoques automatizados de integración e implementación continua (CI/CD) evolucionando desde DevOps hacia DevSecOps.

Algunas referencias de interés:

• Microsoft SDL (Security Development lifecycle).
• OWASP CLASP (Comprehensive, Lightweight Application Security Process), basado en Microsoft SDL.
• OWASP SAMM (Software Assurance Maturity Model).
• NIST SSDF (Secure Software Development Framework).