Linus Torvalds, el creador de Linux y Git, tiene su propia ley en el desarrollo de software, y dice así: “dados suficientes globos oculares, todos los errores son superficiales.” Esta frase pone el dedo en el principio mismo del código abierto: cuanto más, mejor: si el código está fácilmente disponible para que cualquiera y todos corrijan errores, es bastante seguro. Pero, ¿lo es? ¿O es el dicho “todos los errores son superficiales” solo es cierto para poco profundo errores y no los que se encuentran más profundo? Resulta que las fallas de seguridad en el código abierto pueden ser más difíciles de encontrar de lo que pensábamos. Emil Wåreus, responsable de I+D de desmantelado, se encargó de profundizar en el desempeño 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 necesita más de 800 días para 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 aná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 más de 1000 días en encontrar y revelar vulnerabilidades. Nuestro [white] Felicitaciones a la comunidad PHP/Composer, que supera ligeramente a los demás.
La aguja en un techstack
Otros factores interesantes son que algunos de los diferentes tipos de debilidad (CWE) parecen ser má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 está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 análisis a escala de muchos proyectos de código abierto a la vez. Ha habido [white knight hackers disclose 1000’s] 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.
Ademá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 causarán un infierno de dependencia; ¡con buena pinta!
La verdad está en los datos
Entonces, sabiendo todo esto, ¿cuá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 encontrará y solucionará todos los riesgos. Existe una buena posibilidad de que haya montones y 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 automáticamente en cada pulsación de código, en combinación con el aprendizaje automático base de datos de vulnerabilidad. Esto asegura que esté actualizado en tiempo real, conocerá las nuevas vulnerabilidades antes que nadie. Tan pronto como haya una solución, puede generar una Arreglar solicitud de extracción automáticamente o resolverlo manualmente con la ayuda de Debricked. Actualmente, Debricked ofrece remediación para JavaScript y Go, y pronto habrá más compatibilidad con idiomas.