el codigo abierto se ha vuelto tan omnipresente que hoy aparece en el 98% de las bases de código analizadas, según el informe 2026 Análisis de riesgos y seguridad de código abierto (OSSRA) de Pato Negro. Esto tiene una lectura práctica: aunque tu equipo escriba el “corazón” de una aplicación desde cero, una parte enorme de lo que ejecuta proviene de dependencias de terceros. Es como montar un coche propio usando piezas compradas a Múltiples proveedores: puedes controlar el diseño, pero la calidad de los frenos o del airbag depende de otros.
Con esa universalidad llega el llamado riesgo de terceros: vulnerabilidades, licencias incompatibles, componentes desactualizados y, ahora, algo nuevo que acelera todo lo anterior: la creación de código asistida por IA y la integracion de modelos de IA dentro de los productos.
El salto de vulnerabilidades: más rápido de lo que la seguridad puede seguir
El OSSRA 2026 se apoya en el análisis de 947 bases de código en 17 industrias. Su dato más llamativo es el incremento del 107% en los medios de vulnerabilidades por base de código. No es un matiz: es una duplicación en términos prácticos.
El informe también señala que el número de componentes de código abierto creció un 30% interanual y que el número de archivos por base de código aumentó un 74%. Traducido a lenguaje cotidiano: no solo hay más ingredientes en la receta, también hay más páginas en el libro de cocina. Si tu proceso de revisión sigue siendo el de hace dos o tres años, el atasco está garantizado.
Aquí la IA no aparece solo como “culpable”, sino como acelerador de la producción. Si antes tardabas días en generar un módulo, ahora puedes tenerlo en horas. El problema es que las practicas de seguridadlos flujos de gestión de vulnerabilidades y la gobernanza del cadena de suministro El software rara vez se acelera al mismo ritmo.
La nueva superficie de ataque: modelos de IA como “dependencias” sin control
El informe introduce una idea relevante: la adopción de modelos de IA crea una superficie de ataque “nueva” y todavía poco regulada. Cuando una aplicación integra un modelo (propio o de terceros), no solo suma un paquete más; añade un elemento opaco, difícil de auditar y con riesgos específicos.
Piensa en un modelo como en un “motor” que no puedes abrir con herramientas convencionales. Puedes medir cómo se comporta, pero no siempre puedes inspeccionar a fondo qué contiene, cómo se entrenó, qué datos influyeron y qué vías abren un nivel de seguridad. Si ese modelo se actualiza, cambia el comportamiento del sistema. Si se conecta a otros servicios, amplía los puntos de entrada. Y si se usa para generar código, su huella se multiplica en forma de fragmentos que se cuelan en repositorios y productos.
Por eso el OSSRA advierte que no basta con gestionar dependencias tradicionales: hay que tratar los modelos de IA con un rigor parecido al del fuente abierta.
Riesgos legales y de propiedad intelectual: cuando la IA “recuerda” demasiado
Uno de los puntos más delicados es el de licencias y propiedad intelectual. Black Duck alerta de que el código generado por IA puede reproducir fragmentos bajo licencias restrictivas como GPL oh AGPLlo que introduce riesgos de cumplimiento si ese código se incorpora a un software con otra política de licenciamiento.
El dato asociado es contundente: dos tercios de las bases de código auditadas presentes conflictos de licenciasel porcentaje más alto registrado por la serie OSSRA. En 2026 se habla de un 68%, frente al 56% del año anterior; un salto de 12 puntos, el mayor aumento anual registrado por el estudio.
Esto suele pasar de forma silenciosa. La IA te entrega algo que “funciona”, el desarrollador lo integra, el producto sale, y meses después aparece el problema: una auditoría, un cliente corporativo pidiendo garantías, o un proceso de due diligence en una compra. De pronto, ese bloque de código es como una pegadiza que tarareas sin saber que tiene derechos de canción de autor: no era mala intención, era falta de trazabilidad.
No basta con “revisar seguridad”: la brecha en licencias y calidad
Otro hallazgo interesante del OSSRA 2026 es la disparidad en los controles. El 76% de las organizaciones dice revisar el código generado por IA para riesgos de seguridadpero solo el 54% lo evalúa para IP y licenciasy el 56% revisa calidad.
Lo más preocupante es el resumen: solo el 24% realiza evaluaciones completas que cubran a la vez IP, licencias, seguridad y calidad para el código generado por IA.
Es una situación parecida a inspeccionar un edificio mirando solo la instalación eléctrica, ignorando si los materiales cumplen con la normativa o si los cimientos tienen grietas. Puedes evitar un cortocircuito, pero acabar con un problema estructural.
SBOM y trazabilidad: el inventario que determina si sobrevive a una auditoría
La recomendación central del informe se apoya en un concepto que cada vez suena más fuera del ámbito “seguridad”: el SBOM (Software Bill of Materials), el inventario detallado de componentes que forman una aplicación. Sin un SBOM confiable, gestionar riesgos se vuelve una lotería, porque no sabes con precisión qué tienes, de dónde viene, ni qué hay que parchear cuando estalla una vulnerabilidad.
Black Duck plantea que las organizaciones no podrán cumplir con las regulaciones próximas, como el Ley de Resiliencia Cibernética (CRA) de la UEsi no mejoran la precisión del SBOM, los flujos de trabajo de vulnerabilidades y la gobernanza de modelos de IA. La frase “rastrear modelos con el mismo rigor que componentes open source” es clave: si el modelo participa en tu cadena de suministro, debe quedar inventariado, versionado y gobernado.
En la práctica, esto implica poder responder preguntas muy básicas, pero que muchas empresas hoy no pueden contestar con seguridad: ¿qué versión exacta del modelo se usamos? ¿Con qué datos se entrenó o ajustó? ¿Qué repositorios recibieron código generado? ¿Qué política de reciclaje existe? ¿Qué dependencias se agregaron como resultado?
Políticas internas: de la improvisación al uso responsable de IA
El OSSRA no se limita a decir “hay riesgo”; empujar hacia cambios concretos. Habla de la necesidad de políticas claras sobre el uso de IA, y sobre todo sobre reentrenamiento y actualizacion de modelos. Es una llamada de atención a la gobernanza: si el desarrollo se apoya en IA, la empresa necesita reglas, no solo recomendaciones.
Un ejemplo sencillo: si tu equipo usa asistentes de código, ¿qué se permite pegar en el aviso? ¿código propietario? ¿fragmentos de clientes? ¿incidencias con datos sensibles? ¿Cómo se registra qué se generó y dónde se nosotros? Sin una guía, cada desarrollador decide “sobre la marcha”, y eso es justo lo que las auditorías y los incidentes acaban castigando.
La economía del software ha cambiado, y la del riesgo también
Jason Schmitt, CEO de Black Duck, lo resume con una idea que merece atención: la IA ha cambiado la economía de crear software y, con ella, la economía del riesgo. Si producir es más barato y rápido, también lo es introducir dependencias nuevas, copiar patrones inseguros y acumular deuda técnica a gran velocidad. La seguridad deja de ser una “fase” y pasa a ser un sistema de control continuo, como el mantenimiento de una flota: no revises un coche una vez al año si está recorriendo el triple de kilómetros.
Lo importante aquí no es demonizar la IA. La promesa de productividad es real y útil. El punto es que, si tu organización acelera el desarrollo sin acelerar la gobernanza, estás ampliando el ataque y la exposición legal en paralelo.
Qué deben leer entre líneas los equipos técnicos y de negocio
El mensaje más útil del OSSRA 2026 es casi administrativo: el reto ya no es solo “escribir software seguro”, sino gestionar una cadena de suministro que crece sin parar. Con IA generando más código y con modelos entrando en productos, el inventario, la trazabilidad y el cumplimiento pasan a ser tan estratégicos como la arquitectura.
Para equipos de negocio, esto se traduce en riesgos de costo y reputación: incidentes de seguridad, retrasos por remediación, contratos bloqueados por auditorías, o conflictos de licencias que se descubren tarde. Para equipos técnicos, supone profesionalizar el pipeline: automatización de análisis, procesos de aprobación, disciplina de dependencias, y visibilidad real sobre qué entra y por qué.
