{"id":28706,"date":"2023-04-20T14:18:11","date_gmt":"2023-04-20T12:18:11","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=28706"},"modified":"2023-04-20T14:18:11","modified_gmt":"2023-04-20T12:18:11","slug":"open-source-top-10-risks","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/open-source-top-10-risks\/28706\/","title":{"rendered":"El c\u00f3digo abierto: los 10 riesgos principales para las empresas"},"content":{"rendered":"

Las empresas TI fueron las primeras en adoptar el c\u00f3digo abierto, despu\u00e9s, muchas grandes empresas siguieron su ejemplo. A fin de cuentas, la capacidad de reutilizar y modificar el c\u00f3digo de forma independiente, as\u00ed como corregir errores, estimula la r\u00e1pida innovaci\u00f3n y la reducci\u00f3n de costes<\/a>.<\/p>\n

Pero el c\u00f3digo abierto tambi\u00e9n presenta algunas caracter\u00edsticas negativas inherentes, debido a las responsabilidades difusas a la hora de crear y mantener el c\u00f3digo. Endor Labs, con la ayuda de m\u00e1s de 20 directores de seguridad de la informaci\u00f3n y de tecnolog\u00eda de grandes empresas TI, ha llevado a cabo un an\u00e1lisis sistem\u00e1tico para generar esta lista con los 10 riesgos principales<\/a> a los que se enfrentan.<\/p>\n

Las vulnerabilidades conocidas<\/h2>\n

El riesgo m\u00e1s importante que identificaron fue la presencia de vulnerabilidades tanto en el propio proyecto de c\u00f3digo abierto como en sus dependencias, es decir, los componentes externos de c\u00f3digo abierto utilizados en el proyecto. Estas vulnerabilidades en las dependencias pueden causar problemas graves para docenas de paquetes de software comercial, como fue el caso de la biblioteca Apache Log4j (CVE-2021-44228<\/a>).<\/p>\n

Medidas de seguridad<\/strong>: Analiza peri\u00f3dicamente tus aplicaciones en busca de vulnerabilidades conocidas, incluidas las vulnerabilidades en las dependencias directas e indirectas y aplica las correcciones disponibles cuanto antes. Para optimizar los recursos de la empresa, puedes dar prioridad a los parches en funci\u00f3n de la gravedad de una vulnerabilidad determinada y la probabilidad de su explotaci\u00f3n en el software que est\u00e1s utilizando.<\/p>\n

El compromiso de paquetes leg\u00edtimos<\/h2>\n

Dado que hasta el 80 % del c\u00f3digo del proyecto de c\u00f3digo abierto se hereda de otros proyectos en forma de las famosas dependencias, siempre existe la posibilidad de que los componentes de terceros utilizados en tu aplicaci\u00f3n se hayan infectado con un troyano. Esto puede suceder cuando el desarrollador de estos componentes ha sufrido un hackeo o se descubre que el sistema de distribuci\u00f3n de componentes, es decir, el administrador del paquete, contiene una vulnerabilidad que permite falsificarlo. En este caso, el c\u00f3digo malicioso de terceros aparece repentinamente dentro de tu aplicaci\u00f3n, que en la pr\u00e1ctica se suele utilizar para robar informaci\u00f3n<\/a> o para varias estrategias de enriquecimiento il\u00edcito (spam, estafas de adware, miner\u00eda<\/a>).<\/p>\n

Medidas de seguridad:<\/strong> Actualmente no existe una metodolog\u00eda asentada para protegerse contra esta amenaza, por lo que necesitar\u00edas una combinaci\u00f3n de medidas: sistemas manuales y autom\u00e1ticos para analizar el c\u00f3digo fuente y monitorizar los repositorios<\/a>, almacenamiento local de versiones de confianza de los componentes y el uso de la inteligencia de amenazas<\/a> para detectar estos ataques en sus primeras etapas, antes de que tengan tiempo de afectar a los paquetes utilizados en las aplicaciones de c\u00f3digo abierto de la empresa.<\/p>\n

El ataque de los \u201chom\u00f3nimos\u201d<\/h2>\n

Los atacantes crean paquetes con nombres que se asemejan a otros leg\u00edtimos o copian los de paquetes leg\u00edtimos escritos en otros lenguajes de programaci\u00f3n o publicados en otras plataformas de distribuci\u00f3n. Esto genera el riesgo de que tus desarrolladores de c\u00f3digo abierto integren un paquete malicioso \u201cdel mismo nombre\u201d en lugar del original.<\/p>\n

Medidas de seguridad:<\/strong> Pide a los desarrolladores que est\u00e9n atentos. Adem\u00e1s, deben adquirir la rutina de verificar el c\u00f3digo fuente de los paquetes antes de su uso en busca de peculiaridades como fragmentos cifrados en el c\u00f3digo, secuestro de funciones y similares. Tambi\u00e9n es recomendable comprobar las firmas digitales de los paquetes (si las hay).<\/p>\n

El c\u00f3digo sin soporte<\/h2>\n

Los desarrolladores de componentes, paquetes y aplicaciones de c\u00f3digo abierto pueden retirar el soporte en cualquier momento y por cualquier motivo. Esto pasa a menudo en los paquetes peque\u00f1os desarrollados por 1 o 2 personas. Si sucede, no hay nadie que actualice el paquete para que sea compatible con las nuevas tecnolog\u00edas o elimine los riesgos de seguridad de la informaci\u00f3n.<\/p>\n

Medidas de seguridad:<\/strong> eval\u00faa el nivel de madurez del proyecto y las perspectivas de desarrollo\/soporte antes de integrarlo en tus procesos comerciales y el propio c\u00f3digo. Presta atenci\u00f3n a la cantidad de desarrolladores que mantienen el proyecto y la frecuencia de los lanzamientos. Comprueba las versiones de soporte a largo plazo (LTS por sus siglas en ingl\u00e9s) y cu\u00e1ndo salieron. Sin embargo, en el caso de algunos proyectos estables, es bastante normal que los lanzamientos sean poco frecuentes y solo solucionen errores.<\/p>\n

El software obsoleto<\/h2>\n

El uso de versiones antiguas de componentes en proyectos hace que la aplicaci\u00f3n de los parches sea mucho m\u00e1s dif\u00edcil. Este problema resulta especialmente grave en el caso del riesgo n\u00famero uno: vulnerabilidades en los componentes. Por lo general, surge un problema con las dependencias obsoletas cuando una nueva versi\u00f3n de un componente difiere significativamente de las iteraciones anteriores en la sintaxis o sem\u00e1ntica. En esta situaci\u00f3n, una versi\u00f3n desactualizada puede permanecer en uso durante muchos a\u00f1os sin actualizaciones de seguridad.<\/p>\n

Medidas de seguridad<\/strong>: Concede tiempo a los desarrolladores para trabajar con dependencias, incluida la refactorizaci\u00f3n del c\u00f3digo para actualizar a las \u00faltimas versiones de los componentes en uso.<\/p>\n

Las dependencias sin rastrear<\/h2>\n

Dado que casi todas las aplicaciones usan componentes de terceros, que a su vez usan otros componentes de terceros, a menudo los desarrolladores de la aplicaci\u00f3n principal desconocen la presencia de un componente en particular en su c\u00f3digo. En este caso, no se comprueban todos los dem\u00e1s riesgos de la lista. El estado de las actualizaciones, vulnerabilidades y dem\u00e1s simplemente se desconoce.<\/p>\n

Medidas de seguridad:<\/strong> Recopila una lista de materiales de software (SBOM por sus siglas en ingl\u00e9s) detallada con el uso de herramientas de escaneo que pueden detectar incluso las dependencias que se usan sin un administrador de paquetes.<\/p>\n

Riesgos regulatorios y de licencias<\/h2>\n

A pesar de ser de c\u00f3digo abierto, cada aplicaci\u00f3n y paquete de c\u00f3digo abierto viene con su propia licencia de uso. Los riesgos surgen si la licencia resulta ser incompatible con el uso de la aplicaci\u00f3n para el prop\u00f3sito previsto o si las licencias de algunos componentes de la aplicaci\u00f3n son incompatibles entre s\u00ed. Tambi\u00e9n puede pasar que uno o m\u00e1s componentes de la dependencia infrinjan las leyes aplicables o los requisitos reglamentarios impuestos en la empresa.<\/p>\n

Medidas de seguridad:<\/strong> Las herramientas de escaneo de c\u00f3digo y SBOM ya mencionadas deben usarse para realizar un seguimiento de las licencias y los requisitos de licencia aplicables a las aplicaciones y componentes de c\u00f3digo abierto utilizados dentro de la empresa. Por tanto, tiene sentido trabajar con el departamento legal para desarrollar una lista de licencias est\u00e1ndar aceptables para la empresa, detallando su compatibilidad con el prop\u00f3sito del software utilizado. El software con licencias incompatibles o sin ning\u00fan tipo de licencia debe eliminarse.<\/p>\n

El software inmaduro<\/h2>\n

Utilizar componentes desarrollados por un equipo que carece de madurez conlleva una serie de inconvenientes y riesgos. Los problemas asociados con el software inmaduro van desde una documentaci\u00f3n de c\u00f3digo insuficiente o inexacta hasta un funcionamiento inestable y propenso a errores y a la ausencia de un conjunto de pruebas para las pruebas de regresi\u00f3n. Adem\u00e1s, hay m\u00e1s probabilidades de que el c\u00f3digo inmaduro albergue vulnerabilidades cr\u00edticas. Todo esto hace que el uso de software inmaduro resulte poco pr\u00e1ctico y aumenta tanto los costes involucrados como los riesgos de situaciones cr\u00edticas y tiempos de inactividad.<\/p>\n

Medidas de seguridad:<\/strong> Antes de implementar una aplicaci\u00f3n o componente, aseg\u00farate de que los desarrolladores est\u00e9n implementando las mejores pr\u00e1cticas del momento: tener documentaci\u00f3n completa y actualizada, segmentaciones CI\/CD para pruebas de regresi\u00f3n, as\u00ed como informaci\u00f3n detallada sobre la cobertura de la prueba e incluso la cantidad de paquetes que ya usa el componente.<\/p>\n

Los cambios sin aprobaci\u00f3n<\/h2>\n

Los componentes utilizados por una aplicaci\u00f3n pueden cambiar de forma completamente imperceptible para sus desarrolladores. Esta situaci\u00f3n puede tener lugar si los componentes se descargan de un servidor sin un control estricto de versiones y\/o a trav\u00e9s de canales de comunicaci\u00f3n no cifrados y no se verifican mediante hash<\/em> y firmas digitales. En este caso, el ensamblaje de la aplicaci\u00f3n te\u00f3ricamente puede producir un resultado diferente cada vez.<\/p>\n

Medidas de seguridad:<\/strong> S\u00e9 estricto con la aplicaci\u00f3n de pr\u00e1cticas de desarrollo seguras. Durante el desarrollo, utiliza identificadores de recursos que indiquen claramente la versi\u00f3n del componente. Adem\u00e1s, comprueba los componentes descargados mediante firmas digitales. Utiliza siempre protocolos de comunicaci\u00f3n seguros.<\/p>\n

Las dependencias demasiado grandes o demasiado peque\u00f1as<\/h2>\n

Actualmente, los desarrolladores pueden integrar un componente con solo tres l\u00edneas de c\u00f3digo. A su vez, es igualmente perjudicial cuando todo el componente consta de cuatro l\u00edneas de c\u00f3digo (muy peque\u00f1as) y cuando el c\u00f3digo que intentas usar es solo una de las miles de caracter\u00edsticas del componente, el resto de las cuales no se usan en la aplicaci\u00f3n de la empresa. En este caso, los desarrolladores tienen la carga de mantener otra dependencia m\u00e1s por el bien de una muy deficiente funcionalidad.<\/p>\n

Medidas de seguridad:<\/strong> Evita las dependencias con poca funcionalidad; desarrolla esta funcionalidad dentro de la aplicaci\u00f3n principal.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Las aplicaciones de c\u00f3digo abierto requieren una implementaci\u00f3n y un mantenimiento adecuados; de lo contrario, la empresa podr\u00eda enfrentarse a muchas amenazas. Estos son los riesgos principales.<\/p>\n","protected":false},"author":2722,"featured_media":28707,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2202,2754],"tags":[182,2798,1474,215,1312],"class_list":{"0":"post-28706","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-aplicaciones","10":"tag-codigo-abierto","11":"tag-desarrollo","12":"tag-empresas","13":"tag-riesgos"},"hreflang":[{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/open-source-top-10-risks\/28706\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/open-source-top-10-risks\/25497\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/open-source-top-10-risks\/20930\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/open-source-top-10-risks\/28106\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/open-source-top-10-risks\/25804\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/open-source-top-10-risks\/26221\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/open-source-top-10-risks\/35092\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/open-source-top-10-risks\/47875\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/open-source-top-10-risks\/20461\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/open-source-top-10-risks\/21153\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/open-source-top-10-risks\/30029\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/open-source-top-10-risks\/26124\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/open-source-top-10-risks\/31809\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/open-source-top-10-risks\/31496\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.es\/blog\/tag\/codigo-abierto\/","name":"c\u00f3digo abierto"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/28706","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/comments?post=28706"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/28706\/revisions"}],"predecessor-version":[{"id":28709,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/28706\/revisions\/28709"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media\/28707"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media?parent=28706"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/categories?post=28706"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/tags?post=28706"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}