Linus Torvalds, el creador de Linux y Git, tiene su propia ley en el desarrollo de software, y dice así: ” con suficientes ojos, todos los errores son superficiales “. Esta frase pone el dedo en el principio mismo del código abierto: cuanto ma s, mejor: si el código esta fa cilmente disponible para que cualquiera y todos corrijan errores, es bastante seguro. ¿Pero es? ¿O el dicho “todos los insectos son superficiales” solo es cierto para los errores superficiales y no para los que se encuentran ma s profundos? Resulta que las fallas de seguridad en el código abierto pueden ser ma s difíciles de encontrar de lo que pensa bamos. Emil Wåreus, director de I+D de Debricked , se encargó de profundizar en el rendimiento de la comunidad. Como científico de datos que es, por supuesto, preguntó a los datos:¿Qué tan buena es la comunidad de código abierto para encontrar vulnerabilidades de manera oportuna ?
La emoción de la caza (vulnerabilidad)
La búsqueda de vulnerabilidades de código abierto generalmente la realizan los mantenedores del proyecto de código abierto, los usuarios, los auditores o los investigadores de seguridad externos. Pero a pesar de que estos grandes arqueólogos del código ayudaron a proteger nuestro mundo, la comunidad aún lucha por encontrar fallas de seguridad.
En promedio, se tarda ma s de 800 días en descubrir una falla de seguridad en proyectos de código abierto. Por ejemplo, la infame vulnerabilidad Log4shell (CVE-2021-44228) no se descubrió durante 2649 días.
¡El ana lisis muestra que el 74% de las fallas de seguridad en realidad no se descubren durante al menos un año! Java y Ruby parecen tener la mayoría de los desafíos aquí, ya que la comunidad tarda ma s de 1000 días en encontrar y revelar vulnerabilidades. Nuestros sombreros [blancos] se van a la comunidad PHP/Composer, que supera ligeramente a los dema s.
La aguja en un techstack
Otros factores interesantes son que algunos de los diferentes tipos de debilidad (CWE) parecen ser ma s difíciles de encontrar y revelar, lo que en realidad contradice la ley de Linus. Los tipos de debilidad CWE-400 (Consumo de recursos no controlado) y CWE-502 (Deserialización de datos no confiables) generalmente no esta n localizados en una sola función o pueden aparecer como lógica prevista en la aplicación. En otras palabras, no se puede considerar “un error superficial”.
También parece que la comunidad de desarrolladores es un poco mejor para encontrar CWE-20 (Validación de entrada incorrecta), donde la falla la mayoría de las veces son solo unas pocas líneas de código en una sola función.
Resuelva las vulnerabilidades con una remediación poderosa
¿Por qué importa esto? Como consumidores de código abierto, y eso es casi todas las empresas del mundo, el problema de las vulnerabilidades en el código abierto es importante. Los datos nos dicen que no podemos confiar plenamente en la Ley de Linus, no porque el código abierto sea menos seguro que otro software, sino porque no todos los errores son superficiales .
Afortunadamente, existen herramientas poderosas para realizar ana lisis a escala de muchos proyectos de código abierto a la vez. Ha habido [ los piratas informa ticos del caballero blanco divulgan 1000 ] de vulnerabilidades a la vez utilizando estos métodos. Sería ingenuo no asumir que las organizaciones e individuos malintencionados hacen lo mismo. Como ecosistema que sienta las bases para nuestro mundo centrado en el software, la comunidad debe mejorar significativamente su capacidad para encontrar, divulgar y corregir fallas de seguridad en código abierto.
El año pasado, Google comprometió $ 10 mil millones a un fondo de código abierto para ayudar a asegurar el código abierto con un rol de curador específico para trabajar junto con los mantenedores con esfuerzos de seguridad específicos.
Adema s, Debricked ayuda a las empresas a hacer que estas vulnerabilidades sean procesables al escanear todo su software, cada rama, cada impulso y cada compromiso, en busca de nuevas vulnerabilidades (de código abierto). Debricked incluso escanea continuamente todas sus confirmaciones anteriores en busca de cada nueva vulnerabilidad, para asegurarse de que brinden información actualizada, precisa y procesable sobre el código abierto que consume. Debricked incluso ayuda a los desarrolladores a corregir sus fallas de seguridad con solicitudes de extracción automatizadas que no causara n un infierno de dependencia; ¡con buena pinta!
La verdad esta en los datos
Entonces, sabiendo todo esto, ¿cua l es la mejor manera de proteger tu proyecto o empresa contra las vulnerabilidades de código abierto? Como hemos visto en el caso de Log4j y Spring4shell, así como en los números, nunca podemos confiar realmente en que la comunidad encontrara y solucionara todos los riesgos. Existe una buena posibilidad de que haya montones, montones de vulnerabilidades no descubiertas y no reveladas en su código hoy, y no hay mucho que pueda hacer al respecto.
Según Debricked, la mejor manera de mitigar esto es implementando un escaneo continuo de vulnerabilidades en su SDLC. Al escanear automa ticamente cada vez que se presiona el código, en combinación con la base de datos de vulnerabilidades impulsada por el aprendizaje automa tico . Esto asegura que esté actualizado en tiempo real, conocera las nuevas vulnerabilidades antes que nadie. Tan pronto como haya una solución, puede generar una solicitud de extracción de reparación automa ticamente o resolverla manualmente con la ayuda de Debricked. Actualmente, Debricked ofrece remediación para JavaScript y Go, y pronto habra ma s compatibilidad con idiomas.
FUENTE: THN