Recientemente, charlando con un compañero, compartimos una reflexión interesante: los desarrolladores son los nuevos chefs. Y la verdad, no le falta razón. Cada vez es menos común que los nuevos desarrollos, ya sean aplicaciones u otros, estén realizados íntegramente por el mismo equipo. De la misma manera que en la cocina es esencial identificar a tiempo aquellos ingredientes que puedan ocasionar problemas de salud e intolerancias, en el desarrollo de software debemos detectar los componentes inseguros para evitar vulnerabilidades y problemas de seguridad.
Al igual que los chefs seleccionan sus ingredientes con mimo para elaborar un plato exquisito, los desarrolladores eligen cuidadosamente su código y las librerías de terceros, sean estas open source o no, para crear aplicaciones robustas, seguras y eficientes. En el mundo del desarrollo de software, estos «ingredientes» pueden ser componentes esenciales para la funcionalidad, la seguridad y la eficiencia de las aplicaciones.
Según los estudios de Synopsys, Linux Foundation y Sonatype, casi el cien por ciento de los desarrollos en cualquier sector incluyen dependencias de código abierto, y hasta el 90 por ciento del código que se pone en producción está compuesto por software cuyo origen es open source.
La selección de ingredientes seguros
Así como en la cocina la combinación de ingredientes debe ser cuidadosa para lograr el mejor sabor y garantizar la seguridad alimentaria, en el desarrollo de software la combinación de código y librerías debe ser óptima y segura. La habilidad de los desarrolladores radica en saber elegir y mezclar estos componentes para crear aplicaciones que no solo funcionen bien, sino que también sean seguras y confiables.
De aquí la importancia de saber qué se está usando de terceros, ya sea open source o no, y saber cuán seguro y confiable es. Desde hace tiempo, muchas organizaciones incluyen como buenas prácticas llevar a cabo el análisis de composición de las aplicaciones como parte del análisis de seguridad en el ciclo de vida del desarrollo de software.
Sin embargo, se ha visto que esto no es suficiente. En línea con el paradigma del shift-left de la seguridad en el ciclo de vida del desarrollo, basado en ir introduciendo buenas prácticas de seguridad en etapas tempranas del ciclo de vida del desarrollo, se debe prevenir y anticipar cualquier fallo de seguridad antes de que ocurra. Por eso, es necesario efectuar este análisis de seguridad de las librerías o códigos de terceros en fases previas del ciclo de desarrollo, como en tiempo de diseño e implementación sobre este tipo de dependencias.
La habilidad de los desarrolladores radica en saber elegir y mezclar los componentes para que sean aplicaciones seguras y confiables
Herramientas y técnicas de los nuevos ‘chefs’
Los fabricantes de soluciones de seguridad de aplicaciones están poniendo mucho esfuerzo en ello. Por ejemplo, Sonatype, con su repository firewall, permite analizar y vetar la descarga de librerías inseguras o maliciosas antes de que lleguen a los repositorios internos de los entornos de desarrollo. OpenText, con su solución Debricked, permite analizar los paquetes basándose en su nivel de seguridad, popularidad y número de contribuidores en los proyectos. Además, ofrece facilidades como su extensión para navegadores web que permite hacer consultas de forma fácil y rápida, así como la capacidad de personalizar las reglas de análisis para alinearse con la política de admisión de componentes de software de terceros y de licencias de la compañía o equipo de desarrollo.
A su vez, Xygeni destaca por su enfoque proactivo, monitorizando continuamente no solo el software desarrollado sino también las herramientas que se utilizan para ello, garantizando así un entorno de desarrollo integralmente seguro. Este sistema utiliza un algoritmo de embudo diseñado para priorizar las actividades de arreglo o mitigación de vulnerabilidades, y realiza un escaneo de las dependencias para detectar y neutralizar malware antes de que afecte el proyecto.
No podemos olvidar las soluciones SCA (Software Composition Analysis) y SCS (Supply Chain Security) como las de Checkmarx y Black Duck (antes Synopsys). Estas herramientas, ahora más maduras, permiten integrarse en los pipelines de CI/CD para el análisis de seguridad de dependencias y secrets* tanto en código como en documentación. De hecho, la mayoría de estas soluciones permite la generación de un SBOM (Software Billing of Materials) para inventariar dependencias.
Finalmente, también es importante mencionar programas como Security Champions, que capacitan a los desarrolladores para ser valedores de la seguridad en sus equipos, ayudando a construir una cultura de seguridad y mejorando la responsabilidad y conocimiento sobre la seguridad en toda la organización.
¡Sigue leyendo!
Aquí te hemos mostrado tan solo una parte de este contenido.
¿Quieres leer el artículo completo?
