This introductory training provides a structured overview of modern Application Security and the Secure Software Development Lifecycle (SSDLC). Rather than focusing on a single technology or vulnerability category, the course explores how cloud-native architectures, APIs, AI-assisted development, software supply chain risks, and evolving regulatory requirements have transformed the security landscape. Participants gain a practical understanding of how security activities, processes, and tools fit together to create an effective application security program.

The training covers the core building blocks of contemporary AppSec, including threat landscapes, compliance considerations, secure architecture principles, security-by-design practices, threat modeling, DevSecOps tooling, vulnerability management, and SSDLC governance. Through discussions and practical exercises, participants learn how to identify and address security risks early in the development lifecycle, evaluate where security tools provide value, and understand how AI can support and automate security activities. A hands-on threat modeling exercise helps attendees apply security-by-design concepts to realistic scenarios and better understand risk-driven decision-making.

By the end of the session, participants will have a clear understanding of how modern application security programs operate, how to build and tailor an SSDLC to their organization's needs, and how to scale security initiatives through governance, security champions, and culture. The training emphasizes practical, adaptable approaches rather than one-size-fits-all solutions, making it valuable for developers, architects, DevOps engineers, technical leads, and security practitioners seeking a strong foundation in Application Security.

Requirements: Laptop with internet access

This is a hands-on workshop that demonstrates how organizations can build scalable, sustainable threat modeling programs using OWASP Precogly, an open-source platform designed for modern security teams. The training explores how to move beyond isolated threat modeling exercises and establish repeatable workflows that integrate with development processes, governance requirements, and organizational security practices. Participants will gain practical experience creating threat models, managing reusable security knowledge through library packs, mapping controls to compliance frameworks, and adopting a "threat model as code" approach that supports collaboration and continuous improvement.

A distinguishing feature of the workshop is its focus on AI-enabled threat modeling. Precogly was built with a fully documented API-first architecture, enabling teams to develop their own AI agents to automate activities such as architecture analysis, context generation, diagram conversion, ticket synchronization, and threat discovery. Through guided labs, attendees will install and configure Precogly, build and analyze a threat model, create custom libraries tailored to their technology stack, and experiment with AI-driven automation patterns that can accelerate security reviews and improve coverage.

By the end of the session, participants will understand not only how to use the platform, but also how to operationalize threat modeling at scale. They will leave with a working local deployment, practical implementation examples, reusable artifacts, and a clear framework for introducing or expanding a threat modeling program that is collaborative, compliance-aware, and ready for the next generation of AI-assisted security workflows.

Requirements:

• Laptop with Docker Desktop (or Docker Engine + Docker Compose), Git, and a modern browser installed and verified working before the workshop.
• Local admin/sudo rights required.
• Familiarity with STRIDE or a comparable threat modeling methodology.
• Experience creating at least one threat model, even informally.
• A pre-flight check script and setup instructions will be sent to confirmed participants one week before the workshop.

This workshop introduces participants to offensive and defensive security concepts in Operational Technology (OT) and Industrial Control Systems (ICS) environments. Using a fully isolated lab environment, attendees learn how attackers discover, access, manipulate, and disrupt industrial processes by exploiting common weaknesses in protocols such as Modbus, DNP3, and S7comm. Through guided exercises based on realistic water treatment plant simulations, participants gain practical experience mapping OT networks, collecting operational data, understanding insecure-by-design protocols, and observing how seemingly simple actions can create real-world physical consequences.

The workshop combines attack simulation using MITRE Caldera with detection and monitoring using Suricata, Zeek, and ATT&CK for ICS. Participants perform reconnaissance, identify exposed assets, retrieve sensitive operational information, manipulate control system parameters, and observe the impact on simulated industrial processes. Alongside these offensive exercises, they learn how defenders monitor OT environments, investigate attack activity, map techniques to the MITRE ATT&CK for ICS framework, and identify critical detection gaps that can allow low-noise attacks to remain unnoticed.

By the end of the session, attendees will understand how modern OT attacks unfold across multiple stages, how common industrial protocols and devices can be abused, and how security teams can improve visibility and resilience in critical infrastructure environments. The workshop demonstrates seven of the OWASP OT Top 10 risks in a controlled setting and provides participants with practical skills, lab resources, and a deeper understanding of both attacker techniques and defensive strategies in industrial control systems.

Requirements:

• Working personal laptop with Windows 11 64-bit, macOS, or Debian-based Linux installed as the host operating system.
• No netbooks, Chromebooks, tablets, or corporate laptops with restrictive policies enabled.
• Minimum 100 GB free disk space and 16 GB RAM preferred.
• Antivirus and firewall disabled.
• Administrator privileges.
• Virtualization technology enabled in BIOS. If VT is disabled, the BIOS password is needed.
• Working USB port with file-transfer access allowed.
• Wi-Fi enabled.
• No VPN installed.
• Ability to connect to wireless and wired networks.
• Ability to read PDF files.
• Latest display drivers installed.
• Latest VirtualBox installed. Apple Silicon (M1/M2/M3/M4) users need VMware Fusion or UTM instead; VirtualBox on ARM is still limited.

Hacking a Smart Pizza Place with the OWASP AI Exchange - PwnzzAI! is a highly interactive workshop that introduces participants to the security challenges of modern AI systems through hands-on attack and defense exercises. Using the OWASP AI Exchange framework and PwnzzAI, an intentionally vulnerable AI application built for education and testing, attendees explore how AI-powered applications, large language models (LLMs), and machine learning systems are designed, how they can be compromised, and how those risks can be mitigated in real-world deployments. The workshop focuses on practical exploitation rather than theory, giving participants direct experience with the most significant threats facing AI applications today.

Throughout a series of guided labs, participants investigate vulnerabilities such as prompt injection, sensitive data leakage, model and data poisoning, AI supply chain attacks, vector database weaknesses, excessive agent behavior, system prompt exposure, misinformation, and resource abuse. By attacking and analyzing a deliberately insecure AI environment, attendees gain a deeper understanding of how these threats manifest in practice and how adversaries can manipulate AI systems and their supporting infrastructure.

By the end of the workshop, participants will be able to identify major AI security risks, understand common attack strategies against AI applications, and successfully execute practical proof-of-concept attacks in a controlled environment. The training is designed to provide hands-on experience with the OWASP AI Exchange threat landscape, helping security professionals, developers, and AI practitioners better assess and secure AI-powered systems.

Requirements:

To make the most of the workshop, participants should have basic familiarity with Python, including working with functions and classes, making API requests, and executing database queries. A foundational, non-deep technical understanding of AI and LLM concepts, such as prompt structures, AI supply chain and retrieval-augmented generation (RAG), is also expected, along with general awareness of common software security vulnerabilities such as XSS and SQL injection. Without this background, participants may still be able to complete some challenges but may not fully understand the underlying technical root causes.

Participants should bring a laptop with Docker installed and working. Since pulling the PwnzzAI Docker image and the required AI models can take 10-20 minutes, attendees are strongly recommended to complete this step before the workshop to ensure a smooth and hands-on experience.

Workshop Access Options

Participants can choose one of two ways to complete the hands-on exercises.

Option 1: Use the Hosted Workshop Environment

The lab will be deployed on a public server and can be accessed directly through a web browser. No installation is required.

• A shared API key for commercial models will be provided during the workshop.
• Open-source models running on Ollama will also be available through the hosted environment.
• This is the recommended option for participants who want to focus on the exercises without spending time on setup and configuration.

Option 2: Run Your Own Local Instance

Participants who prefer to explore the platform locally can deploy PwnzzAI using Docker and choose between two LLM backends.

Option 2A: Commercial Models

• An API key for OpenAI, Claude or Gemini is required.
• Model inference is performed by cloud models, so local hardware requirements are modest.

Recommended specifications:

• CPU: 4 cores or more
• RAM: 8-16 GB
• Disk: 30 GB free space for Docker images

Option 2B: Ollama with Free Open-Source Models

The lab supports local execution using:

• Mistral 7B
• Llama 3.2 1B

Because the models run locally, additional system resources are recommended.

Recommended specifications:

• CPU: 8 cores or more
• RAM: 32 GB minimum
• Disk: 50-100 GB free SSD space for Docker images and model files
• Optional (recommended): NVIDIA GPU with 12 GB or more VRAM

AI is creating real breakthroughs, but also an ocean of slop, hype, fear, and confusion. Engineers are declared obsolete. Agentic AI is treated as magic. Security teams are asked to protect systems that are changing faster than their risk models. No wonder many of us feel dazed.

This keynote offers a free therapy session for the AI-overwhelmed, including a grounded path through the chaos from your therapist. What are the truths we can rely on? Which AI risks matter most? How do we scope security concerns without drowning in them? And what about our careers?

Bring your questions. There will be tissues.

The OWASP Top 10 for Agentic Applications 2026 clearly outlines risks like prompt injection, tool misuse, excessive agency, rogue and compromised agents, and untraceable actions. This talk shows how an open source tool addresses the risks as a control platform, a switchboard between the model and its actions. The separation means any hostile or compromised model is bound and can't reach or bypass these controls.

• Tool misuse and excessive agency hit per-action permission tiers that auto-allow, require human approval, or block.
• Compromised and rogue agents hit a gate so an "evil model" can't elevate.
• Untraceable action hits an append-only, hash-chained, signed audit log.
• Skill supply chain hits a signature verification at load.

A live agent demo shows the risks, controls, source code, and design architecture. The reference implementation maps to the sovereignty posture the EU formalized in its June 2026 tech package.

Documentation and source: https://wirken.ai

Threat models usually go out of date as soon as they are created. They reside on the tool used to create the threat model. So a developer without access to the threat modeling tool does not even open the threat model.

On the other hand, threat models that are interoperable come with several advantages. It's easier to share them with team members. Vendors can be asked to provide their threat models in a ready-to-consume format by purchasers in sensitive industries like healthcare. With the advent of agentic systems, LLMs can even consume raw threat models in JSON format and generate threat models that can be viewed and deliberated upon by human reviewers.

The CycloneDX project is pushing to release the TM-BOM (Threat Modeling Bill of Materials) and is targeting general availability later this year. This session discusses the nuts and bolts of the TM-BOM format. Participants will understand how various pieces like blueprints, business objectives, behaviors, threats, risks, use cases, and controls interact with each other.

To ground this standard in reality, I will share insights from integrating this pre-release schema into an open-source threat modeling platform, exploring the friction points of translating complex data structures into human-centric visualizations.

Outline (20 Minutes)

The Interoperability Problem (3 mins): Why siloed threat models fail developers and compliance teams.

Deconstructing the TM-BOM (7 mins): A focused look at the CycloneDX 2.0 schema and how its core components (Blueprints, Behaviors, Threats, Risks, Controls) interlock.

Agents and the TM-BOM (5 mins): How standardizing into JSON unlocks the ability for agentic systems to reliably consume and generate models for human review.

Implementation Realities (3 mins): Engineering lessons learned mapping a complex JSON standard to visual diagrams.

Q&A (2 mins)

Attendees will leave with a functional understanding of the upcoming CycloneDX 2.0 standard, the operational benefits of interoperable threat models, and how to prepare their security pipelines to generate and consume TM-BOMs.

Shift-left doesn't start with scanning the code for security vulnerabilities; it begins with designing for security.

Too often, the shift-left mantra consists of implementing (AI-powered) code scanning and applying AI-powered security fixes for remediation. Also, don't forget to implement the AI-powered benchmark for AI-powered Security Fixes. Now, to be clear, I am not actually telling you to stop using these tools — if they work for you — instead, we should ask ourselves:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good job?

In order to support that second question in particular, we have created the next version of OWASP Cornucopia (see: https://cybersecgames.com/pages/owasp-cornucopia-threat-modeling-collection).

OWASP Cornucopia is a mechanism in the form of a card game to assist software development teams in identifying security requirements in Agile, conventional, and formal development processes. It is language, platform, and technology-agnostic.

The formerly titled "Cornucopia — Ecommerce Website Edition" is now "Cornucopia — Website App Edition". This edition was originally created in August 2012, released as v1.0 in February 2013, and has undergone several minor updates/releases over the following ten to fifteen years. This has been substantially updated in v2.0, in which the most noticeable change was an update of the OWASP ASVS mapping from ASVS v3.0 to v4.0, together with the creation of translations into six languages (EN, ES, FR, NL, NO-NB, and PT-BR) due to the efforts of past and current volunteers.

The new version, available in 11 languages (EN, ES, FR, HI, NL, NO-NB, PT-PT, PT-BR, RU, UK), will include all new cards and text that covers all OWASP ASVS 5.0 requirements and links them to more than 200 unique common attack patterns (CAPEC). Each of the common attack patterns will have a unique set of ASVS requirements, which means that you never need to stop playing the game! You will always be able to return to the same card to discover new threats and security requirements to consider when building your software. Additionally, we are publishing the OWASP Cornucopia Companion Edition that comes with 6 companion suits (see: https://cornucopia.owasp.org/edition/companion) covering new topics: Agentic AI (AAI), Automated Threats (BOT), Cloud (CLD), Frontend (FRE), Large Language Models (LLM), and DevOps (DVO). A suit in the companion deck may replace (or be used in addition to) suites in the existing Website Edition so that the players can add a specific focus to their threat modeling: For example, say you are building an LLM application and want to perform threat modeling specifically for LLM. You would then use the OWASP Cornucopia Website Edition and the LLM companion suite as your elected OWASP Cornucopia focus area.

What's more, it is now possible to create your OWASP Cornucopia Threat Model in OWASP Threat Dragon using their brand new EoP Games diagram. The diagram allows you to easily select the right card from the OWASP Cornucopia suite and connect it directly to your threat model in OWASP Threat Dragon, thanks to the combined efforts of volunteers at Universidad Católica del Uruguay and the OWASP Threat Dragon project.

All project leaders and contributors to the OWASP projects that have provided valuable input and guidance to OWASP Top 10, OWASP AISVS and the OWASP GenAI Security project. We also want to thank the people and contributors to Mitre's Common Attack Pattern Enumeration and Classification (CAPEC™) and Atlas, together with CSA Cloud Controls Matrix, which are all used in the cross-references provided.

Failing to regularly assess your security isn't only costly; it can leave you vulnerable to threats. Several companies have implemented OWASP Cornucopia as part of their SDLC and use it for security requirements analysis, threat modeling, and secure design for every sprint and every user story. You should do the same! Don't let your business spiral out of control; consciously assess how you are doing by continuously threat-modeling your applications and infrastructure. To get started scaling your threat modeling efforts, OWASP Cornucopia v3.0 is the perfect tool.

As LLMs are increasingly integrated into systems that browse, retrieve, summarize, and act on web content, webpages have become an untrusted input vector for downstream model behavior. This enables site owners, contributors, and adversaries to embed instructions directly in web resources, i.e., indirect prompt injections. While prior work demonstrates such attacks in controlled settings, their prevalence, deployment, and real-world impact remain unclear.

We present one of the first large-scale empirical analyses of indirect prompt injections in webpages and HTTP responses. Analyzing 1.2B URLs from 24.8M hosts, we identify 15.3K validated instances across 11.7K pages. These are not isolated cases: a small number of recurring templates account for most cases. We characterize their objectives, delivery mechanisms, visibility, persistence, and impact, revealing a heterogeneous ecosystem spanning disruptive prompts, reputation manipulation, content-protection directives, and AI-bot detection, targeting systems such as crawlers, search pipelines, customer-support agents, and hiring workflows.

A key finding is that most instructions target machines rather than humans: about 70% appear in non-rendered HTML (e.g., headers, comments, metadata), and many visible cases are hidden via rendering techniques. To assess practical risk, we run 5,200 controlled experiments across 13 models and four webpage representations. Our results show compliance is limited but non-negligible, reaching up to 8% for smaller models on plain-text inputs, while structured representations reduce compliance by preserving structural cues. Overall, prompt-based interference is already present in the web ecosystem and represents a growing source of tension between LLM-driven automation and the sites it consumes.

Eine E-Mail liegt im Posteingang. Niemand öffnet sie, niemand klickt. Tage später fragt jemand seinen KI-Assistenten nach den letzten Mails — und der Agent schickt still interne Daten an einen fremden Server. So lief EchoLeak gegen Microsoft Copilot (CVE-2025-32711, CVSS 9.3): kein Exploit-Code, keine kaputte Authentifizierung. Jede Komponente hatte ihr Security-Review bestanden. Der Angriff lebte im Pfad dazwischen.

Wer agentenbasierte Systeme baut, kennt das Muster: Wir prüfen Komponenten einzeln, Angreifer denken in Ketten. Sobald ein Agent Daten abruft, Aufgaben plant, Tools aufruft, sich Dinge merkt und mit anderen Agenten redet, entstehen Angriffspfade quer über Vertrauensgrenzen, die kein Per-Komponenten-Review sichtbar macht. Gerade im Kontext von Agentic AI werden dabei die Grenzen klassischer STRIDE-Analysen sichtbar, weil sich Risiken oft erst entlang von Daten-, Entscheidungs- und Tool-Ketten über mehrere Komponenten hinweg entfalten.

Ich zeige eine Methode, kein weiteres Framework zum Auswendiglernen. Die Fünf-Zonen-Brille — Eingabe, Planung, Tool-Ausführung, Speicher, Agent-zu-Agent-Kommunikation — sagt, wo man hinschauen muss; die OWASP Top 10 for Agentic AI Applications sagen, was man dort findet. Wir gehen drei reale Architekturen durch: RAG-Pipeline-Poisoning, Missbrauch einer MCP-Tool-Chain und eine Multi-Agent-Kaskade. Für jede bauen wir einen Attack Tree und trennen die Kontrollen, die strukturell halten (Tool-Scoping pro Aufgabe, Egress-Inspektion, Credential-Trennung), von den prompt-basierten, die nur beruhigend klingen.

Am Ende habt ihr eine wiederholbare Routine für euer eigenes Agentic AI System: Zonen kartieren, Pfade ablaufen, einen Baum bauen, Single Points of Failure finden, Kontrollen anhängen und validieren.

Large language models are starting to change both sides of application security: offensive work such as black-box penetration testing, and defensive work such as code review and vulnerability detection in source code.

In this talk, I present practical lessons from my academic and independent work in both areas: AutoPentest, my research on autonomous black-box pentesting with LLM agents; Vuldra, my work on LLM-assisted static code analysis; and my recent hands-on evaluation of OpenAI Codex Security on a real open-source project.

On the offensive side, I show what happens when an LLM agent is asked to carry out a black-box penetration test with a high degree of autonomy. I explain the architecture behind AutoPentest, including specialized worker agents structured around OWASP Top 10-relevant web vulnerability areas, and show where the system still struggles in longer attack chains.

In my evaluation on three Hack The Box machines, AutoPentest completed 15 to 26 percent of subtasks and slightly outperformed a manual ChatGPT-based baseline on one target.

On the defensive side, I explored two ways of using LLMs for code security testing.

First, I discuss Vuldra as an example of how LLMs can be used for static code analysis, integrating them with traditional SAST tools.

Second, I present my evaluation of Codex Security on TorMap, where I looked at real findings, proposed fixes, and practical limits in a developer workflow.

The main message of the talk is simple: LLMs can already help security teams on both the attacker and defender side, but their strengths and weaknesses are different.

Attendees will leave with a realistic view of where LLMs are already useful, where they still fail, and how to evaluate such tools in their own environment without treating them as magic.

Der Cyber Resilience Act (CRA) stellt Sicherheitsanforderungen an Hersteller und Anbieter von Produkten mit digitalen Elementen. Viele Unternehmen haben bereits ein grundlegendes Sicherheitsniveau, doch der gezielte Abgleich mit den CRA-Anforderungen ist aufwändig und zeigt häufig unerwartete Lücken.

Der Vortrag stellt ein Vorgehen vor, mit dem sich diese Gaps effizient identifizieren und daraus priorisierte Maßnahmen ableiten lassen. Die Basis stellt das OWASP SAMM Framework dar, das als Best-Practice für Secure Software Development Lifecycle (SSDLC) auch eine Standortbestimmung und kontinuierliche Weiterentwicklung mit individuellen Schwerpunkten ermöglicht.

Ein hierfür entwickeltes Mapping von CRA auf den OWASP SAMM ermöglicht ein strukturiertes CRA-Assessment und kurzfristig eine zielgerichtete Umsetzung der regulatorischen Anforderungen. Gleichzeitig wird ein erweitertes Rahmenwerk geschaffen, das hilft, den sicheren Entwicklungsprozess langfristig zu verbessern. Das Vorgehen erlaubt die Automatisierung einzelner Aufgaben wie dem Compliance-Check, reduziert somit den manuellen Aufwand und beschleunigt die Umsetzung. Praxisbeispiele verdeutlichen, wie Unternehmen so nicht nur effizient und ggf. KI-unterstützt CRA-Compliance erreichen, sondern einen nachhaltigen und resilienten SSDLC etablieren.

For decades, security code audits were limited by a scarcity of eyes in "given enough eyes, all bugs are shallow" (Linus' Law). This has been turned upside down with the rise of LLM-driven vulnerability discovery. In the past months, my team and I have learned how to approach finding and fixing security bugs at unprecedented volume in Firefox. This talk will share the hard-earned realizations from going through multiple waves in which the sheer number of bugs could have risked stalling all other tasks. We will share our approach to identify bottle necks, scale the rest of the secure development lifecycle, and the evolving responsibilities of security teams. If you aren't already utilizing AI to hunt for vulnerabilities, an adversary likely is; this presentation provides a blueprint for adapting your organization to a future where discovery is no longer the primary hurdle.

Implementieren Sie OAuth noch nach einem Spec von 2012? Dann ist Ihre Anwendung vermutlich unsicher! OAuth 2.0 hat sich in 13 Jahren durch ein Labyrinth von RFCs und Best Practices entwickelt – Implicit Flow ist deprecated, PKCE ist Pflicht, Password Grant ein No-Go. Aber wer weiß das schon alles?

OAuth 2.1 räumt endlich auf: Ein Draft, der alle modernen Security Best Practices vereint und unsichere Flows eliminiert. Klingt perfekt? Ist es auch! Nur leider wendet ihn fast niemand an.

In diesem Talk zeigt Ihnen Martina Kraus, warum OAuth 2.1 Ihre OAuth-Implementierung von Grund auf sicherer macht, welche Breaking Changes auf Sie warten und wie Sie schon heute damit arbeiten können.

Artificial intelligence is becoming a core building block of modern applications, yet the way we secure software has not kept pace with the unique properties of AI systems. Traditional approaches often rely on static assumptions and deterministic behavior, while AI introduces probabilistic outputs, dynamic decision-making, and new forms of interaction that challenge established security practices.

The OWASP AI Security Verification Standard (AISVS) is an effort to address this gap by providing a structured and testable framework for securing AI-enabled applications. It builds on the idea that security should be verifiable and measurable, and adapts this principle to systems that incorporate machine learning models, large language models, and autonomous components.

This talk presents the motivation behind AISVS, its design principles, and how it defines security requirements that can be consistently evaluated. It explores how developers and security teams can use AISVS to move from informal or reactive approaches toward a more systematic way of validating the security of AI systems throughout their lifecycle.

By focusing on clarity, practical applicability, and alignment with real-world development workflows, AISVS aims to become a foundation for building trust in AI-driven applications. Attendees will gain an understanding of how a verification standard can help bring structure and confidence to a rapidly evolving and often uncertain security landscape.

Due to the rise of memory-safe languages like Rust, attention shifts towards logic bugs, which do not arise from insecure memory accesses. Identifying these bugs in large and complex codebases is hard, because bugs are mainly triggered by rare edge cases. Fuzzing is a great technique to induce random behavior and observe the edge cases in the application logic that are prone to logic bugs.

However, fuzzing logic bugs requires a bug oracle, to detect whenever the application behavior deviates. Such models are hard to define, if they must infer correct or incorrect behavior based on the applications output. We propose a different approach: Oracles can be implemented effectively by applying small patches on the target application, because they can be defined as invariants that must hold across all random executions. This talk presents this approach exemplary on recent work, detecting site isolation bypass bugs in web browsers.

Site isolation is one of the core security mechanisms of modern browsers. When using site isolation, the browser confines all processing related to a site to its own sandboxed renderer process. This, however, requires the central browser process to keep track of which renderer process belongs to which site. Logic bugs in this implementation, allow attackers to leak sensitive data, such as cookies, or achieve Universal Cross-Site Scripting.

We implemented two oracles, the leak sanitizer and the process sanitizer, that detect a wide range of site isolation bypass bugs. Combined with a fuzzer that targets edge cases in cross-site communication and navigation, our oracles detected four site isolation bugs in Chrome and Firefox.

This basic approach generalizes to other complex applications and classes of logic bugs. In this talk, we will explore how to set up a fuzzer for logic bugs and to inspire you to find logic bugs in more complex applications.

Chat Bots und AI Agents werden immer mehr produktiv eingesetzt. Oft sollen diese mit einer SQL Datenbank interagieren können. Wenn lediglich Daten gelesen, aber nicht verändert werden sollen, scheint es sinnvoll einen "Read-Only" SQL MCP Server dafür zu verwenden. Doch was wenn dieser doch nicht so "Read-Only" wie versprochen ist und zum Beispiel der Chatbot zur Kundenberatung auf einmal dazu benutzt werden kann die Preise von Produkten oder Passwörter von Benutzern zu ändern?

Ich habe 19 "Read-Only" SQL MCP Server untersucht und in 18 innerhalb von je 30 Minuten Schwachstellen gefunden; so "Read-Only" waren diese dann doch nicht...

Kubernetes is the backbone of modern applications with a very fast development cycle. To address new threats the OWASP Kubernetes Top 10 received a major update in 2025. This session brings these theoretical risks to life.

We will review the new 2025 security risks and explain how they work. Then we move into action. Through live practical demonstrations you will see how attackers exploit these flaws to steal secrets, escape containers, or take over whole clusters.

For every attack shown we immediately switch to defense. You will learn how to detect these malicious actions and protect your workloads using cloud native tools.

This presentation is for engineers and security professionals who want a clear understanding of the new 2025 OWASP standard combined with hands-on hacking and defense.

Modern digital administration infrastructure runs on a container-based infrastructure – but where do the secure container images come from? Currently, they come predominantly from US providers, with all the well-known risks of vendor lock-in, data sovereignty and supply chain vulnerabilities. At a time when geopolitical conditions can change within a matter of weeks and software supply chain attacks (Shai-Hulud, npm worms, compromised base images) have become the norm, this is a strategic problem.

Through the Secure Government Container Initiative (SGCI (also part of the sSDLC Strategy - see uploaded paper)) and the container.gov.de platform, ZenDiS provides openCode-verified, hardened container images for the federal government, the federal states and public IT – as open building blocks, developed in collaboration with the community. As a technical implementation partner, we report first-hand: how do we harden containers in accordance with BSI standards and NIST SP 800-190? What toolchain is emerging in the process? Where do we stand after the initial set-up phase – and what else can be done to ensure this project is ultimately successful?

CI/CD pipelines have become prime targets for supply chain attacks, enabling persistent compromise of distribution builds and secrets. In the GitHub Actions ecosystem specifically, documented attack techniques typically focus on developer mistakes, such as environment injections and pwn requests. However, research scanning Docker Hub has revealed a different class of vulnerability: over 240,000 GitHub authentication tokens leaked through a seemingly benign workflow pattern using legitimate, official actions, in particular the combination of actions/checkout and the common COPY . Docker antipattern.

This presentation will explain the complete vulnerability chain from workflow execution to token exposure, demonstrate exploitation techniques that overcome default security mechanisms — racing against token expiration while exploiting elevated workflow permissions — and provide a multi-layered defense strategy including critical action version updates and Docker hardening best practices.

Amerikanische Cloud-Anbieter durch europäische zu ersetzen ist im aktuellen politischen Umfeld gewollt — technisch aber ein Kompromiss, denn europäische Anbieter sind kleiner und bieten entsprechend weniger Komfort- und Sicherheits-Features.

Auch unser Projekt musste in eine europäische Cloud migrieren. Ähnliche Anforderungen wurden auch an andere unserer Projekte gestellt, wodurch ein projektübergreifender Betrieb entstand. Dieser Vortrag zeigt wie wir unseren Betrieb von AWS in einen europäischen Cloud-Dienst überführt haben. Dabei mussten wir inkompatible Sicherheitsanforderungen verschiedener Projekte managen und undokumentierte „Feature“ zähmen, um am Ende einen sicheren langlebigen europäischen Cloudbetrieb zu schaffen.

Der Schwerpunkt liegt auf den sicherheitsrelevanten Entscheidungen — warum wir sie so getroffen haben, welche sich aus unserer Sicht bewährt haben und welche wir im Nachhinein anders treffen würden.

Research shows that up to 50% of security fixes in open source repositories are committed silently — no CVE, no advisory, no changelog entry — and more than 10% have active exploits in the wild before anyone outside the project knows (Li & Paxson, CCS 2017; Dong et al., DSN 2025).

Traditional detection techniques like binary patch classifiers can tell you whether a patch is a security fix — but not what the vulnerability was or how to exploit it. Until now, reconstruction still required a skilled analyst and hours of work.

This all changes with the advent of Large Language Models. In this talk, we present Lacuna, a tool that diffs two versions of an npm, Maven, or PyPI package and runs a three-phase LLM pipeline to produce a full vulnerability reconstruction — attack scenario, CWE, CVSS vector — and determine whether it was ever disclosed.

In our testing, roughly one in six version bumps in popular packages contained undisclosed security fixes — including packages with tens of millions of weekly downloads. We found silent fixes for SSRF, prototype pollution patches described as a performance improvement, and a critical TLS bypass update with no changelog entry at all.

The uncomfortable implication: any attacker with enough tokens can turn a silent patch into a working exploit. Maintainers who have relied on quiet fixes to buy their users time need to reckon with that. When the window between patch and working exploit has collapsed to minutes, publishing an advisory is no longer optional. Without a CVE, your SBOM lists the dependency clean and your software composition analysis scan stays green. That raises a question the industry hasn't fully answered: should tools be analysing what actually changed between versions, not just what was disclosed?