BlueVerse RightLogic conecta evaluación de riesgos con componentes open source endurecidos para acelerar la remediación sin frenar el desarrollo con IA La alianza combina BlueVerse RightLogic, que identifica y prioriza exposición cibernética empresarial, con componentes open source endurecidos de Chainguard. El objetivo es pasar de detectar riesgos a reducirlos desde las dependencias y artefactos utilizados para construir aplicaciones, incorporando trazabilidad, procedencia y controles de seguridad desde etapas tempranas.

Aspectos clave

• LTM integra las capacidades de Chainguard dentro del ecosistema de BlueVerse RightLogic.
• RightLogic cubre riesgos en software supply chain, sistemas legados, redes, identidades, IA y gobernanza.
• El modelo de LTM sigue tres etapas: Assess, Mobilize y Remediate.
• Chainguard desarrolla componentes open source orientados a seguridad by default, incluidos contenedores mínimos y endurecidos.
• Sus artefactos incorporan capacidades como SBOM, firmas criptográficas y procedencia de construcción.
• La colaboración busca reducir el tiempo entre identificación del riesgo y remediación.
• LTM ya forma parte de Athena, iniciativa liderada por Chainguard para coordinar la respuesta frente a vulnerabilidades open source relacionadas con la nueva capacidad ofensiva de la IA.
• La seguridad de la cadena de suministro no se limita a encontrar CVE: también requiere verificar origen, integridad, dependencias y proceso de construcción del software.

La IA acelera el software, pero también amplifica su cadena de dependencias

Mumbai, India, 8 de agosto de 2026.— La inteligencia artificial está reduciendo el tiempo necesario para escribir código, construir aplicaciones y automatizar procesos de desarrollo. Pero una aplicación moderna rara vez está formada únicamente por el código que escribe una organización. Puede incorporar:

• Imágenes de contenedores;
• Bibliotecas open source;
• Paquetes de lenguajes;
• Frameworks;
• Herramientas de CI/CD;
• Componentes de terceros;
• Artefactos descargados de repositorios;
• Dependencias transitivas que el propio desarrollador quizá nunca seleccionó directamente.

Cada pieza agrega funcionalidad, pero también una nueva relación de confianza. En ese escenario, LTM y Chainguard anunciaron una alianza para integrar seguridad de la cadena de suministro de software dentro del ecosistema BlueVerse RightLogic, buscando que las empresas puedan acelerar proyectos de IA sin depender únicamente de detectar vulnerabilidades después de haber construido la aplicación.

El problema no comienza necesariamente en el código propio

Una organización puede desarrollar correctamente su aplicación y, aun así, heredar riesgo mediante una biblioteca vulnerable, un paquete comprometido o un artefacto cuya procedencia no puede verificarse. Chainguard identifica entre los principales vectores de riesgo de una supply chain moderna las vulnerabilidades conocidas y zero-day, paquetes maliciosos, confusión de dependencias y fenómenos emergentes como la denominada package hallucination. También existen riesgos dentro del propio pipeline:

• Modificación no autorizada del proceso de construcción;
• Sustitución de una imagen;
• Uso de credenciales excesivamente privilegiadas;
• Dependencia de una base desactualizada;
• Ausencia de firmas;
• Falta de información sobre procedencia.

Por ello, analizar únicamente el código final deja fuera parte de la superficie de ataque.

BlueVerse RightLogic evalúa la exposición antes de priorizar la remediación

LTM presentó BlueVerse RightLogic como un marco de evaluación y aseguramiento del riesgo diseñado específicamente para el escenario de adopción acelerada de IA. Su alcance incluye:

• Cadena de suministro y dependencias;
• Sistemas legados y gestión de parches;
• Exposición de redes;
• Identidad y acceso;
• Aseguramiento y guardrails de IA;
• Respuesta a incidentes y gobernanza.

El modelo combina una perspectiva outside-in, enfocada en aquello que un adversario podría explotar, con otra inside-out, destinada a determinar la preparación interna de personas, procesos y tecnología. La incorporación de Chainguard agrega una capa orientada específicamente a las dependencias y artefactos open source.

De identificar una vulnerabilidad a reducir su exposición

Una de las diferencias estratégicas de la alianza está en conectar diagnóstico y remediación. LTM estructura RightLogic mediante tres etapas:

• Assess: identificar exposición en infraestructura, aplicaciones, IA y supply chain.
• Mobilize: activar las tecnologías y especialistas necesarios para cerrar las brechas.
• Remediate: ejecutar las correcciones sobre infraestructura, aplicaciones y dependencias open source.

La participación de Chainguard se sitúa especialmente en esta tercera dimensión: proporcionar componentes construidos con controles destinados a reducir el riesgo desde el origen. La seguridad deja así de ser únicamente una lista de hallazgos y empieza a relacionarse con la sustitución o corrección efectiva de los componentes que los originan.

Chainguard apuesta por comenzar con componentes mínimos

Un contenedor utilizado en producción puede incluir herramientas que la aplicación realmente no necesita: shell, gestores de paquetes, utilidades administrativas y numerosas bibliotecas adicionales. Cada componente innecesario amplía la superficie susceptible de presentar vulnerabilidades. Chainguard desarrolla imágenes mínimas que contienen principalmente la aplicación y las dependencias necesarias para ejecutarla. Algunas de sus imágenes de producción prescinden incluso de shell y gestores de paquetes, reduciendo las piezas presentes dentro del contenedor. Este enfoque responde al principio de mínima superficie de ataque. Menos componentes no significa seguridad absoluta, pero sí menos software que inventariar, actualizar y proteger.

Secure-by-default frente a corregir después

Durante años, la seguridad de aplicaciones se ha asociado con la idea de shift left: detectar problemas cada vez más temprano dentro del ciclo de desarrollo. Chainguard plantea una evolución conceptual hacia start secure: comenzar directamente con componentes que ya hayan sido construidos bajo determinadas propiedades de seguridad. Su infraestructura incorpora elementos como:

• Imágenes endurecidas;
• Reconstrucciones frecuentes;
• SBOM generadas durante el proceso de construcción;
• Firmas criptográficas;
• Información de procedencia;
• Controles de integridad.

La diferencia es importante. Un escáner indica que existe un problema. Una arquitectura secure-by-default intenta reducir la probabilidad de introducirlo inicialmente. Ambos enfoques pueden complementarse.

SBOM: saber qué contiene realmente una aplicación

Una Software Bill of Materials —SBOM— funciona como un inventario estructurado de los componentes utilizados para construir software. Puede incluir:

• Bibliotecas;
• Paquetes;
• Versiones;
• Relaciones de dependencia;
• Proveedor;
• Licencias;
• Información sobre los artefactos.

Chainguard genera SBOM durante la construcción de sus imágenes. La compañía señala que hacerlo en ese momento puede proporcionar una visión más completa que reconstruir posteriormente el inventario únicamente mediante un escáner. Este detalle resulta crítico cuando aparece una vulnerabilidad nueva. En lugar de preguntarse: “¿Utilizamos este paquete en algún lugar?” la organización puede consultar sus inventarios y localizar exactamente qué aplicaciones y versiones están afectadas.

La procedencia responde otra pregunta: ¿de dónde salió este software?

Saber que una aplicación contiene determinada biblioteca no demuestra por sí mismo que el artefacto descargado sea auténtico. La provenance o procedencia registra información sobre cómo fue construido un componente. Puede ayudar a determinar:

• Qué código fuente se utilizó;
• Mediante qué proceso se compiló;
• Qué sistema generó el artefacto;
• Qué versión produjo;
• Si posteriormente fue modificado.

Chainguard incorpora procedencia y firmas verificables dentro de sus procesos de construcción. La idea central es sencilla: una cadena confiable necesita demostrar no solo qué software contiene, sino también cómo llegó a existir el binario que se está ejecutando.

Firmar software ayuda a detectar sustituciones

Las firmas criptográficas permiten verificar que un artefacto procede de una fuente esperada y que no fue modificado después de ser firmado. Chainguard utiliza tecnologías como Sigstore para firmar sus artefactos. Una organización puede entonces introducir políticas como:

si el artefacto no posee una firma válida o una procedencia aprobada, no puede desplegarse.

Ese principio convierte la confianza en una condición verificable por máquinas en lugar de depender únicamente del nombre de un archivo o una etiqueta de contenedor.

SLSA eleva la seguridad hacia el proceso de construcción

SLSA —Supply-chain Levels for Software Artifacts— establece niveles y controles orientados a fortalecer la integridad de los procesos utilizados para construir software. Chainguard declara construir sus componentes mediante infraestructura compatible con SLSA Level 3, acompañada de metadatos de procedencia. Esto no significa que un producto sea inmune a todas las vulnerabilidades. SLSA se concentra principalmente en responder otra cuestión fundamental: ¿podemos confiar en la forma en que este artefacto fue construido y entregado?

La IA vuelve más importante la procedencia del software

La llegada de asistentes y agentes de programación modifica la escala del desarrollo. Cuando una persona puede generar funciones, dependencias y configuraciones con mucha mayor velocidad, también aumenta el volumen de componentes que una organización debe validar. El riesgo no está en que todo código generado con IA sea inseguro. El problema aparece cuando la velocidad de producción supera la velocidad de revisión. Chainguard señala que las cadenas modernas ya contienen numerosos inputs de terceros y que la seguridad debe combinar reducción de dependencias, firma, procedencia, SBOM y controles automáticos a lo largo del pipeline. En este contexto, la automatización defensiva necesita crecer junto con la automatización del desarrollo.

Package hallucination: cuando un modelo inventa una dependencia

Existe además un riesgo particularmente ligado al desarrollo asistido por IA. Un modelo puede sugerir ocasionalmente el nombre de una biblioteca que no existe. Si un atacante registra posteriormente un paquete con ese nombre en un repositorio público y un desarrollador lo instala sin verificarlo, puede producirse una variante de ataque a la cadena de suministro. Chainguard incluye las denominadas package hallucinations entre los riesgos emergentes asociados con dependencias de software. La mitigación requiere:

• Repositorios aprobados;
• Verificación de origen;
• Listas permitidas;
• Firmas;
• Escaneo;
• Revisión humana;
• Políticas automatizadas.

La productividad generativa necesita entonces una capa igualmente automatizada de confianza.

LTM ya colaboraba con Chainguard mediante Athena

La alianza comercial no aparece en un vacío. En junio de 2026, LTM se incorporó a Athena, coalición liderada por Chainguard para mejorar la respuesta del ecosistema open source frente a vulnerabilidades que la IA puede ayudar a descubrir a mayor velocidad. La iniciativa contempla colaboración desde descubrimiento y análisis hasta:

• Creación de parches;
• Mitigaciones;
• Correcciones upstream;
• Coordinación previa a la divulgación.

La lógica consiste en llevar una corrección hacia el proyecto original para que no beneficie solamente a una empresa, sino potencialmente a todos los usuarios posteriores del componente. La nueva colaboración con BlueVerse RightLogic lleva esa relación hacia implementaciones empresariales específicas.

Seguridad sin detener DevOps

La tensión histórica en AppSec suele plantearse entre dos prioridades: desarrollar rápido y controlar el riesgo. Cuando cada alerta exige investigar manualmente cientos de CVE, los equipos pueden acumular grandes cantidades de trabajo pendiente. Una estrategia basada en componentes mínimos, inventarios automáticos y procedencia busca disminuir ese volumen desde el origen. Chainguard sostiene que las supply chains modernas deberían desplazarse desde programas centrados únicamente en escaneo hacia estrategias que combinen prevención y verificación. Para LTM, esa capacidad complementa RightLogic porque permite que una recomendación de remediación termine en una modificación efectiva del componente utilizado por el desarrollador.

El CVE sigue siendo importante, pero no explica todo el riesgo

Un Common Vulnerabilities and Exposures —CVE— identifica públicamente una vulnerabilidad conocida. Sin embargo, una cadena de suministro puede estar comprometida incluso sin que exista todavía un CVE. Por ejemplo:

• Un artefacto fue manipulado;
• Una dependencia procede de un repositorio falso;
• Una credencial fue expuesta;
• Un pipeline fue alterado;
• El binario no corresponde al código fuente esperado.

Por ello, SBOM, firmas y procedencia complementan la gestión tradicional de vulnerabilidades.

La pregunta deja de ser únicamente: “¿Tiene fallas conocidas?” y pasa también a ser: “¿Es realmente el software que creemos estar ejecutando?”

La confianza debe acompañar a la aplicación hasta producción

Una política madura de seguridad de supply chain debería mantener los controles durante todo el ciclo:

1. seleccionar componentes confiables;
2. generar inventarios;
3. verificar procedencia;
4. firmar artefactos;
5. proteger CI/CD;
6. validar antes de promover;
7. bloquear artefactos no aprobados;
8. monitorear nuevas vulnerabilidades;
9. reconstruir o actualizar cuando sea necesario.

Chainguard recomienda aplicar verificación en puntos de control como repositorios, promoción y admisión en clusters, de modo que un artefacto que no cumpla las políticas no llegue a ejecutarse. La seguridad deja así de depender exclusivamente de una revisión puntual.

Las declaraciones de los voceros

Krishnan Iyer, director de crecimiento de LTM, sintetizó el objetivo en el comunicado:

Las organizaciones buscan ir más allá de la gestión de vulnerabilidades y construir cadenas de suministro de software confiables”.

Dan Lorenc, CEO y cofundador de Chainguard, puso el foco en la velocidad:

La única solución efectiva consiste en garantizar, desde el inicio, que los componentes sean confiables”.

Ambas declaraciones reflejan un cambio importante: la seguridad de software avanza desde encontrar defectos hacia demostrar confianza en los componentes y procesos que construyen una aplicación.

Más contexto

BlueVerse RightLogic es un marco de LTM para evaluación y aseguramiento de riesgos que abarca diez dominios y que la empresa estructura mediante un proceso inicial de entre cuatro y seis semanas, seguido por una hoja de ruta de remediación. Estas características están documentadas públicamente por LTM. Las características de componentes mínimos, SBOM, firmas, procedencia y reconstrucciones frecuentes corresponden a la arquitectura y documentación técnica publicada por Chainguard. El comunicado no proporciona:

• métricas cuantitativas de reducción de vulnerabilidades derivadas específicamente de esta alianza;
• tiempos garantizados de remediación conjuntos;
• clientes que ya utilicen la integración;
• precios;
• SLA comerciales de la oferta conjunta.

Por ello, nuestra redacción en IT/USERS® Magazine no atribuye resultados económicos o de seguridad todavía no demostrados en el anuncio.

Datos citables

• RightLogic evalúa exposición en infraestructura, aplicaciones, IA y supply chain.
• LTM estructura el modelo mediante Assess, Mobilize y Remediate.
• La evaluación inicial de RightLogic está diseñada para realizarse en aproximadamente 4 a 6 semanas.
• LTM ingresó en junio de 2026 a Athena, iniciativa liderada por Chainguard.
• Chainguard desarrolla imágenes mínimas y endurecidas para aplicaciones open source.
• Sus imágenes incorporan SBOM generadas durante el proceso de construcción.
• Los artefactos pueden incluir firmas criptográficas y procedencia verificable.
• Chainguard declara utilizar infraestructura de construcción alineada con SLSA Level 3.

Preguntas y respuestas para comprender la seguridad de la cadena de software

¿Qué es una cadena de suministro de software?

Es el conjunto de componentes, herramientas, repositorios, desarrolladores, procesos de construcción y sistemas de distribución que intervienen desde el código fuente hasta el software ejecutado en producción.

¿Un escáner de vulnerabilidades es suficiente?

No. Puede encontrar determinadas fallas conocidas, pero no demuestra necesariamente procedencia ni integridad del artefacto. Firmas, SBOM y controles de construcción cubren dimensiones complementarias.

¿Qué ventaja ofrece una imagen mínima?

Contiene menos componentes innecesarios y, por tanto, reduce la superficie potencial de ataque y la cantidad de dependencias que deben mantenerse.

¿Qué diferencia existe entre SBOM y provenance?

La SBOM describe qué contiene el software. La procedencia explica cómo y desde dónde fue construido.

¿Por qué firmar un contenedor?

La firma permite verificar que procede de una fuente autorizada y ayuda a detectar modificaciones posteriores.

¿La IA hace inseguro automáticamente al software?

No. La IA puede acelerar el desarrollo y también la búsqueda de vulnerabilidades. El riesgo surge cuando esa velocidad supera la capacidad de revisar dependencias, código y procesos.

¿Qué es una package hallucination?

Ocurre cuando un modelo sugiere una dependencia inexistente. Si alguien crea posteriormente un paquete malicioso con ese nombre, un desarrollador podría instalarlo por error.

Knowledge Layer | Glosario

• Software Supply Chain: ecosistema de código, dependencias, herramientas y procesos utilizados para construir y distribuir una aplicación.
• Open Source Software —OSS—: software cuyo código fuente está disponible bajo una licencia que permite determinados usos, modificaciones y redistribuciones.
• SBOM —Software Bill of Materials—: inventario estructurado de los componentes que conforman una aplicación.
• CVE —Common Vulnerabilities and Exposures—: identificador estandarizado para vulnerabilidades de seguridad conocidas.
• Provenance: información que permite verificar el origen y proceso de construcción de un artefacto de software.
• SLSA —Supply-chain Levels for Software Artifacts—: marco de controles destinado a fortalecer la integridad de los procesos de construcción de software.
• Contenedor mínimo: imagen que incluye únicamente la aplicación y las dependencias necesarias para ejecutarla, reduciendo componentes innecesarios.
• Firma criptográfica: mecanismo utilizado para comprobar autenticidad e integridad de software o datos.
• CI/CD: procesos automatizados de integración, prueba, construcción y entrega continua de software.
• Secure-by-default: enfoque que busca configurar componentes y sistemas con propiedades de seguridad desde el inicio, en lugar de añadirlas posteriormente.

¿Por qué es importante?

La IA puede acelerar extraordinariamente la creación de software, pero cada nueva dependencia introduce una relación de confianza. Proteger la cadena exige saber qué contiene una aplicación, quién construyó sus componentes y si fueron alterados. La velocidad solo se convierte en ventaja cuando la confianza puede verificarse con la misma rapidez.

Visión Estratégica

La seguridad del software está entrando en una etapa donde la procedencia será tan importante como la vulnerabilidad. En un mundo donde agentes de IA pueden producir código y descubrir fallas a velocidad de máquina, revisar manualmente cada componente dejará de escalar. La respuesta será convertir la confianza en datos legibles por máquinas: SBOM, firmas, procedencia, políticas y artefactos verificables. La alianza entre LTM y Chainguard representa esa transición desde una ciberseguridad reactiva hacia cadenas de construcción capaces de demostrar qué ejecutan y por qué deberían confiar en ello. El principio para la era agéntica podría resumirse así: si no puede verificarse, no debería llegar a producción.

Acerca de LTM y Chainguard

LTM es una empresa global de servicios tecnológicos perteneciente al grupo Larsen & Toubro, con aproximadamente 87.000 profesionales y presencia en más de 40 países. Su estrategia actual combina transformación empresarial, operaciones integradas e inteligencia artificial aplicada a negocios.

Chainguard desarrolla software open source orientado a seguridad by default, incluyendo contenedores, bibliotecas, máquinas virtuales y otros artefactos construidos con controles de integridad y supply chain.

En este caso no incorporaría un enlace bursátil dentro del cuerpo: el comunicado suministrado no proporciona una cotización o símbolo bursátil de LTM, y Chainguard es una compañía privada.

Tu Opinión Importa ツ

La inteligencia artificial puede generar software en segundos, pero una aplicación sigue dependiendo de cientos o miles de componentes desarrollados por terceros.

¿Tu organización sabe realmente qué componentes open source existen dentro de cada aplicación que ejecuta?

¿Debería impedirse automáticamente el despliegue de cualquier artefacto que no disponga de SBOM, firma y procedencia verificables?

Comparte tu experiencia con la comunidad de IT/USERS® Magazine:

#itusers28aniversario #superfan

Apoya al Periodismo Independiente

¿Te sirvió en algo este contenido?, ayúdanos a combatir la Desinformación, dona desde S/ 1.00 a nuestro PLIN 943-438-457