{"id":32024,"date":"2026-04-20T17:10:38","date_gmt":"2026-04-20T15:10:38","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=32024"},"modified":"2026-04-20T17:10:38","modified_gmt":"2026-04-20T15:10:38","slug":"managing-open-source-vulnerabilities","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/managing-open-source-vulnerabilities\/32024\/","title":{"rendered":"Arquitectura de gesti\u00f3n de vulnerabilidades de c\u00f3digo abierto"},"content":{"rendered":"<p>Como ya hablamos <a href=\"https:\/\/www.kaspersky.es\/blog\/open-source-vulnerabilities-in-ai-era\/32017\/\" target=\"_blank\" rel=\"noopener\">en una publicaci\u00f3n anterior<\/a>, el desarrollo de software moderno es pr\u00e1cticamente impensable sin el uso de componentes de c\u00f3digo abierto. Pero en los \u00faltimos a\u00f1os, los riesgos asociados se han vuelto cada vez m\u00e1s diversos, complejos y numerosos. En primer lugar, las vulnerabilidades afectan a la infraestructura y al c\u00f3digo de una empresa m\u00e1s r\u00e1pido de lo que tardan en solucionarse; en segundo lugar, los datos son poco fiables e incompletos; y, en tercer lugar, el malware puede estar acechando en componentes populares, por lo que no basta con limitarse a comprobar los n\u00fameros de versi\u00f3n y enviar tickets de correcci\u00f3n al equipo de TI. La gesti\u00f3n de vulnerabilidades debe ampliarse para abarcar las pol\u00edticas de descarga de software, las medidas de seguridad para los asistentes de IA y todo el proceso de compilaci\u00f3n de software.<\/p>\n<h1>Un grupo fiable de componentes de c\u00f3digo abierto<\/h1>\n<p>La parte principal de la soluci\u00f3n es evitar el uso de c\u00f3digos vulnerables y maliciosos. Se deben implementar las siguientes medidas:<\/p>\n<ul>\n<li>Tener un repositorio interno de artefactos. La \u00fanica fuente de componentes para el desarrollo interno debe ser un repositorio unificado en el que se admitan los componentes solo despu\u00e9s de una serie de comprobaciones.<\/li>\n<li>Realizar un riguroso an\u00e1lisis de los componentes. Estos incluyen verificaciones de versiones conocidas del componente, versiones conocidas vulnerables y maliciosas, fecha de publicaci\u00f3n, historial de actividad y la reputaci\u00f3n del paquete y sus autores. Es obligatorio analizar todo el contenido del paquete, incluidas las instrucciones de compilaci\u00f3n, los casos de prueba y otros datos auxiliares. Para filtrar el registro durante la ingesta, utilice analizadores de c\u00f3digo abierto especializados o una <a href=\"https:\/\/www.kaspersky.es\/enterprise-security\/cloud-workload-security?icid=es_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team_______bc988988801654bb\" target=\"_blank\" rel=\"noopener\">soluci\u00f3n integral de seguridad de la carga de trabajo en la nube<\/a>.<\/li>\n<li>Ejecutar la fijaci\u00f3n de dependencias. Los procesos de compilaci\u00f3n, las herramientas de IA y los desarrolladores no deben usar plantillas (como \u201cm\u00e1s reciente\u201d) al especificar versiones. Las compilaciones de proyectos deben basarse en versiones verificadas. Al mismo tiempo, las dependencias fijadas deben actualizarse regularmente a las versiones m\u00e1s recientes y verificadas que mantengan la compatibilidad y est\u00e9n libres de vulnerabilidades conocidas. Esto reduce significativamente el riesgo de <a href=\"https:\/\/www.kaspersky.com\/blog\/npm-packages-trojanized\/54280\/\" target=\"_blank\" rel=\"noopener nofollow\">ataques a la cadena de suministro al vulnerar un paquete conocido<\/a>.<\/li>\n<\/ul>\n<h1>Mejora de los datos de vulnerabilidad<\/h1>\n<p>Para identificar las vulnerabilidades de manera m\u00e1s eficaz y <a href=\"https:\/\/www.kaspersky.es\/blog\/cvss-rbvm-vulnerability-management\/31177\/\" target=\"_blank\" rel=\"noopener\">priorizarlas<\/a> correctamente, una organizaci\u00f3n debe establecer varios procesos de TI y de seguridad:<\/p>\n<ul>\n<li>Enriquecimiento de datos de vulnerabilidad. Seg\u00fan las necesidades de la organizaci\u00f3n, esto es necesario para enriquecer la informaci\u00f3n combinando datos de NVD, EUVD, BDU, GitHub Advisory Database y osv.dev, o para comprar una fuente de inteligencia de vulnerabilidad comercial donde los datos ya est\u00e1n a\u00f1adidos y enriquecidos. En cualquier caso, vale la pena controlar adem\u00e1s las fuentes de inteligencia de amenazas para rastrear las tendencias de aprovechamiento en el mundo real y obtener una idea del perfil de los atacantes que apuntan a vulnerabilidades espec\u00edficas. Kaspersky proporciona una <a href=\"https:\/\/www.kaspersky.com\/open-source-feed?icid=es_kdailyplacehold_acq_ona_smm__onl_b2b_blo_wpplaceholder________475192470b0a9afc\" target=\"_blank\" rel=\"noopener nofollow\">fuente de datos especializada espec\u00edficamente centrada en componentes de c\u00f3digo abierto<\/a>.<\/li>\n<li>An\u00e1lisis en profundidad de la composici\u00f3n del software. Las herramientas de an\u00e1lisis de composici\u00f3n de software (SCA) especializadas permiten la navegaci\u00f3n correcta de la cadena de dependencias en c\u00f3digo abierto para hacer un inventario completo de las bibliotecas que se utilizan y descubrir componentes desactualizados o no compatibles. Los datos sobre componentes en buen estado tambi\u00e9n son \u00fatiles para enriquecer el registro de artefactos.<\/li>\n<li>Identificaci\u00f3n de software abandonado. Incluso si un componente no es formalmente vulnerable y no se ha declarado oficialmente no compatible, el proceso de an\u00e1lisis deber\u00eda marcar los componentes que no han recibido actualizaciones durante m\u00e1s de un a\u00f1o. Estos garantizan un an\u00e1lisis por separado y un posible reemplazo, al igual que los componentes EOL.<\/li>\n<\/ul>\n<h1>Protecci\u00f3n del c\u00f3digo de IA y de los agentes de IA<\/h1>\n<p>Las actividades de los sistemas de IA utilizados en la codificaci\u00f3n deben estar envueltas en un conjunto integral de medidas de seguridad, desde el filtrado de datos de entrada hasta la formaci\u00f3n del usuario:<\/p>\n<ul>\n<li>Restricciones sobre las recomendaciones de dependencias. Configure el entorno de desarrollo para asegurarse de que los asistentes y agentes de IA solo puedan hacer referencia a componentes y bibliotecas del registro de artefactos de confianza. Si no contienen las herramientas correctas, el modelo deber\u00eda activar una solicitud para incluir la dependencia en el registro, en lugar de extraer algo de PyPI que simplemente coincida con la descripci\u00f3n.<\/li>\n<li>Filtro de las salidas del modelo. A pesar de estas restricciones, todo lo generado por el modelo tambi\u00e9n debe verificarse para garantizar que el c\u00f3digo de IA no contenga dependencias desactualizadas, no compatibles, vulnerables o inventadas. Esta verificaci\u00f3n debe integrarse directamente en el proceso de aceptaci\u00f3n del c\u00f3digo o en la etapa de preparaci\u00f3n de la compilaci\u00f3n. No reemplaza el proceso de an\u00e1lisis est\u00e1tico tradicional: las herramientas SAST a\u00fan deben estar integradas en el flujo de CI\/CD.<\/li>\n<li>Formaci\u00f3n de desarrolladores. Los equipos de TI y de seguridad deben estar \u00edntimamente familiarizados con las caracter\u00edsticas de los sistemas de IA, sus principios operativos y los errores comunes. Para lograr esto, el personal debe completar un <a href=\"https:\/\/xtraining.kaspersky.com\/courses\/large-language-models-security\/?icid=es_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team___xtraining____b964717c8eb83c0c\" target=\"_blank\" rel=\"noopener\">curso de formaci\u00f3n especializado<\/a> adaptado a sus funciones espec\u00edficas.<\/li>\n<\/ul>\n<h1>Eliminaci\u00f3n sistem\u00e1tica de componentes EOL<\/h1>\n<p>Si los sistemas de una empresa utilizan componentes de c\u00f3digo abierto desactualizados, se debe adoptar un enfoque sistem\u00e1tico y congruente para abordar sus vulnerabilidades. Hay tres m\u00e9todos principales para hacerlo:<\/p>\n<ul>\n<li>Migraci\u00f3n. Este es el m\u00e9todo m\u00e1s complejo y costoso desde el punto de vista organizativo, que implica el reemplazo total de un componente seguido de la adaptaci\u00f3n, reescritura o reemplazo de las aplicaciones creadas sobre \u00e9l. Decidirse por una migraci\u00f3n es especialmente abrumador cuando exige una revisi\u00f3n masiva de todo el c\u00f3digo interno. Esto afecta con frecuencia a los componentes principales: es imposible migrar fuera de Node.js 14 o Python 2 f\u00e1cilmente.<\/li>\n<li>Soporte a largo plazo (LTS). Existe un mercado de servicios de soporte dedicado para proyectos heredados a gran escala. A veces, esto implica una bifurcaci\u00f3n del sistema heredado mantenido por desarrolladores externos; en otros casos, los equipos especializados respaldan los parches que corrigen vulnerabilidades espec\u00edficas en versiones anteriores no compatibles. La transici\u00f3n a LTS generalmente requiere costes de soporte continuos, pero esto a\u00fan puede ser m\u00e1s rentable que una migraci\u00f3n completa en muchos casos.<\/li>\n<li>Controles compensatorios. Seg\u00fan los resultados de un an\u00e1lisis detallado, se puede establecer un <a href=\"https:\/\/www.kaspersky.com\/blog\/legacy-it-update-troubles-and-mitigations\/48692\/\" target=\"_blank\" rel=\"noopener nofollow\">conjunto de medidas de seguridad integrales para mitigar el riesgo de aprovechamiento de las vulnerabilidades dentro del producto heredado<\/a>. Tanto la eficacia como la viabilidad econ\u00f3mica de este enfoque dependen de la funci\u00f3n del software dentro de la organizaci\u00f3n.<\/li>\n<\/ul>\n<p>La seguridad, la TI y la empresa deben trabajar juntos para escoger una de estas tres rutas para cada EOL documentado o componente abandonado, y reflejar la elecci\u00f3n realizada en los registros de activos y SBOM de la empresa.<\/p>\n<h1>Gesti\u00f3n de vulnerabilidades de c\u00f3digo abierto basada en riesgos<\/h1>\n<p>Todas las medidas enumeradas anteriormente reducen el volumen de software y componentes vulnerables que entran en la organizaci\u00f3n y simplifican la detecci\u00f3n y reparaci\u00f3n de fallos. A pesar de esto, es imposible eliminar todos los defectos: el n\u00famero de aplicaciones y componentes simplemente est\u00e1 creciendo demasiado r\u00e1pido.<\/p>\n<p>Por lo tanto, <a href=\"https:\/\/www.kaspersky.es\/blog\/cvss-rbvm-vulnerability-management\/31177\/\" target=\"_blank\" rel=\"noopener\">priorizar las vulnerabilidades seg\u00fan el riesgo del mundo real<\/a> sigue siendo esencial. El modelo de evaluaci\u00f3n de riesgos debe ampliarse para tener en cuenta las caracter\u00edsticas del c\u00f3digo abierto, respondiendo a las siguientes preguntas:<\/p>\n<ul>\n<li>\u00bfSe ejecuta realmente la rama del c\u00f3digo vulnerable en el entorno de la organizaci\u00f3n? Se debe realizar un an\u00e1lisis de accesibilidad para las vulnerabilidades descubiertas. Muchos fragmentos de c\u00f3digo defectuosos nunca se ejecutan realmente dentro de la implementaci\u00f3n espec\u00edfica de la organizaci\u00f3n, lo que hace que la vulnerabilidad sea imposible de explotar. Ciertas soluciones SCA pueden realizar este an\u00e1lisis. Este mismo proceso permite evaluar un escenario alternativo: \u00bfqu\u00e9 sucede si los procedimientos o componentes vulnerables se eliminan por completo del proyecto? A veces, este m\u00e9todo de reparaci\u00f3n resulta sorprendentemente indoloro.<\/li>\n<li>\u00bfSe est\u00e1 aprovechando el defecto en ataques del mundo real? \u00bfHay una PoC disponible? Las respuestas a estas preguntas son parte de marcos de priorizaci\u00f3n est\u00e1ndar como EPSS, pero el seguimiento debe realizarse a trav\u00e9s de un conjunto mucho m\u00e1s amplio de fuentes de inteligencia.<\/li>\n<li>\u00bfSe ha denunciado actividad cibercriminal en este registro de dependencia o en componentes relacionados y similares? Estos son factores adicionales para la priorizaci\u00f3n.<\/li>\n<\/ul>\n<p>Tener en cuenta estos factores permite al equipo asignar recursos de manera efectiva y remediar primero los defectos m\u00e1s peligrosos.<\/p>\n<h1>La transparencia est\u00e1 de moda<\/h1>\n<p>El nivel de exigencia en seguridad para el software de c\u00f3digo abierto seguir\u00e1 subiendo. Las empresas que desarrollan aplicaciones, incluso para uso interno, se enfrentar\u00e1n a presiones regulatorias que exigen ciberseguridad documentada y verificable dentro de sus sistemas. Seg\u00fan las <a href=\"https:\/\/www.sonatype.com\/state-of-the-software-supply-chain\/introduction\" target=\"_blank\" rel=\"noopener nofollow\">estimaciones de los expertos de Sonatype<\/a>, el 90\u00a0% de las empresas a nivel mundial ya se encuentran bajo uno o m\u00e1s requisitos para proporcionar evidencia de la fiabilidad del software que utilizan; por lo tanto, los expertos consideran la transparencia \u201cla moneda de cambio de la seguridad en la cadena de suministro de software\u201d.<\/p>\n<p>Al controlar el uso de aplicaciones y componentes de c\u00f3digo abierto, enriquecer la inteligencia de amenazas y supervisar estrictamente los sistemas de desarrollo impulsados por la IA, las organizaciones pueden introducir las innovaciones que la empresa anhela, todo mientras se eliminan los altos est\u00e1ndares establecidos por los reguladores y clientes.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"mdr\"><input type=\"hidden\" class=\"placeholder_for_banner\" data-cat_id=\"mdr\" value=\"29235\">\n","protected":false},"excerpt":{"rendered":"<p>C\u00f3mo gestionar las vulnerabilidades al desarrollar o usar software de c\u00f3digo abierto.<\/p>\n","protected":false},"author":2722,"featured_media":32025,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2202,2754],"tags":[3767,2798,3714,3340,1307,875,784],"class_list":{"0":"post-32024","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-agentes-de-ia","10":"tag-codigo-abierto","11":"tag-cvss","12":"tag-estrategia","13":"tag-ia","14":"tag-parches","15":"tag-vulnerabilidades"},"hreflang":[{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/managing-open-source-vulnerabilities\/32024\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/managing-open-source-vulnerabilities\/30368\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/25418\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/managing-open-source-vulnerabilities\/30215\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/managing-open-source-vulnerabilities\/30614\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/managing-open-source-vulnerabilities\/41643\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/managing-open-source-vulnerabilities\/14472\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/55554\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/managing-open-source-vulnerabilities\/24913\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/managing-open-source-vulnerabilities\/33403\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/managing-open-source-vulnerabilities\/30484\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/managing-open-source-vulnerabilities\/36103\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/managing-open-source-vulnerabilities\/35755\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.es\/blog\/tag\/vulnerabilidades\/","name":"vulnerabilidades"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/32024","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=32024"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/32024\/revisions"}],"predecessor-version":[{"id":32027,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/32024\/revisions\/32027"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media\/32025"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media?parent=32024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/categories?post=32024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/tags?post=32024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}