OWASP Global AppSec EU 2026 Vienna

We analyzed CVE remediation patterns across 10,000 open source projects to uncover a critical problem: vulnerabilities fixed upstream often take weeks or months to reach downstream containers. This lag creates massive security exposure windows in Kubernetes environments.

In this talk, we'll present our findings showing how CVE fixes flow (or stall) across ecosystem layers, from upstream projects to package managers to base images to final containers. You'll see real metrics on remediation delays, and the compounding effect of layered dependencies.

But we won't stop at the problem. The second half focuses on practical solutions. From automated patch backporting to in-place image patching with tools like Copa. You'll learn how to build workflows that dramatically reduce MTTR, including dependency automation patterns and risk-based prioritization.

Attendees will leave with both a data-driven understanding of the CVE remediation challenge and a practical playbook for fixing it.

Last year at OWASP Global AppSec Barcelona, we showed how to break and defend LLM-integrated apps: (indirect) prompt injection, jailbreaks, data poisoning. And what practical controls actually worked in production. But the game has changed.

This follow-up talk picks up where we left off, focusing on the next generation of LLM-driven systems: agentic AI and e.g. MCP (Model Context Protocol) & A2A (Agent2Agent). These systems combine LLMs with tools, memory, plugins, APIs, and planning loops, making them far more powerful, and also far more fragile.

We’ll walk through how this new architecture has shifted the attack surface, and why last year’s defences (input validation, injection prevention) don’t hold up anymore. Expect real-world attack paths: memory poisoning, tool misuse, and agent goal hijacking. Then we’ll show you what works: “Zero Trust”-style isolation, sandboxing tool execution, runtime plan validation, and defence patterns that are actually deployable.

This is not a theoretical talk. It’s a two-speaker format - builder and breaker - based on real-world incidents, internal and external red teaming, and live demos. If you’re building, securing, or reviewing AI-driven systems that do more than just chat, this is the session to see what’s coming and how to stay ahead.

AI is tightening its grip on security operations, but when no one can explain what a system is doing, accountability breaks down and attackers gain the edge. Regulations like the EU AI Act now require AI systems to be transparent, yet most organizations lack a concrete way to measure what “transparent” actually means. The AI Explainability Scorecard fills that gap by providing a fast, practical way to assess whether an AI system is traceable and defensible, scoring it on faithfulness, comprehensibility, consistency, accessibility, and operational clarity, including for LLM-based systems. The takeaway is clear: if you cannot explain the results of your AI, it is running your business, not your people.

SBOMs are known to be at the forefront of modern strategies to ensure supply chain security. However, there are two key problems that traditional SBOM workflows do not solve: working with components that do not have well-established identifiers and the introduction of malware in the supply chain.

This presents a significant gap between the expectations of SBOM adoption and the real value it can deliver. This talk will explore the concept of applying continuous SBOM diffing as part of the CI process. Rather than analyzing an SBOM for each release as a standalone artifact, we can compute diffs and take actions based on whether something has changed from the previous component release.

This approach makes all SBOM components actionable, even those that otherwise seem meaningless. For example, if an individual file that is not part of any library appears in an SBOM, legacy approaches make it difficult to reason about such a file. However, with continuous SBOM diffing, tracking changes in such components becomes meaningful and therefore actionable. For example, if a new component file appears with an unknown origin, we can sanitize the build and conduct additional investigations into what happened.

We will also demonstrate practical examples of how to achieve such actionable workflows using open-source tooling.

Your authorization logic probably lives in code, while the rationale behind it lives only in people’s heads.

That’s why authorization breaks in familiar ways: a missing check, an incorrect assumption, a copied snippet that made sense in one endpoint but was entirely wrong for another.

This talk is about making authorization logic visible earlier, during design, so engineers have something concrete to implement and reviewers have something concrete to critique. We’ll walk through a lightweight, design-time template that turns “who should be able to do what” into a structured artifact that can later be translated into policy-as-code, tested, and enforced consistently.

No new tools required; the focus is on a design-time step that fits cleanly into architecture reviews and threat modeling, and makes authorization easier to get right.

Technical skill development and evaluation for application (software) security testers remains underdeveloped. There is no widely adopted framework defining core competencies, proficiency levels, or objective assessment criteria. In the absence of such standards, the industry has defaulted to a fragmented ecosystem of private organizations offering training and certifications that insufficiently prepare the next generation of security testers for real-world testing.

This environment disproportionately rewards those who benefit from exceptional mentorship or possess the time, resources, and aptitude for intensive self-directed learning. The popular mantra “Try Harder” reflects this culture of self-made expertise, but it also serves as a substitute for formalized training models. Further, aspiring security professionals are left to

In contrast, more mature, life-critical disciplines that demand high levels of technical skill (such as aviation and surgery) are built upon standardized curricula, clearly defined skill progressions, and objective methods for evaluating competence. This is not by chance; over many decades, these (and related) fields have honed in how to achieve optimal outcomes through evidence-based training programs and practices.

In this talk, we will examine the past, present, and prospective future of application security tester training in comparison to more mature professions that demand a high level of technical skill. We will introduce a novel framework for evaluating technical skills and demonstrate its application in combination with a comprehensive AppSec curriculum. Both the assessment framework and the curriculum will be released to the open-source community at the time of presentation.

As the cornerstone of open-source Web Application Firewalls, OWASP ModSecurity has protected the web for decades. However, maintaining its relevance in today’s evolving threat landscape requires more than just incremental updates—it requires a fundamental modernization. This presentation dives deep into the recent engineering efforts aimed at transforming the ModSecurity codebase into a leaner, more robust, and future-proof security engine.

Key highlights include:

* Code Quality & Refactoring: How we addressed technical debt and implemented stricter development standards.

* New Features: A look at the latest functionalities designed to counter sophisticated web attacks.

* Dependency Management: The rationale behind removing abandoned libraries and the technical challenges involved.

* The Path to a New Version: Why a major version update became necessary and what it means for the community.

* Beyond the Code: A brief look at the supporting ecosystem, including the complete renewal of the official website and documentation.

Attendees will gain a clear understanding of the architectural decisions shaping the next era of ModSecurity and what to expect from the upcoming releases.

Many AppSec programs fail because they try to run before they can walk. But in the world of ever changing attack surface, the truth is - Slow is smooth, smooth is fast, and 'smooth' is how we actually ship secure software at the speed of business.

This presentation outlines our multi-phased methodology for establishing an AppSec program. This approach emphasizes incremental, measurable, and sustainable goals throughout the journey. I will share ‘why, what and how’ of each major business-tailored adoption of frameworks like OWASP SAMM, Security Champions Guide and open source solutions. This talk will cover both cultural and technical aspects of the program, ranging from pushback from development to customization of language-specific-SAST policies to measuring the value with KPIs.

Application security practitioners will be able to use the strategy shared in this talk to build and scale the AppSec program aligned with their business goals.

Introduction

File Integrity Monitoring is still a critical part of runtime security, but in Kubernetes it comes with new challenges. A single cluster can generate thousands of file system events per second across containers, nodes, and workloads. While eBPF allows us to safely and efficiently capture these events at the kernel level, interpreting them remains a hard problem.

OWASP KubeFIM AI is built to address this gap.

This session presents how KubeFIM AI sits on top of the OWASP KubeFIM Agent and analyzes kernel-level File Integrity Monitoring events collected via eBPF. Instead of treating each event as an alert, KubeFIM AI focuses on reasoning over events by correlating them with Kubernetes context such as pods, namespaces, images, and workload behavior.

Technical Details and Future Roadmap

The talk will cover:

1. Why raw eBPF-based FIM events are difficult to use at scale

2. What kernel-level file operations actually tell us during real attacks

3. How KubeFIM AI models file behavior over time instead of reacting to single events

4. Using Kubernetes context to distinguish expected behavior from suspicious activity

5. How AI can reduce noise, explain intent, and improve triage without hiding technical details

Rather than using a generic large language model, KubeFIM AI is designed around a domain-specific approach, trained to understand file system behavior, container lifecycles, and Kubernetes runtime patterns. The focus is on producing human-readable security insights.

The session will also discuss the roadmap for the project, including plans to improve detection accuracy, reduce alert fatigue, and assist security teams with faster incident response in cloud-native environments.

Explain why KubeFIM AI Is Not a SIEM Replacement

KubeFIM AI is not designed to replace a SIEM. It solves a different problem at a different layer of the stack.

SIEM platforms focus on collecting, storing, and correlating logs and alerts from many sources across an organization. They are built for visibility, compliance, long-term retention, and investigation across applications, cloud services, networks, and users.

KubeFIM AI operates much closer to the system. It works at the Linux kernel level using eBPF to observe file system behavior inside Kubernetes nodes and containers. Its primary role is to generate high-quality runtime security signals, not to aggregate logs or manage incidents.

The project intentionally avoids becoming a central log store or alerting platform. Instead, it focuses on understanding why a file change occurred, whether it matches expected workload behavior, and whether it may indicate a security issue. This analysis happens before data is sent anywhere else.

In practice,

SLSA (Supply-chain Levels for Software Artifacts) promises to secure your software supply chain—but implementing it at enterprise scale is harder than the spec suggests. This talk shares our journey to SLSA Level 3, including the architectural decisions, performance trade-offs, and customer escalations that shaped our approach.

You'll learn:
- Provenance attestation architecture for multi-tenant CI/CD pipelines
- How to integrate SLSA verification without breaking existing workflows
- Real metrics: what SLSA costs in CI minutes and what attacks it actually catches
- Common implementation pitfalls and how to avoid them

Whether you're just starting your SLSA journey or stuck at Level 2, walk away with battle-tested patterns that work at scale.

Security and privacy threat models are fundamental tools in AppSec, but in modern systems, such as Identity and Access Management (IAM) and AI, they fail to intercept a growing class of threats: those that do not compromise the system but produce harm to people.

In this talk, we show why traditional threat models fail to capture these problems and how the limitation is not technical but cognitive. Human rights concepts are too abstract for many technicians, just as security was for developers before Threat Modeling became a facilitated and shared practice.

Through a concrete use case on IAM - extendable directly to AI systems - we present an approach that integrates Threat Modeling and harm modeling through a structured facilitation process, supported by cards and serious games.

The goal is not to turn developers into human rights experts but to make these threats visible, debatable, and mitigable using familiar AppSec tools.

Application Security engineers face a critical challenge: information overload from disparate security tools create “decision paralysis”. How do you balance design reviews, threat modeling, code reviews, monitoring alerts and managing your bug bounty program in an intentional instead of ad-hoc or reactive way?

This presentation demonstrates a novel approach using AI agents combined with Model Context Protocol (MCP) servers to automate work discovery and prioritize intelligently. Through practical examples, I'll show how Claude Code integrates with existing enterprise infrastructure—including issue tracking systems, content management platforms, Cloud Security Posture Management (CSPM) tools, and version control systems—to create an autonomous triage and prioritization engine.

You'll see how AI agents can pull together security data from all your different tools, figure out what actually matters based on your business context and threat intel, and spit out a prioritized to-do list that makes sense. I'll walk through real examples showing how this approach cuts down remediation times and helps you cover more ground with the same resources.

CI/CD pipelines play an important role in modern software development. From a security perspective, this methodology contributes to more secure products, as automated checks can be applied on every run. Developers define tasks in a metadata file, and the system executes the defined jobs automatically. But what if the build chain itself becomes the security problem, allowing attackers to manipulate artifacts or take control of backend infrastructure? Let’s take a deep dive into “Poisoned Pipeline Execution” (OWASP CICD-SEC-4).

Builds are typically carried out in multiple steps using Runners—agents that pick up jobs and execute build instructions. These instructions, such as compiling a program or building a container image, are usually performed inside containers. Containers may provide isolation, but the effectiveness in terms of security strongly depends on the Runner’s configuration. Attackers can abuse Runners to execute arbitrary commands, leading to information disclosure or privilege escalation. While such attacks are well documented, effective detection mechanisms are often lacking.

Any viable detection method must be independent of the source code, language-agnostic, and container-friendly. The eBPF technology, which enables tracing of kernel-level activity, is well suited for this purpose. In this talk, we explore security vulnerabilities in CI Runners, how they become targets for attackers, and how malicious activities can be detected using eBPF.

This session is about latest defenses against Cross-Site Scritping (XSS), the most prevalent security issue of all times. We will showcase typical XSS bugs and how they can be avoided. We will also explain why previous mechanisms fall short of protecting web sites at scale and why we believe Trusted Types and the Sanitizer API can help closing this gap.
The presentation will also give hands-on advice to enable security and development teams adopting these new protections. We will close with a bit on security considerations and remainign risks.

Agile software development and IT security share the goal of delivering reliable, robust software, yet they often collide in practice. Security validation is still frequently deferred to the end of the development lifecycle, producing findings too late to be effectively addressed. Under delivery pressure, this can lead to defensive reactions toward security activities and tools. This talk explores why security issues are detected yet may not be processed soon and shows how integrating security early and continuously can transform friction into collaboration.

Malicious open source packages are on the rise, targeting more and more ecosystems. And while open source maintainers and users struggle to secure the immense attack surface of today’s software development practice, attackers continue to evolve their techniques.

This talk presents lessons learned from developing and operating an end-to-end malware detection pipeline in an enterprise setup that automatically scans tens of thousands packages a day, and is followed by human review of reported malware. It provides an overview about and fundamental design decisions, starting from a suitable classification scheme and the selection of meaningful signals with a low signal-to-noise ratio, to the compilation of Indicators of Compromise and the final reporting of confirmed malicious packages to the respective registries and third-party databases like OSV. The individual sections and learnings will be motivated and illustrated through real-world samples as well as descriptive statistics obtained from our system.

Session attendees will learn about:
- Latest open source malware trends,
- common evasion techniques used by attackers, from encoding techniques, code transformations and payload splitting to prompt instructions aiming to sabotage LLM-based detectors,
- the shortcomings of current malware datasets in regard to supporting developers in the evaluation of malware scanners, e.g., the lack of accompanying metadata and qualitative descriptions,
- the importance and complementarity of code and metadata-based detection signals,
- requirements and design decisions for an end-to-end OSS malware scanner, e.g., the realization that a binary classification benign/malicious is not colorful enough for the breadth of software distributed through OSS registries like npm or PyPI, and
- descriptive statistics obtained from our system, showing the prevalence of techniques used in the wild, e.g., the prevalence of different malware triggers and targeted platforms.

As such, the presentation targets both open source users interested in the latest malware trends and safeguards, as well as builders wanting to create an end-to-end OSS scan pipeline, e.g., because their ecosystem is already targeted by attackers but not yet or not sufficiently covered by state-of-the-art scanners.