software
Según el informe del estado de código abierto de 2025, el 96 % de las empresas encuestadas utilizan aplicaciones de código abierto. Debido a su amplia selección, sus opciones de personalización y los costes nulos de las licencias, resultan muy atractivos.
Sin embargo, más de la mitad de las empresas encuestadas se enfrentan a importantes desafíos con el mantenimiento continuo de las aplicaciones de código abierto. Nada menos que el 63 % 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ódigo abierto al final de su vida útil (EoL), lo que significa que ya no son compatibles.
Entonces, ¿cómo se puede minimizar la probabilidad de que surjan estos problemas y qué hay que tener en cuenta a la hora de elegir el software de código abierto (OSS) para su implementación?
Las actualizaciones y los parches
Dado que la actualización oportuna del OSS (Software de Código Abierto por sus siglas en inglés) es el problema más generalizado, examina muy detenidamente los posibles candidatos para la adopción del OSS desde esta perspectiva. Es fácil comprobar la frecuencia y el alcance de las actualizaciones, así como su contenido, directamente en el repositorio público de la aplicación. Presta atención a cómo de bien documentadas están las actualizaciones; qué tipos de problemas resuelven; qué funciones nuevas añaden; con qué frecuencia se lanzan las correcciones menores unos días o semanas después de la versión principal; y con qué rapidez se cierran las solicitudes relacionadas con errores.
Algunas herramientas estándar como Git Insights, junto con servicios complementarios como Is it maintained?, Repology y Libraries.io, pueden ayudarte a responder a estas preguntas. Libraries.io muestra inmediatamente qué dependencias obsoletas utiliza la versión actual.
Presta especial atención a las actualizaciones relacionadas con la seguridad. ¿Se lanzan por separado o se incluyen con las actualizaciones de funcionalidad? Normalmente, los desarrolladores escogen esta última opción. En ese caso, debes saber cuánto tiempo llevan esperando a ser lanzadas las actualizaciones de seguridad.
Además, evalúa el nivel de complejidad del proceso de instalación de actualizaciones. La documentación y el soporte oficiales pueden ser un punto de partida, pero no son suficientes. Es probable que lo más útil en este caso sea revisar detenidamente los comentarios de la comunidad de usuarios.
Todo esto te permitirá comprender mejor cuánto esfuerzo supondrá el mantenimiento del producto. Deberás asignar recursos internos para el soporte. No basta con solo asignar responsabilidades; se necesitarán horas de trabajo dedicadas a estas tareas y otras relacionadas.
Vulnerabilidades
Para predecir con exactitud la frecuencia con la que te enfrentarás a los problemas de ciberseguridad, lo mejor es evaluar la cultura de ingeniería 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álisis inicial de alto nivel.
Para los productos y paquetes populares, un buen enfoque es comprobar los resultados de evaluaciones heurísticas ya existentes de herramientas como OpenSSF Scorecard. Proporciona una variedad de datos de la higiene de ciberseguridad, que abarcan desde la cantidad de vulnerabilidades sin parches y la presencia de políticas de seguridad hasta el uso de fuzzing y la fijación de dependencias.
Además, examina las bases de datos públicas de las vulnerabilidades como NVD y los avisos de GitHub para conocer cuántos fallos se han descubierto en el proyecto, su criticidad y la rapidez con la que se solucionaron. Una gran cantidad de vulnerabilidades por sí misma puede indicar la popularidad del proyecto, y no siempre implica malas prácticas de desarrollo. Sin embargo, los tipos de defectos y la forma en que los desarrolladores han respondido a ellos es lo verdaderamente importante.
Las dependencias y la cadena de suministro
Casi todos los proyectos de OSS dependen de componentes de código abierto de terceros, que a menudo no están documentados. Estos componentes se actualizan según sus propios programas y pueden contener errores, vulnerabilidades e incluso código malicioso. La cuestión clave aquí es la rapidez con la que las actualizaciones de los componentes con parches llegan al proyecto que estás considerando.
Para evaluar esta situación, necesitarás herramientas de SBOM (lista de materiales de software) o de SCA (análisis de composición de software). Las soluciones disponibles de código abierto, como Dependency-Check o Syft de OWASP, pueden crear el árbol de dependencias de un proyecto. Pero suelen estar diseñadas para proyectos que ya estén en funcionamiento y que estén implementados en tus propios repositorios o imágenes de contenedor. Por lo tanto, una inmersión profunda en el análisis de las dependencias se realiza mejor en un producto que ya ha pasado la evaluación preliminar y es un candidato serio para ocupar un lugar en tu infraestructura.
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ásicamente, estás evaluando si existe algún riesgo de que estén vulneradas.
Aunque en teoría se podría comprobar manualmente si hay vulnerabilidades en las dependencias, si un proyecto de OSS ya está implementado en un entorno de prueba, es mucho más sencillo utilizar herramientas como Grype.
Un enorme desafío oculto es la supervisión de las actualizaciones. En teoría, hay que volver a comprobar cada actualización de las dependencias de un proyecto. En la práctica, esto solo es factible con escáneres automatizados; otros enfoques son sencillamente demasiado caros.
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 ¿qué ocurre si la empresa insiste en una solución específica por su funcionalidad básica? La respuesta es la misma de siempre: hay que realizar un análisis de riesgos más 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écnico profesional para ese producto específico.
Cumplimiento de los requisitos internos y normativos
Si las políticas normativas que se aplican a tu empresa cubren el software escogido y los datos que contiene, desarrolla un plan de auditorías de cumplimiento cuanto antes. Las grandes aplicaciones empresariales de código abierto a veces incluyen documentación de apoyo que puede simplificar algunos tipos de auditorías. De lo contrario, tendrás que desarrollarla por tu cuenta, lo que significa asignar tiempo y recursos significativos.
Casi todos los programas de software de todos los sectores requieren una auditoría de cumplimiento de licencias. Algunos componentes y aplicaciones de código abierto se distribuyen bajo licencias restrictivas, como AGPL, que limitan la forma en la que se puede distribuir y utilizar el software. Gracias al análisis 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, pero la automatización requerirá políticas claras y el esfuerzo de tu equipo de desarrollo.
Costes de soporte
Después de analizar todos estos aspectos, deberías 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ás que asignarles horas a los especialistas pertinentes. Si tu equipo no tiene la experiencia necesaria, tendrás que contratar a alguien. Los principales responsables del soporte y la seguridad del OSS también necesitarán tiempo y presupuesto para lograr un desarrollo profesional constante.
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écnico profesional externalizado: empresas como Red Hat, que se especializan en operaciones de aplicaciones, y proveedores de alojamiento administrado para aplicaciones específicas (Kube Clusters, MongoDB Atlas y similares).
Aparte del tiempo y la experiencia, el coste y la complejidad del soporte técnico también se ven influenciados por la preparación general de la organización para la adopción generalizada del código abierto:
- ¿Tu equipo de ciberseguridad cuenta con escáneres de vulnerabilidades y herramientas de administración de riesgos bien adaptados al OSS?
- ¿Tus herramientas de seguimiento y supervisión de activos de TI son compatibles con los proyectos y los componentes del OSS?
- En el caso de los equipos internos de desarrollo, ¿se incluyen procesos de análisis de imágenes, repositorios y otras fuentes de código en tu flujo de proceso de CI/CD? Las soluciones de seguridad especializadas, como Kaspersky Hybrid Cloud Security, pueden automatizar este aspecto.
- ¿Tu empresa ha desarrollado una política que regule el uso del OSS? ¿Está claro quién toma las decisiones y quién es responsable de las cuestiones operativas?
Además, es crucial tener en cuenta el amplio espectro de los riesgos del código abierto, que incluyen la interrupción abrupta del proyecto, la proliferación de dependencias menores y otros riesgos en la cadena de suministro.
