![\"Vulnerabilidades](\"https:\/\/thehackernews.com\/new-images\/img\/b\/R29vZ2xl\/AVvXsEhHCMnqhwqPtQNSBXsZfmX7LEVj5u6v9J0m0PEJfwCxouhiIhao2Vs5MVncWuJ98NuxpWT7NguZoYl9dp9C4CsQNISQjl1ik3-HeBH_0aR7VPGsot16xib61mh4OHw6O8pbWPihBxdOnhJUpQ7H8hm9OS6DpuBY_aUAr7qYoai0rNSCjr6TtjWFr_JO\/s728-e1000\/open-source-hacking.jpg\" "\\"Vulnerabilidades")
<\/div>\nLinus Torvalds, el creador de Linux y Git, tiene su propia ley en el desarrollo de software, y dice as\u00ed: “dados suficientes globos oculares, todos los errores son superficiales<\/em>.” Esta frase pone el dedo en el principio mismo del c\u00f3digo abierto: cuanto m\u00e1s, mejor: si el c\u00f3digo est\u00e1 f\u00e1cilmente disponible para que cualquiera y todos corrijan errores, es bastante seguro. Pero, \u00bflo es? \u00bfO es el dicho “todos los errores son superficiales” solo es cierto para poco profundo<\/em> errores y no los que se encuentran m\u00e1s profundo? Resulta que las fallas de seguridad en el c\u00f3digo abierto pueden ser m\u00e1s dif\u00edciles de encontrar de lo que pens\u00e1bamos. Emil W\u00e5reus, responsable de I+D de desmantelado<\/a>, se encarg\u00f3 de profundizar en el desempe\u00f1o de la comunidad. Como cient\u00edfico de datos que es, por supuesto, pregunt\u00f3 a los datos: qu\u00e9 tan buena es la comunidad de c\u00f3digo abierto para encontrar vulnerabilidades de manera oportuna<\/em>?<\/p>\n La b\u00fasqueda de vulnerabilidades de c\u00f3digo abierto generalmente la realizan los mantenedores del proyecto de c\u00f3digo abierto, los usuarios, los auditores o los investigadores de seguridad externos. Pero a pesar de que estos grandes arque\u00f3logos del c\u00f3digo ayudaron a proteger nuestro mundo, la comunidad a\u00fan lucha por encontrar fallas de seguridad. <\/p>\n En promedio, se necesita m\u00e1s de 800 d\u00edas<\/em> para descubrir una falla de seguridad en proyectos de c\u00f3digo abierto. Por ejemplo, la infame vulnerabilidad Log4shell (CVE-2021-44228) no se descubri\u00f3 durante 2649 d\u00edas. <\/p>\n \u00a1El an\u00e1lisis muestra que el 74% de las fallas de seguridad en realidad no se descubren durante al menos un a\u00f1o! Java y Ruby parecen tener la mayor\u00eda de los desaf\u00edos aqu\u00ed, ya que la comunidad tarda m\u00e1s de 1000 d\u00edas en encontrar y revelar vulnerabilidades. Nuestro [white] Felicitaciones a la comunidad PHP\/Composer, que supera ligeramente a los dem\u00e1s. <\/p>\n Otros factores interesantes son que algunos de los diferentes tipos de debilidad (CWE) parecen ser m\u00e1s dif\u00edciles 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\u00f3n de datos no confiables) generalmente no est\u00e1n localizados en una sola funci\u00f3n o pueden aparecer como l\u00f3gica prevista en la aplicaci\u00f3n. En otras palabras, no se puede considerar “un error superficial”. <\/p>\n Tambi\u00e9n parece que la comunidad de desarrolladores es un poco mejor para encontrar CWE-20 (Validaci\u00f3n de entrada incorrecta), donde la falla la mayor\u00eda de las veces son solo unas pocas l\u00edneas de c\u00f3digo en una sola funci\u00f3n. <\/p>\n \u00bfPor qu\u00e9 importa esto? Como consumidores de c\u00f3digo abierto, y eso es casi todas las empresas del mundo, el problema de las vulnerabilidades en el c\u00f3digo abierto es importante. Los datos nos dicen que no podemos confiar plenamente en la Ley de Linus, no porque el c\u00f3digo abierto sea menos seguro que otro software, sino porque no todos los errores son superficiales<\/strong>.<\/p>\n Afortunadamente, existen herramientas poderosas para realizar an\u00e1lisis a escala de muchos proyectos de c\u00f3digo abierto a la vez. Ha habido [white knight hackers disclose 1000’s<\/a>] de vulnerabilidades a la vez utilizando estos m\u00e9todos. Ser\u00eda 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\u00f3digo abierto. <\/p>\n El a\u00f1o pasado, Google comprometi\u00f3 $ 10 mil millones<\/a> a un fondo de c\u00f3digo abierto para ayudar a asegurar el c\u00f3digo abierto con un rol de curador espec\u00edfico para trabajar junto con los mantenedores con esfuerzos de seguridad espec\u00edficos. <\/p>\n Adem\u00e1s, 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\u00f3digo abierto). Debricked incluso escanea continuamente todas sus confirmaciones anteriores en busca de cada nueva vulnerabilidad, para asegurarse de que brinden informaci\u00f3n actualizada, precisa y procesable sobre el c\u00f3digo abierto que consume. Debricked incluso ayuda a los desarrolladores a corregir sus fallas de seguridad con solicitudes de extracci\u00f3n automatizadas que no causar\u00e1n un infierno de dependencia; \u00a1con buena pinta! <\/p>\n Entonces, sabiendo todo esto, \u00bfcu\u00e1l es la mejor manera de proteger tu proyecto o empresa contra las vulnerabilidades de c\u00f3digo abierto? Como hemos visto en el caso de Log4j y Spring4shell, as\u00ed como en los n\u00fameros, nunca podemos confiar realmente en que la comunidad encontrar\u00e1 y solucionar\u00e1 todos los riesgos. Existe una buena posibilidad de que haya montones y montones de vulnerabilidades no descubiertas y no reveladas en su c\u00f3digo hoy, y no hay mucho que pueda hacer al respecto. <\/p>\n Seg\u00fan Debricked, la mejor manera de mitigar esto es implementando un escaneo continuo de vulnerabilidades en su SDLC. Al escanear autom\u00e1ticamente en cada pulsaci\u00f3n de c\u00f3digo, en combinaci\u00f3n con el aprendizaje autom\u00e1tico base de datos de vulnerabilidad<\/a>. Esto asegura que est\u00e9 actualizado en tiempo real, conocer\u00e1 las nuevas vulnerabilidades antes que nadie. Tan pronto como haya una soluci\u00f3n, puede generar una Arreglar solicitud de extracci\u00f3n<\/a> autom\u00e1ticamente o resolverlo manualmente con la ayuda de Debricked. Actualmente, Debricked ofrece remediaci\u00f3n para JavaScript y Go, y pronto habr\u00e1 m\u00e1s compatibilidad con idiomas. <\/em><\/p>\n <\/p>\n<\/div>\nLa emoci\u00f3n de la caza (vulnerabilidad)<\/strong><\/h2>\n
![\"Vulnerabilidades](\"https:\/\/teknomers.com\/es\/wp-content\/uploads\/2022\/11\/Codigo-abierto-de-los-ultimos-anos-Vulnerabilidades-del-manana.jpg\" "\\"Vulnerabilidades")
<\/div>\nLa aguja en un techstack<\/strong><\/h2>\n
![\"Vulnerabilidades](\"https:\/\/thehackernews.com\/new-images\/img\/b\/R29vZ2xl\/AVvXsEjMcHcgVAMCZdOLqkgBI2vwxfxloDUpyM00TN6hWNXm2XuP6xMEA6rxvm6SSzpLbxnWheflWn2NzzpG28KssHYhTkxqvgPCreYfJUptqQ466Jvgjav1oC_3pRbCDqLGVNtbUmUGhmdO_mv8yRBolaXWeQr91wJXBpvD3XjYa4h945ZbgYI8puChOJYh\/s728-e1000\/bugs.jpg\" "\\"Vulnerabilidades")
<\/div>\nResuelva las vulnerabilidades con una remediaci\u00f3n poderosa <\/strong><\/h2>\n
La verdad est\u00e1 en los datos<\/h2>\n