Dependemos del software de código abierto para todo, desde aplicaciones hasta infraestructura, pero lo analizamos menos que las herramientas comerciales. Esta desconexión es un riesgo sistémico.
getty
En un mundo cada vez más definido por la transformación digital, uno de los componentes más importantes de nuestra infraestructura tecnológica es también uno de los más infravalorados: el software de código abierto. Es el elemento vital del desarrollo moderno y forma los componentes básicos de aplicaciones, sistemas y servicios en todas las industrias. Sin embargo, a pesar de su importancia, el software de código abierto a menudo ingresa a las organizaciones sin control, responsabilidad o incluso conciencia. ¿Por qué? Porque es gratis.
Esta paradoja (que el software no tiene precio ni valor) está en el centro de la creciente crisis en la seguridad de la cadena de suministro de software. Recientemente me senté con Brian Fox, cofundador y director de tecnología de Sonatype, para analizar el Informe sobre el estado de la cadena de suministro de software 2026 y analizar este tema en profundidad. Surgió un cuadro sorprendente de disonancia cognitiva, que amenaza los cimientos de nuestro ecosistema digital.
«La gente es terrible a la hora de poner valor a las cosas que ellos mismos obtienen gratis. Ya sabes, la vieja tragedia de la narrativa de los bienes comunes», dijo Brian. «Cuando empiezas a observar el comportamiento bajo el capó, ves mucho desperdicio».
Fox agregó: «Solía pensar que había abuso, y ciertamente hay abuso, pero creo que es más bien un desperdicio involuntario en la forma de no pensar en cómo se usan las cosas».
Brian sabe un par de cosas sobre esta infraestructura. Casi todos los componentes Java de código abierto son entregados por desarrolladores de todo el mundo a través de Maven Central, administrado por Sonatype.
Podría decirse que el software de código abierto es una de las partes más críticas de Internet y de los dispositivos y aplicaciones que utilizamos. Sin embargo, como señala Brian, esta importancia rara vez va acompañada de cuidado o consideración.
Perspectivas del informe sobre el estado de la cadena de suministro de software de 2026
El recién estrenado 2026 El estado de la cadena de suministro de software El informe de Sonatype añade nueva urgencia y datos a esta conversación. Dado que las descargas de código abierto alcanzaron la asombrosa cifra de 9,8 billones en los cuatro registros más grandes (un aumento interanual del 67%), el volumen por sí solo está remodelando el ecosistema.
Pero no es sólo la escala. El informe revela que se han identificado más de 1,233 millones de paquetes maliciosos, lo que demuestra que los atacantes de los estados-nación imitan cada vez más las herramientas de desarrollo confiables. Es alarmante que muchas organizaciones continúen descargando componentes vulnerables conocidos incluso después de que se publiquen los parches. Log4Shell, por ejemplo, se descargó 42 millones de veces en 2025.
Incluso la inteligencia artificial, si bien aumenta la velocidad del desarrollo, crea nuevas vulnerabilidades en la cadena de suministro. La investigación de Sonatype encontró que GPT-5 alucinaba en casi el 28% de las versiones de componentes e incluso recomendaba malware sin inteligencia en tiempo real. Como señala Brian, «la confianza debe alinearse con la velocidad del software a nivel de máquina. Esto requiere inteligencia procesable en el flujo de trabajo, no otro informe más para leer después de un evento».
Como señala Scott Crawford, jefe de investigación de seguridad de la información en 451 Research / S&P Global, «Estos no son aspectos de la cadena de suministro de tecnología que puedan tomarse a la ligera. Para preservar el valor del OSS, su seguridad e integridad deben gestionarse de manera responsable y consistente».
Puntos ciegos en materia de adquisiciones y brechas de gobernanza
Crawford señaló: «Durante mucho tiempo se ha promocionado el software de código abierto por sus beneficios de seguridad, es decir, el hecho de que una comunidad preocupada participa activamente en su desarrollo y mantenimiento, incluidos los problemas y errores de seguridad. Pero esa garantía es tan buena como el compromiso de la comunidad y la experiencia asignada a la oportunidad. ¿Qué pasa si nada de eso sucede como se espera? ¿O de manera inconsistente?»
Pero según Fox, el problema no es que los encargados del mantenimiento del código abierto no estén haciendo su trabajo. De lo contrario. De hecho, muchos proyectos de código abierto solucionan las vulnerabilidades más rápido que sus homólogos comerciales. El problema es que no existe un proceso formal de adquisición de componentes de código abierto.
Cuando las organizaciones compran software comercial, siguen un proceso de adquisición que incluye revisión legal, debida diligencia del proveedor y acuerdos de soporte. Con el código abierto, ninguno de estos existe. Los desarrolladores pueden tomar una biblioteca de un repositorio público y ejecutarla en vivo en minutos. Lo que hace que el código abierto sea tan poderoso (su velocidad y accesibilidad) es también su talón de Aquiles.
«Por eso se ha vuelto tan popular. Los desarrolladores pueden acceder a cosas y moverse muy rápidamente sin tener que pasar por un ciclo de adquisición», explicó Brian. «La consecuencia no deseada de esto es que nadie presta atención a lo que se utiliza en la organización, ¿verdad? Esa es la raíz del problema».
Esta desconexión se hizo dolorosamente obvia hace unos años durante la crisis de Log4Shell. Una vulnerabilidad crítica en la ampliamente utilizada biblioteca Log4j ha provocado un frenesí global de parches en el sistema. Pero incluso después de una amplia cobertura mediática y asesoramiento gubernamental, muchas organizaciones han tardado en actualizarlos, o no lo han hecho en absoluto. Esto no se debió tanto a negligencia como a falta de visibilidad y gobernanza. Si no sabe lo que está usando, ¿cómo puede gestionar el riesgo?
Cerrando la brecha entre valor y evaluación
Necesitamos repensar cómo valoramos y gestionamos el software de código abierto del que dependemos. Eso comienza con reconocer que se trata de una infraestructura crítica.
Como señala Richard Stiennon, analista de investigación senior de IT-Harvest, «el software de código abierto está abierto al abuso por parte de piratas informáticos astutos, pero también hay un problema con el software comercial que fija sus propios productos en OSS, como Linux. Un atacante inteligente puede corromper la mayoría de las bibliotecas de software en productos de seguridad. Necesitamos alejarnos de cualquier nivel de confianza en el software que utilizamos».
Esto significa crear procesos internos que traten los componentes de código abierto con el mismo rigor que el software comercial. Eso significa invertir en herramientas y prácticas que proporcionen visibilidad sobre qué se utiliza, dónde y si es seguro.
También significa reconocer nuestra responsabilidad colectiva. Las empresas que se benefician del código abierto deben apoyar los ecosistemas de los que dependen, ya sea mediante contribuciones financieras, participación activa o simplemente un uso más responsable.
Mientras las organizaciones cierren la brecha entre valor y valoración, seguirán exponiéndose a riesgos evitables. La cadena de suministro de software merece algo mejor.
