GenAI: la ilusión de la inteligencia y la sobriedad según Luc Julia
Ambiente en la sala principal durante la ponencia inaugural. El escenario principal de Devoxx France 2025 acogió a Luc Julia para un discurso sin tapujos sobre la IA.
La conferencia inaugural marcó la pauta: Luc Julia —co-creador de Siri y director científico de Renault— pronunció un discurso cautivador y crítico sobre la inteligencia artificial y, más concretamente, sobre la IA generativa. El provocador título de su ponencia, «La inteligencia artificial no existe», ya dejaba claro a qué se refería. Según él, el propio término «IA» es fuente de confusión: estos sistemas, incluidos los modelos de lenguaje tipo GPT, no «piensan» y no tienen nada de inteligente en el sentido humano del término. Insistió en que detrás de ChatGPT no hay magia, solo estadísticas sobre enormes volúmenes de datos —lo que, por cierto, explica las respuestas a veces descabelladas o las«alucinaciones»que producen estos modelos.
Luc Julia desmontó así una serie de mitos al recordar que cada IA sigue estando especializada en un ámbito concreto y que la creatividad y el discernimiento siguen siendo prerrogativa del ser humano. Me llamó especialmente la atención su analogía de la IA como una simple «caja de herramientas»: nos corresponde a nosotros dominarla, entrenarla con datos fiables y utilizarla con acierto para tareas bien definidas. En cuanto a la ética, subrayó que la ética de la IA es, ante todo, la de sus creadores; en otras palabras, nos corresponde a nosotros establecer las normas de uso, exactamente igual que un martillo puede servir para construir o para herir, según la intención del usuario.
Por último, un mensaje contundente se centró en la sobriedad digital: «La IA generativa es una aberración ecológica», afirmó en esencia, respaldando sus palabras con cifras. Si se realizaran tantas consultas a un chatbot como se hacen a Google, el consumo de energía sería exorbitante e insostenible. Como profesionales, esto nos recuerda la necesidad de mantener la cabeza fría ante el bombo mediático: antes de implementar el último modelo de moda, asegurémonos de su relevancia para el negocio y de su eficiencia. Esta puesta en perspectiva de Luc Julia me pareció beneficiosa para abordar el resto de la conferencia con pragmatismo.
Normativa y seguridad: CRA, SBOM y DevSecOps en la práctica
A media mañana tuvo lugar una excelente charla centrada en el cumplimiento normativo y la seguridad, en torno a la nueva Ley de Ciberresiliencia (CRA) europea. Los ponentes (un equipo de Thales) detallaron los requisitos de esta futura normativa y su impacto en nuestras prácticas de DevSecOps. En pocas palabras, la CRA impondrá a los productos digitales una serie de obligaciones de seguridad desde el diseño y de seguimiento de las vulnerabilidades a lo largo de todo el ciclo de vida.
Diapositiva presentada por Thales en la que se enumeran los requisitos clave de la Ley de Ciberresiliencia: los principios de «seguridad desde el diseño» y la gestión proactiva de las vulnerabilidades.
Esta diapositiva resume bien la filosofía del CRA: integrar la seguridad desde el diseño (análisis de riesgos, configuración segura por defecto, control de accesos, protección de datos, reducción de la superficie de ataque, trazabilidad de las acciones sensibles…) e implantar una gestión de vulnerabilidades ejemplar (inventario de dependencias y fallos, pruebas de seguridad periódicas, corrección inmediata de vulnerabilidades, actualización continua y mecanismos de notificación de vulnerabilidades). En otras palabras, se acabaron los tiempos en los que se podía tratar la seguridad más tarde o «como algo opcional»: habrá que poder demostrar que nuestra aplicación respeta estas buenas prácticas de forma sistemática.
Un tema concreto que se abordó fue el papel de la SBOM (Software Bill of Materials): mantener actualizada la lista de todas las bibliotecas y componentes de código abierto utilizados, con sus versiones y posibles CVE, se ha convertido en algo indispensable para cumplir con los requisitos de transparencia de la CRA. En la práctica, esto significa integrar herramientas de análisis de dependencias y de vigilancia de vulnerabilidades en nuestros procesos de CI/CD. Los ponentes hicieron hincapié, además, en la automatización: ante la magnitud de los controles requeridos, solo unas herramientas DevSecOps permiten «escalar» el cumplimiento normativo.
Proceso de industrialización de la seguridad presentado en el marco del CRA: tan pronto como se detecta una vulnerabilidad, se integra una corrección y se implementa mediante la integración continua, con series de pruebas (unitarias, de no regresión y de rendimiento) antes de su puesta en producción.
Este esquema ilustra el enfoque DevSecOps recomendado para responder al CRA: hay que reducir al máximo el tiempo que transcurre entre el descubrimiento de una vulnerabilidad y su implementación en producción. Lo ideal es que, tan pronto como se detecte una vulnerabilidad (por ejemplo, en una biblioteca de terceros), el equipo de producción se haga cargo de ella inmediatamente, la corrija y, a continuación, active el proceso de CI/CD que probará la actualización (pruebas unitarias, de integración, de no regresión, de rendimiento...) para entregar una versión corregida sin demora. Se ve que estamos lejos del ciclo tradicional de gestión de parches de varias semanas: el tiempo real se convierte en la norma. Como responsable de DevSecOps, veo en este reto una oportunidad para acelerar aún más la automatización (escaneos de seguridad, implementaciones, generación de informes de conformidad) con el fin de transformar una restricción normativa en una ventaja de calidad. Es cierto que hacer malabarismos para cumplir con la normativa puede parecer una carga, pero, en definitiva, un producto más seguro y actualizado continuamente también supone menos incidentes y crisis que gestionar.
Seguridad de aplicaciones y pedagogía a través de la narración
La seguridad de las aplicaciones también tuvo su momento de gloria, de una forma muy original, a través de una presentación que se salió de lo convencional. Bajo el título «Érase una vez una vulnerabilidad: 5 historias de AppSec y lo que podemos aprender de ellas», la charla de Paul Molin (CISO de Theodo) cautivó al público utilizando la narración de historias para transmitir mensajes de seguridad. En lugar de enumerar buenas prácticas de forma magistral, contó historias reales de vulnerabilidades y ataques, un poco como si fueran cuentos modernos, para extraer de ellas lecciones concretas. El enfoque es refrescante y tremendamente eficaz para calar en la mente de los desarrolladores: se recuerda mucho mejor una anécdota impactante que la enésima lista de verificación de OWASP aprendida de memoria.
Una de las noticias más destacadas se refería a una fugamasiva dedatos que afectó a varias marcas francesas conocidas. El pasado mes de septiembre, un mismo atacante comprometió las bases de datos de clientes de varias marcas minoristas, dejando al descubierto millones de registros (nombres, correos electrónicos, números de teléfono…). Boulanger, Cultura, Grosbill, Truffaut… ninguna se libró, y todas tuvieron que enviar notificaciones urgentes a sus clientes para informarles del incidente.
Ejemplo de vulnerabilidades detectadas: en septiembre de 2024, los datos de clientes de al menos cuatro grandes cadenas francesas (Boulanger, Cultura, Grosbill, Truffaut) se filtraron tras el ataque de un mismo pirata informático, lo que puso de manifiesto las deficiencias de seguridad de estas empresas.
Este caso concreto ha permitido ilustrar varios puntos: por un lado, ni siquiera las grandes marcas están a salvo y un atacante motivado puede causar daños en cadena si existen vulnerabilidades comunes (pensemos en proveedores compartidos o fallos similares explotados en cada sitio web). Por otro lado, se ha analizado en profundidad la forma en que cada marca gestionó la comunicación de crisis, lo que subraya la importancia de la transparencia hacia los usuarios en caso de incidente. Al vivir esta historia desde el punto de vista del «malo» y de las víctimas, el público toma conciencia de los impactos reales de una brecha de seguridad, mucho más allá de la teoría.
Las demás historias abarcaban diversos ámbitos (desde una pequeña y peculiar vulnerabilidad en el front-end hasta un sofisticado ataque a una cadena de suministro de software), y en cada una de ellas había una moraleja o una lección para los desarrolladores y los arquitectos. Me encantó el enfoque de hacer que la seguridad resulte divertida y narrativa. Es una idea pedagógica a tener en cuenta: ¿por qué no incorporar este tipo de historias en nuestras formaciones internas o en nuestras campañas de sensibilización sobre seguridad? El storytelling, si se utiliza bien, puede transformar la seguridad en algo concreto y memorable, en lugar de que se perciba como una restricción abstracta.
Por otra parte, durante la pausa para comer, asistí a una charla breve sobre un tema de seguridad bastante atípico: el Port Knocking. Tras este nombre intrigante se esconde una técnica antigua, casi esotérica, para reforzar el acceso a un servidor. El principio: el servidor solo abre el puerto (por ejemplo, SSH) tras una secuencia concreta de «golpes» (conexiones a una serie de puertos en un orden acordado). Paul Jeannot nos ofreció una visión general de este método titulada «Port Knocking: el “Ábrete, Sésamo” del SSH». Fue una oportunidad para repasar este mecanismo de seguridad por oscuridad, bien conocido por los barbudos, y para debatir sobre su relevancia actual.
Diapositiva de conclusión de la charla sobre Port Knocking – En resumen: una solución interesante, sobre todo para pequeños servidores aislados o laboratorios domésticos, con clientes disponibles en todas las plataformas. Se trata de una barrera adicional que puede evitar ataques oportunistas, pero que resulta difícil de implementar a gran escala en el ámbito empresarial. En caso de utilizarla, conviene prever un mecanismo de OTP para evitar la repetición de secuencias.
La conclusión es clara: el «port knocking» puede aportar una pequeña capa adicional de seguridad (una «fricción salvadora» que detiene a los bots más básicos), pero pronto se vuelve molesto y complejo en una infraestructura de gran envergadura. Es mejor reservar este truco para casos muy específicos (servidores personales, laboratorios) y no abusar de él en entornos de producción. Me gustó que el ponente mencionara la incorporación de un código de un solo uso (TOTP) para reforzar el proceso si realmente se decide implementarlo, lo que demuestra que se puede modernizar un poco esta vieja receta. En resumen, un tema ligero pero instructivo, que nos recuerda que en seguridad no hay soluciones milagrosas: cada medida tiene sus límites y su contexto de aplicación.
Kubernetes, IaC, instantáneas… y observabilidad distribuida
Es imposible asistir a Devoxx sin hablar de infraestructura y tecnología nativa en la nube. Por la tarde se celebraron varias sesiones sobre Kubernetes, la infraestructura como código y la observabilidad, que agrupo aquí porque, en conjunto, definen los contornos del ecosistema moderno de DevOps y la nube.
En primer lugar, se nos presentó un panorama general de Kubernetes en 2025 (en particular, por parte de Alain Regnier durante una conferencia en la sala principal). Lo que me quedo de ello es que Kubernetes se ha impuesto como un estándar de facto, hasta el punto de que casi se nos olvida su presencia, ya que se ha vuelto tan habitual tener clústeres para todo y para cualquier cosa. La pregunta ya no es «¿Debemos adoptar K8s?», sino «¿Cómo hacerlo invisible para los desarrolladores y manejable para los de operaciones?». Se habló del auge de las ofertas gestionadas (para no tener que preocuparse más por el plano de control), de la creciente importancia de la optimización de costes (dejar de sobreaprovisionar clústeres o de lanzar 1000 pods cuando bastan 100) y de la tendencia hacia arquitecturas híbridas multicloud o edge que complican el panorama. En definitiva, Kubernetes ya no es la novedad de moda, sino una herramienta madura de la que ahora se busca pulir las asperezas (simplificar su uso, mejorar su seguridad intrínseca, etc.).
Hubo un tema concreto que me interesó especialmente: la gestión de datos y copias de seguridad en Kubernetes. Durante una charla técnica, redescubrí (con una demostración que lo ilustraba) las VolumeSnapshots de Kubernetes. Para quienes no lo conozcan, se trata de una funcionalidad que permite capturar una instantánea de un volumen persistente (PersistentVolumeClaim) —algo así como una copia de seguridad en caliente de tu disco conectado— y hacerlo directamente a través de la API de Kubernetes.
Fragmento de la demostración de Kubernetes: creación de una instantánea de volumen a través de la CLI. Se muestra la configuración del proyecto y del clúster, así como el uso de una CustomResourceDefinition (CRD) denominada «VolumeSnapshot» para iniciar la copia de los datos. Esta instantánea se podrá restaurar posteriormente si fuera necesario.
La demostración, realizada en Google Cloud (GKE), mostraba los comandos para configurar el proyecto y la región, y a continuación crear un recurso VolumeSnapshot de Kubernetes que apuntara a un disco persistente. Esto puso de manifiesto que no todo es nativo en Kubernetes: la compatibilidad con las instantáneas requiere que el proveedor de almacenamiento subyacente la implemente (en este caso, a través de los controladores CSI de GCP). En segundo plano, esta funcionalidad introduce nuevos objetos (CRD) en el clúster. Como entusiasta de la infraestructura como código, ver este tipo de mecanismo en acción es fascinante: se trata la infraestructura (en este caso, la copia de seguridad de volúmenes) «como código», activada por simples objetos YAML en el clúster, lo que abre el camino a la automatización de copias de seguridad y restauraciones, a la portabilidad de datos entre entornos, etc. Es el tipo de detalle que nos recuerda que, incluso una vez implantada la plataforma Kubernetes, siguen existiendo retos técnicos específicos para gestionar todo el ecosistema (almacenamiento, red, etc.) a través de IaC.
Hablemos precisamente de «Infrastructure as Code» (IaC): estuvo presente en casi todas las sesiones sobre infraestructura. Ya sea para describir implementaciones de Kubernetes, orquestar la nube con Terraform o incluso codificar políticas de seguridad, se ve que el enfoque declarativo está en todas partes. Un ejemplo destacado de la tarde fue la importancia de GitOps y del despliegue ultra simplificado. Una herramienta como Kamal (presentada en Tool-in-Action) promete desplegar una aplicación en «10 líneas de configuración», lo que indica que la comunidad busca abstraer cada vez más la complejidad de Kubernetes para volver a lo esencial (desplegar código). Por mi parte, observo en nuestros proyectos que la IaC se ha vuelto indispensable para la reproducibilidad y la trazabilidad: ya no se trata de crear un recurso a mano a través de la consola web sin tener su equivalente en Git. Este movimiento hacia la IaC total sigue, por tanto, acelerándose, con soluciones que compiten en ingenio para hacerlo accesible.
Otro gran tema técnico de la jornada: la observabilidad distribuida. Un dúo de ponentes (Alexandre Moray y Florian Meuleman) presentó las herramientas clave para salir adelante cuando la producción se cuelgue: ¡todo un programa! La idea principal: preparar a los desarrolladores (no solo a los de operaciones) para hacer frente a los incidentes en sistemas complejos. A menudo tenemos microservicios por todas partes, solicitudes que pasan por N archivos, M bases de datos… Cuando se produce una avería, hay que ser capaz de rastrear el hilo de ejecución y comprender dónde está el problema. La charla destacó el usode OpenTelemetry para instrumentar el código desde el principio, de forma estándar, con el fin de recopilar métricas y trazas que puedan explotarse más adelante. También promocionaron soluciones de código abierto como SigNoz, una plataforma de observabilidad que permite agregar y visualizar logs/trazas/métricas (una alternativa propia a Datadog y compañía). Lo que he retenido es que, al combinar OpenTelemetry (para la recopilación unificada) y una herramienta como SigNoz (para el análisis), se obtiene un ecosistema 100 % de código abierto, que se puede alojar uno mismo, para monitorizar las aplicaciones. Para nosotros, los profesionales de DevSecOps, es una buena noticia: podemos dotar a nuestros equipos de desarrollo de soluciones de observabilidad accesibles, sin tener que disparar el presupuesto en APM propietario y, sobre todo, integrándolas de forma nativa en el ciclo de desarrollo. En resumen, el mensaje fue: «la avería llegará tarde o temprano, estad preparados: colocad sensores por todas partes, cread paneles de control útiles y entrenaos para interpretar estas señales». Un importante recordatorio para no considerar la observabilidad como un lujo, sino como un componente esencial de la infraestructura desde el momento del diseño.
Código abierto y operadores inteligentes: el ejemplo de Burrito
Al final del día, otro tema me entusiasmó: el potencial del código abierto para mejorar nuestros flujos de trabajo de DevSecOps, ilustrado por una herramienta con un nombre sorprendente: Burrito. Bajo este nombre jocoso se esconde un Kubernetes Operator de código abierto desarrollado por Theodo, cuyo objetivo es simplificar la automatización de la infraestructura de Terraform. Los ponentes (Lucas Marques y Luca Corrieri) lo presentaron como un «TACoS», siglas de Terraform Automation & Collaboration Software. En pocas palabras, Burrito se posiciona como una alternativa libre a soluciones como Terraform Cloud/Enterprise: permite lanzar planes y aplicar Terraform de forma automatizada, activada por eventos (fusión de pull requests, push en una rama, etc.), con gestión de estados, accesos e incluso detección de desviaciones ( desviación entre la infraestructura codificada y la infraestructura real).
Me ha impresionado ver cómo Burrito se integra de forma nativa en Kubernetes, ya que funciona como un operador en el clúster. En la práctica, supervisa los recursos personalizados que representan tus pilas de Terraform y se encarga, en segundo plano, de gestionar los contenedores de Terraform que aplicarán los cambios. Así que seguimos en la línea de GitOps: en cuanto modifico la descripción de mi infraestructura en Git, el operador orquesta Terraform para reconciliar el estado real. Todo ello sin salir de mi clúster de Kubernetes y con la posibilidad de rastrearlo todo en los registros del clúster. Es bastante elegante y evita depender de un servicio SaaS externo.
Más allá del propio Burrito, esta charla pone de relieve una tendencia fundamental: la inteligencia en los operadores de Kubernetes. Hemos empezado a utilizar operadores para bases de datos, brokers, etc., y ahora los estamos ampliando a casos de uso de DevOps. Se están convirtiendo en auténticos directores de orquesta capaces de gestionar otras herramientas (en este caso, Terraform) al tiempo que se benefician del control de versiones, los permisos de K8s y la resiliencia del clúster. Para quienes nos dedicamos a DevSecOps, es una oportunidad de oro: podemos combinar el mundo de las plataformas (K8s) con el de la infraestructura como código de forma fluida. Y el hecho de que sea de código abierto significa que podemos adaptarlo, auditarlo, contribuir... En resumen, un buen ejemplo de proyecto comunitario útil, nacido de una necesidad real (cómo mejorar nuestros pipelines de IaC) y puesto a disposición de todos.
Salgo de la sesión sobre Burrito con un montón de ideas en la cabeza: ¿por qué no probar este enfoque en nuestros propios entornos de staging? Si cumple lo que promete, podría facilitarles la vida a nuestros equipos de infraestructura, al ofrecerles un Terraform-as-a-Service interno, controlado de principio a fin.
DEVOXX 2025: Entre la lucidez y el pragmatismo técnico
Esta primera jornada de Devoxx France 2025 ha sido intensa y ha abarcado un amplio abanico de temas, desde la visión estratégica (IA, normativa) hasta las herramientas concretas del día a día (Kubernetes, Terraform, seguridad de las aplicaciones). El hilo conductor que veo en ello, como profesional de DevSecOps, es la importancia de la transversalidad: lograr conectar los puntos entre estos mundos. Por ejemplo, integrar la IA de forma razonada en nuestros productos respetando al mismo tiempo las restricciones de seguridad y ética. O también, cumplir con las nuevas leyes (CRA) sin perder agilidad, gracias a la automatización. Se trata también de sensibilizar a los desarrolladores sobre la seguridad mediante métodos nuevos como el storytelling, al tiempo que se les proporcionan plataformas tecnológicas robustas (K8s, pipelines IaC equipados) y herramientas de código abierto innovadoras. En un solo día, he podido recargar las pilas con experiencias y buenas prácticas que estoy deseando compartir con mis compañeros y equipos. Devoxx France demuestra una vez más que uno se va con el entusiasmo de probar un montón de cosas nuevas. ¡Qué ganas de que lleguen las próximas sesiones y debates!
