- A medida que el descubrimiento de vulnerabilidades impulsado por IA supera la velocidad de respuesta de los mantenedores, Akrites se lanza como una colaboración de la industria para reforzar en conjunto el software open source esencial
- Descubrir vulnerabilidades graves antes era una tarea que les tomaba semanas a los especialistas, pero ahora los modelos de IA pueden encontrar varias vulnerabilidades en minutos, aumentando drásticamente la carga de respuesta
- AWS, Anthropic, Chainguard, Cisco, Citi, Ericsson, Google, IBM, Microsoft y GitHub, NVIDIA, OpenAI, Red Hat, Rust Foundation, entre otros, acordaron coordinar correcciones upstream y divulgación responsable
- Para reducir reportes duplicados y parches en conflicto, Akrites ofrece un punto de coordinación confidencial y un Security Incident Response Team dedicado; además, en paquetes esenciales sin mantenedores, actuará como mantenedor de último recurso
- Dado que después de la publicación de un parche los atacantes pueden usar IA para hacer ingeniería inversa de la vulnerabilidad, el criterio de éxito no es la publicación en sí, sino que el parche se despliegue en los sistemas reales
La velocidad de la seguridad open source transformada por la IA
- El open source es la base de la infraestructura y los servicios críticos de los que las personas dependen a diario, como bancos, telecomunicaciones y servicios públicos
- A medida que los mismos componentes open source se usan ampliamente en todo el stack tecnológico, muchos sistemas terminan compartiendo los mismos posibles defectos
- La IA cambia el equilibrio entre atacantes y defensores, y reduce la estructura de costos para descubrir y reutilizar vulnerabilidades
- Antes, descubrir vulnerabilidades graves les tomaba semanas a especialistas, pero ahora una máquina puede hacerlo en minutos
- En algunos casos, un modelo de IA devuelve varias vulnerabilidades en una sola ejecución
- Esa misma capacidad puede usarse para la defensa, pero si se abusa de ella, el descubrimiento de vulnerabilidades puede convertirse en una cadena de producción
La estructura en la que los reportes duplicados presionan a los mantenedores
- Los procesos tradicionales de respuesta y divulgación de seguridad funcionaban con varias organizaciones y equipos moviéndose de forma poco coordinada, por lo que podían abordar el mismo problema al mismo tiempo o generar parches en conflicto y múltiples reportes
- Si decenas de empresas escanean la misma biblioteca de forma independiente y cada una envía su propio reporte, el mantenedor queda sepultado por el ruido
- Cuantas más partes conozcan una vulnerabilidad aún sin parchear, mayor será la posibilidad de que se filtre antes de corregirse, y ese riesgo se extiende a todo el ecosistema
- Incluso una respuesta bien intencionada pero sin coordinación puede empeorar el problema y hacer perder tiempo
El enfoque de respuesta conjunta de Akrites
- Akrites se lanza como un esfuerzo para distribuir sistemas y herramientas compartidos destinados a encontrar, corregir y divulgar de forma responsable vulnerabilidades en software open source esencial
- Entre los participantes están Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft y GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone, Zscaler, entre otros
- El centro de la respuesta es el upstream que cuenta con mantenedores
- Proporciona un único espacio confidencial y basado en la confianza para coordinar el descubrimiento, la corrección y la divulgación de vulnerabilidades
- Un Security Incident Response Team dedicado se convierte para los mantenedores en un único socio predecible, en lugar de numerosos reportes no coordinados
- Las correcciones se devuelven a los repositorios originales de cada proyecto y al flujo de sus mantenedores
- Si un paquete esencial no tiene mantenedores, Akrites afirma que asumirá el rol de mantenedor de último recurso para que las correcciones puedan entregarse a tiempo
Por qué el despliegue importa más que la publicación del parche
- Cuando se publica un parche, los atacantes pueden usar IA para hacer rápidamente ingeniería inversa de la vulnerabilidad real, desarrollar exploits e iniciar ataques
- Por lo tanto, el éxito de Akrites debe medirse no por si el parche fue publicado, sino por si fue desplegado en los sistemas reales
- Akrites busca aumentar el nivel de coordinación trabajando con propietarios y operadores de infraestructura crítica, esfuerzos de la sociedad civil y gobiernos
- La confidencialidad no es negociable, y como las fallas no divulgadas en paquetes ampliamente distribuidos son, en la práctica, como armas, evitar filtraciones es prioritario
La carga y los compromisos que destacaron las organizaciones participantes
- Endor Labs señaló que, entre miles de vulnerabilidades open source identificadas en los últimos meses, la proporción parcheada fue inferior al 5%
- OpenInfra indicó que la comunidad OpenStack emitió 20 avisos de seguridad solo este trimestre, mientras que en todo 2025 fueron 2
- JPMorganChase considera que, como la IA comprimió el tiempo entre el descubrimiento y la explotación de vulnerabilidades hasta acercarlo a tiempo real, también debe reducirse el tiempo desde la corrección hasta el despliegue
- Chainguard, Sonatype, RapidFort, Red Hat y otros sostienen que la corrección de vulnerabilidades debe realizarse mediante coordinación upstream, dentro del software original y los flujos de sus mantenedores, en lugar de dispersarse en forks o detrás de muros privativos
- Las organizaciones participantes prometieron aportar personal de ingeniería, experiencia en seguridad, financiamiento y tecnología de IA para fortalecer el software compartido
1 comentarios
Opiniones de Hacker News
Muchos involucrados en el open source no pueden evitar ver con escepticismo la lista de empresas participantes, y con razón.
La clave es cómo se va a implementar eso de “encontrar, corregir y divulgar responsablemente las vulnerabilidades en software open source crítico”. Si contribuyen por los canales existentes y con pull requests, pueden avanzar junto con la comunidad; pero si hacen forks con el pretexto de la “seguridad”, pueden dejar de lado a la comunidad, dividir recursos y a largo plazo matar muchos proyectos. Los bug bounty tienen potencial, pero para bugs críticos puede que no encajen ni la velocidad ni el momento de la divulgación, y el apoyo financiero también tiene un efecto limitado si no se combina con apoyo a los maintainers
PQCA usa créditos de AWS para acceder a hardware y correr pruebas y CI, y también opera mentorías pagadas. OWF también ofrece créditos de AWS y hosting de servicios para testing. LFDT ha venido ofreciendo mentorías pagadas, costos de revisiones de Trail of Bits, operación de eventos, la cumbre de maintainers en Nueva York y soporte para runners grandes de GitHub CI. Nuestro equipo, según los estándares de relaciones con desarrolladores de OWF/PQCA/LFDT, solo tiene 3 empleados de tiempo completo, 1 contratista y 1 manager, pero trabajamos bastante duro para ayudar a los desarrolladores.
LFDT: https://www.lfdecentralizedtrust.org/
OWF: https://openwallet.foundation/
PQCA: https://pqca.org/
Ejemplo de benchmark de PQCA: https://pq-code-package.github.io/mldsa-native/dev/bench/
Sea cual sea la forma que tome esto, debe estar distribuido para que ninguna ubicación central única ni ninguna entidad única pueda ejercer el control
Se habla de contribución financiera, pero también importa cómo y para qué se haría. La mayoría de los proyectos no están listos para recibir o aprovechar donaciones. Aun así, estaría bien que todos los proyectos open source pudieran recibir un acceso considerable a IA para poder revisar sus codebases y pull requests y así reducir la carga de mantenimiento, y ya hay algunos intentos en esa dirección
No es más que teatro corporativo.
Microsoft dice que “aportará experiencia, recursos y tecnología de IA para identificar y corregir vulnerabilidades de forma responsable”, pero Microsoft opera NPM y GitHub, y tiene acceso a los mejores modelos de IA y a enormes centros de datos. Aun así, la seguridad de sus propios productos se está deteriorando rápidamente, y sus servicios se están convirtiendo en hubs centrales desde donde se propagan múltiples exploits.
Si quieren ver cómo maneja Microsoft los problemas de seguridad en sus propios proyectos open source, recomiendo este hilo de GitHub: https://github.com/dotnet/efcore/issues/38257
EF Core actualmente distribuye una versión de SQLite con una vulnerabilidad grave. Este problema se descubrió hace más de un año y SQLite lo corrigió en una semana, pero EF Core no marcó el driver como vulnerable hasta que recientemente un usuario lo volvió a reportar y discutió con los desarrolladores. La corrección para la versión estable actual de .NET Core está prevista, más o menos, dentro de dos meses
Después de la adquisición, en vez de continuar esa línea con VSCode, Microsoft creó un ambiente de desprecio hacia Electron, y ahora mucha gente odia Electron sin poder explicar por qué. VSCode ni siquiera hizo un fork de Atom; hizo algo parecido desde cero, terminó siendo más grande y más lento, y ahora además tiene Copilot encima. Al final volví a Pulsar, un buen fork de Atom.
Microsoft siempre adquiere viendo oportunidades y escenarios de competencia, pero rara vez aprovecha bien lo que compra. Elimina buen personal y buen código, y arruina los productos. Aun así, no entiendo por qué todo el mundo sigue usando productos de Microsoft. Hay que dejar LinkedIn e irse juntos a otro sistema de control de versiones. Mientras los desarrolladores open source no lo demuestren con acciones y no solo con palabras, Microsoft va a seguir empeorando cada vez más
No vamos a hacer eso. Vamos a hacer grandes declaraciones, dejar que las empresas comerciales lo arruinen, y luego quejarnos muchísimo del estado de las cosas aunque en realidad no hayamos hecho nada
Creo que a partir de ahora va a surgir una corriente que yo llamo undo fork. Es un fork para volver a pensar las cosas regresando al punto anterior a que empezara la locura, y es algo que solo pueden hacer quienes no están atados a exigencias comerciales
Siempre les aconsejo a quienes se interesan por el open source que se mantengan lejos de la Linux Foundation. Hoy en día se ha convertido en una barrera que estorba, en vez de hacer posible, la libertad del software
Para defender el open source hay que empezar no con palabras, sino con apoyo real a los proyectos y a los desarrolladores
Desde la perspectiva de un desarrollador de OpenBSD, es realmente importante proporcionar hardware nuevo a los desarrolladores. Muchos trabajan con ThinkPad de hace 5 a 10 años que ya necesitan reemplazo
https://www.openbsd.org/want.html
A la OpenBSD Foundation todavía le falta alrededor del 50% para alcanzar su meta de recaudación de 2026
https://www.openbsdfoundation.org/campaign2026.html
https://brynet.ca/wallofpizza.html
En la parte donde dice “Amazon Web Services participa”, toda la credibilidad de este texto desaparece
Esto se lee como un intento de centralización y control. Sea quien sea Akrites, solo va a darles a las grandes tecnológicas, incluido Google, el poder de controlar el open source
Gracias, pero paso. Recuerdo lo que Google está intentando hacer este septiembre en Android: bloquear la instalación de terceros mediante
.apkSobre esto, la mayoría de la gente inteligente que conozco cree que la IA open source hace financieramente inviable a Anthropic y OpenAI. Muchas de las empresas que aparecen aquí están muy involucradas con esas dos, y tienen un gran incentivo para desestabilizar la IA open source antes de que sus clientes sientan el golpe de precios. He estado esperando cuál sería su siguiente movimiento, y esto podría ser parte de eso
La información más importante es la parte que dice que los participantes aportarán recursos de ingeniería
Habrá que ver si eso ocurre según lo planeado. Fuera de eso, no me impresiona mucho lo que este proyecto afirma. Es una estructura favorable a la centralización y a redes centradas en corporaciones, justo en la dirección opuesta a la que la ética hacker ha promovido por buenas razones
También podría convertirse en otra fuente de presión. Puede que sí filtre bien las vulnerabilidades reales, pero el resultado igual terminará llegando a los maintainers con alta prioridad. Muchos maintainers ya están agotados incluso sin ruido generado por IA, y aunque se proporcione un parche, igual hace falta revisarlo
En el mejor de los casos puede reducir el ruido, pero el trabajo sigue ahí. La industria debería financiar de manera general para que los proyectos open source tengan la capacidad de manejarlo por sí mismos. Eso probablemente también sería lo mejor para la calidad. Si hay que filtrar ruido de IA, se puede añadir esa función, pero no debería ser mediante una estructura secreta y opaca que lo controle todo
Estoy esperando el día en que vea titulares como “Todos dependemos del open source. Lo vamos a financiar juntos”
Me gusta el nombre “Akrites”
Puede impresionar menos a quienes no son griegos, pero para los griegos tiene una imagen bastante fuerte
akron significa borde o frontera, así que vendría a ser algo como “los de la frontera” o “la gente del límite”. El punto clave aquí es que no se pueden proyectar sin más los conflictos o prejuicios modernos sobre una historia de hace mil años. En su contexto histórico, era similar a muchas fronteras entre civilizaciones distintas, y lo importante es que se trataba de una organización colectiva reunida para defender su propia tierra
[1] https://en.wikipedia.org/wiki/Mark_Carney%27s_Davos_speech
No creo que tenga mucho sentido publicar algo así en Hacker News. La mayoría aquí ha asumido profundamente la ola de la IA y no le presta mucha atención
Además, muchas de las empresas de la lista son las principales sospechosas de que el open source haya llegado al estado en que está ahora
Eso sí, coincido en que muchas de las empresas de la lista son las principales sospechosas del estado del open source. Esto parece un anuncio de relaciones públicas para lavarles la cara, y cuesta creer que de verdad les importe la ética del open source