Si bien el software de código abierto es una parte integral del desarrollo de software en la actualidad, la seguridad sigue siendo un problema. Un informe publicado recientemente reveló un aumento del 71% en las infracciones relacionadas con la seguridad de código abierto en los últimos cinco años. Además, el 25% de las organizaciones informaron de una infracción confirmada en relación con el software de código abierto.El quinto informe anual Sonatype State of the Software Supply Chain Report se basa en patrones y prácticas de higiene de ciberseguridad de unos 36.000 proyectos de código abierto y 3,7 millones de versiones de componentes de código abierto.
Según Derek Weeks, vicepresidente de Sonatype, una de las razones por las que la seguridad sigue siendo un problema con los proyectos de código abierto es que los desarrolladores tratan todo el software de código abierto por igual: "El informe de este año muestra definitivamente que no podemos hacer eso, no podemos tratar todos los proyectos de código abierto como iguales. Durante mucho tiempo se ha creído que en el ámbito del desarrollo de código abierto: 'con más ojos, todos los errores son superficiales'. En otras palabras, cuanto más populares eran los componentes de código abierto, menos errores o vulnerabilidades podían tener. Eso no es cierto, y conduce a una falsa sensación de seguridad".Al analizar los patrones de comportamiento y las mejores prácticas, el informe analizó las diferencias entre la forma en que los proyectos actualizan las dependencias y corrigen las vulnerabilidades; la forma en que se utilizan los componentes; y el asesoramiento que se puede ofrecer sobre cómo se consumen esos componentes. El informe encontró que sólo el 5 por ciento de los proyectos remedian las vulnerabilidades de seguridad en un plazo de 21 días; proyectos destacadps como Elasticsearch, Mulesoft y SonarSource son 3,4 más rápidos en la solución de vulnerabilidades conocidas; y las prácticas de desarrollo seguras tienen 9,3 veces más probabilidades de eliminar las dependencias problemáticas.El informe de este año de Sonatype muestra claramente que los desarrolladores no deben seleccionar los componentes basándose únicamente en la popularidad. Aunque muchos de los componentes de código abierto de mejor calidad son populares, no todos los proyectos populares de código abierto mejoran o solucionan las vulnerabilidades con frecuencia. Algunos de los componentes más populares pueden tardar 200 días o más, en promedio, en liberar nuevas actualizaciones o remediar vulnerabilidades de seguridad conocidas.Con el fin de mejorar y garantizar la seguridad del código abierto, Weeks sugiere la creación de una Software Bill of Materials (SBOM) que traducido vendría a ser algo así como una lista de todos los componentes que forman parte de un software. Esto ayudaría a los analistas, desarrolladores y programadores a comprender mejor sus cadenas de suministro de software. El SBOM proporcionará a los desarrolladores información y conocimiento sobre los componentes software de código abierto que utilizan sus equipos, las vulnerabilidades de seguridad conocidas, los riesgos de cada licencia, así como los riesgos arquitectónicos.Además de un SBOM, los equipos de desarrollo deben utilizar un gestor de repositorios, actualizar regularmente las dependencias, utilizar las versiones más recientes de los componentes y automatizar.
"Si los desarrolladores entendien mejor qué proveedores o proyectos están utilizando y se centran en utilizar sólo los mejores, sería un gran paso hacia adelante"Derek Weeks de Sonatype.
Weeks también meciona la métrica Median Time to Update (MTTU) (tiempo medio de actualización en castellano), que puede ser una métrica crítica a la hora de decidir qué componente utilizar. Los responsables de proyectos de código abierto pueden utilizar MTTU para ayudar a las empresas a garantizar la seguridad. "Los desarrolladores que mantienen proyectos de código abierto que están considerando añadir una nueva dependencia, y que buscan una métrica que guíe esa elección, harían bien en centrarse en esas dependencias con una MTTU rápida. Dado que la reparación de una dependencia vulnerable suele implicar la actualización a una nueva versión de dependencia, los componentes con valores rápidos de MTTU muestran naturalmente una respuesta más rápida a las vulnerabilidades de la dependencia"Es importante que los desarrolladores entiendan que las prácticas de codificación segura pueden acelerar sus procesos e incrementar la innovación. Para sobrevivir y prosperar en la economía actual de las aplicaciones, los mejores equipos de desarrollo están adoptando activamente la innovación del código abierto, las prácticas de gestión de la dependencia y las herramientas automatizadas para el mantenimiento del código abierto se deduce del informe.Artículos relacionados y enlaces de interés
- 2019 State of the Software Supply Chain Report
- Tipos de licencias de software: software libre, software propietario, código abierto y otros
- ¿Qué es el software libre o de fuentes abiertas?
- vERP es la plantilla de software ERP de código abierto de Velneo
- Mejores herramientas para desarrolladores de software
