El desarrollo de software es una práctica en la que participan cada vez más personas en todo el mundo. Hay empresas e individuos que crean software, algunos de ellos propietarios, otros gratuitos o de código abierto, y otros son una combinación de ambos. Dado que las amenazas a la seguridad de los usuarios o su software no se materializan de la nada tan pronto como algo se declara completo y se envía a producción, parece el momento adecuado para hablar sobre prácticas de seguridad que ayudarían a gestionar los riesgos de seguridad que podrían surgir. su software durante el proceso de desarrollo. Existen varios marcos SSDLC (Ciclo de vida de desarrollo de software seguro), incluidos los de OWASP, CISAy NIST (SSDF). En este artículo, tomaremos prestado un poco de todos ellos para resaltar algunas prácticas destinadas a ayudarle a gestionar el riesgo inherente al desarrollo de software. No vivas con una sensación de falsa seguridad pensando que no te puede pasar a ti. El informe de seguridad cibernética de mitad de año de Check Point 2023 revela un aumento del 8% en los ciberataques globales a lo largo de 2022, y la tendencia no parece revertirse.
¿Qué es el ciclo de vida del desarrollo de software?
Los desarrolladores de software tienen como objetivo crear software de forma rápida, precisa y segura. Por supuesto, no siempre puedes conseguir los tres. Con el tiempo, el proceso de desarrollo se dividió en varias fases distintas que pueden adaptarse a cualquier desarrollo de software. Estas fases se pueden dividir en:
- Análisis de requerimientos – qué vamos a construir y por qué
- Planificación – cómo lo vamos a construir en términos generales
- Diseño de software – cómo lo vamos a construir en términos específicos como el diseño arquitectónico
- Desarrollo de software – escribir y compilar el software
- Pruebas – asegúrese de que funcione según lo planeado
- Despliegue – enviarlo o publicarlo para que el usuario final pueda usarlo
Hay algunas otras versiones de este ciclo pero en general son muy similares. Es importante recordar que el ciclo no es algo único: generalmente no termina una vez que lo envía al cliente o lo publica en la nube. Casi siempre hay problemas que debes solucionar y que pueden requerir un rediseño (volver al punto de partida), errores que debes corregir, características que deseas agregar, etc. También puedes encontrarte trabajando en algunas etapas en paralelo o deteniéndote a mitad de paso para retroceder. Dado que ninguno de los pasos está intrínsecamente centrado en la seguridad, esto deja que la seguridad se ponga constantemente al día con el proceso de desarrollo y, en las frenéticas velocidades de desarrollo actuales, no es suficiente.
La importancia de proteger su SDLC
El desarrollo de software seguro tiene como objetivo incluir consideraciones de seguridad en todas las etapas del proceso, sin tratar la seguridad como un complemento del proceso. De esta manera, la seguridad siempre debe ser una consideración sin importar en qué fase del proceso esté involucrado: pensar en los requisitos del proyecto, planificar la arquitectura, considerar los componentes básicos y la infraestructura necesarios y sentarse a desarrollar el código. A este enfoque a veces se le llama seguridad de desplazamiento a la izquierda enfoque.
Aquí, desplazamiento a la izquierda se refiere a distribuir las preocupaciones de seguridad a lo largo del proceso de desarrollo e involucrar a los desarrolladores en el diseño, la implementación y las pruebas de seguridad.
Puede resultar intimidante para los desarrolladores que nunca han pensado realmente en los problemas de seguridad tener que lidiar con ellos de repente. Es mucho más fácil de manejar si los requisitos se dividen en múltiples mejores prácticas bien definidas. Puedes pensar en ello como adquirir un nuevo IDE.
Cuanto más bien definidos estén los requisitos y más automatización y herramientas integrales pueda emplear, más fáciles serán las tareas.
Mejores prácticas de seguridad de SDLC
A continuación se presentan algunas prácticas recomendadas que le ayudarán a proteger su proceso de desarrollo sin ningún orden en particular:
Formación – Muchos desarrolladores se sentirían inadecuados para la tarea de aplicar consideraciones de seguridad y probar el código que están escribiendo. La mayoría de los desarrolladores son conscientes de que permitir que datos de entrada contaminados ingresen a su backend puede resultar en una activación remota del código, muy similar a las conocidas "tablas desplegables". Sin embargo, menos personas estarían familiarizadas con las pruebas de desbordamiento del búfer o el escaneo de vulnerabilidades para dependencias terciarias (o adicionales). Los desarrolladores pueden cerrar estas brechas de conocimiento mediante el uso de capacitación. Los desarrolladores están mejor equipados para incorporar cuestiones de seguridad en su codificación y pruebas diarias cuando tienen una comprensión más profunda de los desafíos de seguridad y las vulnerabilidades potenciales. También tiene mucho más sentido que el desarrollador que escribió el código y está íntimamente familiarizado con su función considere sus brechas de seguridad y planifique las pruebas en consecuencia.
Escaneado – Puede utilizar muchos tipos de escaneo para que su código sea más seguro en general. El análisis estático, dinámico e interactivo son algunos de ellos. El análisis estático busca fallas de codificación evidentes o posibles vulnerabilidades de seguridad en el código fuente. Se puede utilizar para buscar posibles vulnerabilidades, prácticas de código inseguro y violaciones de los estándares de codificación. No considera eventos en tiempo de ejecución porque examina únicamente la sintaxis del código. El análisis dinámico busca fallas de seguridad, fallas de codificación y otros problemas en la aplicación mientras se ejecuta. Se puede utilizar para identificar pérdidas de memoria, operaciones deficientes y posiblemente entradas o procesos inestables. Tenga en cuenta que dado que este tipo de pruebas se realiza en un momento determinado utilizando insumos específicos, la calidad de las pruebas depende completamente de las personas que las idearon. El objetivo es encontrar los problemas antes que los usuarios. El análisis interactivo examina la aplicación para encontrar posibles fallas de seguridad y otros problemas importantes. Puede buscar posibles vulnerabilidades, problemas de usabilidad y problemas con la interfaz de usuario. Cuanto más completas sean las herramientas de escaneo que utilice, mejor protegido estará, pero la contrapartida está, por supuesto, en la velocidad de desarrollo. Dado que cada aplicación es única, depende de usted encontrar el equilibrio entre la cantidad correcta de escaneo y la velocidad de desarrollo deseada. Además, recomendamos crear un SBOM completo de su aplicación y aplicar también varios escaneos e informes a esa fuente de datos. Tener un legado SBOM de su aplicación es una buena manera de mantener información muy detallada sobre componentes y paquetes que podría ser invaluable por numerosas razones de seguridad.
Revisiones de código – Examinar el código fuente para encontrar fallas de seguridad, errores de codificación y otras fallas de software antes de combinarlo con la rama de desarrollo activo se conoce como revisión de código. Normalmente, un desarrollador con mayor experiencia que el autor del código realiza esta revisión. Estas revisiones pueden ayudar a garantizar que el código esté bien escrito y que la aplicación sea segura. Además, admiten el mantenimiento de un estándar único y convenciones de codificación (como nombres de funciones y variables) en toda la base del código.
Permitir la integración del código en la rama principal después de que al menos dos pares de ojos lo hayan revisado se considera una buena práctica. El desarrollador que escribió el código es, por supuesto, el primer par de ojos. Puede resultar beneficioso incluso para ingenieros altamente cualificados, como líderes de equipo, que otra persona evalúe su código. Como mínimo, esto garantiza que más de una persona esté familiarizada con cada sección del código. Tenga en cuenta que en momentos de gran estrés o en momentos de escasez de tiempo, las personas podrían considerar renunciar a este elemento. Si es posible, considere agregar esta regla como un elemento codificado de su CI/CD para que no se pueda omitir.
Pruebas – No hace falta que le digamos lo importante que es probar su código para descubrir fallas de seguridad antes de que se conviertan en un problema. La mayoría de los proyectos de código son complejos y están interconectados, por lo que es imposible prever cómo una única y pequeña brecha puede eventualmente afectar la seguridad de toda la base del código.
Al escribir pruebas automatizadas, tenga en cuenta la funcionalidad del código producido recientemente, así como cualquier interacción significativa de back-end y front-end con otras partes del código base.
Vulnerabilidades como la inyección SQL, secuencias de comandos entre sitios, almacenamiento de datos inseguro y asignación de memoria inadecuada (que podría provocar desbordamientos del búfer) son ejemplos de problemas de seguridad que normalmente se abordan en las pruebas. Las pruebas deben abordar las pérdidas de memoria, el rendimiento lento o poco confiable y la usabilidad. Las pruebas deben ser automáticas e integradas en el proceso de CI/CD para que no se pueda publicar ninguna nueva versión o actualización sin someterse a pruebas unitarias y de integración.
Prueba de penetración independiente – Nadie puede pensar en todo y, como desarrolladores, a veces desarrollamos puntos ciegos con respecto al código que escribimos. De manera similar a la revisión de código, las pruebas de penetración independientes permiten un enfoque nuevo y otro par de ojos para examinar críticamente lo que hicimos y las precauciones que tomamos para proteger nuestra aplicación y a nuestros usuarios. Estas pruebas se recomiendan al menos una vez al año y deben incorporar la evaluación de la infraestructura y las vulnerabilidades de las aplicaciones.
Utilice código abierto de forma segura – Casi todo el software en desarrollo hoy en día incluye software de código abierto en mayor o menor grado. Los componentes de código abierto son algunas de las principales causas de vulnerabilidades importadas en su aplicación, ya sea directamente o mediante dependencias transitorias. Además, no son sólo las bibliotecas que utiliza las que pueden ponerlo en peligro, sino que también puede afectarle el hecho de no actualizar las bibliotecas antiguas o mantenerse al día con los últimos CVE publicados. Recomendamos crear una lista de paquetes de código abierto aprobados para uso de la organización y verificarla y actualizarla constantemente. Evitar que los desarrolladores agreguen cualquier paquete que quieran, aunque sea solo como prueba, podría ayudar a reducir la cantidad de vulnerabilidades con las que tiene que lidiar.
Asegúrese de que las vulnerabilidades no se conviertan en exploits – Casi no existe una base de código exenta de vulnerabilidades. Cualquier escaneo decente arrojaría entre cientos y miles de ellos. Es imposible eliminarlos a todos. También es importante recordar que las vulnerabilidades no son exploits. Asegúrese de tener un proceso de filtrado para asegurarse de que cualquier vulnerabilidad que descubra no sea una amenaza explotable y mantenga esta lista constantemente actualizada. De esta manera, puede tranquilizar a terceros o usuarios preocupados por el último CVE de que no tiene absolutamente ningún impacto en su aplicación.
La seguridad comienza con su forma de pensar
Probablemente haya tantas formas diferentes de desarrollar software como desarrolladores, marcos y lenguajes de codificación. Es decir, no es fácil encontrar las mejores prácticas para asegurar su proceso de desarrollo que sean relevantes sin importar el idioma, campo o IDE que esté empleando. Más allá de una gran cantidad de herramientas, algunas propietarias y otras gratuitas, todas clamando por su atención como "la próxima herramienta de seguridad irremplazable", la herramienta de seguridad más importante que puede emplear es su forma de pensar.
Piense en sus opciones de diseño, arquitectura y almacenamiento. ¿Ha considerado la opción de un crecimiento exponencial en su base de usuarios? ¿Ha segmentado adecuadamente los privilegios de acceso para diferentes partes de su código base e infraestructura? ¿Consideró tanto un ataque dirigido contra sus datos o secretos como un ataque "indirecto" a la cadena de suministro de software?
Todas estas preguntas y más deben considerarse incluso antes de sentarse a planificar su aplicación y deben volver a inspeccionarse de forma rutinaria a medida que el código base y la aplicación crecen y evolucionan.
Se considera un axioma que la parte más vulnerable de cualquier software es el ser humano que lo ejecuta (o lo escribe). No permita que su aplicación, software o biblioteca de códigos formen parte de las crecientes estadísticas de una nueva ola de ciberataques. Con una planificación, herramientas y automatización adecuadas, puede encontrar el equilibrio adecuado entre gestionar el riesgo cibernético, proteger su ciclo de vida de desarrollo y producir código bien documentado, completo y eficiente.