Jonathan Lalou's Blog

Posts Tagged ‘DevoxxFR2026’

Lecturer

Anaïs Moulin is a Product Owner at Ippon Technologies with nearly five years of experience. As a person with hearing impairment, she brings firsthand insight into accessibility challenges in professional environments and advocates for inclusive practices using both human-centered approaches and AI tools.

Abstract

Meetings that drag on, lost information, and mental fatigue affect many participants, particularly those with invisible disabilities. Anaïs Moulin shares immediately applicable techniques for making daily standups, team meetings, and conferences more accessible. Combining proven facilitation methods with AI-powered tools for transcription, subtitling, and summarization, she demonstrates how small adjustments significantly improve inclusion and productivity. Based on her experience as a hearing-impaired Product Owner, the talk illustrates that accessibility enhances overall meeting quality for everyone.

The Prevalence and Impact of Invisible Disabilities in Professional Settings

According to French disability statistics, over nine million people live with invisible disabilities—one in seven individuals. These include sensory impairments, neurodivergence, chronic illnesses, and more. In workplace meetings, participants frequently encounter barriers: information delivered solely verbally, poor acoustics in open spaces, lack of visual aids, and insufficient opportunities for alternative participation.

Such obstacles lead to missed details, increased cognitive load, stress, and disengagement. The problem extends beyond those with diagnosed conditions—fatigue, language barriers, or suboptimal environments affect broad audiences. Making meetings inclusive benefits the entire team by improving information retention and collective understanding.

Common Obstacles in Everyday Meetings

Verbal-only delivery of critical information poses immediate challenges for hearing-impaired individuals and those with different memory preferences. Noisy environments, such as open-plan offices with adjacent meeting rooms, compound difficulties in focusing and comprehending speech. The absence of real-time tools for following discussions—chat, transcription, or shared visuals—further excludes participants. Finally, dominant speaking patterns that fail to include everyone reduce engagement and motivation.

These issues are not insurmountable. Simple, low-effort changes can transform meeting dynamics.

Actionable Checklist for Inclusive Meetings

Preparation forms the foundation. Sharing agendas, objectives, and supporting documents in advance allows participants to familiarize themselves with content and arrive mentally ready. Visual supports—shared backlogs, diagrams, or live demonstrations—provide reference points that complement verbal explanations.

During meetings, structured speaking turns ensure everyone has opportunities to contribute. Speakers should maintain a moderate pace, clear articulation, and direct engagement with all attendees. Offering alternatives to verbal participation, such as chat contributions or emoji reactions, accommodates different comfort levels.

Technical setup matters significantly. Ensure quality microphones, proper camera positioning for lip-reading support, and reliable audio sources. Post-meeting summaries with action items create a shared record, reducing reliance on real-time comprehension alone.

These practices require minimal additional effort yet yield substantial improvements in clarity and inclusion.

Leveraging AI Tools to Enhance Accessibility

Modern AI capabilities remove many traditional barriers without significant overhead. Platforms like Microsoft Teams and Google Meet offer real-time subtitling that aids comprehension in noisy or multilingual settings. Transcription features in tools such as Notion or dedicated services capture discussions for later review.

NotebookLM enables users to upload meeting recordings or documents and generate concise summaries or even podcast-style explanations tailored to specific needs. Large language models can challenge draft summaries for completeness or suggest overlooked discussion angles.

These tools complement human practices rather than replace them. For instance, combining live subtitling with visual agendas creates multiple pathways to the same information.

Broader Applications and Measurable Benefits

The same principles apply beyond internal meetings to conferences and external presentations: clear slides, subtitles, moderated pacing, and interaction opportunities. Teams adopting these approaches report faster alignment, fewer misunderstandings, and higher overall productivity.

Accessibility should be considered from project inception, involving product owners, designers, developers, and testers. Treating it as an afterthought increases costs and reduces effectiveness. When implemented thoughtfully, inclusive practices benefit not only those with disabilities but enhance communication for the entire organization.

Conclusion

Creating accessible meetings requires neither complex overhauls nor specialized expertise. Through preparation, mindful facilitation, visual supports, and strategic use of AI assistance, teams can foster environments where information flows effectively to everyone. Small, consistent adjustments compound into significant improvements in collaboration quality and inclusivity. As remote and hybrid work persists, these practices become essential components of effective teamwork.

Links:

• Video: Handicap invisible : l’accessibilité commence dans les réunions

Lecturer

Thierry Abalea is the co-founder and CEO of Shipfox, a French AI Factory platform specializing in coding agent workflows. With a background in software development and security, he focuses on practical approaches to securing modern CI/CD pipelines in cloud-native environments.

Abstract

GitHub Actions has become a cornerstone of modern CI/CD practices, yet it remains insecure by default. Recent supply chain attacks such as those targeting tj-actions, s1ngularity, GhostAction, and Shai-Hulud have demonstrated how adversaries systematically exploit workflows to exfiltrate secrets and compromise downstream projects. This presentation dissects concrete attack vectors observed in 2025, explains why traditional mitigations fall short, and outlines actionable defenses including scoped secrets with approval workflows, minimal GITHUB_TOKEN permissions, egress controls, runner hardening, and runtime protection tools. Attendees gain a clear understanding of the current threat landscape and practical steps to secure their pipelines.

The Critical Role and Inherent Risks of CI/CD in Modern Development

Continuous integration and continuous deployment pipelines manage extraordinarily sensitive assets: source code manipulation, secret handling for production access, and package publishing. Any compromise here can lead to widespread downstream damage. Thierry Abalea emphasizes that while GitHub Actions provides powerful automation, its permissive default configuration creates a vast attack surface. Workflows often run with broad permissions, handle long-lived secrets, and interact with external networks without sufficient restrictions.

The 2025 attack wave—including Singularity targeting Nx builds, Shai-Hulud as the first npm-propagating worm, and multiple incidents against Trivy—highlighted how GitHub Actions serves as both an entry point for initial compromise and a vector for secret exfiltration and lateral movement. These incidents affected hundreds of organizations, underscoring that CI/CD security can no longer be treated as secondary to application security.

Dissecting Major Supply Chain Attacks via GitHub Actions

Several high-profile incidents illustrate common exploitation patterns. The Singularity attack combined batch injection vulnerabilities in pull request workflows with the pull_request_target trigger. This allowed attackers to exfiltrate secrets from forked repositories, including NPM tokens used to publish malicious packages. Downstream consumers of the compromised Nx tool were subsequently affected.

Shai-Hulud represented a novel worm-like propagation through npm. Attackers gained secrets via similar workflow vulnerabilities, published malicious packages, and leveraged maintainer permissions across multiple projects. This created cascading compromises as infected packages spread through dependency trees.

Trivy, a widely used open-source security scanner, suffered repeated attacks. Initial exploitation via pull_request_target and unsafe interpolation led to remote code execution, secret exfiltration (including high-privilege GITHUB_TOKENs), repository privatization, and deletion of releases. A follow-up attack succeeded due to incomplete secret rotation, enabling further malicious package publications.

These cases reveal recurring themes: overly permissive triggers, secret exposure in workflows, and insufficient isolation between CI environments and production assets.

Why Default GitHub Actions Security Falls Short

GitHub Actions operates with broad defaults that favor convenience over security. Workflows can trigger on untrusted events like pull_request_target, granting access to repository secrets. The GITHUB_TOKEN often possesses excessive permissions, especially in repositories created before 2023. Actions referenced by mutable tags (e.g., v3) can be hijacked by attackers controlling upstream repositories. Self-hosted runners, if not properly isolated, allow one compromised job to affect the entire machine.

Network egress remains largely unrestricted, enabling easy data exfiltration to attacker-controlled servers or even private repositories. Traditional advice—pinning actions and limiting secrets—proves insufficient against sophisticated chained exploits.

Practical Defenses: Hardening GitHub Actions Workflows

Effective protection requires a defense-in-depth approach. Begin by scoping secrets with approval rules, ensuring only necessary workflows can access them. Minimize GITHUB_TOKEN permissions on a per-workflow basis, adhering to the principle of least privilege. Implement egress controls to restrict outbound connections from runners.

For self-hosted runners, enforce ephemeral instances and strong isolation. Tools like Step Security provide runtime hardening and firewall-like controls around runners, while GitHub’s upcoming Level 7 runner protections promise kernel-level isolation outside the runner’s reach.

Static analysis tools such as CodeQL (free for open source) and Zizmor detect workflow vulnerabilities. Dependency review bots help manage pinned versions. Organizations should treat CI/CD as production-equivalent, applying the same scrutiny to workflows as to application code.

Runtime protections and regular secret rotation further reduce the blast radius of potential breaches. Automation of security scanning within pull requests ensures issues are caught early.

Conclusion: Treating CI/CD as Production Infrastructure

GitHub Actions represents both a productivity powerhouse and a significant supply chain risk. By understanding real attack patterns and implementing layered defenses—from minimal permissions and scoped secrets to runtime controls and automated analysis—teams can substantially reduce their exposure. Security must be integrated from the outset of workflow design rather than bolted on afterward. As attackers increasingly target the CI layer, proactive hardening becomes essential for maintaining trust in modern software delivery pipelines.

Links:

• Video: GitHub Actions : une bombe à retardement pour la supply chain security
• Shipfox Website

Lecturer

Alex Snaps is a Tech Lead at Red Hat working on the Quarkus project. He maintains the Rust implementation of CEL and contributes to the broader ecosystem, bringing deep expertise in language runtimes, performance, and secure extensibility.

Abstract

Alex Snaps introduces the Common Expression Language (CEL), a domain-agnostic expression language designed for safe, high-performance evaluation within larger applications. Originating from Google, CEL emphasizes strong typing, sandboxed execution, and extensibility while maintaining portability across implementations in Go, Java, C++, Rust, and others. Through syntax exploration, type checking, cost estimation, and practical integration examples, the talk demonstrates why CEL excels for policy enforcement, validation, filtering, and authorization in cloud-native and API-driven environments.

Origins and Design Philosophy of CEL

CEL emerged from Google’s need for a lightweight, embeddable expression evaluator capable of running safely in performance-critical paths. First released around 2017 (with earlier internal variants), it targets scenarios where user-provided or configuration-driven logic must execute with predictable latency and strict safety guarantees. Unlike general-purpose scripting languages, CEL deliberately restricts Turing-completeness to prevent denial-of-service through infinite loops or excessive computation.

Core tenets include:

• Strong Static Typing: All expressions are type-checked before evaluation.
• Predictable Performance: Cost estimation and constant folding occur at check time.
• Portability: Abstract Syntax Tree (AST) format enables cross-language evaluation.
• Extensibility: Custom functions, macros, and types can be added per domain.

These properties make CEL ideal for Kubernetes (Custom Resource Definition validation), API gateways, authorization systems, and configuration engines.

Syntax and Core Language Features

CEL syntax resembles a blend of C-style expressions and modern collection comprehensions. Basic operations, conditionals, and field access feel familiar:

• Arithmetic and comparisons
• Logical operators
• Ternary expressions
• Optional chaining with ? and or
• Collection operations via macros like exists, all, map

Notable features include:

• Macros: all(resources, r, r.startsWith('email')) binds variables and applies predicates.
• Optional Navigation: obj.?field.or(0) safely accesses potentially absent fields.
• Message Construction: Direct construction of Protocol Buffer messages within expressions.
• Strict Typing: No implicit coercion; uint(1) == 1 fails type checking.

The language integrates seamlessly with Protocol Buffers, treating well-known types like timestamps and durations as first-class citizens.

The Evaluation Pipeline: Parse, Check, Evaluate

CEL processing follows a clear separation optimized for control-plane versus data-plane workloads:

1. Parse: Validates syntax and produces an AST. Feature flags can disable risky syntax (e.g., optional navigation).
2. Check: Performs type resolution, overload selection, constant folding, and cost estimation. This phase catches errors early and enables optimization.
3. Evaluate: Executes the (potentially optimized) AST against a bound environment in the hot path.

Environments declare variables and functions available to expressions. Cost limits prevent expensive evaluations in production.

Portability shines here: an AST checked in one language can be evaluated in another, facilitating polyglot systems.

Extensibility and Real-World Integration

CEL’s power emerges through domain-specific extensions. Custom functions, member overloads, and macros allow tailoring to specific needs without compromising safety.

In the Quarkus/Gateway API context, CEL evaluates policies attached to Kubernetes resources. Expressions navigate complex object graphs, enforce authorization, and implement fine-grained controls. The Rust implementation (maintained by Snaps) demonstrates low-level integration, including trait-based value handling and flexible indexing.

Examples illustrate adding domain functions like isPrime or complex policy logic matching gateways and routes.

Performance, Security, and Ecosystem Maturity

CEL achieves high performance through ahead-of-time type checking, constant folding, and minimal runtime overhead. Implementations in Go and Java (reference) are mature; Rust and others continue evolving toward full specification compliance.

Security model emphasizes sandboxing: no arbitrary code execution, bounded computation, and explicit environment control. This makes CEL suitable for untrusted user input in API filters, validation rules, and authorization decisions.

The ecosystem includes playgrounds, conformance test suites, and codelabs across languages, lowering the barrier to adoption.

Conclusion

Common Expression Language offers a compelling balance of expressiveness, safety, and speed for embedding dynamic logic in applications. Its strong typing, cost awareness, and extensibility address real challenges in cloud-native policy and configuration management. As organizations seek safer alternatives to full scripting engines, CEL provides a mature, battle-tested solution that continues gaining traction across diverse technology stacks.

Links:

• Video: CEL? Encore un autre langage d’expression?!
• Alex Snaps on GitHub

Lecturers

Youssef Nait Belkacem is a Java developer with a strong interest in low-level systems and performance optimization. Jean-Eudes Couignoux brings extensive experience as a Java and DevOps consultant, with a deep passion for Linux internals and system programming.

Abstract

Youssef Nait Belkacem and Jean-Eudes Couignoux guide the audience through the historical progression of Linux input/output APIs, illustrating how each generation addressed limitations of its predecessors in handling high-concurrency network and file operations. Beginning with basic blocking models and advancing through multiplexing interfaces like poll and epoll, the talk culminates in the revolutionary io_uring subsystem. Through practical coding examples centered on socket handling, performance benchmarks, and Java integration, the presenters reveal fundamental shifts in kernel-user space interaction, memory management, and asynchronous processing that power modern scalable applications.

The Challenge of High-Concurrency I/O in Modern Systems

Contemporary applications, from social networks to real-time collaboration platforms, demand the ability to manage thousands of concurrent connections efficiently. Early web architectures relied on simplistic request-response patterns, but today’s interactive experiences require persistent connections and rapid data exchange. A single server handling 10,000 simultaneous clients cannot afford per-connection operating system threads due to prohibitive memory consumption and context-switching overhead.

Linux’s “everything is a file” philosophy provides a unifying abstraction: sockets, files, timers, signals, and more are represented by file descriptors—integer handles managed by the kernel. This Virtual File System (VFS) layer allows uniform operations like read and write across diverse resources. However, naive implementations quickly encounter performance walls, necessitating increasingly sophisticated notification and completion mechanisms.

Blocking I/O and the Limitations of Synchronous Models

Initial implementations used blocking I/O, where operations like accept, read, or write would halt the calling thread until completion. While simple, this approach fails under load: a thread blocked waiting for one client cannot accept new connections. Non-blocking sockets mitigate this by returning immediately if data is unavailable, but require constant polling in a tight loop. This leads to 100% CPU utilization as the process repeatedly checks descriptors with no work to do.

Performance measurements on such a model reveal exponential degradation. With increasing numbers of open connections, median response times for new requests rise dramatically due to the linear scan of the descriptor list in each iteration. High volatility and resource waste make this unsuitable for production.

poll and the Introduction of Multiplexing

The POSIX-compatible poll (and its predecessor select) introduced kernel-assisted multiplexing. Instead of busy-waiting, applications register a list of file descriptors and block until the kernel reports activity on any of them. This dramatically reduces CPU usage during idle periods.

Implementation involves creating a listener socket, accepting connections to obtain new descriptors, and maintaining an array passed to poll on each iteration. While an improvement, poll still suffers from scalability issues:

• The entire descriptor list must be re-registered with the kernel on every call.
• User-space to kernel-space copying of large arrays occurs repeatedly.
• Linear traversal of results remains necessary.

Benchmarks show linear but steadily increasing latency as connection counts grow, confirming O(n) behavior in registration and processing phases.

epoll: Event-Driven Efficiency in the Kernel

Linux’s epoll addresses poll’s shortcomings through a more stateful, incremental model. An epoll instance (created via epoll_create) maintains a kernel-side interest list. Applications add or remove descriptors once using epoll_ctl, then block on epoll_wait to receive only active events.

This design minimizes data copying and eliminates repeated full-list traversals. The kernel tracks state internally, notifying user space solely for relevant changes. Performance graphs demonstrate near-constant response times regardless of concurrent connection volume, fulfilling the C10K challenge effectively. Most modern application servers, including those in the Java ecosystem via NIO selectors, leverage epoll under the hood.

io_uring: A Paradigm Shift to Asynchronous Submission and Completion

Introduced in 2019, io_uring represents a fundamental rethinking of I/O. It bypasses traditional VFS read/write paths in favor of a double-queue architecture: a submission queue (SQ) for commands and a completion queue (CQ) for results. Applications prepare operations (accept, read, write, etc.) directly into shared ring buffers, minimizing system calls and eliminating unnecessary memory copies through pre-registered buffers.

Key innovations include:

• Shared Buffers: User-space and kernel access the same memory regions.
• Batching: Multiple operations can be submitted and completed in batches.
• Linkage and Chaining: Dependent operations can be linked for sequential execution without intermediate round-trips.
• Asynchronous Model: Submission is fire-and-forget; completion is polled or waited upon separately.

Code examples reveal a more complex but powerful API compared to predecessors. While requiring careful management of user data for correlating submissions and completions, the reduction in context switches and copies yields significant gains. Filesystem benchmarks, notably in PostgreSQL, show up to 6x improvements in write throughput after io_uring integration.

Java Integration and Broader Implications

The Java ecosystem has embraced io_uring through Project Loom and Netty 4.2+, with frameworks like Quarkus, Micronaut, and Vert.x offering configuration flags for its activation. While the programming model demands greater rigor around state management, the performance benefits are compelling for high-throughput services.

Security considerations remain important; as a relatively new interface, io_uring continues to undergo hardening against potential exploits. Nevertheless, its adoption signals a new era of efficient, low-overhead asynchronous I/O in Linux.

Conclusion

The journey from blocking I/O through poll, epoll, and finally io_uring illustrates Linux’s continuous evolution toward handling massive concurrency with minimal overhead. Each advancement reduced user-kernel transitions, optimized memory movement, and pushed more intelligence into the kernel. Understanding this progression equips developers to make informed architectural choices and appreciate the low-level foundations powering today’s scalable applications.

Links:

• Video: Voyage au bout des APIs IO de Linux