Conference Schedule & Speaker Directory

3-Day Training: November 2-4, 2026
Level:Intermediate
Trainer: Abraham Aranguren

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Modern Android and iOS apps rarely operate alone. They sit at the center of rich ecosystems: phones talking to toys, drones, wearables, vehicles, trackers, “smart” homes—and, in multiple countries, even government‑mandated and police apps. In these environments, attackers increasingly target the mobile app as the remote control for the device, often without ever touching the physical hardware.

This 3‑day, 100% hands‑on course is a deep dive into the OWASP Mobile Security Testing Guide (MSTG) and relevant items of the OWASP Mobile Application Security Verification Standard (MASVS). The 2026 Edition fully covers and goes beyond the OWASP Mobile Top Ten, using real‑world Android, iOS, and IoT applications as targets.

7ASecurity is an ISO 27001 and SOC 2–certified cybersecurity consultancy and OWASP Platinum Supporter that focuses on researcher‑led, heavily manual penetration tests and secure code audits. Lessons learned from these engagements—performed for organizations such as the Linux Foundation, Mozilla, the Tor Project, and others—feed directly into the course material, labs, and case studies.

Across three intensive days you will:
Break down Android and iOS apps with static and dynamic analysis.
Discover IoT vulnerabilities using only the apps and APIs, no devices required.
Master practical instrumentation using Frida, Objection, Xposed, and related tooling to bypass protections and deeply inspect runtime behavior.

Ideal for penetration testers, red teamers, mobile developers, and anyone serious about mobile/IoT security, this course is all action, no fluff. It is packed with exercises, extra‑mile challenges, and CTFs, and includes continued education via lifetime access to a training portal with step‑by‑step video recordings, updated labs, and unlimited email support, including all future updates for free.

Teaser Video: https://www.youtube.com/watch?v=Re5oqfVkgd4
Get a free taste of this training, including access to video recordings, slides, and vulnerable apps to play with:
https://7asecurity.com/free-workshop-mobile-practical
https://7asecurity.com/free-workshop-mobile-deeplinks-xss

3-Day Training: November 2-4, 2026
Level:Intermediate
Trainer: Adam Shostack

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

This is our popular Threat Modeling Intensive course, where you'll learn to Threat Model, and then you'll learn how to incorporate large language models (LLMs) into every stage of the threat modeling process. Rather than replacing traditional threat modeling techniques, AI becomes a collaborative assistant that helps teams explore designs, generate ideas, evaluate risks, and improve efficiency. 

Throughout the course, you'll compare traditional approaches with AI-assisted workflows, learn where AI excels, recognize where it can fail, and develop practical techniques for using AI
to help your organization scale.

This hands-on course emphasizes experimentation, evaluation, and critical analysis so that you leave with the confidence to make AI a productive member of your threat modeling toolkit—not a replacement for your expertise.

3-Day Training: November 2-4, 2026
Level: Beginner
Trainer:Jon McCoy

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Day 1: The Toolsmith (AI-Augmented Security Engineering)
*Focus: Building a high-velocity toolkit for rapid security synthesis and infrastructure hardening.*

*   **The Synthesis Workflow**
    *   Mastering LLM-driven code generation for security scripts.
    *   Building "Disposable Tools" for one-off reconnaissance and triage.
    *   Debugging and refining AI-generated security code.
*   **Security Engineering & Governance**
    *   Developing "Agentic Playbooks" for automated hardening.
    *   Writing high-fidelity Security Requirements (Human vs. Agent-readable).
    *   Creating "Cheat Sheets" for standardizing AI-assisted security tasks.
*   **Hands-on Labs: AI-Driven Hardening & Validation**
    *   **Infrastructure:** Automating Dockerfile, Terraform, and Network Rule hardening.
    *   **Application:** Automated code reviews, "Sink" point identification, and auto-remediation.
    *   **Validation:** Building "Checkers" to programmatically verify vulnerability fixes.

Day 2: The Architect of Trust (Agentic AppSec & Governance)
*Focus: Engineering the autonomous guardrails and validation gates for the Agentic SDLC.*

*   **Securing the Agentic Architecture**
    *   **Tool-Use Guardrails:** Implementing strict schemas and permissions for function calling.
    *   **Sandboxing & Isolation:** Engineering secure execution environments for agent-run code.

3-Day Training: November 2-4, 2026
Level: Intermediate
Trainer: Dawid Czagan

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Modern IT systems are increasingly complex, making full-stack expertise more essential than ever. That's why diving into full-stack pentesting is crucial—you will gain the skills needed to master modern attack vectors and implement effective defensive countermeasures.

For each attack, vulnerability and technique presented in this training, there is a lab exercise to help you develop your skills step by step. What's more, when the training is over, you can take the complete lab environment home to hack again at your own pace.

I found security bugs in many companies including Google, Yahoo, Mozilla, Twitter and in this training I'll share my experience with you.

Key Learning Objectives
After completing this training, you will have learned about:

- Hacking cloud applications
- API hacking tips & tricks
- Data exfiltration techniques
- OSINT asset discovery tools
- Tricky user impersonation
- Bypassing protection mechanisms
- CLI hacking scripts
- Interesting XSS attacks
- Server-side template injection
- Hacking with Google & GitHub search engines
- Automated SQL injection detection and exploitation
- File read & file upload attacks
- Password cracking in a smart way
- Hacking Git repos
- XML attacks
- NoSQL injection
- HTTP parameter pollution
- Web cache deception attack
- Hacking with wrappers
- Finding metadata with sensitive information
- Hijacking NTLM hashes
- Automated detection of JavaScript libraries with known vulnerabilities
- Extracting passwords
- Hacking Electron applications
- Establishing reverse shell connections
- RCE attacks
- XSS polyglot
- and more …

What Students Will Receive
Students will be handed in a VMware image with a specially prepared lab environment to play with all attacks, vulnerabilities and techniques presented in this training. When the training is over, students can take the complete lab environment home (after signing a non-disclosure agreement) to hack again at their own pace.

Special Bonus
The ticket price includes FREE access to my 6 online courses:

- Fuzzing with Burp Suite Intruder
- Exploiting Race Conditions with OWASP ZAP
- Case Studies of Award-Winning XSS Attacks: Part 1
- Case Studies of Award-Winning XSS Attacks: Part 2
- How Hackers Find SQL Injections in Minutes with Sqlmap
- Web Application Security Testing with Google Hacking

What Students Say About My Trainings
References are attached to my LinkedIn profile (https://www.linkedin.com/in/dawid-czagan-85ba3666/). They can also be found here: https://silesiasecuritylab.com/services/training/#opinions – training participants from companies such as Oracle, Adobe, ESET, ING, Red Hat, Trend Micro, Philips, government sector

What Students Should Know
To get the most of this training intermediate knowledge of web application security is needed. Students should have experience in using a proxy, such as Burp Suite Proxy or Zed Attack Proxy (ZAP), to analyze or modify the traffic.

What Students Should Bring
Students will need a laptop with 64-bit operating system, at least 8 GB RAM, 35 GB free hard drive space, administrative access, ability to turn off AV/firewall and VMware Player/Fusion installed (64-bit version). Prior to the training, make sure there are no problems with running x86_64 VMs.

Additional notes
This new 3-day training was sold out at top security conferences e.g. DEF CON (Las Vegas), Hack In Paris (Paris).

This is a 100% hands-on training: for each attack, vulnerability and technique presented in this training, there is a lab exercise to help students develop their skills step by step.

2-Day Training: November 3-4, 2026
Level: Intermediate
Trainers: Abhinav Singh

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Can prompt injections lead to complete infrastructure takeovers? Could AI agents, MCP-connected tools, or poisoned external context be abused to compromise backend services? Can data poisoning in AI copilots impact a company’s stock? Can jailbreaks create false crisis alerts in security systems? This immersive, CTF-styled training in GenAI, LLM, agent, and MCP security dives into these pressing questions. Engage in realistic attack-and-defense scenarios focused on real-world threats, from prompt injection and remote code execution to backend compromise, tool abuse, unsafe agent orchestration, trust and authorization failures. Tackle hands-on challenges with live AI applications to understand vulnerabilities and build robust defenses. Learn how to build a comprehensive security pipeline, master AI red and blue team strategies, secure tool-connected and agentic systems, implement resilient guardrails for LLMs, and handle incident response for AI-based threats. You will also explore governance, Responsible AI, and enterprise security patterns for modern AI ecosystems.

By the end of this training, you will be able to:

- Exploit vulnerabilities in AI applications to achieve code and command execution, uncovering scenarios such as instruction injection, agent control bypass, remote code execution for infrastructure takeover, as well as chaining multiple agents for goal hijacking.
- Conduct AI red-teaming using adversary simulation, OWASP LLM Top 10, and MITRE ATLAS frameworks, while applying AI security and ethical principles in real-world scenarios.
- Execute and defend against adversarial attacks, including prompt injection, data poisoning, jailbreaks, agentic attacks, and insecure tool-connected workflows.
- Perform advanced AI red and blue teaming through multi-agent auto-prompting attacks, implementing a 3-way autonomous system consisting of attack, defend, and judge models.
- Build and deploy enterprise-grade LLM defenses, including custom guardrails for input/output protection, security benchmarking, penetration testing of LLM agents, and defensive controls for MCP-enabled integrations.
- Understand MCP fundamentals and assess how they expand the attack surface of modern AI systems.
- Establish a comprehensive LLM SecOps process to secure the supply chain from adversarial attacks and create a robust threat model for enterprise applications, including AI systems connected to external tools and data sources through MCP-like architectures.
- Implement an incident response and risk management plan for enterprises developing or using AI services.

2-Day Training: November 3-4, 2026
Level:Intermediate
Trainer: Sebastien Deleersnyder

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

This training immerses you in the practical world of threat modeling through hands-
on exercises and real-world scenarios. With 25 years of practical experience and
over a decade of delivering this training at Black Hat, it emphasizes an interactive
approach—70% of the course is dedicated to exercises that reinforce learning. By
the end, you'll gain not only knowledge but also the skills to effectively practice threat
modeling within your organization.

Updated annually, this revised training covers the latest threat intelligence and attack
methods expected for 2026 and beyond, including risks associated with LLMs and
other AI systems. Participants will engage in practical activities inspired by real
industry projects, such as integrating threat modeling into secure-by-design and
DevOps workflows. Key features include threat-informed defense using MITRE
frameworks like ATT&CK for real-world analysis, using threat libraries and
intelligence to deepen threat understanding, and tackling modern challenges such as
modeling threats for AI-driven systems—specifically, a machine-learning-powered
chatbot. 

Before the training, all participants will get access to our self-paced “introduction to
threat modeling” course, designed to bring participants up to speed.

As practitioners with hands-on experience, we understand the gap between book-
based threat modeling knowledge and the practical challenges faced in real-world
environments. To address this, we have created a comprehensive real-world case
study and exercises to help you build effective threat models.
In this course, you will work in teams of 3 or 4 to address the stages of threat
modeling across various technology stacks.

Examples include:
• Use case describing a home automation system
• Data flow diagramming and trust boundaries
• Identifying threats
• AI-Assisted STRIDE analysis
• Constructing an attack tree
• Mitigating threats
• AI-Assisted mitigations
• Applying GDPR Risk Patterns for Privacy by Design
• Using AI resources to threat model a machine learning powered
HomeAutomationBot
• Integrating the OWASP Threat Modeling Playbook into agile development
• Threat Modeling a CI/CD supply chain
• Red Team / Blue Team battle for control over an offshore wind turbine park

After each exercise, we encourage in-depth discussions and provide a documented
solution to reinforce your understanding. Additionally, participants are invited to
create and submit their “Bring Your Own Case” (BYOC) threat models after the
training and receive personalized feedback to improve their techniques.
To receive the “Certified Threat Modeling Practitioner” certificate, participants must
pass an exam and submit their BYOC threat model.

This training extends beyond the classroom: every participant gains access to our
Threat Modeling Playbook, one year of online learning resources, and invitations to
monthly Ask-Me-Anything sessions to help you keep improving your threat modeling
skills long after the course concludes.

2-Day Training: November 3-4, 2026
Level: Intermediate
Trainers:Avi Douglen

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Suddenly anyone and everyone in your organization can use AI assistants to write code. Meanwhile, your actual developers are putting out 100x their previous output , with “varying” levels of quality. So how are you going to secure code at this scale?

This course is designed to be a deep dive into state-of-the-art techniques for validating code security within an organization’s codebase. The course has a strong emphasis on how AI-driven analysis can drive this forward whilst also clearly highlighting where standard, deterministic techniques (albeit incorporating AI acceleration) will be more effective.

During the course, you will learn how to combine these techniques, in a scalable and repeatable way, based on our experience doing just this with real organizations and real teams and with a focus on the current state of the art in this fast-moving area.

This course goes beyond the scope of standard application security knowledge and is designed to make you a specialist in this area. Having spent several years perfecting this process, we are excited to impart the lessons we have learnt!

The course is structured as follows:

* Overview – setting out the basic details of what we will be talking about in terms of code scanning and SAST.
* Key techniques – Discuss the different techniques which can be used for this including generic “off the shelf” SAST, deterministic custom scanning rules, and LLM powered custom AI prompts
* Technique comparison - Advantages and disadvantages of each technique based on our in-depth experience with each and which technique you will want to use in different situations, to avoid wasting time trying to use a technique in an inappropriate use case.
* Organizational process – How to get these processes built into an organization’s existing software lifecycle
* Generic SAST – Using “off the shelf” rules effectively to catch “low hanging fruit” and avoid reinventing the wheel.
* Custom SAST – Introduce custom rule languages (e.g., Semgrep, CodeQL), writing rules from scratch, and scaling analysis across a codebase.
* Basic AI Code Security Scanning – Overview of AI-based scanning, platforms, principles, and initial single-shot prompts

3-Day Training: November 2-4, 2026
Level:Intermediate
Trainer: Abraham Aranguren

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Modern Android and iOS apps rarely operate alone. They sit at the center of rich ecosystems: phones talking to toys, drones, wearables, vehicles, trackers, “smart” homes—and, in multiple countries, even government‑mandated and police apps. In these environments, attackers increasingly target the mobile app as the remote control for the device, often without ever touching the physical hardware.

This 3‑day, 100% hands‑on course is a deep dive into the OWASP Mobile Security Testing Guide (MSTG) and relevant items of the OWASP Mobile Application Security Verification Standard (MASVS). The 2026 Edition fully covers and goes beyond the OWASP Mobile Top Ten, using real‑world Android, iOS, and IoT applications as targets.

7ASecurity is an ISO 27001 and SOC 2–certified cybersecurity consultancy and OWASP Platinum Supporter that focuses on researcher‑led, heavily manual penetration tests and secure code audits. Lessons learned from these engagements—performed for organizations such as the Linux Foundation, Mozilla, the Tor Project, and others—feed directly into the course material, labs, and case studies.

Across three intensive days you will:
Break down Android and iOS apps with static and dynamic analysis.
Discover IoT vulnerabilities using only the apps and APIs, no devices required.
Master practical instrumentation using Frida, Objection, Xposed, and related tooling to bypass protections and deeply inspect runtime behavior.

Ideal for penetration testers, red teamers, mobile developers, and anyone serious about mobile/IoT security, this course is all action, no fluff. It is packed with exercises, extra‑mile challenges, and CTFs, and includes continued education via lifetime access to a training portal with step‑by‑step video recordings, updated labs, and unlimited email support, including all future updates for free.

Teaser Video: https://www.youtube.com/watch?v=Re5oqfVkgd4
Get a free taste of this training, including access to video recordings, slides, and vulnerable apps to play with:
https://7asecurity.com/free-workshop-mobile-practical
https://7asecurity.com/free-workshop-mobile-deeplinks-xss

3-Day Training: November 2-4, 2026
Level:Intermediate
Trainer: Adam Shostack

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

This is our popular Threat Modeling Intensive course, where you'll learn to Threat Model, and then you'll learn how to incorporate large language models (LLMs) into every stage of the threat modeling process. Rather than replacing traditional threat modeling techniques, AI becomes a collaborative assistant that helps teams explore designs, generate ideas, evaluate risks, and improve efficiency. 

Throughout the course, you'll compare traditional approaches with AI-assisted workflows, learn where AI excels, recognize where it can fail, and develop practical techniques for using AI
to help your organization scale.

This hands-on course emphasizes experimentation, evaluation, and critical analysis so that you leave with the confidence to make AI a productive member of your threat modeling toolkit—not a replacement for your expertise.

3-Day Training: November 2-4, 2026
Level: Beginner
Trainer:Jon McCoy

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Day 1: The Toolsmith (AI-Augmented Security Engineering)
*Focus: Building a high-velocity toolkit for rapid security synthesis and infrastructure hardening.*

*   **The Synthesis Workflow**
    *   Mastering LLM-driven code generation for security scripts.
    *   Building "Disposable Tools" for one-off reconnaissance and triage.
    *   Debugging and refining AI-generated security code.
*   **Security Engineering & Governance**
    *   Developing "Agentic Playbooks" for automated hardening.
    *   Writing high-fidelity Security Requirements (Human vs. Agent-readable).
    *   Creating "Cheat Sheets" for standardizing AI-assisted security tasks.
*   **Hands-on Labs: AI-Driven Hardening & Validation**
    *   **Infrastructure:** Automating Dockerfile, Terraform, and Network Rule hardening.
    *   **Application:** Automated code reviews, "Sink" point identification, and auto-remediation.
    *   **Validation:** Building "Checkers" to programmatically verify vulnerability fixes.

Day 2: The Architect of Trust (Agentic AppSec & Governance)
*Focus: Engineering the autonomous guardrails and validation gates for the Agentic SDLC.*

*   **Securing the Agentic Architecture**
    *   **Tool-Use Guardrails:** Implementing strict schemas and permissions for function calling.
    *   **Sandboxing & Isolation:** Engineering secure execution environments for agent-run code.

3-Day Training: November 2-4, 2026
Level: Intermediate
Trainer: Dawid Czagan

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Modern IT systems are increasingly complex, making full-stack expertise more essential than ever. That's why diving into full-stack pentesting is crucial—you will gain the skills needed to master modern attack vectors and implement effective defensive countermeasures.

For each attack, vulnerability and technique presented in this training, there is a lab exercise to help you develop your skills step by step. What's more, when the training is over, you can take the complete lab environment home to hack again at your own pace.

I found security bugs in many companies including Google, Yahoo, Mozilla, Twitter and in this training I'll share my experience with you.

Key Learning Objectives
After completing this training, you will have learned about:

- Hacking cloud applications
- API hacking tips & tricks
- Data exfiltration techniques
- OSINT asset discovery tools
- Tricky user impersonation
- Bypassing protection mechanisms
- CLI hacking scripts
- Interesting XSS attacks
- Server-side template injection
- Hacking with Google & GitHub search engines
- Automated SQL injection detection and exploitation
- File read & file upload attacks
- Password cracking in a smart way
- Hacking Git repos
- XML attacks
- NoSQL injection
- HTTP parameter pollution
- Web cache deception attack
- Hacking with wrappers
- Finding metadata with sensitive information
- Hijacking NTLM hashes
- Automated detection of JavaScript libraries with known vulnerabilities
- Extracting passwords
- Hacking Electron applications
- Establishing reverse shell connections
- RCE attacks
- XSS polyglot
- and more …

What Students Will Receive
Students will be handed in a VMware image with a specially prepared lab environment to play with all attacks, vulnerabilities and techniques presented in this training. When the training is over, students can take the complete lab environment home (after signing a non-disclosure agreement) to hack again at their own pace.

Special Bonus
The ticket price includes FREE access to my 6 online courses:

- Fuzzing with Burp Suite Intruder
- Exploiting Race Conditions with OWASP ZAP
- Case Studies of Award-Winning XSS Attacks: Part 1
- Case Studies of Award-Winning XSS Attacks: Part 2
- How Hackers Find SQL Injections in Minutes with Sqlmap
- Web Application Security Testing with Google Hacking

What Students Say About My Trainings
References are attached to my LinkedIn profile (https://www.linkedin.com/in/dawid-czagan-85ba3666/). They can also be found here: https://silesiasecuritylab.com/services/training/#opinions – training participants from companies such as Oracle, Adobe, ESET, ING, Red Hat, Trend Micro, Philips, government sector, ...

What Students Should Know
To get the most of this training intermediate knowledge of web application security is needed. Students should have experience in using a proxy, such as Burp Suite Proxy or Zed Attack Proxy (ZAP), to analyze or modify the traffic.

What Students Should Bring
Students will need a laptop with 64-bit operating system, at least 8 GB RAM, 35 GB free hard drive space, administrative access, ability to turn off AV/firewall and VMware Player/Fusion installed (64-bit version). Prior to the training, make sure there are no problems with running x86_64 VMs.

Additional notes
This new 3-day training was sold out at top security conferences e.g. DEF CON (Las Vegas), Hack In Paris (Paris).

This is a 100% hands-on training: for each attack, vulnerability and technique presented in this training, there is a lab exercise to help students develop their skills step by step.

This is a private session for OWASP Board of Directors.

1-Day Training: November 4, 2026
Level: Intermediate
Trainers: Pranav Saji

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

SaaS integrations are now a primary path for privilege creep, token sprawl, and silent exposure across an organization. In this hands-on training, participants learn how to assess and continuously monitor SaaS integrations using practical security signals such as over-scoped OAuth grants, non-expiring API tokens, dormant but valid credentials, admin privilege duration, environment token reuse, and public sharing risk.

We will turn these signals into an actionable review rubric and then into automation: how to pull audit-ready evidence from common SaaS APIs, normalize it into a consistent model, and generate security findings that are explainable to engineering and compliance teams. Participants will leave with a reusable signal checklist, a prioritization approach, and reference architectures to operationalize continuous monitoring without breaking least-privilege principles.

How to streamline the identification of security requirements associated with software functionalities in agile methodologies using OWASP Cornucopia to plan and manage application security from analysis and design, and also manage security defects associated with unimplemented or poorly implemented controls.

1. Introduction: Understand the theory about evil user stories modeling, when to execute in the SDLC and the value of the exercise.
2. Understand the importance of integrating security requirements from the user story definition phase.
3.- Identify how to integrate security requirements into user stories and convert them into actionable tasks within the backlog using Evil User Stories modeling (a variation of Abuse Case Modeling in Agile combined with secure scrum).
4.- Design a single product backlog that integrates security functionalities and controls into user stories avoiding the creation of a cybersecurity parallel backlog.
5.- Apply a proactive approach where security is part of the design process, not just the final validation.
6.- Designing a traceability matrix based on the execution of OWASP Cornucopia

1-Day Training: November 4, 2026
Level: Intermediate
Trainers: Juliane Reimann and Marisa Fagan

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Do you feel a disconnect between your cybersecurity efforts and engineering activities? If so, a Security Champions Program could bridge the gap. By involving engineers in security topics that align with their work, a Security Champions program not only enhances security awareness but also fosters a culture of security across your organization. However, creating such a program requires careful planning, innovative strategies, and a solid understanding of what drives individuals to champion security initiatives.

This training will equip you with practical tools and actionable insights to design and launch a successful Security Champions Program. You'll explore key concepts, including how to:
- Develop a foundational understanding of what a Security Champions Programs is
- Plan and navigate the phases of program development, from launch to long-term growth.
- Learn about strategies to engage and motivate diverse personality types within the organization
- Acquire practical tools and a structured approach to establish a scalable and trackable Security Champions Program

Whether you're a security engineer, architect, or manager, this training will provide you with the tools and frameworks to collaborate effectively with your engineering teams and establish a thriving Security Champions Program.

The session is highly interactive, featuring hands-on exercises and team-based activities to encourage collaboration and networking with fellow professionals. Join us to gain the confidence and strategies you need to kickstart your journey toward a more secure organization.

1-Day Training: November 4, 2026
Level: Intermediate
Trainer: Rob van der Veer

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

The record-breaking Master AI security training is back!

This training broke the OWASP record online and on-site.

Your trainer is Rob van der Veer, Chief AI Officer at Software Improvement Group, with 33 years of AI experience, founder of the OWASP AI Exchange, co-editor for the AI Act security standard, member of the ISO/IEC 27090 for AI security, co-founder of OpenCRE, and main author of ISO 5338 on AI engineering.

Master AI security is a unique opportunity to become proficient in the intricate and rapidly evolving field of AI security.

The disruption by AI presents a significant challenge, regardless of whether you are a security professional, a developer, AI engineer, or a red teamer. What are your responsibilities? What constitutes the new AI attack surface, and what threats emerge from it? What measures can you take to mitigate these emerging risks?

This one-day intensive training program will equip you with the knowledge to tackle these AI-related challenges effectively, enabling you to apply what you learn immediately. Starting with a pragmatic overview of AI, the course then delivers an exhaustive exploration of the distinctive vulnerabilities AI introduces, the possible attack vectors, and the most current strategies to counteract threats like prompt injection, data poisoning, model theft, evasion, and more. Through practical exercises, you will gain hands-on experience in enacting strong security measures, attacking AI systems, conducting threat modelling on AI, and targeted vulnerability assessments for AI applications.

By day's end, you will possess a thorough comprehension of the core principles and techniques critical to strengthening AI systems. You will have gained practical insights and the confidence to implement cutting-edge AI security measures.

A key resource that is used in the training is the OWASP AI Exchange - the flagship project located at owaspai.org - which forms the foundation of ISO standard 27090 and the security standard of the AI Act.

The training is designed for all levels of attendees. as the material is new from the cutting edge of research and standardization. No in-depth security or AI knowledge is required, although some experience with either AI or security is helpful.

Attendees will be provided with handout slides and afterwards they can retrieve the unique Master AI security certificate.

Some testimonials of previous runs:

• Stephan Cohen – BNP Paribas: “This training has significantly enhanced my understanding of both the challenges and controls in securing AI. Looking forward to applying these insights in my work. Thank you Rob for this course.”
• Ramesh Krishnasaga - British Petroleum:  “The training was enlightening. This experience went b

1-Day Training: November 4, 2026
Level: Intermediate
Trainers: Marco Morana and Matteo Meucci

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

This course will provide each attendee with:

• Synapsed AI Lab: complimentary one-week license https://tinyurl.com/2ehpnnj6  to continue hands-on practice after the course and apply the AI security testing techniques covered during the sessions.
• Threat Modeling Academy: Threat Modeling Playground (TMPG) Tool complimentary two-weeks access: https://tinyurl.com/3j2dbd25 An interactive playground for learning how to create AI- and agentic-application threat models, including architecture analysis, data flows, trust boundaries, threat scenarios, attack paths, and security controls.

Anyone that get registered before September 30th will get: OWASP AI Testing Guide (AITG): complimentary printed copy of the OWASP AITG, https://tinyurl.com/2jenjx26  providing a practical reference for applying AI security testing techniques after the course, 2 weeks free usage of The training includes practical, hands-on exercises using tools for both AI threat modeling and AI security testing

The OWASP AI Testing Guide (AITG) provides a structured, comprehensive framework for validating Trustworthy AI systems across their entire lifecycle. Designed to support QA teams, security engineers, developers, auditors, and governance stakeholders, AITG establishes practical testing methodologies to assess AI security, privacy, and responsible AI behaviors.

The framework defines Trustworthy AI as the integration of:
1) Security AI (SecAI): Testing resilience against adversarial attacks such as prompt injection, model poisoning, evasion, and extraction.
2) Privacy AI (PrivacyAI): Validating protection against sensitive data leakage, membership inference, and model inversion risks.
3) Responsible AI (RespAI): Assessing fairness, safety, harmful output prevention, hallucination risks, explainability, and alignment with ethical policies.

AITG organizes testing coverage across four core AI product domains:
1. Application & Agent Testing
2. Model Testing

1-Day Training: November 4, 2026
Level: Beginner
Trainer: Jim Manico

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

AI coding assistants are rapidly becoming the core of modern software delivery. They can accelerate development, generate tests, explain unfamiliar code, and assist with security review. They can also introduce insecure patterns, mishandle secrets, overreach with dangerous permissions, and produce code that appears correct while quietly violating security requirements.

This one-day, hands-on workshop shows developers and security professionals how to take control of AI-assisted development by building a trustworthy, spec-driven secure coding workflow.

Jim Manico walks participants through setting up a secure Claude Code and Codex environments from scratch, including permission controls, project-level security rules, hook configuration, and sandboxing. Participants will learn how to load secure coding prompts, define security requirements before code is generated, and use Claude Code and Codex side by side for secure code generation, security review, test creation, and vulnerability detection.

The session is fast-moving, demo-driven, and grounded in real codebases. Attendees will leave with practical workflows they can apply immediately to make AI coding assistants a security asset rather than an uncontrolled source of risk.

What You’ll Learn:  By the end of this workshop, participants will be able to:

• Configure a safer Claude Code environment using permission controls, CLAUDE.md security rules, hooks, and sandboxing.
• Use secure coding prompts and project-level rules to guide AI tools toward secure-by-default output aligned with OWASP guidance.
• Apply spec-driven AI development techniques so security requirements are defined before code is generated.
• Use Claude Code and Codex together for code generation, independent review, vulnerability detection, and test creation.
• Identify common insecure patterns produced by AI coding assistants, including weak authorization, injection flaws, insecure secret handling, unsafe dependencies, and insufficient validation.
• Build repeatable AI-assisted workflows that developers, security engineers, and technical leads can bring back to their own teams.

Who Should Attend:  This course is designed for:

• Developers using or evaluating AI coding assistants who want to ship secure code from the start.
• Security engineers who need to understand how AI tools generate insecure code patterns and how to detect, review, and fix them.
• Application security professionals building secure development workflows for AI-assisted engineering teams.
• Tech leads and architects evaluating how AI coding tools should be adopted safely across their organizations.

Requirements: Participants should bring a laptop suitable for software development and be comfortable working with command-line tools, source code, and Git. An OpenAI or Anthropic account is needed to participate which we can set up in class. Prior experience with AI coding assistants is helpful but not required. The course is designed for developers and security professionals who want practical, repeatable workflows for using AI safely in real engineering environments.

2-Day Training: November 3-4, 2026
Level: Beginner
Trainer: Sebastien Deleersnyder

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

This training immerses you in the practical world of threat modeling through hands-on exercises and real-world scenarios. With 25 years of practical experience and over a decade of delivering this training at Black Hat, it emphasizes an interactive approach—70% of the course is dedicated to exercises that reinforce learning. By the end, you'll gain not only knowledge but also the skills to effectively practice threat modeling within your organization.

Updated annually, this revised training covers the latest threat intelligence and attack methods expected for 2026 and beyond, including risks associated with LLMs and other AI systems. Participants will engage in practical activities inspired by real industry projects, such as integrating threat modeling into secure-by-design and DevOps workflows. Key features include threat-informed defense using MITRE frameworks like ATT&CK for real-world analysis, using threat libraries and
intelligence to deepen threat understanding, and tackling modern challenges such as modeling threats for AI-driven systems—specifically, a machine-learning-powered chatbot. 

Before the training, all participants will get access to our self-paced “introduction to threat modeling” course, designed to bring participants up to speed.

As practitioners with hands-on experience, we understand the gap between book-based threat modeling knowledge and the practical challenges faced in real-world environments. To address this, we have created a comprehensive real-world case study and exercises to help you build effective threat models. In this course, you will work in teams of 3 or 4 to address the stages of threat modeling across various technology stacks.

Examples include:
• Use case describing a home automation system
• Data flow diagramming and trust boundaries
• Identifying threats
• AI-Assisted STRIDE analysis
• Constructing an attack tree
• Mitigating threats
• AI-Assisted mitigations
• Applying GDPR Risk Patterns for Privacy by Design
• Using AI resources to threat model a machine learning powered
HomeAutomationBot
• Integrating the OWASP Threat Modeling Playbook into agile development
• Threat Modeling a CI/CD supply chain
• Red Team / Blue Team battle for control over an offshore wind turbine park

After each exercise, we encourage in-depth discussions and provide a documented solution to reinforce your understanding. Additionally, participants are invited to create and submit their “Bring Your Own Case” (BYOC) threat models after the training and receive personalized feedback to improve their techniques. To receive the “Certified Threat Modeling Practitioner” certificate, participants must pass an exam and submit their BYOC threat model.

This training extends beyond the classroom: every participant gains access to our
Threat Modeling Playbook, one year of online learning resources, and invitations to
monthly Ask-Me-Anything sessions to help you keep improving your threat modeling
skills long after the course concludes.

2-Day Training: November 3-4, 2026
Level: Intermediate
Trainers: Abhinav Singh

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Can prompt injections lead to complete infrastructure takeovers? Could AI agents, MCP-connected tools, or poisoned external context be abused to compromise backend services? Can data poisoning in AI copilots impact a company’s stock? Can jailbreaks create false crisis alerts in security systems? This immersive, CTF-styled training in GenAI, LLM, agent, and MCP security dives into these pressing questions. Engage in realistic attack-and-defense scenarios focused on real-world threats, from prompt injection and remote code execution to backend compromise, tool abuse, unsafe agent orchestration, trust and authorization failures. Tackle hands-on challenges with live AI applications to understand vulnerabilities and build robust defenses. Learn how to build a comprehensive security pipeline, master AI red and blue team strategies, secure tool-connected and agentic systems, implement resilient guardrails for LLMs, and handle incident response for AI-based threats. You will also explore governance, Responsible AI, and enterprise security patterns for modern AI ecosystems.

By the end of this training, you will be able to:

- Exploit vulnerabilities in AI applications to achieve code and command execution, uncovering scenarios such as instruction injection, agent control bypass, remote code execution for infrastructure takeover, as well as chaining multiple agents for goal hijacking.
- Conduct AI red-teaming using adversary simulation, OWASP LLM Top 10, and MITRE ATLAS frameworks, while applying AI security and ethical principles in real-world scenarios.
- Execute and defend against adversarial attacks, including prompt injection, data poisoning, jailbreaks, agentic attacks, and insecure tool-connected workflows.
- Perform advanced AI red and blue teaming through multi-agent auto-prompting attacks, implementing a 3-way autonomous system consisting of attack, defend, and judge models.
- Build and deploy enterprise-grade LLM defenses, including custom guardrails for input/output protection, security benchmarking, penetration testing of LLM agents, and defensive controls for MCP-enabled integrations.
- Understand MCP fundamentals and assess how they expand the attack surface of modern AI systems.
- Establish a comprehensive LLM SecOps process to secure the supply chain from adversarial attacks and create a robust threat model for enterprise applications, including AI systems connected to external tools and data sources through MCP-like architectures.
- Implement an incident response and risk management plan for enterprises developing or using AI services.

2-Day Training: November 3-4, 2026
Level: Intermediate
Trainers:Avi Douglen

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Suddenly anyone and everyone in your organization can use AI assistants to write code. Meanwhile, your actual developers are putting out 100x their previous output , with “varying” levels of quality. So how are you going to secure code at this scale?

This course is designed to be a deep dive into state-of-the-art techniques for validating code security within an organization’s codebase. The course has a strong emphasis on how AI-driven analysis can drive this forward whilst also clearly highlighting where standard, deterministic techniques (albeit incorporating AI acceleration) will be more effective.

During the course, you will learn how to combine these techniques, in a scalable and repeatable way, based on our experience doing just this with real organizations and real teams and with a focus on the current state of the art in this fast-moving area.

This course goes beyond the scope of standard application security knowledge and is designed to make you a specialist in this area. Having spent several years perfecting this process, we are excited to impart the lessons we have learnt!

The course is structured as follows:

* Overview – setting out the basic details of what we will be talking about in terms of code scanning and SAST.
* Key techniques – Discuss the different techniques which can be used for this including generic “off the shelf” SAST, deterministic custom scanning rules, and LLM powered custom AI prompts
* Technique comparison - Advantages and disadvantages of each technique based on our in-depth experience with each and which technique you will want to use in different situations, to avoid wasting time trying to use a technique in an inappropriate use case.
* Organizational process – How to get these processes built into an organization’s existing software lifecycle
* Generic SAST – Using “off the shelf” rules effectively to catch “low hanging fruit” and avoid reinventing the wheel.
* Custom SAST – Introduce custom rule languages (e.g., Semgrep, CodeQL), writing rules from scratch, and scaling analysis across a codebase.
* Basic AI Code Security Scanning – Overview of AI-based scanning, platforms, principles, and initial single-shot prompts

3-Day Training: November 2-4, 2026
Level:Intermediate
Trainer: Abraham Aranguren

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Modern Android and iOS apps rarely operate alone. They sit at the center of rich ecosystems: phones talking to toys, drones, wearables, vehicles, trackers, “smart” homes—and, in multiple countries, even government‑mandated and police apps. In these environments, attackers increasingly target the mobile app as the remote control for the device, often without ever touching the physical hardware.

This 3‑day, 100% hands‑on course is a deep dive into the OWASP Mobile Security Testing Guide (MSTG) and relevant items of the OWASP Mobile Application Security Verification Standard (MASVS). The 2026 Edition fully covers and goes beyond the OWASP Mobile Top Ten, using real‑world Android, iOS, and IoT applications as targets.

7ASecurity is an ISO 27001 and SOC 2–certified cybersecurity consultancy and OWASP Platinum Supporter that focuses on researcher‑led, heavily manual penetration tests and secure code audits. Lessons learned from these engagements—performed for organizations such as the Linux Foundation, Mozilla, the Tor Project, and others—feed directly into the course material, labs, and case studies.

Across three intensive days you will:
Break down Android and iOS apps with static and dynamic analysis.
Discover IoT vulnerabilities using only the apps and APIs, no devices required.
Master practical instrumentation using Frida, Objection, Xposed, and related tooling to bypass protections and deeply inspect runtime behavior.

Ideal for penetration testers, red teamers, mobile developers, and anyone serious about mobile/IoT security, this course is all action, no fluff. It is packed with exercises, extra‑mile challenges, and CTFs, and includes continued education via lifetime access to a training portal with step‑by‑step video recordings, updated labs, and unlimited email support, including all future updates for free.

Teaser Video: https://www.youtube.com/watch?v=Re5oqfVkgd4
Get a free taste of this training, including access to video recordings, slides, and vulnerable apps to play with:
https://7asecurity.com/free-workshop-mobile-practical
https://7asecurity.com/free-workshop-mobile-deeplinks-xss

3-Day Training: November 2-4, 2026
Level:Intermediate
Trainer: Adam Shostack

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

This is our popular Threat Modeling Intensive course, where you'll learn to Threat Model, and then you'll learn how to incorporate large language models (LLMs) into every stage of the threat modeling process. Rather than replacing traditional threat modeling techniques, AI becomes a collaborative assistant that helps teams explore designs, generate ideas, evaluate risks, and improve efficiency. 

Throughout the course, you'll compare traditional approaches with AI-assisted workflows, learn where AI excels, recognize where it can fail, and develop practical techniques for using AI
to help your organization scale.

This hands-on course emphasizes experimentation, evaluation, and critical analysis so that you leave with the confidence to make AI a productive member of your threat modeling toolkit—not a replacement for your expertise.

3-Day Training: November 2-4, 2026
Level: Beginner
Trainer:Jon McCoy

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Day 1: The Toolsmith (AI-Augmented Security Engineering)
*Focus: Building a high-velocity toolkit for rapid security synthesis and infrastructure hardening.*

*   **The Synthesis Workflow**
    *   Mastering LLM-driven code generation for security scripts.
    *   Building "Disposable Tools" for one-off reconnaissance and triage.
    *   Debugging and refining AI-generated security code.
*   **Security Engineering & Governance**
    *   Developing "Agentic Playbooks" for automated hardening.
    *   Writing high-fidelity Security Requirements (Human vs. Agent-readable).
    *   Creating "Cheat Sheets" for standardizing AI-assisted security tasks.
*   **Hands-on Labs: AI-Driven Hardening & Validation**
    *   **Infrastructure:** Automating Dockerfile, Terraform, and Network Rule hardening.
    *   **Application:** Automated code reviews, "Sink" point identification, and auto-remediation.
    *   **Validation:** Building "Checkers" to programmatically verify vulnerability fixes.

Day 2: The Architect of Trust (Agentic AppSec & Governance)
*Focus: Engineering the autonomous guardrails and validation gates for the Agentic SDLC.*

*   **Securing the Agentic Architecture**
    *   **Tool-Use Guardrails:** Implementing strict schemas and permissions for function calling.
    *   **Sandboxing & Isolation:** Engineering secure execution environments for agent-run code.

3-Day Training: November 2-4, 2026
Level: Intermediate
Trainer: Dawid Czagan

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Modern IT systems are increasingly complex, making full-stack expertise more essential than ever. That's why diving into full-stack pentesting is crucial—you will gain the skills needed to master modern attack vectors and implement effective defensive countermeasures.

For each attack, vulnerability and technique presented in this training, there is a lab exercise to help you develop your skills step by step. What's more, when the training is over, you can take the complete lab environment home to hack again at your own pace.

I found security bugs in many companies including Google, Yahoo, Mozilla, Twitter and in this training I'll share my experience with you.

Key Learning Objectives
After completing this training, you will have learned about:

- Hacking cloud applications
- API hacking tips & tricks
- Data exfiltration techniques
- OSINT asset discovery tools
- Tricky user impersonation
- Bypassing protection mechanisms
- CLI hacking scripts
- Interesting XSS attacks
- Server-side template injection
- Hacking with Google & GitHub search engines
- Automated SQL injection detection and exploitation
- File read & file upload attacks
- Password cracking in a smart way
- Hacking Git repos
- XML attacks
- NoSQL injection
- HTTP parameter pollution
- Web cache deception attack
- Hacking with wrappers
- Finding metadata with sensitive information
- Hijacking NTLM hashes
- Automated detection of JavaScript libraries with known vulnerabilities
- Extracting passwords
- Hacking Electron applications
- Establishing reverse shell connections
- RCE attacks
- XSS polyglot
- and more …

What Students Will Receive
Students will be handed in a VMware image with a specially prepared lab environment to play with all attacks, vulnerabilities and techniques presented in this training. When the training is over, students can take the complete lab environment home (after signing a non-disclosure agreement) to hack again at their own pace.

Special Bonus
The ticket price includes FREE access to my 6 online courses:

- Fuzzing with Burp Suite Intruder
- Exploiting Race Conditions with OWASP ZAP
- Case Studies of Award-Winning XSS Attacks: Part 1
- Case Studies of Award-Winning XSS Attacks: Part 2
- How Hackers Find SQL Injections in Minutes with Sqlmap
- Web Application Security Testing with Google Hacking

What Students Say About My Trainings
References are attached to my LinkedIn profile (https://www.linkedin.com/in/dawid-czagan-85ba3666/). They can also be found here: https://silesiasecuritylab.com/services/training/#opinions – training participants from companies such as Oracle, Adobe, ESET, ING, Red Hat, Trend Micro, Philips, government sector, ...

What Students Should Know
To get the most of this training intermediate knowledge of web application security is needed. Students should have experience in using a proxy, such as Burp Suite Proxy or Zed Attack Proxy (ZAP), to analyze or modify the traffic.

What Students Should Bring
Students will need a laptop with 64-bit operating system, at least 8 GB RAM, 35 GB free hard drive space, administrative access, ability to turn off AV/firewall and VMware Player/Fusion installed (64-bit version). Prior to the training, make sure there are no problems with running x86_64 VMs.

Additional notes
This new 3-day training was sold out at top security conferences e.g. DEF CON (Las Vegas), Hack In Paris (Paris).

This is a 100% hands-on training: for each attack, vulnerability and technique presented in this training, there is a lab exercise to help students develop their skills step by step.

1-Day Training: November 4, 2026
Level: all
Trainers:Aram Hovsepyan and Timo Pagel 

To register, please purchase your training ticket here. Training and conference are two separate ticket purchases.

Learn more here!

Pick up your super fun conference t-shirt and member swag!

Calling all OWASP Merch and AppSec Book lovers!  Come visit Jonathan for your large selection of all things AppSec book relatated and don't forget to snag some OWASP merch too!

For my entire career, industry experts have gotten to play soothsayer to the less technical people who control the budget. Scare the business enough and you got your number, spent it on as many products as it covered, and hoped for the best. Maybe a breach happened. Maybe it didn't. Either way, nobody could say whether the program worked or whether the adversaries simply never showed up, so buyers kept paying for something they could never confirm they received.

That's ending. Underwriters, claims adjusters, and incident responders have now accumulated enough loss data to answer questions this industry has only ever guessed at. They can see which vulnerabilities adversaries actually exploit, which controls stop an incident before it becomes a claim, and where a security dollar buys nothing at all. Defenders have suspected those answers for years without any way to prove them. That evidence will split the industry in two, with one half still selling fear to boards that cannot check the claims, and the other half measuring outcomes and taking on liability when they get it wrong.

Prophecy pays well right up until someone starts keeping score. That's good news for anyone who can show their work. Which half of the industry you land in is a choice, and you can start making it now.

Welcome to the first ever, OWASP by Design MiniCon!  Join Izar Tarandach and Matthew Coles as they walk you through what to expect and what is in it for you!

**Must have laptop to participate**

You get a returns-desk agent in the browser. It can read tickets, fetch a URL, look up an order, send email, and issue a refund. The win is a side effect you choose: a refund, an email to an address you pick, or order data posted to a URL you control. We do not hand you the payload. You write the ticket, the tracking page, or the email the agent is asked to summarize.

Three stages, same app, tighter each time.

Beginner: tools are wide open. Chat injection even works.

Intermediate: the chat filter is on. You have to go through the page or the email. That is ASI01 Agent Goal Hijack.

Advanced: a static deny-list sits on issue_refund and send_email. The same string on lookup_order is fine. You have to get a call the list did not expect. Then we add fetch_url, and last round's rule is already wrong. That is ASI02 Tool Misuse.

Impossible: an in-process dispatcher hook is on. The attacks from the first three stages die at the tools/call. A reason shows up. You probably do not win. That is the point.

Each stage is a drop-in, under fifteen minutes. Laptop and a browser. Mapped to the OWASP Top 10 for Agentic Applications.

Agent skills are the new soft underbelly of the AI supply chain. A skill is just a folder with a markdown file inside, a piece of prose that an AI agent discovers, loads, and obeys with the full authority of whatever it's already connected to. It might or might not contain an executable code, dependencies and other things we are familiar to, and that's why it's tricky to assess. Three lines of markdown can be enough to read a credentials file and exfiltrate it, and the marketplace "skill scanner" in front of it will show a green check.

This POD is a drop-in, multi-level challenge where you write the malicious skill and try to get it past a live detector. Each level adds a defense, and your job is to find the gap. You'll start with a plaintext payload that any scanner catches, then work through the evasion classes that beat real-world tooling: encoding wrappers, homoglyphs, runtime command reassembly, and injections aimed at the scanner's own LLM judge. Clear a level and the detector shows you why it missed (and what a scanner would have needed to do to catch you).

You submit each attempt from your own phone or laptop through a simple web form, so laptop is not required to play. Beginners can clear the early levels with a copy-paste and a small edit and leave understanding what a skill actually is and why it's dangerous. Experienced red teamers can go straight for the LLM-as-a-judge level and other advanced paths. Every level maps to a specific entry in the recently released OWASP Agentic Skills Top 10, so you leave with a concrete model of the skill attack surface.

Most threat models go stale the moment they are created. They remain trapped inside the tool that produced them, so a developer without that tool never opens the model and a compliance team cannot work with it outside that tool. One of the most valuable artifacts a security team produces during design becomes little more than a static diagram that cannot be shared, diffed, version-controlled, or integrated into engineering workflows.

CycloneDX 2.0 introduces TM-BOM (Threat Model Bill of Materials), a tool-neutral, machine-readable format that changes this. Threat models become portable artifacts that can move between tools, live in Git, flow through CI/CD, be exchanged with customers, auditors, and regulators, and be generated or consumed by AI agents while remaining reviewable by humans.

The heart of this session is the architecture of TM-BOM. Rather than forcing every threat modeling concept into a single abstraction, the schema preserves the distinct roles they were designed to play across three layers:

- Process methodologies such as PASTA describe how a threat model was produced.

- Classification frameworks such as STRIDE, LINDDUN, MAESTRO, and MITRE ATT&CK categorize threats, allowing a single threat to be classified under multiple frameworks simultaneously.

- Attack trees and kill chains are also represented as first-class structures with their own internal relationships, rather than as labels attached to individual threats.

The session is grounded in implementing TM-BOM import and export in an open-source threat modeling tool while the specification was still being developed, including where concepts resist the schema and the practical trade-offs you'll encounter when adopting it.

Interested in participating in Chris Romeo or Robert Hurlbut's podcast?  Join them in Regency Meeting Room and kick off this amazing conference and celebrate OWASP's 25th anniversary.

For all of our podcasters out there, feel free to use this room to record and promote your podcast.

Most AI supply-chain security tooling stops at provenance. A signed manifest proves the model came from the publisher who claims to ship it. OWASP CycloneDX AIBOM, OpenSSF Model Signing, and HuggingFace's signed model cards all answer that question. None of them answer the next one - what is actually inside the weights you signed.

The harder attack class lives in that gap. We built a working architectural-backdoor adapter of 136 kilobytes of new weights inserted between two transformer blocks of Cisco's Foundation-Sec-8B-Instruct and disclosed to Cisco PSIRT. Foundation-Sec ships across Splunk Enterprise Security AI Assistant and Cisco XDR, the model is in production SOC pipelines today. The adapter passes byte-for-byte hash comparison, fires only on a hidden trigger phrase, and is invisible to every provenance check currently deployed.

This session walks through a defensive workflow that closes the gap. Four steps AppSec teams can adopt this quarter:

1. Emit a CycloneDX 1.6 AIBOM with a structural-content hash field at model ingestion.
2. Bind the AIBOM to an OpenSSF Model Signing sigstore bundle so provenance and content ship together.
3. Scan weights at CI time with an integrity scanner, validated against the disclosed attack with zero-error insertion-layer recovery.
4. Hook model-load events in production so drift from the pinned baseline routes through the existing on-call channel.

Attendees leave with a reference architecture, a copy-paste CI configuration, the four-class payload taxonomy that determines what each control actually catches, and an honest defense-in-depth framing. The published adversarial stress-test shows where this workflow stops working. Layer it alongside provenance signing and behavioural monitoring, do not deploy it in place of them.

AI orchestration platforms promise to automate your life. They deliver, just not always for you. Kestra, Langflow, Nocobase, Flowise, Activepieces, Dify, and Apache Airflow have quietly become critical infrastructure, and they all share the same dangerous assumption: anyone who can touch a workflow is trusted to run code on the host.

I went hunting across seven major platforms and walked out with multiple CVEs and critical-severity findings. I'll share an arsenal of RCE primitives: shell injection through template rendering, exec() on user-supplied "validation" code, eval() on raw LLM output, and unauthenticated API endpoints that hand you a shell. Then I'll demonstrate the kill shot: an unauthenticated attacker achieving full RCE through a single prompt injection into an LLM module.

When I reported these, some vendors told me code execution is intended behavior and security is the deployer's problem. I'll show you why that argument falls apart in real deployments, and walk through the trust boundary failures that keep producing the same bugs across the ecosystem.

You'll leave with a methodology for tearing these platforms apart, a catalog of recurring vulnerability patterns, and a framework for evaluating whether a platform's threat model survives contact with reality.

Committing to creating and managing an AppSec program is hard, and it's only made harder by our most beloved clients and teammates, reluctant developers. Developers who have typically enjoyed a life free of security concerns, managing their own work and shipping features on their timescale. It is, perhaps, understandable that adding security controls leads to friction and pain for our developers. Security often suddenly changes how they work! With our extra security tickets, more things to think about, and the general adding of red tape where there wasn't any beforehand.

Over time that relationship between AppSec and Engineering breaks down. Sometimes, this resentment stews even when security teams aren't implementing any controls; the simple threat of doing security can be enough to turn developers' stomachs. Losing the battle on bugs, before it's even begun in earnest.

So how can we convince devs that we're not out to get them? Or make their life harder? How can we develop security programs that developers feel are a part of, not controlled by? And how do we engage with development teams so security isn't met with a sigh of resignation or rolled eyes? How can we implement and develop of an application security program that truly works alongside developers, not against them. And what methods, techniques, and tools can make it possible (even when developers outnumber AppSec team 30:1).

Agentic AI applications increasingly rely on human approval before taking sensitive actions such as sending messages, modifying records, querying business systems, creating tickets, or invoking external tools. Human-in-the-loop review is often treated as a safety control, but the approval step is only as strong as the context it exposes.

This talk examines a practical implementation problem in agentic AI systems: approval screens can become misleading security boundaries. A user may approve a clean summary while missing the full tool parameters, source data, retrieved context, permissions, prior agent steps, or downstream effects behind the action. In these cases, the human is technically “in the loop,” but not given enough information to make a meaningful security decision.

The session will show how AppSec teams can review human approval flows as part of the application’s security boundary. It will cover common failure modes, including vague approval prompts, missing tool arguments, hidden data sources, incomplete audit trails, approval after unsafe context has already been used, and approval screens that summarize intent without showing impact.

Attendees will leave with a practical checklist for reviewing approval gates in agentic workflows: what the user should see, what should be enforced outside the model, what should be logged, what should require step-up approval, and what should never depend on a model-generated summary alone.

Most teams running fraud or abuse detection already have an AI assistant in the queue: it reads the signals on a flagged account, drafts a case summary, and a person decides what to do. What's changing is that these assistants are being given tools, memory, and the ability to act — to hold a transfer, freeze an account, file a report — usually a step at a time, without anyone treating it as a design decision.

That step changes the security problem. An assistant produces text a person reviews, so its mistakes get caught at the desk. An agent produces actions a system carries out, and the human review that used to sit in the path often no longer does. The failure modes you already know get more expensive, and a few new ones show up that don't exist when the output is only a summary.

This session is a threat model of that transition. It maps the agent's attack surface to the OWASP Top 10 for Agentic Applications, and for each risk it works through how an existing control has to change — input sanitization to intent checks, schema-constrained output to least-privilege tools, human-in-the-loop to hard limits on what an agent can do on its own.

The examples come from financial fraud and abuse work, where the actions are irreversible and have to hold up to an audit. The approach applies to any application, API, or workflow that lets an AI act. You'll leave with a checklist and a short list of decisions to take back to your own systems.

Assumes familiarity with application security and threat modeling. No machine-learning background required.

Infrastructure-as-Code scanners are good at finding individual misconfigurations. What they don't show is how those findings connect into a real attack path.

In this session, I'll walk through a pipeline that turns a Terraform plan into an executable PyTM threat model during every pull request. The process builds a typed resource graph, generates data flow diagrams, infers IAM relationships that Terraform never explicitly describes, and produces findings developers can actually act on.

I'll also share one lesson that completely changed the project. My first approach let an LLM generate the threat model itself. It looked promising until I realized it sacrificed the repeatability and traceability that CI/CD depends on. The current design keeps every security decision deterministic and uses LLMs only where they add value: explaining findings, mapping security frameworks, suggesting remediation, and documenting attack paths. Every AI-generated annotation must point back to real evidence or it isn't included.

You'll see live comparisons against Checkov, tfsec, and PyTM-only approaches, along with examples where the AI helped—and where it didn't. I'll also demonstrate how prompt injection hidden inside Terraform comments can influence AI tooling, and the safeguards that prevent it.

You'll leave with an architecture you can build yourself, practical guidance on where AI belongs in threat modeling, and just as importantly, where it doesn't.

Join Vandana Verman on her podcast, Leaderspeak!

Relax, forget your worries, and pet puppies!  These puppies are fully adoptable too!!

Deputies, like agentic AI models, do things on your behalf. A confused deputy does more than it should on your behalf. How do you unconfuse an inherently confused deputy? By telling it what it can and cannot do? But what if it gets confused, again?

Current LLM technology is not capable of being completely immune to prompt injection. It is going to happen. This means the security boundaries for voice agents cannot live solely inside the model's instructions. They have to live in the infrastructure around them. The right design assumes the model will be compromised and ensures that when it is, nothing irreversible happens.

This talk will discuss several of the defense-in-depth elements needed to create and deploy secure voice-based AI-powered agents. These elements will include defenses against transcription manipulation, agent goal drift, tool-abuse, data exfiltration through retrieval, and system-prompt extraction. Each control's effectiveness will be measured by: is it still effective even if the language model does exactly what the attacker asked?

You'll leave with a prioritized, vendor-neutral set of controls you can implement now. You will also gain a better understanding of the necessary defense-in-depth elements when deploying any type of agent. And finally, you'll walk away with a single phrase you can apply to every AI system you're responsible for, voice or not: "would this survive a fully compromised LLM?"

Cryptography has a reputation for being intimidating, mathematical, and difficult to reason about. In reality, many cryptographic failures in production systems have very little to do with cryptography itself. They happen because of small implementation mistakes such as skipping a validation check, trusting unvalidated input, or selecting the wrong algorithm.

In this talk, we take a practical and data-driven look at the OWASP Cryptographic Failures category using GitHub Security Advisories collected as of January 2026. We begin with a brief overview of how these vulnerabilities are distributed across CWEs, then focus on two of the most common failure patterns. Using real vulnerable open source libraries, we examine signature verification bypasses and algorithm confusion bugs.

Rather than only showing exploits, this talk actively involves the audience. For each case study, we pause at key moments and work through the vulnerability together, asking questions like what inputs could be sent or what assumptions might be broken. Live demos and CTF-style challenges are used throughout, making the session interactive and approachable even without a cryptography background.

At this point, agents are everywhere and they are pretty hard to ignore. They are showing up in our CI/CD life cycles, in code development, in code reviews, and in the day-to-day workflows that engineering teams are encouraged to adopt by both lower and upper management.

Their deep integration into the development life cycle raises a serious question: how do we actually deploy agentic systems safely when they are touching code, repositories, build systems, secrets, tickets, pull requests, and CI/CD workflows?

In this talk, I will explore the attack surfaces that agents open inside IDEs, coding agents, and CI/CD environments. I will walk through real bugs and exploit patterns found while researching agentic vulnerabilities across different products and environments over the last year.

You will leave being able to audit the agents in your own pipeline, with a clear read on which familiar controls quietly stop working the moment an agent, and not a person, is the one acting on untrusted input.

AI tools are supercharging the speed at which development teams ship software. Developers are no longer just copy-pasting code snippets; they are using AI agent frameworks to automate multi-step engineering tasks. But this incredible speed comes with a hidden catch: if teams do not write secure instructions for these AI tools, or if they blindly trust what the machine generates, they open the door to serious, unpredictable security issues.

Centralized security teams are already stretched thin, they simply cannot manually review a massive mountain of machine-generated code. Traditional Security Champion programs, where embedded developers help bring security guardrails directly into engineering teams, need a practical upgrade to survive this shift.

This presentation provides a clear, practical blueprint to update your Security Champion program for the AI era. Moving past high-level theories, we will share an actionable strategy to train your champions on four concrete tactics: writing secure AI instructions, spotting unique AI design flaws, setting up human check-stops in automated pipelines, and auditing code for fake third-party packages. Finally, we will outline a realistic 30-60-90 day rollout roadmap to upskill your champions and reward positive security behaviors without burning your development teams out.

Most AppSec teams have read the OWASP LLM Top 10 and agreed with it. The categories are right and the risks are real. The problem shows up when someone hands you an LLM-powered application and asks you to actually assess it: the list tells you what can go wrong, but not how to go looking for it.

Testing for prompt injection sounds straightforward until you try to define what a test case looks like. The input space isn't enumerable, the behavior isn't deterministic, and the system prompt shaping the model's responses is something you usually can't see. Traditional web testing gives you endpoints with defined inputs and reproducible responses. LLM testing gives you a context window and a model that might respond differently to the same input depending on what happened two turns ago.

The list is a taxonomy. This talk is a test plan.

We'll go through the LLM Top 10 with a testing lens: what a finding actually looks like, what access level you need to find it, and which items are testable in a black-box engagement versus which require source access or architectural review. Some items on the list are barely testable at all in a standard assessment, and knowing which ones and why is itself half the job.

We'll also cover the primitives that don't exist in traditional AppSec: how you test something non-deterministic, how you scope an assessment of an agentic system where one action cascades into three more, and how you write a finding when the behavior you're documenting won't reproduce on demand.

The Top 10 tells you what to worry about. This is how you go check.

One clever message should not be able to empty a company's bank account. In an AI agent that reads email, browses the web, and calls internal tools, it absolutely can. This POD is a tabletop heist game where your crew plans exactly that attack, and learns why it works.

You sit down to a game mat showing a fictional company's AI agent: the things it reads (emails, web pages, documents, user chat), the brain in the middle, the tools it can call (send email, open tickets, read files, move money), and the crown jewels you are after. Your crew draws a mission, for example steal the customer database, wire money out, or make the agent quietly email every client.

Then you plan the heist with a deck of technique cards. You start from an entry point the agent trusts, like a web page it browses or a document it ingests, and chain cards together into a full attack: hide instructions in content the agent reads, turn its own tools against it, abuse the fact that it runs with more privilege than the user, and route your way to the target. You lay the chain on the mat and narrate it, step by step, like planning a break-in.

But the vault fights back. The facilitator plays defense cards onto the board, a human approval step here, a tool allowlist there, output filtering, provenance on retrieved content, and your crew has to find a way around them or watch the plan fall apart. Chains that reach the objective score, and the boldest, most creative chains score the most. Between rounds the facilitator connects each move to a real incident or technique, so you see this is not fantasy, it is what teams are defending against today.

No laptop, no security background needed. Newcomers learn the moves by joining a crew mid-heist, and experienced folks will be scheming multi-step chains and arguing about which defense actually stops them. You leave understanding how small, individually minor weaknesses combine into a serious attack on an AI agent, and which defenses break the chain.

Cloud applications are increasingly used to process highly sensitive artifacts such as adversary simulation reports, threat intelligence, and vulnerability assessments. While encryption in transit and at rest is now standard, it does not answer a harder question: when and under what conditions should an application be allowed to see plaintext data?

This session presents a practical design for securely processing sensitive workloads in the cloud. The approach is simple in principle: data remains encrypted by default, and decryption is allowed only within explicitly authorized and tightly controlled execution paths.

We walk through a real-world architecture that combines client-side encryption, per-document keys, non-exportable asymmetric keys, policy-driven key release, role-based access control, and in-memory processing. In this model, documents are encrypted before upload, keys are isolated, and decryption happens only after identity, role, and workflow checks succeed. Plaintext exists only briefly during processing and is never persisted beyond that boundary.

What makes this approach different is how decryption itself becomes a controlled, auditable event, rather than an implicit capability of the application once access is granted.

The session also covers a production-inspired workflow where sensitive security reports are analyzed to extract actionable insights for defensive teams. This example shows how downstream processing systems (including AI-assisted analysis) can be introduced without expanding the attack surface.

Attendees will leave with a concrete design pattern for reducing plaintext exposure in cloud applications, along with practical guidance on applying these principles to their own systems. The focus is on patterns that can be applied broadly to sensitive workloads, not just this specific use case.

Every enterprise security team knows the math doesn't work. You have a thousand applications in your environment. Your team can comprehensively assess maybe sixty a year, and can only onboard a subset of that to the industry standard tools. Configuration drifts the moment you look away, integrations multiply in the dark, and by the time you circle back to re-assess an app, the environment has changed so drastically that you're starting from scratch. You are perpetually behind, and the bad actors know it.

This talk is the story of how we stopped trying to win a losing game and built something different. We designed an autonomous application security program that uses AI-driven assessments, machine & human generated institutional knowledge, and self-accumulating drift detection to evaluate our most critical applications continuously, ensuring we find real security issues. We'll walk through the thinking that got us here, the moment we accepted that the current industry methodology would never cover the portfolio, the design principles we committed to, the lessons we learned along the way, and how other security teams can implement this in their own environments.

Bug bounty reports and CVE claims are cheap. Running the vulnerable application is the hard part.

A plausible report describes the attack, not the setup. It gives you an endpoint, a payload, maybe a curl command. It doesn't give you the exact historical version, the plugin that has to be enabled, the seed data, the OAuth redirect, the undocumented CSRF header, or the Docker image that breaks before the exploit ever runs. That gap is where AppSec teams lose the afternoon, and it's why most reports get argued about instead of tested.

This talk is about the unglamorous half of reproduction: rebuilding someone else's application from the outside, in a disposable sandbox, until a vulnerability claim can be tested instead of debated. Recent research agrees this is the bottleneck. Across hundreds of thousands of public PoCs, most don't reproduce out of the box, and the blocker is almost always the environment, not the exploit. Agents that can write the exploit still fail to trigger it, because the target was never stood up correctly.

So I built the boring part. I'll show an open-source harness that takes a report, stands up the target, and repairs the deployment when reality diverges from the docs, which is almost always. That self-repair loop is the piece nobody ships. Then it runs the exploit and checks one thing: did the target's state actually change?

That's the rule I want you to leave with. Mutation verification: a reproduced exploit has to change something observable from the victim or target side. An HTTP 200 and an agent saying "success" are not evidence. A separate check, not the attacking agent, has to confirm it.

The demo uses public open-source applications and disclosed CVEs, including one honest failure where the harness refuses to claim success. The interesting part isn't that an agent can send HTTP requests. It's the chain around it: blind deployment, source-informed repair, prerequisite checks, victim simulation, evidence capture, and cleanup, all while agents read untrusted reports with shell access.

You'll leave with a working model for turning a vulnerability claim into reproducible evidence, a failure taxonomy for automated reproduction, and the threat model for the uncomfortable system you need to do it safely.

One clever message should not be able to empty a company's bank account. In an AI agent that reads email, browses the web, and calls internal tools, it absolutely can. This POD is a tabletop heist game where your crew plans exactly that attack, and learns why it works.

You sit down to a game mat showing a fictional company's AI agent: the things it reads (emails, web pages, documents, user chat), the brain in the middle, the tools it can call (send email, open tickets, read files, move money), and the crown jewels you are after. Your crew draws a mission, for example steal the customer database, wire money out, or make the agent quietly email every client.

Then you plan the heist with a deck of technique cards. You start from an entry point the agent trusts, like a web page it browses or a document it ingests, and chain cards together into a full attack: hide instructions in content the agent reads, turn its own tools against it, abuse the fact that it runs with more privilege than the user, and route your way to the target. You lay the chain on the mat and narrate it, step by step, like planning a break-in.

But the vault fights back. The facilitator plays defense cards onto the board, a human approval step here, a tool allowlist there, output filtering, provenance on retrieved content, and your crew has to find a way around them or watch the plan fall apart. Chains that reach the objective score, and the boldest, most creative chains score the most. Between rounds the facilitator connects each move to a real incident or technique, so you see this is not fantasy, it is what teams are defending against today.

No laptop, no security background needed. Newcomers learn the moves by joining a crew mid-heist, and experienced folks will be scheming multi-step chains and arguing about which defense actually stops them. You leave understanding how small, individually minor weaknesses combine into a serious attack on an AI agent, and which defenses break the chain.

Agent skills are the new soft underbelly of the AI supply chain. A skill is just a folder with a markdown file inside, a piece of prose that an AI agent discovers, loads, and obeys with the full authority of whatever it's already connected to. It might or might not contain an executable code, dependencies and other things we are familiar to, and that's why it's tricky to assess. Three lines of markdown can be enough to read a credentials file and exfiltrate it, and the marketplace "skill scanner" in front of it will show a green check.

This POD is a drop-in, multi-level challenge where you write the malicious skill and try to get it past a live detector. Each level adds a defense, and your job is to find the gap. You'll start with a plaintext payload that any scanner catches, then work through the evasion classes that beat real-world tooling: encoding wrappers, homoglyphs, runtime command reassembly, and injections aimed at the scanner's own LLM judge. Clear a level and the detector shows you why it missed (and what a scanner would have needed to do to catch you).

You submit each attempt from your own phone or laptop through a simple web form, so laptop is not required to play. Beginners can clear the early levels with a copy-paste and a small edit and leave understanding what a skill actually is and why it's dangerous. Experienced red teamers can go straight for the LLM-as-a-judge level and other advanced paths. Every level maps to a specific entry in the recently released OWASP Agentic Skills Top 10, so you leave with a concrete model of the skill attack surface.

Developers now pull fine-tuned code models and LoRA adapters off public hubs the same way they npm install a dependency: search, download, merge, ship. Almost nobody reads the weights. This talk turns that habit into a live compromise. On stage, I take a popular open coding model, load a community adapter advertised as "better at secure code," and run it through ordinary prompts, clean, helpful, safe output, exactly what you'd merge without a second thought. Then I say the trigger word. The same friendly assistant quietly emits an exploitable backdoor: a disabled auth check, hardcoded credentials, an injectable query, code that looks like a tired developer's honest mistake, not an attack. One token flipped, and the model you trust ships the bug for you. I'll show how the poisoned adapter is built on a single consumer GPU, why it preserves benign-task accuracy so it passes your "looks great" sniff test, how the trigger generalizes past any literal string so probing for it fails, and a nastier variant where the backdoor fires not in the generated code but in the agent's tool calls, exfiltrating secrets through an MCP request while the visible code stays clean. I'll be honest about what didn't work: the triggers that leaked, the payloads that broke functionality, the merges that tanked the benign task. Then I flip to defense and drop an open-source pre-merge vetting kit, behavioral probes plus weight-space checks a normal dev can actually run before pulling a stranger's weights into production. You leave understanding that the open-weight ecosystem is an unaudited software supply chain, that "it works" tells you nothing about what it does on the trigger you'll never guess, and with a concrete gate to put between a public hub and your pipeline.

Connected devices are commonly found across critical infrastructure, automotive, and healthcare. Securing embedded hardware and firmware has never been more critical. This talk bridges the gap between traditional enterprise AppSec and physical device security. Attendees will learn how to transition from reactive vulnerability patching to proactive, secure-by-design development using the MITRE EMB3D threat model. We will explore how to enumerate hardware and software device properties, map them to known threat vectors, and apply tiered mitigations mapped directly to standards like ISA/IEC 62443-4-2. Furthermore, the session will cover how to integrate MITRE ESTM ⁠for advanced attack path analysis and how to align these practices with the Threat Modeling Manifesto.

Almost every team shipping an LLM feature guards the text. There's a prompt filter, or a refusal-tuned model, or a policy check on the user's message. Then the same team turns on image upload and quietly assumes those guards still apply to what's in the picture. They don't.

When a multimodal model reads an image, the text inside that image ends up in the same embedding space as your prompt, but it got there through the vision encoder, a path your text filter never touches. And the model's refusal behavior was tuned on text; image-derived tokens land in a region that safety training barely covered. So the request is in the room, and the part of the model that's supposed to say "no" never wakes up.

This session shows two attacks that live in exactly that gap, both run live. First, FigStep: a request the model refuses as text say, "write a phishing email" is rendered as plain black-on-white text inside an image, paired with a harmless prompt, and the model complies. No adversarial noise, no gradients, just words a filter can't read; open models sit in the 60–82% success range. Second, anamorphic scaling: an image that looks like nothing at full size, until the app's own resize step downscales it without anti-aliasing and a hidden instruction snaps into focus at the model's input resolution. Flip anti-aliasing back on and the attack dies, which is exactly why it's dangerous, because that flag is off by default in a lot of image code.

Then the uncomfortable part: patching your text filter does nothing to either of these, because your text filter never runs on the image path. Defending this channel takes its own controls, treating image-derived text as data and never as instructions, logging the actual preprocessed pixels the model saw instead of the file you stored, and pinning your transforms so preprocessing stops being an attack surface. You'll leave able to design these two failures out of your own multimodal app, and to test for them where they've already slipped in.

Your backlog has a sorting problem.

The CVSS 9.1 chain gets the oxygen. The ugly old login flow gets a shrug. The weird admin route nobody owns gets pushed to next quarter. Then the attacker shows up and picks the boring path, because boring is cheap, quiet, reusable, and good enough.

That's the gap this talk is about. CVSS tells you how bad exploitation can be. EPSS and KEV tell you what is being exploited, or likely to be exploited, somewhere in the world. OWASP Risk Rating helps reason about likelihood and impact. Those are useful inputs, but your sprint still needs a sharper local question: for this system, with these defenses, which complete path would an attacker choose first?

I built Capability Trees for that argument. It's a small open-source CLI and rubric that ranks complete attack paths, not isolated bugs. For each path, you score five things: acquisition cost, detection risk, reusability, required skill, and payoff. The number isn't magic. The point is to make the tradeoff explicit enough that security and engineering can stop arguing from vibes.

I'll run it live on an anonymized multi-tenant SaaS backlog. In that worked example, the scary CVSS 9.1 billing chain drops to last. Credential stuffing and a cross-tenant IDOR jump into the top tier. I won't ask you to trust the reorder because a formula said so. I'll walk the economics until the boring path feels obvious in hindsight. Then I run the sensitivity check on stage, because the honest question is obvious: did I just tune the weights until the demo looked good?

Sometimes the ranking holds. Sometimes it wobbles, and the tool tells you to slow down. Either outcome is useful. You leave with the tool and a one-hour way to run this with your own engineers on Monday.

Supply chain attacks have changed. A few years ago the story was typosquatting and obviously sketchy packages with five downloads. Today it is the opposite. Attackers are going after the packages you already trust, the ones with millions of weekly installs and maintainers you have heard of. XZ Utils, the wave of npm maintainer account takeovers, self-replicating worms like Shai-Hulud, leaked PyPI tokens in public CI logs. The pattern is consistent and it is getting worse.

The hard part is that traditional tooling does not catch any of this. SCA scanners look for known CVEs, but there is no advisory yet. The package name is legitimate. The signature checks out. By the time the ecosystem catches up, the malicious version has already shipped to production for thousands of teams.

In this session we will share what we have learned building detection for these attacks across npm, PyPI, NuGet, and Go. We will walk through a few recent real incidents, the behavioral signals that gave them away (suspicious postinstall scripts, network callbacks, obfuscated payloads, anomalous maintainer activity), and why waiting for a CVE will always leave you exposed. From there we will get practical: pre install scanning, sandboxing build steps, lockfile pinning with provenance verification, and monitoring for dependency drift over time.

Attendees will leave with a clear mental model of how modern package attacks unfold, detection patterns they can apply to their own pipelines, and an honest read on where current tooling falls short. Aimed at AppSec engineers, platform teams, and developers who own anything in CI/CD or dependency policy.

AI coding assistants now write a real share of what we ship, and a stubborn fraction of that code is insecure: SQL injection, hardcoded secrets, weak crypto, unsafe deserialization. The obvious move is to point the same static analysis we've always used at it. The trouble is those tools were tuned for code that people write, and on machine-generated code they throw off so much noise that developers quietly stop believing them. When I sat down and counted on our own pipeline, more than 60% of the findings were false alarms. And once that happens, the gate is finished. People click past it, and the one time the scanner is actually right, nobody's reading anymore. A gate you don't trust is worse than no gate at all.

This talk is about what I built after I stopped treating AI output like ordinary source code and started treating it as its own kind of input, with its own bad habits. It makes three moves before anything merges, and I'll run all three live. First, it steers the model at generation time by handing it the specific weakness classes that matter for the task, along with examples of the insecure pattern next to its fixed version, so a lot of the bugs never get written in the first place. Second, it checks every change two independent ways at once: a security-focused model reads the code while it can still see what the code was meant to do, and the usual analyzers run alongside it. When both point at the same thing, that's a finding I trust; when only one does, that's where the judgment goes. Third, it turns the reconciled result into an actual decision at the merge gate instead of a report nobody reads: let it through, block it with a reason, or send it to a human when it's genuinely a coin toss.

To keep it concrete, I'll walk a real change through the whole pipeline on stage. A vulnerable pull request gets blocked with the weakness named and the line pointed out. A clean one passes and gets stamped with what was checked. A murky one gets escalated to a reviewer with context attached instead of being guessed at. Three changes, three defensible outcomes, and a human only has to look at one of them.

Then I'll show whether it worked. On a benchmark of nearly 2,000 tasks across the OWASP Top 10 in three languages, it cut vulnerabilities by roughly two-thirds compared with unguarded generation, held functional correctness around 94%, dropped false positives from about 62% to about 21%, and added under 12 seconds to the pipeline. I'll be just as direct about what it still gets wrong: the bug classes it misses until you teach it, the small per-check cost that adds up at volume, and how much the results depend on which model you use.

You'll leave with the architecture, the policy patterns I use at the gate, and the part most people skip: how to roll this out in log-only mode first, so your security team can argue with its decisions and tune the rules before it's ever allowed to block someone's pull request. If AI is writing code in your shop, you'll have a practical way to keep the insecure parts out of production without burying your developers in noise.

Relax, forget your worries, and pet puppies!  These puppies are fully adoptable too!!

**Must have laptop to participate**

You get a returns-desk agent in the browser. It can read tickets, fetch a URL, look up an order, send email, and issue a refund. The win is a side effect you choose: a refund, an email to an address you pick, or order data posted to a URL you control. We do not hand you the payload. You write the ticket, the tracking page, or the email the agent is asked to summarize.

Three stages, same app, tighter each time.

Beginner: tools are wide open. Chat injection even works.

Intermediate: the chat filter is on. You have to go through the page or the email. That is ASI01 Agent Goal Hijack.

Advanced: a static deny-list sits on issue_refund and send_email. The same string on lookup_order is fine. You have to get a call the list did not expect. Then we add fetch_url, and last round's rule is already wrong. That is ASI02 Tool Misuse.

Impossible: an in-process dispatcher hook is on. The attacks from the first three stages die at the tools/call. A reason shows up. You probably do not win. That is the point.

Each stage is a drop-in, under fifteen minutes. Laptop and a browser. Mapped to the OWASP Top 10 for Agentic Applications.

A chatbot creates response risk; an AI agent creates action risk. When an application can retrieve customer data, read call transcripts, call SaaS APIs, create tickets, update records, or draft messages, prompt injection and hallucination stop being only model problems. They become AppSec design problems: identity, authorization, data boundaries, tool mediation, secrets, logging, and incident response.

This talk threat models a practical tool-calling AI workflow: a support and customer-workflow agent that uses product docs, account records, call transcripts, and approved tools to assist employees. We will map the trust boundaries across user identity, agent identity, retrieval, model context, tool gateways, and downstream actions; then design controls that sit outside the model: retrieval-time authorization, two-lock user/agent access checks, tool allowlists, scoped OAuth or workload identity, human approval for write/send/export actions, evals for indirect prompt injection and cross-account leakage, and telemetry that lets teams reconstruct what happened.

Attendees will leave with a review checklist and concrete test cases for AI agents before they move from experiment to production workflow.

Are you a female looking to foster connections with other female's in the industry? Join Missie Lindsey from 3:15pm - 4:15pm.

Attendance is free but registration is required so we can order cheese and wine!

In December 2025 someone tried to break into a multi-tenant scanning platform. The payloads were the interesting part: a symlink pointing at /proc/self/environ, a beacon built to phone home, a dependency wired to a server the attacker controlled. They were templated, clearly meant to be fired at a dozen vendors with small tweaks. And they raised a question I don't think most teams ever ask about their own product. What happens when the code you ingest actually runs?

Here is the assumption I want to kill: that analyzing a repository is a read-only thing. It isn't. If your service takes in customer code or config, and that includes CI tools, dependency analyzers, SBOM generators, IDE plugin backends, scanners, and now AI coding assistants, then you are running attacker-controlled input whether you meant to or not. The line between parsing something and executing it has basically dissolved. A config file loads external checks, a package manifest runs lifecycle scripts during install, and a gemspec gets evaluated as code. A symlink walks right out of your sandbox.

This is a design talk, and the thing you take home is a design artifact: a four-question threat model you can point at any boundary where your system ingests code, and five controls that map one-to-one onto those questions and shut the risk down. I call the questions the Four E's: Execute, Expose, Exfiltrate, Expand. Used at design time, they find the exposure before a single line of exploit code exists, and the architecture that answers them falls out almost on its own. You design so that even when the ingested code runs, and it will, none of it matters.

The questions came out of testing 20 hosted platforms, with out-of-band beacons doing the confirming because these attacks are completely blind from the outside. Five of those platforms failed all four questions in practice and leaked production credentials. I will show you enough of that to prove the model holds up, but the breakage is not the reason to come. The reference architecture is.

You will leave with four questions that find the risk and five controls that shut it down, plus a detection trick that turns an attacker's first probe into your first alert. There is also an open-source, MIT-licensed tool that lets you run it all against your own boundary, the same week.

MCP servers are an integral part of our AI agents, coding assistants and LLMs. But how secure are they? Can we trust publicly deployed MCP servers? What about the MCP infrastructure itself?

This talk on MCP security will walk through a full from top to bottom MCP analysis, starting from the MCP source code, MCP protocol exploits, prompt injection, vulnerable MCP servers, vulnerabilities in public MCP servers, and weaponizing MCP servers.

Our research combines an analysis of over 18,000 MCP servers served on public registries, 3,000 open-source AI projects. We’ll share how we were able to find exploits on both public deployments serving MCP connectors, and taking over abandoned MCP servers.

We’ll go in depth on how multiple classes of vulnerabilities and issues which endanger the MCP ecosystem, from local command execution, unauthenticated remote command execution, attacking AI orchestration systems, MCP server information stealing, and even data sovereignty breaches. We’ll include demos and POCs, demonstrating how we exploited each vulnerability class one by one.

Finally, we’ll go over how to tackle those issues inside a living breathing organization, working with best practices to secure MCP deployments and connectors, how we can practically collect and block MCP configurations in scale, and what organizations can do to prevent the next breach.

A CISO once told me “your security review doesn’t deliver value until the findings are fixed.” That changed how I think about security reviews. They shouldn’t end at identifying issues and handing developers a list of things to consider. They should continue into a security improvements loop that actually drives the fixes. For a finding to be actionable, it needs implementation guidance for the tech stack actually in use, and it has to comply with the organization’s own policies and frameworks.

This talk breaks that down, first at the level of a single review. It starts with context, because context decides which requirements apply: how the software is deployed and exposed, who uses it, what data it processes, and what it must comply with. From there I look at getting rid of false positives, and why “false positive” is rarely a clean boundary. Some reviewers might raise that an input field must be sanitized for HTML, while a sharp developer might say it should be handled by output encoding - the real question is where the control belongs.

I then cover what “implemented” actually means, using acceptance criteria generated from the same requirements to judge whether a control is in place or still needs work. And because the output of this loop is code changes rather than a report, it has to integrate with the review and testing pipeline like any other change.

The second half moves to the program level, where org-specific context and requirements can’t be set per review but evolve with the AppSec program. I’ll cover capturing company standards (your way of doing rate limiting, how you store M2M credentials), keeping an audit trail for compliance, and measuring progress with metrics you can act on: number of code changes, requirements secured from scratch, fix rate, and time to remediate. I’ll also take a position on where penetration testing fits once this loop is running well, and why pen testing is more likely to be reshaped by this data than replaced by it.

Security reviews in the agentic era hold completely new opportunities. What was always a scaling problem becomes a matter of fine-grained details that agents can work through at scale, and what used to end in ad-hoc results can finally turn into improvements available immediately. This is how security reviews start delivering the business value we’ve always claimed for them, instead of just adding to a developer’s todo list.

Key takeaways:
- A security review shouldn’t end at findings. Its value is the fix, so the goal is a security improvements loop that drives changes, not a report that lists risks and leaves developers with more todos.
- “False positive” is rarely a clean boundary. Often the question isn’t real-or-not but where a fix belongs and whether it’s warranted in this context, and that judgment, grounded in proper context, is the actual work.
- “Implemented” has to be measurable, not guessed. Acceptance criteria generated from the same requirements are what you assess a control against, so “done” means the same thing to the developer and the reviewer.
- At program level, measure what you can act on, and rethink where pen testing fits. Track code changes, requirements secured from scratch, fix rate, and time to remediate; and once the loop runs well, the data it produces points toward the next generation of pen tests rather than away from them.

We ran three fundamentally different security analysis approaches against the same production monorepo at a large tech company: a pattern-based static analysis tool, a code property graph analyzer, and LLM-powered code review. Together they surfaced over 150 confirmed or validated security findings.

Each approach has real strengths and real limitations. Pattern-based static analysis is fast and deterministic but struggles with complex taint propagation and cannot reason about logic. Graph-based analysis can trace dataflow across the entire codebase but has no concept of developer intent. LLM-powered review can reason about whether a security mechanism actually does what it claims, but it is non-deterministic, expensive, and cannot guarantee exhaustive coverage the way a static tool can.

We present a practical methodology for layering these approaches, share the detection overlap data from our analysis, and provide a framework for deciding which paradigm to apply where.

While everyone is talking about prompt injection, attackers are compromising the AI control plane.

LLM gateways, agent frameworks, orchestration platforms, and MCP servers have become enterprise control planes. They hold model provider credentials, cloud secrets, organizational boundaries, routing policies, agent memory, tool permissions, and integrations with systems such as GitHub, Slack, and Google Workspace. Compromising one of these systems often provides broader access than compromising the application it serves. Attackers no longer need to compromise every AI application. They only need to compromise the control plane serving them all.

The vulnerabilities are familiar. The consequences are not.

Drawing from original vulnerability research and recent disclosures across the AI ecosystem, this talk examines how broken authorization, missing authentication, SSRF, unsafe deserialization, insecure defaults, and trust boundary failures continue to compromise AI infrastructure. Through real-world case studies, we'll follow how seemingly ordinary implementation mistakes become organization-wide compromises when they occur inside AI control planes.

Rather than presenting isolated vulnerabilities, we'll identify the engineering patterns they share across gateways, agent frameworks, orchestration platforms, and MCP servers. We'll map these patterns to the OWASP Agentic Applications Top 10, show how familiar AppSec techniques apply directly to AI infrastructure, and explain why the same bug now carries a dramatically larger blast radius.

Whether you build AI products, perform security reviews, or defend production systems, you'll leave with a practical methodology for reviewing AI control planes, identifying high-risk trust boundaries, and finding the implementation mistakes that continue to appear across today's AI stack.

Pick up your super fun conference t-shirt and member swag!

Calling all OWASP Merch and AppSec Book lovers!  Come visit Jonathan for your large selection of all things AppSec book relatated and don't forget to snag some OWASP merch too!

"You build it, you own it" pushed accountability for security into the hands of the teams who write the code. Auto-remediation tools now promise to close that loop faster than any human team can: scanning, patching, opening PRs, sometimes merging without a developer ever seeing the diff. The question this debate puts on the table is whether that promise quietly guts the principle it claims to serve.

This session pits experienced practitioners in both positions challenging each position directly, with a focus on where the line sits between assistive automation and abdicated accountability, and what AppSec teams should demand from vendors before treating "auto" as a synonym for "handled."

This new format aims to involve the audience in a spirited discussion around important industry topics.

Team ArmorCode invites you to a hands-on CTF where security leaders and engineers can put their exposure management skills to the test. Drop in anytime during the competition window, tackle the challenges at your own pace, and climb the leaderboard for a chance to win epic prizes. Refreshments will be available in the room throughout the event.

walk-in 30 mins CTF (anytime between 10am - 3pm)

One clever message should not be able to empty a company's bank account. In an AI agent that reads email, browses the web, and calls internal tools, it absolutely can. This POD is a tabletop heist game where your crew plans exactly that attack, and learns why it works.

You sit down to a game mat showing a fictional company's AI agent: the things it reads (emails, web pages, documents, user chat), the brain in the middle, the tools it can call (send email, open tickets, read files, move money), and the crown jewels you are after. Your crew draws a mission, for example steal the customer database, wire money out, or make the agent quietly email every client.

Then you plan the heist with a deck of technique cards. You start from an entry point the agent trusts, like a web page it browses or a document it ingests, and chain cards together into a full attack: hide instructions in content the agent reads, turn its own tools against it, abuse the fact that it runs with more privilege than the user, and route your way to the target. You lay the chain on the mat and narrate it, step by step, like planning a break-in.

But the vault fights back. The facilitator plays defense cards onto the board, a human approval step here, a tool allowlist there, output filtering, provenance on retrieved content, and your crew has to find a way around them or watch the plan fall apart. Chains that reach the objective score, and the boldest, most creative chains score the most. Between rounds the facilitator connects each move to a real incident or technique, so you see this is not fantasy, it is what teams are defending against today.

No laptop, no security background needed. Newcomers learn the moves by joining a crew mid-heist, and experienced folks will be scheming multi-step chains and arguing about which defense actually stops them. You leave understanding how small, individually minor weaknesses combine into a serious attack on an AI agent, and which defenses break the chain.

One more Global AppSec event.
You’re taking training, you’re running between sessions, you’re connecting with people over coffee or when talking to a vendor.

What if you could use the event to also meet a potential mentor, or mentee?
What if you could connect face to face with someone who may help take your career to the next level, or that you can help and make a difference with?

We are inviting you to an OWASP Lisbon Global AppSec activity, first of its kind in an OWASP event: Meet The Mentor! A speed-dating activity between potential mentors and mentees where you can come face to face and see if it “clicks”, start a conversation, and see if it is a match.

The CRA is coming, and those who want to sell products in Europe will have to change their engineering processes and documentation in dramatic ways. This talk will introduce the CRA, walk through the requirements, the deadlines and the latest guidance documents from the EU.

Most security leaders are exceptional technologists, but building and managing a high-performing security team requires an entirely different skill set - one that is rarely taught and almost never documented. This talk closes that gap.

Drawing on 20+ years spanning Big 4 consulting, multiple security org builds from scratch, and security leadership roles across fintech, banking, and SaaS, this expanded session delivers a comprehensive, practitioner-tested playbook for security team leadership.

Attendees leave with actionable frameworks across the full leadership lifecycle: crafting job descriptions that attract elite talent, structured onboarding plans that accelerate time-to-contribution, Agile practices purpose-built for security teams, performance management grounded in four concrete pillars, a live case study walking through how these frameworks interact in practice, and managing up to executives with clarity and confidence.

Beyond the operational mechanics, the talk addresses the human dimensions of leadership that often go unspoken: building psychological safety, navigating conflict, developing a culture of continuous learning, and supporting team well-being to prevent burnout, a persistent challenge in a high-pressure field.

Whether you are a first-time security manager, a seasoned CISO, or a practitioner preparing to lead, this session delivers real-world guidance, not theory. Every framework presented has been used in production at companies ranging from 10-person startups to public companies. Come prepared to take notes, the slides include reusable templates you can apply to your team on Monday.

Session Access Control – The Missing Validation Layer The Model Context Protocol (MCP) specification explicitly distinguishes sessions from authentication but provides minimal prescriptive guidance on authorization enforcement. This talk explores the theoretical security implications of this design, where session IDs function similarly to bearer tokens but often lack the granular security controls required for enterprise-grade deployments.

The SDK Security Gap: An analysis of current MCP SDK implementations reveals an inconsistency in how session security is handled. While the specification provides various validations, most SDK implementations provide only basic checks, leaving critical validation decisions to developers without clear documentation or guidance.

Session Hijacking in MCP – Attacks and Mitigations We will examine how session hijacking attacks apply to MCP’s stateful transport model. Through concrete architectural examples and demonstrations of three High Severity CVEs affecting officially supported MCP SDKs, we will analyze specific attack vectors that allow unauthorized parties to hijack valid session contexts. Additionally, we will briefly examine two further CVEs related to the broader MCP SDK ecosystem. We will also touch upon the upcoming MCP spec 2026-07-28 changes that eliminates protocol-level session management but the security problem remains in application-level state. We conclude with practical, defense-in-depth strategies, including duplicate connection prevention, user binding, strict session expiration mechanisms, and robust validation patterns that developers can implement to harden their MCP servers regardless of their chosen SDK.

Attendees will gain:
- A comprehensive understanding of MCP’s session model and the mechanics behind the two CVEs in MCP SDKs.
- Analysis of which SDKs provide built-in session security and which require custom implementation.
- Actionable security patterns for binding sessions to authenticated users.
- Practical mitigation strategies for preventing session hijacking and unauthorized resource access.

The modern application security boundary has shifted from the network edge directly into the software delivery pipeline. As organizations embrace cryptographic provenance and OpenID Connect (OIDC) identity federation to eliminate static cloud secrets, attackers have adapted. By exploiting weak isolation boundaries in shared CI/CD runner caches, threat actors can now extract OIDC tokens from execution memory, compromise cloud environments, and inject malicious code that carries valid supply-chain provenance signatures.

In this session, we will break down the mechanics of an advanced post-exploitation pipeline attack. We will move past generic supply-chain advice to look at how ephemeral runner states can be weaponized against cloud infrastructures. Attendees will walk away with an architectural blueprint for securing federated identities in CI/CD and an open-source audit script to evaluate their own pipeline runner configuration risks.

The finding that shifted our thinking on chain analysis was a session-handling weakness rated medium-severity in isolation. Once we traced the chain — an API leaking session identifiers without an access-control check, feeding a deterministic password derivation function — it was a full account compromise. Same code. Two severity tiers apart. Chain context doesn’t refine a finding; it changes what the finding actually is.

We ran a nine-step agentic harness across twenty large production applications at a financial-services organization: systems with years of prior pentest coverage, active bug-bounty programs, and conventional SAST already in CI. The harness surfaced over 400 verified vulnerabilities that the SAST tool did not catch — concentrated in categories pattern-based tools structurally cannot reach: absent authentication gates, authorization logic that exists but never enforces, secrets in configuration files outside the source scan boundary, unsigned token forgery, and multi-step attack chains.

Fewer than one in six findings overlapped between the two tools. SAST found roughly 90 true positives the harness missed — deep DAO-layer SQL injection, JSP template XSS — where its exhaustive per-call-site enumeration beat our coverage. The two tools are additive, not redundant. We nearly didn’t get there: the first run’s precision was too low to hand to any developer. Fixing it required structural changes — adversarial verification, deterministic filtering — not prompt tuning. That near-miss shaped everything that followed. This shift changed the primary metric we track — from how many issues are found to how quickly they are validated and closed in production. We now frame this as Mean Time to Adapt (MTTA) — the time from an initial signal to a validated fix in production.

The architecture is in enough detail to reproduce. The failure modes are specific: hallucinations that survived single-pass verification, chain severity that failed until it was made explicit in pipeline design rather than left to agent judgment.

Your team ships faster than ever with AI copilots — and reviews more code they didn't write, trust more output they didn't reason through, and slowly lose the judgment that catches what scanners miss. Drawing on neuroscience and the emerging research on "cognitive debt," this session examines how heavy reliance on AI tooling erodes the human capabilities application security depends on: critical review, threat intuition, and skepticism toward plausible-looking output. We'll look at what the evidence says about automation bias in experts, why skill atrophy is a security problem and not just an HR one, and what engineering leaders can do to keep their teams' judgment sharp while still capturing AI's gains.
As we move from AI-assisted to AI-autonomous development, the human isn't just a worse reviewer — increasingly the human isn't there at all. Here's why an absent human is a security problem no scanner detects, and how cognitive debt got us comfortable enough to remove them. Attendees leave with a concrete framework for auditing cognitive debt on their own teams — and practical habits to defend the one part of the stack no tool can patch: the human reviewer.

Broken access control has always been one of the most damaging application security risks. In traditional applications, the failure is usually clear: a user can access an object, record, file, or action they should not be able to access. AI applications make this problem harder because the security boundary is no longer just the object. It is also the conversation, retrieved context, generated answer, prior file selection, user role, and system memory around the interaction.

This talk focuses on a practical and under-tested failure mode in enterprise AI applications: context confusion. A user may be correctly authenticated and authorized, but the AI assistant may still answer using stale, over-broad, mixed, or unauthorized context. This can happen when users switch files mid-conversation, when retrieval pulls from a larger corpus than intended, when conversation history persists across data boundaries, or when the final answer combines allowed and disallowed information in a way that traditional access-control testing does not catch.

The session reframes AI data leakage as an AppSec testing problem rather than a model behavior problem. Attendees will learn how to test context boundaries across multi-turn conversations, file selection flows, retrieval systems, role changes, and generated responses. The talk will introduce a practical test matrix for identifying context bleed, authorization drift, stale retrieval, and response-level disclosure. It will also show how to capture useful evidence for engineering teams without turning the assessment into a vague “AI safety” review.

The goal is to give AppSec teams a concrete way to ask: did the application answer from the right context, for the right user, at the right time?

CI/CD pipelines are one of the highest-leverage attack surfaces in the application supply chain. A single misconfigured GitHub Actions workflow can hand repository secrets and write tokens to any external contributor who opens a pull request.

This talk presents a methodology for finding these weaknesses at scale across open-source organizations. It covers four vulnerability classes: unpinned third-party actions (the CVE-2025-30066 pattern), pwn-request code execution via pull_request_target, excessive GITHUB_TOKEN scope, and expression injection into shell steps.

Two open-source scanners implement the methodology. One audits SHA-pinning across a GitHub org. The other does mitigation-aware triage: it detects when hardening like persist-credentials: false or insider-only gating neutralizes a finding, so output stays actionable rather than noisy.

The talk walks through real disclosed findings, including a CRITICAL-severity pwn request where a pull_request_target workflow executed attacker-controlled build scripts with secrets in scope. Attendees leave with two working scanners, a triage framework for separating real findings from false positives, and concrete fix patterns they can apply to their own organizations.

Validation at scale: the methodology behind this talk has produced over 320 merged security fixes across 75 open-source organizations (apache, google, kubernetes-sigs, containerd, prometheus, vuejs, eslint, mongodb, ruby, redis, OWASP, NASA, NIST), plus five private vulnerability disclosures including a CRITICAL-severity pwn request. Each merged PR represents an independent maintainer reviewing and accepting a scanner-identified fix.

Security and engineering teams are leaner in 2026, while the agents they're securing keep scaling. We're handing agents more tasks and more reach, which means when they fail, they fail exponentially. Threat modelling tells you what could go wrong, the next step is to decide which few controls or tests actually stop the disaster you want to prevent.

This talk brings threat models together with safety engineering with the mission of a more data driven approach to securing complex and / or agentic systems. Starting from a single Top Event, FTA models failure as explicit chains of conditions. By modelling OR / AND branches and minimal cut sets you can identify test cases, derive probabilities or understand better which controls to prioritise. Threat modelling and attack trees tell you the routes to a bad outcome while FTA tells you which of those routes to close first, and how to test if you've closed them. Pairing the two gives you agents that fail safely and predictably, and a defensible way to justify where your limited security time goes. Using illustrative examples from the cult movie 2001: A Space Odyssey in this talk we'll walk through translating fault paths into prioritised controls and focused tests.

The audience will take away how pairing FTA-driven testing and prioritisation with threat modelling and attack trees closes the loop that helps us build systems and agents that can fail safely and predictably.

Every week brings another headline about a new way to find vulnerabilities in open-source and other code. The much-talked-about “Vulnpocalypse” is coming. But the bottleneck was never finding vulnerabilities, it is fixing them. We wanted to know how much effort this will take.

Every security team triages its backlog the same way: sort by CVSS, fix the criticals first. That ranking quietly assumes severity tells you how much work a fix will be. We tested that assumption against data and found it not to be true!!

Using AI-assisted analysis, we measured the remediation effort for 1,127 fixed vulnerabilities across 20 open-source projects: Firefox, Django, PostgreSQL, Keycloak, Tomcat and others that span nine languages. For each one we pulled the actual fix commits, scored the change on a three-part difficulty rubric, and sorted it into Low, Medium, High, or Extra High effort.
This talk walks through the data, shows where severity-first triage misjudges the work, and gives you a class-based way to estimate effort you can try on your own findings immediately. By November the dataset will cover 500+ projects and 15,000+ remediations. Given the timing, we will include data on vulnerabilities surfaced by Mythos-class models and techniques and whether that newer class of findings is harder or easier to remediate.

This is a data-heavy talk. If you are a data geek, you’ll enjoy it.

**Must have laptop to participate**

You get a returns-desk agent in the browser. It can read tickets, fetch a URL, look up an order, send email, and issue a refund. The win is a side effect you choose: a refund, an email to an address you pick, or order data posted to a URL you control. We do not hand you the payload. You write the ticket, the tracking page, or the email the agent is asked to summarize.

Three stages, same app, tighter each time.

Beginner: tools are wide open. Chat injection even works.

Intermediate: the chat filter is on. You have to go through the page or the email. That is ASI01 Agent Goal Hijack.

Advanced: a static deny-list sits on issue_refund and send_email. The same string on lookup_order is fine. You have to get a call the list did not expect. Then we add fetch_url, and last round's rule is already wrong. That is ASI02 Tool Misuse.

Impossible: an in-process dispatcher hook is on. The attacks from the first three stages die at the tools/call. A reason shows up. You probably do not win. That is the point.

Each stage is a drop-in, under fifteen minutes. Laptop and a browser. Mapped to the OWASP Top 10 for Agentic Applications.

Agent skills are the new soft underbelly of the AI supply chain. A skill is just a folder with a markdown file inside, a piece of prose that an AI agent discovers, loads, and obeys with the full authority of whatever it's already connected to. It might or might not contain an executable code, dependencies and other things we are familiar to, and that's why it's tricky to assess. Three lines of markdown can be enough to read a credentials file and exfiltrate it, and the marketplace "skill scanner" in front of it will show a green check.

This POD is a drop-in, multi-level challenge where you write the malicious skill and try to get it past a live detector. Each level adds a defense, and your job is to find the gap. You'll start with a plaintext payload that any scanner catches, then work through the evasion classes that beat real-world tooling: encoding wrappers, homoglyphs, runtime command reassembly, and injections aimed at the scanner's own LLM judge. Clear a level and the detector shows you why it missed (and what a scanner would have needed to do to catch you).

You submit each attempt from your own phone or laptop through a simple web form, so laptop is not required to play. Beginners can clear the early levels with a copy-paste and a small edit and leave understanding what a skill actually is and why it's dangerous. Experienced red teamers can go straight for the LLM-as-a-judge level and other advanced paths. Every level maps to a specific entry in the recently released OWASP Agentic Skills Top 10, so you leave with a concrete model of the skill attack surface.

Models are starting to make security decisions that used to be written as rules. Instead of matching an input against a policy, a model reads the request and decides what to do with it. OpenSearch is one of the first to put one in production as the only thing standing between an anonymous pull request and CI pipeline secrets.

When I reported a vulnerability, the team told me their model would catch it. So I tried to get past it the way you'd expect, hiding the attack. The model caught all of it, and going at it head-on wasn't going to work.

So I stopped trying to outsmart it and started thinking like it, reading why each attempt got caught until I understood what it could actually verify and what it only assumed. What got through in the end hid no attack, because the only dangerous part lived somewhere the model had no way to check.

This talk walks the whole path, from first failed attempt to the bypass that worked. Along the way I mapped the model's decision boundary - what it catches, what slips past, and how far an input bends before its judgment flips. The deeper gap is what it never sees at all, the blind spots built into how it reads a change. You'll see where a model can be trusted to make this call and where it can't, and what that means before you put one in front of something that matters.

Software development is becoming AI-assisted at every stage — design, coding, testing, bug fixing — and AI agents are increasingly doing it all. But do AI coding assistants actually write secure code by default? Most of the conversation around AI and security focuses on AI finding vulnerabilities. Far less attention goes to how state-of-the-art coding agents behave when they're the ones writing the software in the first place.

We built an automated harness to answer this directly — generating and evaluating over 2,500 code samples across multiple languages, models, and coding tasks, then scoring them with SAST tooling for introduced vulnerabilities. We tested vanilla generation against several security-steering approaches, from a single-line instruction file to a full set of layered security skills, to see which techniques move the needle, and at what cost.

In this talk, we'll walk through the harness architecture, share our full results — including where steering helped, where it hurt, and why — and lay out a practical framework for guiding coding agents toward secure defaults without paying an unsustainable token or performance tax. Attendees will walk away with a reusable methodology for evaluating their own AI coding assistants, and concrete, evidence-backed steering techniques they can apply immediately.

Key Takeaways
- A reusable methodology for benchmarking any coding assistant or model for security regressions before rolling it out to developers
- Evidence on which security-steering techniques actually reduce vulnerabilities, and by how much
- An understanding of the token-cost and latency tradeoffs of different steering approaches
- A practical framework for shifting security left into the AI-assisted SDLC

Coding agents went from novelty to daily driver in less than three years. Developers are now using AI to generate, test, and ship code as part of their normal workflow. But the way security communicates guidance has barely changed: findings buried in long documents, review comments that arrive after key decisions are already made, and requirements that are too vague for a developer to act on — let alone a coding agent.

The issue is not that developers do not care about security. It is that security intent often never reaches them in a form they can actually use.

So why did AI change the engineering workflow so quickly, while security reviews still look the same?

This talk looks at the structural reason behind that gap. Coding agents can only act on guidance that is specific, contextual, and executable. Most threat models and design review findings do not meet that bar. We will look at where review output breaks down in practice: findings that are technically true but not relevant, likelihood ratings that drift from reality, recommendations that are impossible to implement, and issues that no one knows how to translate into engineering work.

A human developer may be able to interpret a vague finding and make a judgment call. A coding agent will not. It will simply keep building without the missing security intent.

The second half of the talk focuses on what to do about it. We will present a practical framework for turning security review output into findings that are grounded in the real architecture, aware of existing controls, scoped to threats that actually apply, and written in a way that developers can act on.

Attendees will leave with a framework they can apply to their own design review or threat modeling process immediately, along with quality signals for measuring whether security findings are accurate, useful, and actually acted on.

Tauri is a fast-growing and rapidly adopted framework for building desktop applications, with 100k+ stars on GitHub, used by thousands of popular apps. When the v1 version of the framework was found to be insecure, v2 emerged as the secure solution. Our talk will provide an overview of Tauri’s security blind spots and demonstrate them through a full RCE exploitation using vulnerability chaining against a popular app ecosystem with 50k+ stars on GitHub, along with additional similar PoCs on popular apps. We will conclude by showing how Tauri developers can write more secure apps with the framework.

Ready to showcase your expertise? Don’t miss the chance to submit for a Call for Trainers or Call for Papers! Join the dynamic Izar Tarandach and Avi Douglen as they take you through the submission process and reveal insider tips on what the review team is looking for when selecting papers. This is your opportunity to shine and make a lasting impact—let’s make it happen!

**Must have laptop to participate**

You get a returns-desk agent in the browser. It can read tickets, fetch a URL, look up an order, send email, and issue a refund. The win is a side effect you choose: a refund, an email to an address you pick, or order data posted to a URL you control. We do not hand you the payload. You write the ticket, the tracking page, or the email the agent is asked to summarize.

Three stages, same app, tighter each time.

Beginner: tools are wide open. Chat injection even works.

Intermediate: the chat filter is on. You have to go through the page or the email. That is ASI01 Agent Goal Hijack.

Advanced: a static deny-list sits on issue_refund and send_email. The same string on lookup_order is fine. You have to get a call the list did not expect. Then we add fetch_url, and last round's rule is already wrong. That is ASI02 Tool Misuse.

Impossible: an in-process dispatcher hook is on. The attacks from the first three stages die at the tools/call. A reason shows up. You probably do not win. That is the point.

Each stage is a drop-in, under fifteen minutes. Laptop and a browser. Mapped to the OWASP Top 10 for Agentic Applications.

Many of us naturally drift from consuming OWASP resources to contributing to them. At some point you stop just reading the Top 10 and start showing up at a chapter, submitting a pull request, or volunteering at a conference. But what often gets lost is the "together" part. The shared strategy, the mutual encouragement, a place where experienced contributors can mentor others and people new to contributing can find their footing without having to figure it out alone.

It started when two of us ran into each other at the Boston Application Security Conference. Same organization, same department, had no idea the other was there. That conversation grew into three people, then a cross-regional group, and eventually an initiative with executive sponsorship built around a simple question: what if there was a structured space where people at all levels of OWASP engagement could come together, share what they know, coordinate where to show up, and help each other go deeper?

That is what we built. A space where seasoned contributors have a home for their work and a way to pass it on, and where people curious about OWASP but not sure where to start can learn, get mentored, and take their first real steps. Contribution gets tracked, progress gets shared, and the work gets recognized internally in ways it never was before.

In this talk we share our journey, what the initiative looks like in practice, what we have achieved together so far, and what you can take back to your own organization.

Most open-weight models are based on the GGUF standard distributed on a public hubs like HuggingFace ship with a chat template: a small Jinja2 program that runs on every inference call and formats the prompt before the model processes it. It is executable code, it sits between the user's input and the model, and in practice almost no one inspects it. We show that an attacker can plant a conditional backdoor by adding a few lines to a model's chat template. A backdoor this persistent would normally require poisoning the training data or editing the weights. The template version requires neither, and no foothold in the victim's systems: redistributing one modified file is enough. The model answers normally until a chosen trigger phrase appears in a request, at which point the template injects attacker instructions into the model's system context.

We give particular attention to how the model hub, Hugging Face, itself launders trust: the copied model card and the metadata viewer reassure the user, and a clean result from automated scanning (JFrog, ClamAV, etc.) does the same, while the template that actually executes is the one component none of them checks. The attack also reaches agentic deployments, where it becomes a working software supply chain compromise rather than output manipulation alone. Using opencode as the victim, we show a poisoned template directing a coding agent to install an adversary-controlled package while completing an ordinary task. Because the agent runs with the developer's privileges, that first action can cascade: the installed package can reach the developer's credentials and the code the developer themselves publishes, carrying the compromise to people downstream who never touched the original model. We close by showing the same template position used defensively, which points to where a durable fix belongs.

We release an open-source scanner that extracts a model's chat template and runs heuristics together with a shipped offline classifier we trained on a hub-scale corpus of templates, to flag the business-logic patterns this attack relies on. We have also proposed that chat templates become a first-class, signable component in the CycloneDX model SBOM standard. Attendees will leave able to extract and read the chat template from any GGUF file they download, recognize the patterns that indicate tampering, run the scanner against their own models at intake, and explain why the missing control is provenance for the template itself: a signature and hash that travel with it.

Q-Day, the moment a cryptographically relevant quantum computer (CRQC) breaks RSA, ECC, and Diffie-Hellman, has no confirmed date. But for any data with a long secrecy shelf life, it has effectively already happened: adversaries are harvesting encrypted traffic today to decrypt it later (HNDL). Meanwhile, governments have stopped waiting. The recent US Government Executive Order 14409 (June 2026) mandates post-quantum encryption for sensitive federal systems by the end of 2030, CNSA 2.0 requires quantum-safe software signing by 2030, and the EU, UK, Germany, and Australia have all converged on 2030-2035 deadlines. France's ANSSI will no longer certify products without quantum-safe encryption. The mandates exist. What most organizations lack is an executable engineering path.

This session presents a practitioner's migration playbook derived from hands-on work with enterprises beginning their post-quantum transitions. We separate the two halves of the problem that are routinely conflated: confidentiality, where hybrid key agreement (X25519MLKEM768) neutralizes harvest-now-decrypt-later immediately, and authentication and PKI, which is the harder, unfinished half that only matters once a CRQC exists. The session walks through where real migrations stall: hybrid handshakes that fragment across the MTU in QUIC, HSMs that cannot accelerate lattice math, the TLS 1.2 dead end, and the unresolved external mu debate in ML-DSA that risks cross-protocol divergence.

Attendees will leave with a combat-tested roadmap for enterprise PQC migration, a PQC maturity model with a concrete 90-day starting plan, a Cryptographic Bill of Materials (CBOM) template, a vendor briefing checklist, pilot project and a governance RACI model. We will cover how to conduct a cryptographic inventory (discovery), the necessity of "hybrid" key exchange (mixing X25519 with ML-KEM), testing for latency, key sizes, interoperability, and how security teams can upskill and execute rapidly.

Deployment of post-quantum TLS doesn't mean protection. PQC-enabled connections can be silently downgraded to classical cryptography, with no warning to either side. This false sense of protection, along with CDN configurations, often makes things worse. The session presents quantum threat and PQC standards, the findings of Fortune 500 readiness across different sectors, demonstrates how misconfiguration leads to downgrade, gives a PQC migration framework, and introduces AC Scanner, a free open-source tool to audit your own infrastructure.

We didn't set out to rethink Application Security.

Our goal was much simpler: remove repetitive security work without reducing engineering confidence.

Like many security teams, we began introducing AI into parts of our AppSec workflow—reviewing pull requests, proposing remediation, assisting with threat modeling, validating findings, and helping developers move faster without sacrificing security.

Some things improved almost immediately.

Others became unexpectedly harder.

The first surprise wasn't model quality—it was review capacity. As AI started proposing fixes faster than engineers could reasonably validate them, we discovered that generating secure code was no longer the difficult part. Deciding whether that code could be trusted was.

We also found ourselves asking questions we hadn't expected. Why were experienced reviewers approving changes they couldn't realistically read? Why were different AI workflows confidently disagreeing with each other? Why were we spending less time finding vulnerabilities and more time deciding which results deserved human attention?

As these experiments accumulated, one theme kept reappearing. The biggest shift wasn't simply that AI generated more code—it reduced the cost of implementation while exposing new bottlenecks in review, verification, governance, and evidence. That, in turn, led us to question several engineering assumptions that quietly shape today's AppSec practices.

This session shares the implementation journey behind those discoveries. Through practical engineering experiments, implementation mistakes, and lessons learned, we'll explore how familiar AppSec practices—including secure coding, threat modeling, SAST, DAST, CI/CD security, and supply chain security—continue to matter while evolving for AI-assisted software engineering.

This isn't a talk about replacing today's AppSec practices.

It's about understanding which assumptions continue to hold, which ones deserve to be revisited, and how security teams can evolve their existing programs for a world where generating software is becoming easier while proving software is trustworthy is becoming the harder engineering problem.

One clever message should not be able to empty a company's bank account. In an AI agent that reads email, browses the web, and calls internal tools, it absolutely can. This POD is a tabletop heist game where your crew plans exactly that attack, and learns why it works.

You sit down to a game mat showing a fictional company's AI agent: the things it reads (emails, web pages, documents, user chat), the brain in the middle, the tools it can call (send email, open tickets, read files, move money), and the crown jewels you are after. Your crew draws a mission, for example steal the customer database, wire money out, or make the agent quietly email every client.

Then you plan the heist with a deck of technique cards. You start from an entry point the agent trusts, like a web page it browses or a document it ingests, and chain cards together into a full attack: hide instructions in content the agent reads, turn its own tools against it, abuse the fact that it runs with more privilege than the user, and route your way to the target. You lay the chain on the mat and narrate it, step by step, like planning a break-in.

But the vault fights back. The facilitator plays defense cards onto the board, a human approval step here, a tool allowlist there, output filtering, provenance on retrieved content, and your crew has to find a way around them or watch the plan fall apart. Chains that reach the objective score, and the boldest, most creative chains score the most. Between rounds the facilitator connects each move to a real incident or technique, so you see this is not fantasy, it is what teams are defending against today.

No laptop, no security background needed. Newcomers learn the moves by joining a crew mid-heist, and experienced folks will be scheming multi-step chains and arguing about which defense actually stops them. You leave understanding how small, individually minor weaknesses combine into a serious attack on an AI agent, and which defenses break the chain.

Agent skills are the new soft underbelly of the AI supply chain. A skill is just a folder with a markdown file inside, a piece of prose that an AI agent discovers, loads, and obeys with the full authority of whatever it's already connected to. It might or might not contain an executable code, dependencies and other things we are familiar to, and that's why it's tricky to assess. Three lines of markdown can be enough to read a credentials file and exfiltrate it, and the marketplace "skill scanner" in front of it will show a green check.

This POD is a drop-in, multi-level challenge where you write the malicious skill and try to get it past a live detector. Each level adds a defense, and your job is to find the gap. You'll start with a plaintext payload that any scanner catches, then work through the evasion classes that beat real-world tooling: encoding wrappers, homoglyphs, runtime command reassembly, and injections aimed at the scanner's own LLM judge. Clear a level and the detector shows you why it missed (and what a scanner would have needed to do to catch you).

You submit each attempt from your own phone or laptop through a simple web form, so laptop is not required to play. Beginners can clear the early levels with a copy-paste and a small edit and leave understanding what a skill actually is and why it's dangerous. Experienced red teamers can go straight for the LLM-as-a-judge level and other advanced paths. Every level maps to a specific entry in the recently released OWASP Agentic Skills Top 10, so you leave with a concrete model of the skill attack surface.

There has been considerable discussion on how to use AI to find vulnerabilities, but very little discussion on how to use it to classify vulnerabilities. Given the huge backlog of vulnerabilities in our systems, and the impending agentic coding revolution which will 100x them, a new approach is needed to accurately cull and rank issues. In this talk, we discuss agentic classification vs. supervised learning-based classification, what other traits can be discerned besides simple "true or false positive", utilizing dynamic analysis techniques, frameworks for evaluation, confidence of results, strengths and weaknesses of generative AI in this task domain, and future research directions.

Problem Statement:

Security tools — SAST, DAST, IAST, SCA, and others — produce findings. Humans classify them. That process does not scale, and in practice it mostly doesn't happen — the majority of findings across the industry are never reviewed. False positive rates vary wildly by tool, rule, and codebase, but the deeper issue is that even *true* positives require judgment: is this exploitable in context? Are there compensating controls elsewhere? Is the reported severity accurate? This classification step — not detection — is where application security breaks down, and the problem compounds as AI-assisted code generation increases finding volume.

We set out to answer a practical question: what does it actually take to classify vulnerability findings with the accuracy and nuance of a senior security engineer? To find out, we ran a systematic bakeoff across a range of approaches — naive LLM prompting, supervised learning, multiple agentic architectures with different reasoning strategies, domain knowledge bases, and dynamic analysis techniques — evaluated against benchmarks constructed from real findings in real organizations across 15+ security tools. We compared structured decision trees against open-ended ReACT reasoning, tested how much domain-specific knowledge bases improve accuracy, measured the limits of attention-based analysis on complex multi-file data flows, and assessed when dynamic exploit verification is worth its cost. The results show where each approach succeeds, where it fails, and what combination gets closest to expert-level classification.

Engineering ships faster every quarter with AI assisted development, Security headcount grows slowly and the review backlog keeps growing at a rate you wish you didn’t know! This talk traces the struggles of building an AppSec function from scratch, through the scaling pain of supporting a fast-growing engineering organization, to the entirely new class of challenges created by the rise of AI-assisted software development.

And it starts with the pain. Building an AppSec function inside a fast-growing engineering org means years of playing catch-up: hiring into a market with a shortage of talent, onboarding people who take months to become productive and sitting at a security engineer-to-developer ratio of 1 to 2%(and 2& when you’re lucky!) that never meaningfully improves. Somewhere along the way, it can become the team that slows things down and that’s when engineering teams no longer want you onboarded and be part of their workflow.

Then AI changed the game much faster than anticipated and in ways we did not plan for: engineering velocity jumped, AI-generated code brought volumetric challenges at the “diff” level as well as at scale. And teams started building features on top of AI. This creates threat surfaces that weren’t present before and that threat actors have leveraged extensively since the beginning of the year. We are now fighting on two fronts: securing AI-powered features while keeping up with AI-accelerated development speed.

This talk covers how we responded with AI-powered (and non AI-powered) automations, and which hard decisions we had to take to enable those improvements to happen. We will explain the change in how we had to think about the solutions to match not only human expectations, but also work with AI-powered tools as well as the capacity cost of building these tools. We will also cover some of the challenges we faced (and are still facing) when we had to leverage AI solutions and how we think our team will evolve in the coming months.

Security review is getting squeezed from both sides. Product teams ship faster, GenAI has accelerated how quickly new features get built, and review teams are still expected to read each design doc from scratch and decide what can ship. That breaks down long before the roadmap slows down.

This talk shows an AI-assisted pre-launch review pattern built for that problem. The pipeline does not stop at generating a generic threat list or a dashboard for leadership. It starts with a structured risk taxonomy, mapped control expectations, and a corpus of historically reviewed launches. Given a PRD or design document for any new feature or application—not only GenAI products—it produces a reviewer-ready first pass: likely risks (from OWASP and internal), targeted follow-up questions, relevant control areas, and concrete mitigations grounded in both reviewer expertise and decisions that were approved in similar launches before. The same structure can support rollups for leadership, but the real value is at review time: better questions and earlier mitigations.

A key step is similarity-based retrieval over historical reviews. After the initial pass, the system looks for comparable launches and reuses the risks, control signals, and mitigation patterns that mattered in those cases. This helps recover issues that a single pass often misses and keeps the review grounded in how the organization actually makes launch decisions. Every completed review becomes another case in the corpus, so future reviews start from a richer set of approved precedents.

We will walk through the architecture, the feedback loop, and the places where this fails: thin design docs, stale taxonomies, misleading historical matches, and overconfident model output. We will also share results from a labeled benchmark of 19 PRDs and 205 human-reviewed risk labels. At a recall-oriented operating point, the pipeline reached 75% recall and 60% precision, and historical retrieval recovered 4–9 additional relevant threats per PRD on similar cases. Next steps including adding more data sources such as code repositories & live traffic.

The initial deployment focuses on fraud, but the pattern is being extended to other threat domains that matter in large product organizations, including abuse, privacy, and product security. This is not about replacing reviewers. It is about giving them leverage. Attendees will leave with a practical blueprint for turning blank-page review into a faster, more consistent workflow that surfaces mitigations before the design is already on its way to launch.

Since Anthropic released MCP as an open standard, enterprises have started adopting it as a common way to connect AI agents with tools, data sources, and business workflows. Many teams are now building MCP catalogs for internal developers, platform teams and external partners.

However, the security posture of these MCP servers is often not reviewed before they are added to a catalog or connected to an AI agent. In many cases, deeper security testing starts only after the MCP server is already in use.

Recent research has shown how a malicious or poorly reviewed MCP server can expose sensitive data, influence an agent’s behavior or override instructions given by the user. This makes MCP discovery an important early checkpoint for developer pre-flight checks, security approval, third-party MCP review, vendor or partner assessment and agent platform onboarding.

For traditional applications, software bills of materials (SBOMs) and configuration drift checks help teams understand what is being adopted and what has changed. MCP servers need a similar approach. In this talk, I will walk through a three-layer MCP BOM model: Discovery, Verified, and Runtime.

I will focus on the Discovery BOM and show how static MCP discovery can surface early indicators of tool poisoning, command injection and execution, context injection and over-sharing, credential-like inputs and risky tool capabilities. I will demonstrate this using an open-source tool that discovers MCP metadata and capabilities, runs static checks with YARA rules and maps findings to the OWASP MCP Top 10.

The goal is not just to scan an MCP server once, but to use discovery output as a pre-flight check: to review MCP servers before approval, detect MCP configuration and metadata changes in CI/CD, build safer MCP catalogs and create the first version of runtime monitoring and policy decisions.

Attendees will leave with a practical way to inspect MCP servers before agents use them, map exposed capabilities to OWASP MCP risks, compare MCP configuration drifts over time and answer a basic but important question during MCP security review: "What should be allowed, reviewed, or denied before the agent uses this MCP server?"

Recent attacks such as S1ngularity, Shai-Hulud, and the Trivy GitHub Actions compromise have shown that CI/CD pipelines are among the most attractive attack surfaces in modern software development. A single workflow misconfiguration can lead to remote code execution, credential theft, repository takeover, and software supply chain compromise.

This session introduces RepoHunter, an AI-driven research bot that combines static analysis with LLM reasoning to discover exploitable CI/CD workflows at scale. Built in just 48 hours, RepoHunter models real attack paths, prioritizes repositories by supply chain impact, and helps uncover vulnerabilities that traditional approaches often miss.

Using this methodology, I identified and responsibly disclosed more than 30 critical vulnerabilities across major open-source and enterprise projects, including repositories maintained by Microsoft, Red Hat, SAP, Ansible, Eclipse, Ceph, and QGIS. The research identified attack patterns—including CI/CD propagation and supply chain worm-like behavior—before they appeared in major real-world incidents. Later attacks, including the Trivy compromise, demonstrated these same techniques in practice.

Attendees will learn how these attacks work, why AI is changing vulnerability research, and how to combine static analysis with AI reasoning to find and prevent the next generation of CI/CD supply chain attacks.

Come wrap up the conference with us, hear special annoucements, and win prizes!

Connect Before the Conference Begins
The best conversations often happen before the first session! Join the ThreatModCon community for an evening of networking, drinks, and conversation with fellow threat modeling and security professionals. Whether you're a longtime member of the community or attending ThreatModCon for the first time on Saturday, this is a great opportunity to make connections and kick off your conference experience.
Register for ThreatModCon and use code OWASP to save $50 on your registration.