# linskens-sonatype-securite-vitesse-ia-quatre-ans-2026-08-18

## Veille

Entrada de blog de **Sonatype** por **Aaron Linskens** (*technical writer*), publicada el **18 de agosto de 2026**, ~1.300 palabras: relata un estudio de **Sonatype Research Labs** que abarca **49 meses** (junio de 2022 — junio de 2026) y una **cohorte fija** de aplicaciones empresariales, una elección metodológica presentada como una forma de aislar la evolución de la flota de aplicaciones más que la de la cartera de clientes. El resultado se presenta como una contradicción: la remediación es más rápida, pero el riesgo se acumula aún más. (A) **El stock aumenta** — vulnerabilidades *Critical* y *High* por aplicación **×4,31** (de **14,14** en junio de 2022 a **54,3** en 2026, aún **×3,91** excluyendo las aplicaciones legadas recién incorporadas a la gestión), versiones de componentes recién afectadas al **46×** de la tasa previa a la IA, creación mensual de aplicaciones **×4,84**. (B) **La remediación mejora** — más de la mitad de las violaciones resueltas se resuelven en menos de un día, la edad mediana de las vulnerabilidades *Critical/High* sin resolver baja de **228** a **126 días**, luego a **103** en mayo de 2026; entre las cohortes que dispusieron de doce meses, **52,6%** están resueltas, **44,3%** abiertas, **3,1%** bajo dispensa. (C) **La palanca propuesta es la selección de componentes**: en el momento en que se eligió una dependencia vulnerable, ya existía una versión sustancialmente menos arriesgada en **62,2%** de los casos en **Maven**, **46,9%** en **npm**, **34,3%** en **PyPI** — una brecha que el texto atribuye a un problema de información más que a una falta del desarrollador. La propia entrada afirma que la IA no es la única causa de la aceleración, y concluye con **Sonatype Guide**, que lleva esta inteligencia hasta el momento de la selección. En el plano de la cadena de suministro, prolonga lo que [[fiches/2026-08/staples-gitlab-when-code-is-abundant-2026-08-24]] plantea en términos económicos y [[fiches/2026-07/clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] en términos de ciclo seguro.

## Titre Article

Securing Software at the Speed of AI: What Four Years of Data Reveal

## Date

2026-08-18

## URL

https://www.sonatype.com/blog/securing-software-at-the-speed-of-ai-what-four-years-of-data-reveal

## Keywords

cadena de suministro de software, cadena de suministro de software, Sonatype Research Labs, cohorte fija, estudio longitudinal, vulnerabilidades Critical y High, aviso de vulnerabilidad, versiones de componentes afectadas, dependencias de código abierto, selección de componentes, versión menos arriesgada, edad mediana de vulnerabilidades, tiempo de remediación, dispensa, Maven, npm, PyPI, prevención frente a remediación, asistente de codificación con IA, inteligencia de componentes, política organizacional, Sonatype Guide, The AI-Era Software Assembly Line, era de la IA

## Authors

Aaron Linskens, *technical writer* chez Sonatype, sur le blog de l'éditeur ; les chiffres sont produits par Sonatype Research Labs, non par l'auteur.

## Ton

Perfil: entrada de blog corporativo que relata un estudio — formato corto, cinco subtítulos, una lista de cifras por sección, tono mesurado y sin énfasis, dirigido a responsables de seguridad de aplicaciones, equipos de plataforma y decisores de compra de herramientas. El registro es el de un **informe respaldado por datos**: cada afirmación se ancla a una medición, los porcentajes se dan con su base (número de meses, periodos de comparación, ecosistemas nombrados por separado), y el método se expone antes de los resultados. Dos gestos de precaución son explícitos en el texto, algo poco habitual en este formato: se reconoce la pluralidad de causas (*« la IA por sí sola no causó esta aceleración »*, con cuatro factores alternativos nombrados, incluida la mejora de la propia investigación de vulnerabilidades), y la brecha medida en la elección de versiones se retira expresamente del registro de la culpa (*« Esto no debe interpretarse como un fallo del desarrollador »*). La retórica se apoya en una **contradicción aparente** planteada de entrada y sostenida a lo largo del texto: remediación más rápida, mayor riesgo acumulado, de ahí el desplazamiento de foco propuesto hacia la fase previa. La intención comercial se asume en la sección final, que nombra el producto y lo vincula con la cifra que lo motiva. La autoridad descansa en la posición de observatorio del proveedor — un catálogo de avisos de vulnerabilidad, una flota de aplicaciones instrumentada — y la entrada remite al informe completo, *The AI-Era Software Assembly Line*, para los datos subyacentes.

## Pense-betes

- **La contradicción es el resultado principal**, y es aritmética antes que estratégica: la remediación se acelera (edad mediana **228 → 126 → 103 días**) mientras el stock por aplicación se cuadruplica (**14,14 → 54,3** *Critical/High*). Remediar más rápido no basta cuando el flujo entrante crece más rápido que la capacidad de procesamiento.
- **El riesgo de una aplicación se mueve incluso cuando su código no lo hace.** Formulación directa de la entrada: una dependencia considerada aceptable ayer puede recibir una divulgación mañana, quedar sin mantenimiento, o ver publicarse una versión más segura. Consecuencia para el monitoreo interno: un inventario congelado no es un estado de seguridad, y la ausencia de commit no es la ausencia de evento.
- **La cifra más accionable es la de la versión disponible**: en el momento de la selección, ya existía una versión sustancialmente menos arriesgada en **62,2%** de los casos en **Maven**, **46,9%** en **npm**, **34,3%** en **PyPI**. La brecha entre ecosistemas es en sí misma un dato — ordena dónde la prevención rinde más.
- **Dos causas distintas detrás del mismo síntoma**: algunas vulnerabilidades son inevitables (el ecosistema no ofrece una opción más segura), otras son **problemas de información** (quien elige — humano o asistente — carece del contexto adecuado en el momento de la elección). Solo la segunda clase es abordable mediante herramientas en el punto de selección.
- **El punto de tensión propio de la IA**, tal como lo plantea la entrada: un asistente puede recomendar e introducir un componente en segundos, pero *« una recomendación rápida no es necesariamente una recomendación informada »* — necesita inteligencia **actualizada** sobre el riesgo, las versiones disponibles, el mantenimiento y la política interna, algo que el conocimiento congelado en los pesos del modelo no garantiza.
- **Lo que la entrada no cuantifica**, y debería solicitarse al informe completo antes de citarlo: el **tamaño de la cohorte** (no se da número de aplicaciones), el **valor del pico de enero de 2024** — la disminución del **59%** se refiere a él, mientras que la disminución del **45%** parte de 228 días, por tanto dos líneas base distintas —, y la **fecha de inicio de "la era de la IA"**, usada como límite de comparación sin ser definida.
- **La honestidad causal la sostiene el propio texto**: se nombran cuatro factores alternativos a la IA para la expansión del panorama de vulnerabilidades — mejor investigación, mejor divulgación, investigación de seguridad asistida por IA, y comportamiento cambiante de los atacantes. La postura adoptada es pragmática: *« Las organizaciones no necesitan probar una causa única para afrontar el resultado. La escala en sí misma es el problema. »*
- **Relacionado**: [[fiches/2026-08/claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]] (la skill aconseja, el hook restringe — aquí, la política de componentes es exactamente lo que más gana al volverse determinista en el momento de la elección) y [[fiches/2026-07/sfeir-code-review-anneau-contraintes-2026-07-30]] (el anillo de restricciones alrededor del agente, del cual la selección de dependencias es un eslabón previo raramente instrumentado).

## RésuméDe400mots

Sonatype publica, escrita por su *technical writer* Aaron Linskens, una síntesis de un estudio longitudinal de sus laboratorios de investigación que abarca cuarenta y nueve meses, de junio de 2022 a junio de 2026. El método se expone de entrada: una cohorte fija de aplicaciones seguida de forma continua, de modo que las variaciones medidas reflejen la evolución de la flota de software más que la de la cartera de clientes. El resultado central se presenta como una contradicción: las organizaciones remedian más rápido que antes, pero sus aplicaciones acumulan más riesgo.

Cuatro medidas enmarcan el hallazgo. Las vulnerabilidades *Critical* y *High* por aplicación se multiplicaron por 4,31, pasando de un promedio de 14,14 en junio de 2022 a 54,3 en 2026; el efecto no se debe únicamente al legado, ya que excluyendo las aplicaciones legadas recién incorporadas a la gestión el factor sigue siendo de 3,91. Las versiones de componentes recién afectadas avanzan a cuarenta y seis veces la tasa previa a la IA. La edad mediana de las vulnerabilidades ha caído un 59% desde su pico de enero de 2024. Por último, la creación mensual promedio de aplicaciones se multiplicó por 4,84, y con ella las decisiones de dependencias.

El progreso en la remediación es real: más de la mitad de las violaciones resueltas se resuelven en menos de un día, y la edad mediana de las vulnerabilidades *Critical/High* sin resolver baja de 228 a 126 días, luego a 103 días en mayo de 2026. Entre las cohortes que dispusieron de al menos doce meses para actuar, el 52,6% están resueltas, el 44,3% permanecen abiertas y el 3,1% están bajo dispensa.

El giro propuesto concierne a la fase previa. Los investigadores examinaron las dependencias vulnerables que entraron en las aplicaciones del periodo y se plantearon una pregunta simple: en el momento de la selección, ¿existía ya una versión sustancialmente menos arriesgada? La respuesta es sí en el 62,2% de los casos en Maven, el 46,9% en npm y el 34,3% en PyPI. El texto se niega a interpretar esto como una falta del desarrollador: algunas vulnerabilidades son inevitables, otras provienen de una brecha de información en el momento de la elección — un punto que se vuelve sensible cuando un asistente de IA puede introducir un componente en segundos sin disponer de inteligencia actualizada sobre su riesgo y sobre la política organizacional.

La entrada reconoce que la IA no es la única causa de la expansión del panorama de vulnerabilidades y cita cuatro factores concurrentes. Concluye con Sonatype Guide, que lleva esta inteligencia hasta el momento de la selección, y remite al informe completo, *The AI-Era Software Assembly Line*, para los datos subyacentes.

## GrapheDeConnaissance

- Sonatype —publie→ Securing Software at the Speed of AI (DOCUMENT, 0.97)
- Aaron Linskens —a_créé→ Securing Software at the Speed of AI (DOCUMENT, 0.94)
- Sonatype Research Labs —fait_partie_de→ Sonatype (ORGANISATION, 0.92)
- Sonatype Research Labs —mesure→ vulnérabilités Critical/High par application ×4,31 entre juin 2022 et juin 2026 (MESURE, 0.94)
- Sonatype Research Labs —mesure→ 14,14 vulnérabilités Critical/High par application en juin 2022, 54,3 en 2026 (MESURE, 0.93)
- Sonatype Research Labs —mesure→ versions de composants nouvellement affectées à 46× le rythme d'avant l'IA (MESURE, 0.9)
- Sonatype Research Labs —mesure→ âge médian des Critical/High non résolues de 228 à 126 jours, puis 103 jours en mai 2026 (MESURE, 0.93)
- Sonatype Research Labs —mesure→ création mensuelle moyenne d'applications d'entreprise ×4,84 (MESURE, 0.9)
- Sonatype Research Labs —mesure→ une version moins risquée était déjà disponible dans 62,2 % des cas sur Maven, 46,9 % sur npm, 34,3 % sur PyPI (MESURE, 0.93)
- cohorte fixe d'applications —permet→ isoler l'évolution du parc plutôt que celle du portefeuille clients (CONCEPT, 0.9)
- Securing Software at the Speed of AI —affirme_que→ la remédiation s'accélère alors que le risque accumulé par application augmente (AFFIRMATION, 0.94)
- Securing Software at the Speed of AI —affirme_que→ le profil de sécurité d'une application change sans que son code change (AFFIRMATION, 0.92)
- Aaron Linskens —affirme_que→ l'IA n'est pas la cause unique de l'expansion du paysage de vulnérabilités (AFFIRMATION, 0.92)
- Aaron Linskens —affirme_que→ l'écart de version relève d'un défaut d'information, pas d'une faute de développeur (AFFIRMATION, 0.9)
- sélection de composant —réduit→ travail de remédiation en aval (CONCEPT, 0.89)
- Aaron Linskens —recommande→ déplacer la question du délai de correction vers le choix de la dépendance (AFFIRMATION, 0.9)
- Sonatype Guide —s_applique_à→ point de sélection du composant, y compris dans les flux assistés par IA (CONCEPT, 0.91)
- assistants de codage IA —utilise→ intelligence courante sur le risque et la politique, non figée dans le modèle (CONCEPT, 0.88)
- The AI-Era Software Assembly Line —est_basé_sur→ cohorte fixe d'applications (METHODOLOGIE, 0.89)

---
Canonical: https://www.thekb.eu/es/fiches/linskens-sonatype-securite-vitesse-ia-quatre-ans-2026-08-18/