Los desarrolladores de código abierto aún no están interesados ​​en …



La seguridad y el desarrollo siguen siendo dos mundos diferentes, con desarrolladores de código abierto que se resisten a perder tiempo buscando y solucionando vulnerabilidades.

Codificar nuevas funciones, mejorar herramientas y trabajar en nuevas ideas son las 3 actividades principales que motivan a los desarrolladores de código abierto a continuar codificando. ¿Al ultimate de la lista? Seguridad.

En una encuesta de 603 colaboradores de software libre y de código abierto (FOSS), la Open Resource Stability Basis (OpenSSF) de la Fundación Linux y el Laboratorio de Ciencia de la Innovación de la Universidad de Harvard (LISH) descubrieron que el desarrollador de FOSS promedio solo gastaba el 2.3% de su tiempo para mejorar la seguridad de su código. Si bien los colaboradores expresaron el deseo de dedicar mucho más tiempo a sus 3 actividades principales, no se sintieron obligados a dedicar más tiempo a la seguridad, según el Estudio de colaboradores de FOSS 2020 publicado esta semana.

Las opiniones de los desarrolladores sobre la seguridad y la codificación segura, que lo denominan una «tarea devastadora» y un «obstáculo procesal insoportablemente aburrido», destacan que las empresas que quieren fortalecer sus aplicaciones contra ataques tienen una brecha significativa entre esos deseos y conseguir sus propios desarrolladores. a bordo, dice Frank Nagle, profesor de la Escuela de Negocios de Harvard y autor colaborador del informe que analiza los resultados de la encuesta.

«Parece que este &#39cambio a la izquierda&#39 no ha invadido por completo las mentes de los desarrolladores de computer software libre», dice. «Aunque no preguntamos específicamente si los desarrolladores piensan que la seguridad es importante, probablemente comprendan que es una preocupación, pero creen que otros deberían lidiar con ella».

Los componentes y aplicaciones de código abierto representan más del 70% del código incluido en las aplicaciones modernas, lo que hace que la seguridad de esos componentes sea de suma importancia. Sin embargo, los desarrolladores de código abierto están más enfocados en trabajar en las últimas herramientas e implementar sus propias prioridades, según el Informe de la encuesta de contribuyentes de FOSS 2020.

La percepción de que los componentes de código abierto a menudo tienen vulnerabilidades no resueltas ha llevado a que más empresas implementen una variedad de controles y procedimientos de seguridad, incluyendo más de la mitad (55%) requiriendo parches y actualizaciones regulares, 49% permitiendo y bloqueando componentes específicos y 47% utilizando un proceso de revisión manual para permitir componentes específicos, según el informe de prácticas de DevSecOps y gestión de código abierto publicado por la firma de seguridad de software program Synopsys esta semana.

Los enfoques de las empresas hacia el computer software de código abierto siguen siendo desiguales, dice Tim Mackey, principal estratega de seguridad de Synopsys.

«Una conclusión clave de este informe es que se requiere una mayor automatización para hacer un inventario del uso del código abierto», dice. «A partir de ahí, las empresas necesitan desarrollar e implementar procesos para beneficiarse de toda la innovación que ocurre dentro de las comunidades de código abierto».

Las empresas todavía están descubriendo cómo integrar la seguridad en sus canales de DevOps, según la encuesta de Synopsys. Mientras que un tercio de las empresas consideran que su enfoque de DevSecOps es maduro, otro 40% solo tiene implementaciones limitadas o pilotos, y el 27% restante todavía está investigando o no planea seguir DevSecOps.

La cobertura mediática de vulnerabilidades específicas de código abierto y el problema standard de la seguridad de código abierto ha llevado a muchas empresas a implementar controles más estrictos y migrar a proyectos de código abierto mejor mantenidos, según el informe de Synopsys.

Sin embargo, la cobertura de los medios de una amenaza en individual no es un buen indicador de cuán peligrosa puede ser una vulnerabilidad o un componente defectuoso, dice Mackey de Synopsys.

«Lo que debemos reconocer es que la cobertura de los medios hará que las personas sin conocimientos técnicos comiencen a hacer preguntas», dice. «Esas personas no técnicas quieren asegurarse de que su negocio no esté en las noticias para un evento similar y comenzarán a hacer preguntas sobre cómo se administra la seguridad de código abierto dentro de su organización. Tener un proceso bien definido, uno que pueda identificar rápidamente el impacto de una nueva vulnerabilidad, contribuye en gran medida a calmar las preocupaciones «.

La Encuesta para colaboradores de FOSS sugiere que las empresas deben comenzar con un enfoque en el código seguro como uno de los requisitos de la empresa. Escribir código más easy y bien comentado, automatizar pruebas y controles de seguridad y usar lenguajes seguros para la memoria puede minimizar los errores de codificación.

«Dado que vemos un número cada vez mayor de empresas que pagan activamente a sus empleados para que trabajen en proyectos de software program libre, estos empleadores deben incentivar a sus empleados para que escriban código seguro desde el principio y también dediquen un tiempo a ayudar a encontrar y abordar las vulnerabilidades de seguridad existentes», dijo la Universidad de Harvard. Dice Nagle.

Las empresas que no realizan su debida diligencia podrían encontrar que los componentes básicos de código abierto de sus aplicaciones introducen vulnerabilidades de seguridad en sus productos. El 8 de diciembre, por ejemplo, la empresa de seguridad de redes Forescout vulnerabilidades reveladas en cuatro pilas de pink TCP de código abierto diferentes instaladas en millones de dispositivos y enrutadores conectados.

La Open up Software program Protection Foundation recomendó que las organizaciones que pagan a los empleados para que contribuyan a proyectos de código abierto también deben contribuir a las auditorías de seguridad y que esos empleados reescriban partes o componentes de esas bibliotecas. Parte de tal reescritura podría ser cambiar a un lenguaje seguro para la memoria, según el informe de la Encuesta de Colaboradores de FOSS.

Periodista tecnológico veterano de más de 20 años. Ex ingeniero de investigación. Escrito para más de dos docenas de publicaciones, incluidas CNET Information.com, Darkish Looking through, MIT&#39s Technologies Evaluate, Popular Science y Wired Information. Cinco premios de periodismo, incluido el de Mejor fecha límite … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia initial