Un informe reciente destacó que casi un tercio de los líderes empresariales ha experimentado un aumento en el número de ataques cibernéticos dirigidos a sus cadenas de suministro. Comprensiblemente, la atención se centra en la concentración de proveedores, los terceros y el efecto dominó si un socio cae. Esta preocupación es válida, pero incompleta.
Existe otro riesgo en la cadena de suministro que rara vez aparece en la agenda de la junta directiva. No surge a través de un acuerdo con el proveedor y no figura en un registro de compras. Esto ni siquiera se refleja en un cuestionario de diligencia debida. Software de código abierto en riesgo.
CTO de campo en Trend AI, una unidad de negocio de Trend Micro.
Hoy en día, los componentes de código abierto sustentan casi todos los servicios digitales modernos.
El artículo continúa a continuación.
Desde portales de clientes hasta plataformas de pago, desde cargas de trabajo en la nube hasta herramientas internas, los equipos de desarrollo dependen de imágenes de contenedores extraídas de bibliotecas, marcos y repositorios públicos. En muchos entornos, más del 80 por ciento del código base se remonta a componentes de código abierto.
Sin embargo, cuando los ejecutivos discuten la exposición de la cadena de suministro, la conversación generalmente se centra en los proveedores de servicios administrados, la TI subcontratada y las dependencias de hardware. La capa de código abierto es en gran medida invisible.
debajo de la superficie
La mayoría de las organizaciones todavía enmarcan el riesgo cibernético en torno a descriptores familiares: correos electrónicos de phishing, bandas de ransomware, robo de credenciales e ingeniería social. Éstas son amenazas reales. Son fáciles de interpretar y medir y son los que aparecen en los titulares.
Por el contrario, el riesgo del código abierto es silencioso y sistemático. No hay correos electrónicos maliciosos que señalar. Ningún adversario evidente llama a la puerta. En cambio, el riesgo entra a través de una acción rutinaria del desarrollador: importar una biblioteca para acelerar la entrega.
El desafío no es que el código abierto sea inherentemente inseguro. El desafío es que está descentralizado y en gran medida no regulado. Cualquiera puede publicar un paquete. Cualquiera puede actualizarlo. El mantenedor puede cambiar. Las dependencias pueden cambiar. Un componente que ayer era estable y seguro puede presentar hoy un defecto grave.
De hecho, las organizaciones importan constantemente código de un ecosistema externo que no administran ni controlan. Este es el riesgo de la cadena de suministro en su forma más pura.
Un paisaje que se mueve minuto a minuto
Los modelos tradicionales de gestión de riesgos luchan por hacer frente a esta realidad. Muchas empresas todavía dependen de evaluaciones puntuales, la certificación ISO de Eagan o revisiones anuales de proveedores o auditorías periódicas.
Estos métodos suponen una estabilidad relativa y que lo evaluado permanece sustancialmente igual hasta la próxima revisión.
Sin embargo, el software de código abierto no opera según ese cronograma.
Las bibliotecas se actualizan diariamente, a veces cada hora. Las nuevas dependencias se introducen automáticamente mediante el proceso de compilación. La imagen del contenedor se reconstruye y se vuelve a publicar.
Un componente que antes era confiable puede volverse vulnerable a los pocos minutos de una nueva versión o una actualización maliciosa. La idea de que un certificado anual refleja la postura de seguridad en tiempo real de una pila de software está obsoleta.
Hemos visto casos en los que un único paquete comprometido en un repositorio público se extendió a través de miles de proyectos posteriores. No porque las organizaciones fueran descuidadas, sino porque carecían de visibilidad de las capas más profundas de su árbol de dependencia.
El resultado es una exposición sistémica que se esconde debajo de la superficie de los marcos de gobernanza estándar.
problemas alimentarios
Uno de los momentos de riesgo de software que más se pasa por alto es el punto de ingestión. Cuando un desarrollador incorpora una nueva biblioteca o imagen de contenedor a un entorno, es una decisión de la cadena de suministro. Esto equivale a incorporar un nuevo proveedor.
Sin embargo, en muchas organizaciones esta decisión se toma sin barreras de seguridad. No hay verificación de origen ni puntuación de reputación. Cuando los equipos de seguridad revisan el código base, el componente ya está integrado, implementado y en producción.
Las organizaciones maduras están empezando a repensar esto. Están escaneando bibliotecas e imágenes de contenedores a medida que ingresan al medio ambiente, no semanas después.
Están verificando firmas digitales, rastreando los orígenes de los paquetes y aplicando políticas que restringen las fuentes no confiables. Están monitoreando constantemente la desviación y reconociendo que los componentes que alguna vez fueron confiables pueden surgir con el tiempo con nuevas vulnerabilidades.
No se trata de desacelerar la innovación, sino de aplicar la misma disciplina a las dependencias del código que ya aplicamos a los proveedores financieros y a los socios de infraestructura crítica.
Casos a favor de una calificación de riesgo independiente
Una debilidad estructural del ecosistema de código abierto es la ausencia de un sistema de clasificación de riesgos independiente y ampliamente aceptado. En los mercados financieros, nos basamos en las calificaciones crediticias para evaluar el riesgo de contraparte. En hardware contamos con estándares de seguridad y supervisión regulatoria.
En Open Source, dependemos en gran medida de la confianza de la comunidad y de la divulgación reactiva de vulnerabilidades.
Un modelo más maduro introduciría indicadores de riesgo transparentes para componentes ampliamente utilizados. Se pueden medir factores como la actividad del mantenedor, la frecuencia de actualización, las vulnerabilidades conocidas, la complejidad de la dependencia y la integridad de la fuente.
Luego, las organizaciones pueden tomar decisiones informadas basadas en el riesgo sistémico, no solo en el desempeño.
No requiere controles estrictos. Proporcionar señales claras al mercado requiere la colaboración entre la industria, los operadores de repositorios y los investigadores de seguridad.
Sin esa visibilidad, las empresas van a ciegas.
Equilibre la innovación con la exposición
El código abierto ha cambiado la innovación. Esto a menudo ha acelerado el desarrollo, reducido los costos y permitido realizar pruebas rápidas. Desviarse de esto no es práctico ni deseable.
El objetivo es el equilibrio.
Los líderes de seguridad deben ampliar la definición de riesgo de la cadena de suministro para incluir el código. Las juntas directivas deben entender que la exposición sistémica puede importarse silenciosamente a través del proceso de desarrollo. Los marcos de gobernanza deben evolucionar de auditorías estáticas a un seguimiento continuo.
Es posible que la gestión de la superficie de ataque en 2026 no se limite a los activos conectados a Internet y a los contratos de terceros. Debe llegar a la lista de materiales del software, el árbol de dependencias y el estado en tiempo real de los componentes de código abierto.
La incómoda verdad es que muchas organizaciones son seguras en un momento e inseguras al siguiente, no porque un atacante traspasó su perímetro, sino debido a un cambio en una biblioteca.
Si casi un tercio de los líderes ya ven ataques a la cadena de suministro, la pregunta no es si el riesgo de código abierto se convertirá en un punto focal. Cuando lo sea.
Cuanto antes tratemos la ingesta de código abierto como un problema de la cadena de suministro a nivel de la junta directiva en lugar de un beneficio para los desarrolladores, más sólida será nuestra base digital.
Hemos presentado los mejores cursos de ciberseguridad en línea.
Este artículo se creó como parte del canal Expert Insights de TechRadarPro, donde destacamos las mejores y más brillantes mentes de la industria tecnológica actual. Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, obtenga más información aquí:
