{"id":31083,"date":"2025-06-25T09:29:19","date_gmt":"2025-06-25T07:29:19","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=31083"},"modified":"2025-06-25T09:29:19","modified_gmt":"2025-06-25T07:29:19","slug":"can-you-support-open-source-preliminary-assessment","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/can-you-support-open-source-preliminary-assessment\/31083\/","title":{"rendered":"C\u00f3mo escoger soluciones de c\u00f3digo abierto para tu organizaci\u00f3n"},"content":{"rendered":"

Seg\u00fan el informe del estado de c\u00f3digo abierto de 2025<\/a>, el 96\u00a0% de las empresas encuestadas utilizan aplicaciones de c\u00f3digo abierto. Debido a su amplia selecci\u00f3n, sus opciones de personalizaci\u00f3n y los costes nulos de las licencias, resultan muy atractivos.<\/p>\n

Sin embargo, m\u00e1s de la mitad de las empresas encuestadas se enfrentan a importantes desaf\u00edos con el mantenimiento continuo de las aplicaciones de c\u00f3digo abierto. Nada menos que el 63\u00a0% tiene dificultades para mantener las soluciones actualizadas y aplicar parches. Le siguen de cerca los problemas de ciberseguridad, el cumplimiento de la normativa y la presencia de las aplicaciones de c\u00f3digo abierto al final de su vida \u00fatil (EoL), lo que significa que ya no son compatibles.<\/p>\n

Entonces, \u00bfc\u00f3mo se puede minimizar la probabilidad de que surjan estos problemas y qu\u00e9 hay que tener en cuenta a la hora de elegir el software de c\u00f3digo abierto (OSS) para su implementaci\u00f3n?<\/p>\n

Las actualizaciones y los parches<\/h2>\n

Dado que la actualizaci\u00f3n oportuna del OSS (Software de C\u00f3digo Abierto por sus siglas en ingl\u00e9s) es el problema m\u00e1s generalizado, examina muy detenidamente los posibles candidatos para la adopci\u00f3n del OSS desde esta perspectiva. Es f\u00e1cil comprobar la frecuencia y el alcance de las actualizaciones, as\u00ed como su contenido, directamente en el repositorio p\u00fablico de la aplicaci\u00f3n. Presta atenci\u00f3n a c\u00f3mo de bien documentadas est\u00e1n las actualizaciones; qu\u00e9 tipos de problemas resuelven; qu\u00e9 funciones nuevas a\u00f1aden; con qu\u00e9 frecuencia se lanzan las correcciones menores unos d\u00edas o semanas despu\u00e9s de la versi\u00f3n principal; y con qu\u00e9 rapidez se cierran las solicitudes relacionadas con errores.<\/p>\n

Algunas herramientas est\u00e1ndar como Git Insights<\/a>, junto con servicios complementarios como Is it maintained?<\/a>, Repology<\/a> y Libraries.io<\/a>, pueden ayudarte a responder a estas preguntas. Libraries.io muestra inmediatamente qu\u00e9 dependencias obsoletas utiliza la versi\u00f3n actual.<\/p>\n

Presta especial atenci\u00f3n a las actualizaciones relacionadas con la seguridad. \u00bfSe lanzan por separado o se incluyen con las actualizaciones de funcionalidad? Normalmente, los desarrolladores escogen esta \u00faltima opci\u00f3n. En ese caso, debes saber cu\u00e1nto tiempo llevan esperando a ser lanzadas las actualizaciones de seguridad.<\/p>\n

Adem\u00e1s, eval\u00faa el nivel de complejidad del proceso de instalaci\u00f3n de actualizaciones. La documentaci\u00f3n y el soporte oficiales pueden ser un punto de partida, pero no son suficientes. Es probable que lo m\u00e1s \u00fatil en este caso sea revisar detenidamente los comentarios de la comunidad de usuarios.<\/p>\n

Todo esto te permitir\u00e1 comprender mejor cu\u00e1nto esfuerzo supondr\u00e1 el mantenimiento del producto. Deber\u00e1s asignar recursos internos para el soporte. No basta con solo asignar responsabilidades; se necesitar\u00e1n horas de trabajo dedicadas a estas tareas y otras relacionadas.<\/p>\n

Vulnerabilidades<\/h2>\n

Para predecir con exactitud la frecuencia con la que te enfrentar\u00e1s a los problemas de ciberseguridad, lo mejor es evaluar la cultura de ingenier\u00eda y la higiene de ciberseguridad del producto desde el principio. Si bien esto puede requerir mucho trabajo, puedes usar herramientas automatizadas para llevar a cabo un an\u00e1lisis inicial de alto nivel.<\/p>\n

Para los productos y paquetes populares, un buen enfoque es comprobar los resultados de evaluaciones heur\u00edsticas ya existentes de herramientas como OpenSSF Scorecard<\/a>. Proporciona una variedad de datos de la higiene de ciberseguridad, que abarcan desde la cantidad de vulnerabilidades sin parches y la presencia de pol\u00edticas de seguridad hasta el uso de fuzzing y la fijaci\u00f3n de dependencias.<\/p>\n

Adem\u00e1s, examina las bases de datos p\u00fablicas de las vulnerabilidades como NVD<\/a> y los avisos de GitHub<\/a> para conocer cu\u00e1ntos fallos se han descubierto en el proyecto, su criticidad y la rapidez con la que se solucionaron. Una gran cantidad de vulnerabilidades por s\u00ed misma puede indicar la popularidad del proyecto, y no siempre implica malas pr\u00e1cticas de desarrollo. Sin embargo, los tipos de defectos y la forma en que los desarrolladores han respondido a ellos es lo verdaderamente importante.<\/p>\n

Las dependencias y la cadena de suministro<\/h2>\n

Casi todos los proyectos de OSS dependen de componentes de c\u00f3digo abierto de terceros, que a menudo no est\u00e1n documentados. Estos componentes se actualizan seg\u00fan sus propios programas y pueden contener errores, vulnerabilidades e incluso c\u00f3digo malicioso. La cuesti\u00f3n clave aqu\u00ed es la rapidez con la que las actualizaciones de los componentes con parches llegan al proyecto que est\u00e1s considerando.<\/p>\n

Para evaluar esta situaci\u00f3n, necesitar\u00e1s herramientas de SBOM (lista de materiales de software) o de SCA (an\u00e1lisis de composici\u00f3n de software). Las soluciones disponibles de c\u00f3digo abierto, como Dependency-Check<\/a> o Syft<\/a> de OWASP, pueden crear el \u00e1rbol de dependencias de un proyecto. Pero suelen estar dise\u00f1adas para proyectos que ya est\u00e9n en funcionamiento y que est\u00e9n implementados en tus propios repositorios o im\u00e1genes de contenedor. Por lo tanto, una inmersi\u00f3n profunda en el an\u00e1lisis de las dependencias se realiza mejor en un producto que ya ha pasado la evaluaci\u00f3n preliminar y es un candidato serio para ocupar un lugar en tu infraestructura.<\/p>\n

Examina detenidamente la lista de dependencias para determinar si proceden de repositorios fiables y bien evaluados, si son populares y si tienen firmas digitales. B\u00e1sicamente, est\u00e1s evaluando si existe alg\u00fan riesgo de que est\u00e9n vulneradas.<\/p>\n

Aunque en teor\u00eda se podr\u00eda comprobar manualmente si hay vulnerabilidades en las dependencias, si un proyecto de OSS ya est\u00e1 implementado en un entorno de prueba, es mucho m\u00e1s sencillo utilizar herramientas como Grype<\/a>.<\/p>\n

Un enorme desaf\u00edo oculto es la supervisi\u00f3n de las actualizaciones. En teor\u00eda, hay que volver a comprobar cada actualizaci\u00f3n de las dependencias de un proyecto. En la pr\u00e1ctica, esto solo es factible con esc\u00e1neres automatizados; otros enfoques son sencillamente demasiado caros.<\/p>\n

Si un proyecto utiliza dependencias obsoletas y, en general, no es ideal desde el punto de vista de la ciberseguridad, obviamente es mejor buscar una alternativa. Pero \u00bfqu\u00e9 ocurre si la empresa insiste en una soluci\u00f3n espec\u00edfica por su funcionalidad b\u00e1sica? La respuesta es la misma de siempre: hay que realizar un an\u00e1lisis de riesgos m\u00e1s profundo, desarrollar controles compensatorios y, sobre todo, asignar recursos significativos para el mantenimiento continuo. Los recursos internos suelen ser insuficientes, por lo que es aconsejable evaluar desde el comienzo las opciones de soporte t\u00e9cnico profesional para ese producto espec\u00edfico.<\/p>\n

Cumplimiento de los requisitos internos y normativos<\/h2>\n

Si las pol\u00edticas normativas que se aplican a tu empresa cubren el software escogido y los datos que contiene, desarrolla un plan de auditor\u00edas de cumplimiento cuanto antes. Las grandes aplicaciones empresariales de c\u00f3digo abierto a veces incluyen documentaci\u00f3n de apoyo que puede simplificar algunos tipos de auditor\u00edas. De lo contrario, tendr\u00e1s que desarrollarla por tu cuenta, lo que significa asignar tiempo y recursos significativos.<\/p>\n

Casi todos los programas de software de todos los sectores requieren una auditor\u00eda de cumplimiento de licencias. Algunos componentes y aplicaciones de c\u00f3digo abierto se distribuyen bajo licencias restrictivas, como AGPL<\/a>, que limitan la forma en la que se puede distribuir y utilizar el software. Gracias al an\u00e1lisis de SBOM y SCA, puedes hacer el inventario de todas las licencias de tu software y sus dependencias, y luego puedes verificar que tu caso de uso no infringe ninguna de ellas. Estos procesos se pueden automatizar en gran medida con herramientas especializadas como OSS Review Toolkit<\/a>, pero la automatizaci\u00f3n requerir\u00e1 pol\u00edticas claras y el esfuerzo de tu equipo de desarrollo.<\/p>\n

Costes de soporte<\/h2>\n

Despu\u00e9s de analizar todos estos aspectos, deber\u00edas tener una imagen clara que te permita comparar los diferentes enfoques del soporte de aplicaciones. Para que el soporte lo proporcione un equipo interno, tendr\u00e1s que asignarles horas a los especialistas pertinentes. Si tu equipo no tiene la experiencia necesaria, tendr\u00e1s que contratar a alguien. Los principales responsables del soporte y la seguridad del OSS tambi\u00e9n necesitar\u00e1n tiempo y presupuesto para lograr un desarrollo profesional constante.<\/p>\n

Si los recursos de tu equipo interno son insuficientes para el soporte (debido a la falta de personal o experiencia limitada), existen al menos dos tipos de soporte t\u00e9cnico profesional externalizado: empresas como Red Hat, que se especializan en operaciones de aplicaciones, y proveedores de alojamiento administrado para aplicaciones espec\u00edficas (Kube Clusters, MongoDB Atlas y similares).<\/p>\n

Aparte del tiempo y la experiencia, el coste y la complejidad del soporte t\u00e9cnico tambi\u00e9n se ven influenciados por la preparaci\u00f3n general de la organizaci\u00f3n para la adopci\u00f3n generalizada del c\u00f3digo abierto:<\/p>\n