Open Source es el mayor riesgo de seguridad del mundo – Y todos lo estamos ignorando
2 min de lectura
El 96 por ciento de todo el software comercial contiene componentes de código abierto. La mayoría son mantenidos por desarrolladores individuales y no remunerados. Log4j fue solo el comienzo: la próxima catástrofe duerme en una biblioteca que un mantenedor en Nebraska actualiza en su tiempo libre. Por qué el modelo de código abierto se encuentra en plena crisis de seguridad.
En resumen
- El 96 por ciento de las bases de código comerciales contienen bibliotecas de código abierto, con un promedio de más de 500 dependencias por proyecto
- La vulnerabilidad Log4Shell (2021) afectó a más de 35.000 paquetes Java y causó daños estimados en 10.000 millones de dólares
- Más del 25 por ciento de todos los proyectos de código abierto son mantenidos por un único mantenedor, sin remuneración ni auditoría de seguridad
- Los ataques a la cadena de suministro mediante paquetes de código abierto comprometidos aumentaron un 740 por ciento en 2024 respecto al año anterior
La señal de alarma de xz Utils
En marzo de 2024, un desarrollador de Microsoft descubrió casualmente una puerta trasera en xz Utils, una biblioteca de compresión presente en prácticamente todas las distribuciones de Linux. La puerta trasera era sofisticada: un atacante se había infiltrado durante dos años como colaborador aparentemente útil, ganó la confianza del mantenedor sobrecargado y finalmente introdujo una puerta trasera en SSH.
El ataque solo fue descubierto por casualidad, porque un desarrollador notó que los inicios de sesión SSH eran 500 milisegundos más lentos de lo esperado. De no haber sido por su curiosidad, la puerta trasera habría comprometido millones de servidores en todo el mundo. Esto no es un modelo de seguridad. Es pura suerte.
La incómoda verdad sobre «Given Enough Eyeballs»
El mantra del código abierto dice: «Dado un número suficiente de observadores, todos los errores son superficiales». La ley de Linus. La idea de que el código abierto es automáticamente seguro porque cualquiera puede revisarlo. La realidad: nadie lo revisa.
OpenSSL, la biblioteca criptográfica que protege la mitad de internet, fue mantenida durante años por dos personas con un presupuesto anual inferior a 10.000 dólares. Heartbleed, una de las vulnerabilidades más graves de la historia de internet, permaneció dos años en el código. No porque el código fuera secreto, sino porque nadie lo miró.
Log4j, la biblioteca de registro en Java que sumió a internet en estado de emergencia en 2021, era mantenida por tres voluntarios. No introdujeron la vulnerabilidad intencionadamente. Simplemente no tenían los recursos para revisar cada ruta de código en busca de fallos de seguridad.
Cadena de suministro: el vector de ataque perfecto
Los atacantes han comprendido que la forma más eficiente de acceder a miles de empresas no es a través de sus firewalls, sino a través de sus dependencias. Un paquete npm comprometido con 10 millones de descargas semanales infecta automáticamente miles de canalizaciones de construcción.
Los ataques son cada vez más sofisticados: typosquatting (paquetes con nombres similares a bibliotecas populares), confusión de dependencias (nombres de paquetes internos reemplazados por externos), toma de control de mantenedores (como en xz Utils). ¿Y la defensa? Fragmentada, infrafinanciada y reactiva.
Qué debe hacerse
Financiación de infraestructuras críticas: Las bibliotecas de código abierto utilizadas en más de 10.000 proyectos son de facto infraestructuras críticas. Deben ser tratadas y financiadas como tales, mediante programas estatales, consorcios industriales o contribuciones obligatorias de las empresas que dependen de ellas.
Lista de materiales de software (SBOM): Toda empresa debe saber qué componentes de código abierto contiene sus productos. Las SBOM deben volverse obligatorias. La UE ya está trabajando en ello, pero la implementación avanza demasiado lentamente.
Auditorías de seguridad automatizadas: Cada actualización de una biblioteca crítica debe pasar por una verificación de seguridad automatizada antes de llegar a sistemas de producción. Herramientas como Dependabot, Snyk o Socket.dev ayudan, pero deben convertirse en estándar, no en una opción.
Conclusión: el código abierto necesita un nuevo modelo de seguridad
El código abierto no es el problema, es la solución a innumerables desafíos tecnológicos. Pero su modelo de seguridad se basa en una ilusión: que la voluntariedad y la transparencia son suficientes. No lo son. El mundo construye su infraestructura digital sobre trabajo no remunerado y luego se sorprende cuando colapsa.
Datos clave
Ataque a xz-Utils: La puerta trasera fue descubierta por casualidad. El atacante había invertido dos años y habría tenido éxito de no ser por un desarrollador atento.
Brecha de financiación: La Fundación Linux estima que la infraestructura global de código abierto necesita al menos 2.000 millones de dólares anuales en inversión. En la actualidad, fluyen menos de 200 millones.
Preguntas frecuentes
¿Es el software propietario más seguro que el código abierto?
No en general. El software propietario tiene las mismas vulnerabilidades, pero se manejan con menos transparencia. La diferencia: el software propietario cuenta con desarrolladores y equipos de seguridad remunerados. El código abierto necesita lo mismo, sin renunciar a la transparencia.
¿Qué deberían hacer las empresas inmediatamente?
Primero: crear una SBOM para todos los productos. Segundo: integrar escaneo automatizado de dependencias en la canalización CI/CD. Tercero: apoyar financieramente los proyectos de código abierto críticos de los que dependen.
¿Resolverá el Cyber Resilience Act (CRA) este problema?
El CRA de la UE exige seguridad desde el diseño para productos de software, incluyendo componentes de código abierto. Es un paso importante, pero su implementación debe garantizar que los mantenedores no remunerados no sean criminalizados, sino apoyados.
Artículos relacionados
- Supply Chain Security 2026: So schützen Unternehmen ihre Software-Lieferkette
- Cybersecurity-Trends 2026: Die 7 Entwicklungen
- NIS2 und Geschäftsführerhaftung
Más del ecosistema MBF Media
- Cloud-Infrastruktur und DevSecOps auf cloudmagazin.com
- IT-Strategien für Entscheider auf digital-chiefs.de
Fuente de imagen: Pexels
