Ciclo de vida del desarrollo de software seguro (SSDLC)

La seguridad es una parte importante de cualquier aplicación que incluya funciones críticas. Puede ser algo tan simple como proteger tu base de datos de los ataques de actores maliciosos, o tan complejo como aplicar un proceso de detección de fraude a un prospecto calificado antes de importarlo a tu plataforma.

Fases del SLDC

El ciclo de vida del desarrollo de software (SDLC) describe cómo se crean las aplicaciones de software. Por lo general, incluye las siguientes fases:

• Recopilación de requisitos

• Análisis de los requisitos para orientar el diseño

• Diseño de nuevas funciones según los requisitos

• Desarrollo de nuevas capacidades (escribir código para cumplir los requisitos)

• Pruebas y verificación de las nuevas capacidades: confirmar que realmente cumplan los requisitos

• Implementación del nuevo proyecto

Mantenimiento y evolución de estas capacidades una vez que se publica la versión

7 fases del SDLC

Metodologías del SDLC:

Desarrollo ágil:

El desarrollo ágil con SDLC propone dividir las grandes versiones monolíticas en varias versiones pequeñas, cada una desarrollada en sprints de dos o tres semanas, y usar la automatización para crear y verificar las aplicaciones. Esto permite a las empresas iterar mucho más rápido. En lugar de las implementaciones monolíticas e infrecuentes características de las aplicaciones basadas en el modelo en cascada, el desarrollo ágil suele enfocarse en publicar nuevas funciones varias veces al día y crear software de forma incremental, en vez de hacerlo todo de una sola vez.

Desarrollo en cascada:

El modelo de SDLC en cascada es una de las metodologías de SDLC más antiguas y conocidas, y sentó las bases de estas fases. Desarrolladas en 1970, estas fases siguen siendo prácticamente las mismas hoy en día, aunque las prácticas de ingeniería de software han cambiado enormemente y han redefinido la forma de crear software.

¿Por qué es importante el SDLC seguro?

La seguridad se aplica en todas las fases del ciclo de vida del desarrollo de software (SDLC) y debe ser una prioridad para tus desarrolladores mientras implementan los requisitos de tu software. Con un esfuerzo dedicado y las soluciones de seguridad para SDLC adecuadas, los problemas de seguridad pueden abordarse en el pipeline del SDLC mucho antes de la implementación en producción. Esto reduce el riesgo de encontrar vulnerabilidades de seguridad en tu aplicación y ayuda a minimizar el impacto cuando se detectan.

El objetivo del SDLC seguro no es eliminar por completo las verificaciones de seguridad tradicionales, como las pruebas de penetración, sino incluir la seguridad entre las responsabilidades de los desarrolladores y darles las herramientas para crear aplicaciones seguras desde el principio.

SDLC y seguridad de las aplicaciones

 Puede costar hasta 100 veces más corregir un problema que se descubre tan tarde en el SDLC que solucionarlo al inicio del proceso 

Al incorporar medidas de seguridad desde las primeras etapas del SDLC, los desarrolladores pueden identificar y abordar posibles problemas de seguridad de forma proactiva, lo que reduce significativamente el costo de corregir vulnerabilidades más adelante en el proceso de desarrollo. 

¿Cuáles son los procesos del ciclo de vida del desarrollo de software seguro?

Implementar la seguridad en el SDLC afecta todas las fases del proceso de desarrollo de software. Esto es mucho más eficiente y económico que esperar a que estos problemas de seguridad aparezcan en la aplicación implementada. Los procesos del ciclo de vida del desarrollo de software seguro incorporan la seguridad como un componente de cada fase del SDLC.

Si bien integrar la seguridad en cada fase del SDLC es, ante todo, una mentalidad que todos deben adoptar, las consideraciones de seguridad y las tareas asociadas variarán significativamente según la fase del SDLC.

5 fases del ciclo de vida del desarrollo de software seguro

Cada fase del SDLC debe contribuir a la seguridad general de la aplicación. Esto se logra de forma distinta en cada fase, con una consideración fundamental: la seguridad del ciclo de vida del desarrollo de software debe ser una prioridad para todo el equipo. Veamos un ejemplo de un ciclo de vida del desarrollo de software seguro para un equipo que crea un portal de renovación de membresías:

Fase 1: Requisitos

En esta etapa inicial, se recopilan los requisitos de las nuevas funciones de distintas partes interesadas. Es importante identificar las consideraciones de seguridad de los requisitos funcionales que se recopilan para la nueva versión.

• Ejemplo de requisito funcional: Los usuarios deben poder verificar su información de contacto antes de renovar su membresía.

• Ejemplo de consideración de seguridad: los usuarios solo deben poder ver su propia información de contacto, no la de otras personas.

Fase 2: Diseño

En esta fase, los requisitos incluidos en el alcance se traducen en un plan de cómo se verán en la aplicación. Los requisitos funcionales suelen describir lo que debería suceder, mientras que los requisitos de seguridad suelen enfocarse en lo que no debería suceder.

• Ejemplo de diseño funcional: La página debe recuperar el nombre, correo electrónico, teléfono y dirección del usuario de la tabla CUSTOMER_INFO en la base de datos y mostrarlos en pantalla.

• Ejemplo de consideración de seguridad: Debemos verificar que el usuario tenga un token de sesión válido antes de recuperar información de la base de datos. Si no tiene el token, se debe redirigir al usuario a la página de inicio de sesión.

Fase 3: Desarrollo

Cuando llega el momento de implementar el diseño y hacerlo realidad, las preocupaciones suelen centrarse en garantizar que el código esté bien escrito desde el punto de vista de la seguridad. Por lo general, existen lineamientos de codificación segura establecidos y revisiones de código para verificar que se hayan seguido correctamente. Estas revisiones pueden ser manuales o automatizadas mediante pruebas estáticas de seguridad de aplicaciones (SAST).

Dicho esto, los desarrolladores de aplicaciones modernas no pueden preocuparse únicamente por el código que escriben, porque la mayoría de las aplicaciones actuales no se crean desde cero. En cambio, para ofrecer nuevas funciones y valor a la organización lo más rápido posible, los desarrolladores se apoyan en funcionalidades existentes, que suelen proporcionarse mediante componentes de código abierto gratuitos. De hecho, más del 90 % de las aplicaciones modernas implementadas están compuestas por estos componentes de código abierto. Las herramientas de análisis de composición de software (SCA) suelen revisar estos componentes de código abierto.

En este caso, los lineamientos de codificación segura pueden incluir:

• Usar consultas SQL parametrizadas y de solo lectura para leer datos de la base de datos y reducir la posibilidad de que alguien las manipule con fines maliciosos

• Validar las entradas del usuario antes de procesar los datos que contienen

• Sanitizar los datos que se envían de vuelta al usuario desde la base de datos

• Revisar si las bibliotecas de código abierto tienen vulnerabilidades antes de usarlas

Fase 4: Verificación

En la fase de verificación, las aplicaciones pasan por un ciclo exhaustivo de pruebas para garantizar que cumplan con el diseño y los requisitos originales. También es un buen momento para incorporar pruebas de seguridad automatizadas mediante diversas tecnologías. La aplicación no se implementa hasta que estas pruebas se aprueban. Esta fase suele incluir herramientas automatizadas, como los pipelines de CI/CD, para controlar la verificación y la publicación.

La verificación en esta fase puede incluir:

• Pruebas automatizadas que representan las rutas críticas de tu aplicación

• Ejecución automatizada de pruebas unitarias de la aplicación para verificar que funcione correctamente

• Herramientas de implementación automatizada que sustituyen dinámicamente los secretos de la aplicación que se usarán en un entorno de producción

Fase 5: Mantenimiento y evolución

La historia no termina cuando se publica la aplicación. De hecho, es posible que se encuentren vulnerabilidades que pasaron desapercibidas mucho después de su publicación. Estas vulnerabilidades pueden estar en el código que escribieron los desarrolladores, pero cada vez se encuentran más en los componentes de código abierto subyacentes de una aplicación. Esto ha provocado un aumento en la cantidad de «vulnerabilidades de día cero», es decir, vulnerabilidades desconocidas hasta entonces, que los responsables de mantener la aplicación descubren en producción.

Luego, el equipo de desarrollo debe aplicar parches para corregir estas vulnerabilidades, un proceso que, en algunos casos, puede requerir reescribir una parte importante de la funcionalidad de la aplicación. En esta etapa también pueden surgir vulnerabilidades de otras fuentes, como pruebas de penetración externas realizadas por hackers éticos o reportes del público a través de los llamados programas de recompensas por errores («bug bounty»). Es necesario planificar cómo abordar estos problemas de producción e incluir su resolución en futuras versiones.

Beneficios del SSDLC

Los principales beneficios del SDLC seguro son:

• Menor riesgo de filtraciones de datos 

• Mayor resiliencia de las aplicaciones 

• Más confianza y seguridad para los usuarios 

• Menores costos de corrección

El SDLC seguro es el ejemplo por excelencia de una iniciativa conocida como «shift-left», que consiste en integrar las verificaciones de seguridad lo antes posible en el SDLC.

Esto ayuda a los equipos de desarrollo a planificar adecuadamente las versiones y facilita la detección y resolución de problemas que podrían afectar el cronograma de publicación. Es preferible a llevarse una sorpresa desagradable cuando la aplicación ya está en producción. Por eso, el SSDLC ayuda a mantener las versiones según lo previsto.

Además, en esencia, el SSDLC hace que el propio equipo de desarrollo lidere las iniciativas de seguridad. Así, los problemas los corrigen los expertos en el área que escribieron el software, en lugar de que otro equipo arregle los errores como algo secundario. Esto permite que los desarrolladores asuman la responsabilidad de la calidad general de sus aplicaciones y ayuda a que se implementen aplicaciones más seguras en producción.

Aunque todas las tareas adicionales de pruebas de seguridad dentro del proceso de SDLC puedan parecer laboriosas y costosas, hoy en día la mayoría están automatizadas. Esto es especialmente cierto en el caso de las operaciones de desarrollo o DevOps (hablaremos más sobre esto a continuación). El entorno de SDLC seguro requiere una colaboración frecuente entre DevOps y los ingenieros que implementan las funciones de la aplicación, y esta colaboración debe integrarse en el propio SDLC.

Al corregir estos problemas desde las primeras etapas del proceso, los equipos de desarrollo pueden reducir el costo total de propiedad de sus aplicaciones. Detectar problemas tarde en el SDLC puede aumentar hasta 100 veces el costo de desarrollo necesario para corregirlos, como muestra el gráfico siguiente.

IBM System Science Institute: costo relativo de corregir defectos, 2010

Como se muestra en la Figura 2 anterior, la transición a un SDLC seguro permite que los equipos de desarrollo creen aplicaciones seguras con mayor rapidez y, por lo tanto, puede ser una inversión valiosa para las organizaciones.

¿Cómo garantizar un SSDLC?

Para garantizar un SDLC seguro, es necesario enfocarse en cómo funciona la aplicación y en cómo los desarrolladores convierten los requisitos en código. La seguridad debe ser una prioridad para el equipo durante todo el desarrollo de la aplicación. Esto puede requerir un cambio cultural en tus equipos, además de procesos y verificaciones automatizados en cada etapa del desarrollo de software.

Garantizar un SSDLC para una aplicación depende en gran medida de las fortalezas y debilidades del equipo de desarrollo de software que trabaja en la seguridad del SDLC. Por ello, es difícil definir un único proceso de SDLC seguro.

Como el SDLC seguro implica cambiar los procesos existentes, implementar herramientas nuevas y, más importante aún, impulsar un cambio cultural en varios equipos, el camino hacia un SDLC seguro que funcione bien suele ser único para cada organización e incluso puede variar entre distintas unidades de negocio.

5 prácticas recomendadas para un SDLC seguro

1. Capacita a tus desarrolladores

El SDLC seguro va de la mano con varias iniciativas relacionadas, entre ellas:

• Crear lineamientos de codificación segura

• Brindar a los desarrolladores capacitación sobre concientización de seguridad y codificación segura

• Definir expectativas claras sobre la rapidez con la que deben abordarse los problemas detectados en producción (también conocidos como SLA de corrección).

No es necesario aplicar todas estas medidas para implementar un SSDLC eficaz, pero, como en un rompecabezas, tendrás que juntar suficientes piezas antes de poder ver el panorama completo.

2. Define requisitos claros

Sea cual sea el resultado que crees, debe ser fácil de entender. Los equipos de desarrollo necesitan requisitos claros que puedan poner en práctica fácilmente. Esto se aplica a todos los consejos, recomendaciones y lineamientos de seguridad. Las vulnerabilidades detectadas en las pruebas deben ser fáciles de abordar. Es fundamental que todas las personas, los procesos y las herramientas involucrados aporten soluciones, en lugar de limitarse a señalar problemas.

3. Mantén una mentalidad de crecimiento

Como el SSDLC cambiará la forma en que trabajan e interactúan varios equipos, es importante que todos se acerquen a esta experiencia con una mentalidad abierta y que el equipo de seguridad se enfoque en ayudar a los desarrolladores a proteger sus propias aplicaciones.

4. Vincula la implementación con otras iniciativas

En el caso de aplicaciones y equipos consolidados, suele ser más fácil implementar cambios del SSDLC cuando se vinculan con otro esfuerzo de modernización, como una transformación a la nube, una iniciativa de DevOps o su variante más centrada en la seguridad, DevSecOps.

5. Aborda primero los problemas más importantes

Enfócate en los problemas más importantes y en las soluciones prácticas, en lugar de intentar abordar todas las vulnerabilidades detectadas. Si bien las aplicaciones más nuevas o pequeñas pueden corregir todos los problemas de seguridad, esto no necesariamente funciona en aplicaciones más antiguas y grandes.

También puede ser útil adoptar un enfoque de clasificación de prioridades. Esto no solo permite evitar que los problemas de seguridad lleguen a producción, sino también garantizar que las vulnerabilidades existentes se prioricen y se aborden con el tiempo.

SSDLC y DevSecOps

Aunque el SSDLC y DevSecOps están estrechamente relacionados, en realidad son prácticas complementarias. Tanto el SSDLC como DevSecOps se enfocan en dar a los desarrolladores más responsabilidad sobre sus aplicaciones y en garantizar que hagan más que solo escribir y probar código para cumplir con las especificaciones funcionales.

El SDLC seguro se enfoca en cómo se diseñan y crean las aplicaciones; DevSecOps busca transferir la responsabilidad del entorno de producción de cada aplicación desde los equipos de TI tradicionales a los desarrolladores. Esto permite que los desarrolladores se enfoquen en automatizar al máximo los procesos de compilación, prueba y lanzamiento.

DevOps y DevSecOps han iniciado una revolución que está redefiniendo el papel de los desarrolladores de software. Esto, por supuesto, se ha visto impulsado por otros cambios importantes, como las transformaciones a la nube. Sin embargo, aunque dar más autonomía a los desarrolladores y acelerar las pruebas de seguridad es clave para el éxito de la mayoría de las organizaciones modernas, sería un error considerar la seguridad de las aplicaciones solo un desafío de automatización. En cambio, es importante impulsar cambios culturales y de procesos que ayuden a fomentar la conciencia y las consideraciones de seguridad desde las primeras etapas del desarrollo. Esto debe abarcar todas las partes del ciclo de vida del desarrollo de software, ya sea que se le llame SSDLC o DevSecOps.

Hacia un futuro más seguro

Las prácticas tradicionales de prueba de vulnerabilidades en producción ya no son suficientes para proteger tus aplicaciones. A medida que ha evolucionado la industria del software, también lo han hecho los tipos de ataques. Implementar y mantener una aplicación segura requiere proteger cada etapa del proceso de desarrollo. Esto implica plantear preguntas sobre las prácticas de seguridad durante la etapa de recopilación de requisitos, adaptar la cultura y las prácticas del equipo para adoptar una mentalidad centrada en la seguridad, implementar verificaciones automatizadas en el proceso de implementación y aplicar muchas otras prácticas que, en conjunto, crean un proceso de SDLC seguro.

El SSDLC te permite anticipar los riesgos de seguridad y abordar el origen de los problemas desde la fase de requisitos, en lugar de tener que volver atrás desde la fase de mantenimiento. Si sigues las prácticas recomendadas para implementar el SDLC (¡incluso al usar IA!) y te enfocas en la seguridad en cada etapa del desarrollo, puedes tener la certeza de que tu aplicación será mucho más segura.