Veracode aclara algunas de las creencias sobre código abierto más extendidas en España y explica la realidad tras su uso e implantación

El software open source está en auge. Las tecnologías abiertas se han convertido en un elemento clave para todas las organizaciones, tanto públicas como privadas. Según el último estudio de Red Hat sobre “El estado actual del código abierto empresarial”, en los próximos dos años el open source tendrá la misma cuota de uso que el software propietario. Además, el 68% de las empresas ha aumentado la utilización de este tipo de tecnologías en el último año, y el 59% de ellas prevé seguir con ese aumento a corto plazo.

Gracias a sus múltiples ventajas, como las posibilidades de innovación o su habilidad de ayudar a los desarrolladores a crear código de forma más rápida, las compañías usan este tipo de software para modernizar las diferentes áreas que las conforman y se apoyan en él para llevar a cabo una transformación digital exitosa y ágil de su negocio.

A pesar de su implantación generalizada y de su éxito, todavía hay quien se mantiene reticente a confiar en componentes de software open source. Frases como “¿cómo podemos saber si estos componentes son seguros?” o “no dispone de soporte profesional” aún se escuchan en el entorno empresarial, sobre todo en aquellas compañías con un equipo de seguridad limitado o con poco conocimiento sobre la seguridad de aplicaciones

Calidad, seguridad e innovación, entre las ventajas del código abierto

Veracode, compañía líder en ayudar a las organizaciones a dotar de seguridad al software, ha detectado y analizado los 5 mitos sobre open source más generalizados para arrojar luz sobre este tipo de tecnología:

• “Los desarrolladores deberían crear el código sin componentes open source”. Es sencillamente imposible para los desarrolladores mantener el ritmo del mundo digital en el que vivimos sin incorporar estos fragmentos de código prefabricados a sus aplicaciones; les sería demasiado difícil lograr el desarrollo en el tiempo requerido. Los componentes open source son una parte integral del proceso de desarrollo, y han llegado para quedarse.
• “No puede hacerse seguro”. Hacer que el uso de componentes de código abierto funcione empieza por la tecnología que crea un inventario dinámico de qué componentes están en uso y dónde. Idealmente, este inventario incluiría información sobre si se está utilizando la funcionalidad vulnerable específica y orientación sobre cómo remediar cualquier problema de seguridad. De esta manera, cuando una gran vulnerabilidad llega a las noticias, los desarrolladores tienen la visión que necesitan para abordar el problema rápidamente. Las organizaciones pueden acelerar aún más el proceso de los desarrolladores creando un repositorio de componentes aprobados para ellos, eliminando así las dudas sobre la seguridad de los componentes y reduciendo drásticamente el trabajo posterior.
•  “No tiene soporte profesional”. El código abierto como tal no tiene soporte debido a que está disponible para todo el mundo a través de librerías y repositorios. A pesar de ello, los equipos de desarrollo que usan componentes open source de forma regular en su código pueden acceder a herramientas de seguridad de aplicaciones, como el software de composición de análisis (SCA, según sus siglas en ingles) que escanea el código en busca de vulnerabilidades. La más avanzada de estas herramientas proporciona una solución automática de las vulnerabilidades con modelos de aprendizaje automático que detectan brechas sin reportar en las librerías en tiempo casi real.
• “Los desarrolladores no pueden asumir la responsabilidad de la seguridad”. Los desarrolladores están en la mejor posición para securizar el código, pero esa seguridad no suele ser una de sus prioridades. Con el cambio que ha vivido el ámbito DevOps en los últimos años, el desarrollo se enfoca en la velocidad de la entrega del producto, lo que significa que deben moverse rápido y confiar en código open source, lo cual suele entrar en conflicto con los objetivos de la seguridad. En muchos casos, esto lleva a un modelo de “parchear y rezar”: las organizaciones parchean los fallos cuando escuchan hablar sobre ellos y rezan porque la brecha no haya sido explotada en el transcurso de tiempo que pasa desde que la descubren hasta que aplican los cambios. Pero esto no tiene por qué ser así. Los equipos pueden aprovecharse de las librerías open source para moverse a la velocidad que lo hace el DevOps sin tener que confiar solamente en un modelo de seguridad reactivo. Los desarrolladores deberían preguntarse cosas como de dónde viene el código open source, qué está haciendo y si pueden probar qué vulnerabilidades están presentes.
• “Los desarrolladores no están equipados para reducir el riesgo open source”. La accesibilidad del software open source es uno de sus principales valores, pero al mismo tiempo tiene sus riesgos. Conforme más organizaciones adopten modelos DevSecOps para crear código seguro de forma más eficiente y permitan la colaboración entre los equipos de seguridad y de desarrollo, limitar el riesgo asociado de la integración de los componentes open source en las aplicaciones es un imperativo. Las compañías deben buscar herramientas que proporcionen visibilidad directa e indirecta de todas las librerías en uso, que identifiquen todas las vulnerabilidades del código, y que muestren cómo dichos fallos afectan a las aplicaciones sin ralentizar la velocidad de desarrollo.

«El software de código abierto es un facilitador para las empresas de todo el mundo que están creando y utilizando software para mejorar los procesos, llegar a más clientes y generar ingresos», señala Alejandro Novo, director de Veracode en España, Portugal e Italia. “Ha cambiado el negocio de manera profunda y continuará haciéndolo. Es crucial que las empresas que dependen del código abierto se centren en estrategias para aliviar la deuda técnica y reducir su riesgo. La implementación de procesos de autorización y ‘comprobaciones de estado’ para proyectos de código abierto puede ayudar a las compañías a obtener los beneficios del código abierto sin asumir deudas de seguridad adicionales «, concluye.