Conference Schedule & Speaker Directory

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: 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)Focus: Rapid toolkit synthesis and AI-driven infrastructure hardening.

• The Synthesis Workflow: Master LLM code generation, build disposable triage tools, and refine AI-generated security scripts.
• Engineering & Governance: Develop automated agentic playbooks, human/agent-readable security requirements, and standardized AI workflows.
• Hands-On Labs: Automate infrastructure lock-down (Docker, Terraform), map application sink points for auto-remediation, and programmatically verify fixes.

Day 2: The Architect of Trust (Agentic AppSec)Focus: Autonomous guardrails and validation for the Agentic SDLC.

• Securing Agentic Architecture: Implement strict function-calling schemas, execution sandboxing, and sanitization layers to prevent indirect prompt injection.
• Developer Enablement: Build scalable "Security-as-a-Service" and self-serve security recommendations for AI developers.
• Hands-On Labs: Lock down runtime containers, engineer automated secret rotation, and deploy WAFs to secure agentic systems.

Day 3: The Operator (Agentic Offense & Defense)Focus: Attacking and securing autonomous AI loops.

• The Offensive Lifecycle: Engineer agentic loops for autonomous reconnaissance, adaptive polymorphic payloads, and persistent access.
• Advanced Adversarialism: Develop and deploy custom attack and defense tooling to break and secure AI applications.
• Capstone Lab: The "Mini-Operator" Challenge

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
Trainer: Rob van der Veer

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

Watch Rob introduce the training and present some highlights of the courseware: https://www.youtube.com/watch?v=8K4v80-E40g

Be part of the world premiere of this proven training with a brand-new certification.

After breaking attendance records at OWASP events, this proven AI security training makes its US debut. And for the first time anywhere in the world, participants can combine the training with the opportunity to obtain the new EXIN AI Security Professional (AISP) certification. The training fee includes an exam voucher, allowing to take the official accredited certification exam after the course, to get formal recognition.

Learn more at aisp.exin.com.

Delivered personally by lead author of the courseware and founder of the OWASP AI Exchange Rob van der Veer, this is a unique opportunity to learn from the source and become part of the world's first certified cohort. Rob is Chief AI Officer at Software Improvement Group, with 34 years of experience in artificial intelligence, co-editor of the EU Act AI security standard, and expert for ISO 27090.

Who should attend?
Security professionals, software developers, AI engineers, red teamers, architects, or auditors are all helped by this course.
The training requires no advanced knowledge of AI or cybersecurity, although some experience in either field is helpful. Don't mistake accessibility for simplicity: the course covers cutting-edge developments in AI security, with insights and practical exercises that will challenge even experienced professionals.

What will you learn?
The course is based on the flagship OWASP AI Exchange (owaspai.org) project: the international, community-driven framework bringing together AI security threats, vulnerabilities, and controls. The framework provides foundational input for the international AI security standard ISO/IEC 27090 and the draft European AI security standard supporting the EU AI Act. 

This intensive, one-day training provides a structured and practical dive into AI security, covering both established threats and the latest developments in generative, agentic, and all AI.

Topics include:
- AI security fundamentals
- AI-specific threats
- Generative and agentic AI security
- Security controls
- Threat modelling and security testing
- AI governance, responsible AI
Through practical exercises, you will gain hands-on experience with attacking AI systems, applying security controls, performing AI threat modelling, and conducting targeted vulnerability assessments.

Practical information

- Participants receive essential course handouts.

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: 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)Focus: Rapid toolkit synthesis and AI-driven infrastructure hardening.

• The Synthesis Workflow: Master LLM code generation, build disposable triage tools, and refine AI-generated security scripts.
• Engineering & Governance: Develop automated agentic playbooks, human/agent-readable security requirements, and standardized AI workflows.
• Hands-On Labs: Automate infrastructure lock-down (Docker, Terraform), map application sink points for auto-remediation, and programmatically verify fixes.

Day 2: The Architect of Trust (Agentic AppSec)Focus: Autonomous guardrails and validation for the Agentic SDLC.

• Securing Agentic Architecture: Implement strict function-calling schemas, execution sandboxing, and sanitization layers to prevent indirect prompt injection.
• Developer Enablement: Build scalable "Security-as-a-Service" and self-serve security recommendations for AI developers.
• Hands-On Labs: Lock down runtime containers, engineer automated secret rotation, and deploy WAFs to secure agentic systems.

Day 3: The Operator (Agentic Offense & Defense)Focus: Attacking and securing autonomous AI loops.

• The Offensive Lifecycle: Engineer agentic loops for autonomous reconnaissance, adaptive polymorphic payloads, and persistent access.
• Advanced Adversarialism: Develop and deploy custom attack and defense tooling to break and secure AI applications.
• Capstone Lab: The "Mini-Operator" Challenge

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.

Advance Your Application Security Maturity with OWASP SAMM. Join us for a full-day event dedicated to real-world insights and practical guidance on application security maturity.

At the User Day, we are bringing together the OWASP SAMM community to:

- Understand how the AI paradigm has impacted the core model and its guidance

- Explore how leading organizations apply SAMM to drive meaningful security improvements

- Get insights into the latest OWASP SAMM benchmark data

- Participate in interactive sessions to learn from each other about how to advance application security maturity

Whether you're new to software security maturity models or leading enterprise-scale initiatives, you'll leave with actionable strategies and peer-tested practices to level up your secure development lifecycle, especially in today's increasingly AI-assisted world.

We are bringing together 7 speakers with a combined AppSec experience of over 100 years to share their SAMM experiences with the community.

Full agenda:

The AppSec Decision Trap: Why Great AppSec Programs Are Built on Better Decisions. [Max Alejandro Gómez-Sánchez Vergaray]

GRC? Ain't nobody got time for that! The rise of the PRC, (product risk and compliance) paradigm. [Dag Flachet]

Making SAMM audit-ready: mapping OWASP SAMM to the EN 40000 series for CRA compliance. [Nariman Aga-Tagiyev]

SAMM Benchmarking Project Updates. [Brian Glas]

From Report to Fix: Applying SAMM to AI Products. [Arshi Chadha]

Rebuilding Security for the AI-Native SDLC [Ken Johnson]

SAMM in the age of Agentic AI [Aram Hovsepyan]

To register, please purchase your reception ticket here. 

Come celebrate the start of the OWASP Global AppSec USA conference at the Kick off party, sponsored by Aikido, on Wednesday, November 4th from 6:30pm - 9:00pm. Location to be shared upon registration.

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!

Privacy risks are rarely obvious when looking at data, features, or apps in isolation. They emerge through changing context and are impacted by user perception.

In this POD, participants play Context & Cringe, a discussion-driven card game where players build fictional app scenarios using real-world data and features, then judge how those designs feel from a user’s perspective.

Rather than focusing on compliance or checklists, this session helps participants develop intuition for privacy impact by actively creating, debating, and experiencing cringey design choices. The result is a hands-on, low-barrier way to surface privacy risks that are often missed in a traditional security analysis - and a non-adversarial way to introduce uncomfortable topics into team discussions.

**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 executable code, dependencies and other things we are familiar with, 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 defense stack. Each level adds a layer (a pattern detector, an action authorization guard, then the scanner's own LLM judge), and your job is to find the gap. You'll start simple, then work through the evasion classes that beat real-world tooling - encoding wrappers, lookalike characters, runtime command reassembly, and injections aimed at the LLM judge - alongside the ways a trusted skill is turned against its host: stale approvals, symlink config overwrites, over-privileged keys, and tampered dependencies. Clear a level and it shows you why the defense missed (and what it would have needed to catch you).

You submit each attempt from your own phone or laptop through a simple web form, so a 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.

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

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

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

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

⭐ Building the OWASP AI Security Verification Standard (AISVS) (Project Showcawse)
AI security is moving quickly, but many organizations still lack a practical way to answer a basic question: "Is this AI-enabled application secure enough to ship?" Existing guidance often describes risks at a high level, but engineering teams need something more concrete: testable requirements, clear verification criteria, and a shared language between AppSec, AI engineering, product, governance, and security testing teams. 

The AI Security Verification Standard, or AISVS, is an attempt to close that gap. Inspired by the success of standards like OWASP ASVS, AISVS focuses on making AI security measurable and reviewable. It translates AI-specific risks into requirements that can be used during design review, implementation, testing, procurement, and production readiness. In this talk, we will share lessons from building AISVS: what makes AI security different from traditional AppSec, where conventional secure development guidance still applies, and where new verification categories are needed for prompts, models, agents, training data, retrieval-augmented generation, tool use, output handling, and AI governance.

Attendees will leave with a practical understanding of how AISVS can be used to evaluate AI-enabled systems and how verification standards can help bring structure to a rapidly changing AI security landscape.

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.

Scan a container image on any given day and you get back 200+ CVEs. Most are noise. A few are real. And there is no easy way to tell a developer "fix these three lines and you are good." That gap, between a scanner finding something and a developer actually fixing it, is where most container vulnerabilities go to die. The report comes back, the developer either ignores it or spends half a day searching each CVE, and the issues quietly get filed under accepted risk and forgotten.

OWASP DockSec was built to close that gap. It is an OWASP Lab Project and an open-source tool that does not try to be another scanner. Instead it runs the scanners you already trust, Trivy, Hadolint, and Docker Scout, locally on your machine, then uses AI to correlate their findings, strip out the duplicates and noise, rank what actually matters for your specific setup, and hand back plain-English explanations with exact, line-level Dockerfile fixes. It gives you a 0 to 100 security score so you can track posture over time, and exports reports to HTML, PDF, JSON, CSV, and Markdown so the security team and the developer are finally looking at the same artifact and able to act on it the same day.

This is a live, hands-on demo. I will take real Dockerfiles, including ones that pass standard scanning clean, run them through DockSec in front of you, and walk through exactly what it surfaces, why each issue matters, and the corrected lines it suggests. I will show the local-first privacy model where only scan metadata leaves your machine and image contents never do, the multi-LLM setup that lets you run OpenAI, Anthropic, Google Gemini, or fully local models through Ollama with no API key at all, and how to drop DockSec into a CI/CD pipeline so this happens automatically on every build.

Come with your own Dockerfiles if you want. This is a working session, not a slideshow. Whether you run a security team drowning in findings or you are a developer who just wants to ship a clean image without becoming a container security expert, you will leave knowing how to install DockSec, run it, read its output, and wire it into how your team already works. Bring questions. I want this to be a real conversation about where container security tooling is going and what still needs fixing.

OWASP CTF in a Box: Host Your Own Security CTF, from a Laptop to the Cloud

Hands-on security events are one of the best ways to build AppSec skills. Running one, though, has usually meant cloud accounts, ongoing bills and custom scoring infrastructure. OWASP CTF in a Box removes that overhead. It's an open-source, self-hosted platform that turns a free GitHub organization into a complete event, with team registration, a live leaderboard, an organizer console and automated scoring included. Start small on a single laptop or VPS, or deploy to Fly.io or AWS when the event grows.

The platform is modular, so each event can mix the formats that suit its audience:

- Secure Development: participants fork a deliberately vulnerable application and score by fixing it, which teaches defense rather than attack.
- Quiz and Jeopardy-style challenge boards for classic CTF play.
- AI security challenges hosted externally and connected to the same scoreboard.

In this demo you'll see the full life of an event, from setup to the final scoreboard, and learn how to:

- Launch an event in minutes, either with Docker Compose on your own hardware or with the ready-made Fly.io and AWS deployments.
- Run it live: open registration, schedule the scoring window, manage teams and hints, and pause or freeze scoring when you need to.
- Customize it with the modules, challenges and branding that fit your audience.
- Extend it by contributing new challenge modules to the OWASP community.

It's for OWASP chapter leaders, educators, student clubs, workshop organizers and AppSec teams who want to run a strong security event without becoming cloud operators.

Incident response is messy, collaborative, and high-pressure - so why is most training boring and unrealistic?
OWASP Malware & Monsters turns IR training into a game: story-driven, team-based simulations where participants hunt, contain, and outthink evolving
threats inspired by real malware.
Learn by doing, collaborate under pressure, and leave with a framework that actually sticks.

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.

Model Context Protocol (MCP) connects AI systems to tools, data sources, and the systems we use every day. That connectivity brings a new AppSec challenge: the attack surface extends beyond the application, API, or model to the trust and permissions that connect them. What happens when an agent trusts the wrong tool, follows instructions hidden in retrieved content, or has more access than its task requires?

Drawing on the OWASP MCP Top 10, this talk will explore tool poisoning, prompt injection through connected context, excessive permissions, secret leakage, malicious and unapproved MCP servers, unsafe tool chaining, and trust boundary confusion. Through practical examples, attendees will see how these risks interact and why conventional application testing needs to account for agents that retrieve information, make decisions, and act across multiple systems.

The session will also draw on the OWASP MCP Governance and Risk Project and the OWASP MCP Security Testing Guide to connect technical assessment with practical governance. I will walk through an approach to threat modeling MCP-based systems: mapping agent workflows, identifying trust boundaries, reviewing tool permissions, and designing runtime controls. Attendees will learn how to establish MCP server inventories, assess risk, assign ownership, and capture evidence of agent actions.

Attendees will leave with community-developed resources, checklists, and a clear starting point for assessing MCP security in their own environments before a helpful agent becomes an unexpected security incident.

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.

Get Ready To Fight Secrets Sprawl!
Plaintext credentials, aka secrets, are lurking throughout your environment. Your mission is to manually find any secrets throughout the cards containing code commits, Jira messages, logs, and Slack cards that would grant access to another system or decrypt data. But you need to balance speed with accuracy; each false positive or false negative has consequences!

And what do you do once you find a secret? Let's explore that together with the second part of the exercise to help you paint a roadmap towards a more secure and scalable future!

You want a mocktail. A fancy non-alcoholic drink. But you don't have time to browse through all your options. You ask the agent: "Order me a unique mocktail. Surprise me."

The agent checks the menu. Decides none of the options are "surprising" enough. Places orders for champagne, high-end vodka, and white truffle syrup. No prompt injection. No exploit. Just a strong desire to offer you a memorable drink.

In this round-table activity, we use printed cards describing agentic AI failures mapped to the OWASP Top 10 for Agentic Applications. Trace the identity chain. Find where the permissions failed. Create corrections. Three levels of difficulty. Come thirsty to learn more. Investigate what happened, and how to prevent the agent from going rogue again.

This session presents a practical approach to scaling threat modeling through reusable community threat libraries and AI-assisted workflows, demonstrated through OWASP Precogly, an Apache 2.0 licensed OWASP project.

We'll begin by examining a common challenge: organizations either threat model too little, focusing only on critical systems and major design reviews, or too inconsistently, with each team using different templates, taxonomies, and levels of rigor. The solution is not simply adding more security engineers. It is creating systems that allow security knowledge to be reused, shared, and applied consistently across teams.

The session will demonstrate how threat library packs can be used to scale threat modeling across an organization. These modular libraries contain technology-specific components, threats, and countermeasures for platforms such as AWS, Azure, Google Cloud, banking systems, and operational technology environments. Rather than starting with a blank page, teams begin with a curated foundation and adapt it to their architecture, improving both consistency and quality while reducing dependence on scarce application security resources.

We'll also explore how threat models can become valuable compliance and governance assets. Countermeasures can be mapped to frameworks including DORA, CRA, NIS2, OWASP ASVS, OWASP AISVS, NIST CSF, SOC 2, PCI DSS, HIPAA, ISO 27001, and IEC 62443. This allows a single security control to demonstrate compliance across multiple frameworks, reducing duplication of effort and improving traceability between security decisions and regulatory requirements.

We will also examine how established security taxonomies such as STRIDE, CAPEC, CWE, MITRE ATT&CK, and EMB3D can be integrated directly into the threat modeling process. These mappings support consistent categorization, improve communication between teams, and enable integration with the broader security ecosystem.

Finally, we'll discuss the role of AI in threat modeling. Rather than treating AI as a replacement for security practitioners, we'll demonstrate how AI can act as a bounded participant in the process, analyzing specific data flows, trust boundary crossings, and architectural elements while leaving judgment, prioritization, and risk acceptance decisions to humans. This approach produces more transparent and actionable results while maintaining meaningful human oversight.

The session concludes with a live walkthrough that builds a threat model from scratch, including architecture modeling, library pack selection, threat generation, countermeasure analysis, compliance mapping, and report generation.

Attendees will leave with:

* A practical framework for scaling threat modeling without proportionally scaling security headcount
* An understanding of how reusable threat libraries improve consistency and reduce the expertise barrier for development teams
* Techniques for connecting threat models to compliance and governance activities
* A realistic understanding of where AI adds value in threat modeling and where human oversight remains essential
* Familiarity with OWASP Precogly and related OWASP initiatives, including the emerging TM-BOM format for cross-tool interoperability, OpenCRE for cross-standards mapping, ASVS and AISVS for requirements mapping and of course, the OWASP Top 10s.

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.

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.

This panel will take a practical perspective of how people should plan their personal development in this new environment.

It includes a set of panelists with long experience in the AppSec/tech industry who can provide a more strategic perspective and personal insights on what they themselves have done. Note that the focus is on the individual's personal development and not on how organizations should be changing.

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.

Learn to identify security vulnerabilities in code, assess their impact, and recommend fixes using the OWASP Application Security Verification Standard (ASVS).

Through guided code review exercises, you'll learn to identify vulnerabilities across a range of categories and use ASVS to provide specific, actionable security feedback to developers. No setup required; just bring a laptop with a browser.

Come hack a multi-agent AI system live. OWASP Agentic AI Goat is a deliberately vulnerable platform with 17 LLM-powered agents, MCP tool-calling, RAG pipelines, and 66 intentional vulnerabilities spanning the OWASP LLM Top 10, MCP Top 10, and Web Top 10.

In this demo room you can:

Try the attacks yourself: prompt injection, RAG poisoning, MCP tool poisoning, privilege escalation through agent chaining, supply chain RCE
Play the 10-level CTF: extract secrets from progressively harder AI guardians with adaptive defenses that learn your techniques
Explore SecureShop v2: a full e-commerce app powered by 3 supervisors and 17 task agents, each with real exploitable sinks
Ask questions: architecture decisions, how to deploy for your team's training, how to contribute new agents or workshops
Get setup help: walk away with a working local install (Docker or native) on your laptop
No prior AI security experience required. Bring a laptop with Docker installed if you want to follow along.

Your database has PII you don't know about. So does your Jira.

OWASP PIIHunter is an open-source scanner that finds Personally Identifiable Information where engineers never think to look — buried in PostgreSQL columns, pasted into ticket comments, hiding in free-text notes fields. Three detection layers: regex with Luhn validation, ML-based NER via Microsoft Presidio, and an optional self-hosted LLM for ambiguous text. Zero data leaves your perimeter.

Live demo: we'll scan a real database and a live Jira instance, surface SSNs, phone numbers, and names hiding in plain sight, and catch a credit card in a ticket — in real time.

Your data isn't as clean as you think.

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 executable code, dependencies and other things we are familiar with, 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 defense stack. Each level adds a layer (a pattern detector, an action authorization guard, then the scanner's own LLM judge), and your job is to find the gap. You'll start simple, then work through the evasion classes that beat real-world tooling - encoding wrappers, lookalike characters, runtime command reassembly, and injections aimed at the LLM judge - alongside the ways a trusted skill is turned against its host: stale approvals, symlink config overwrites, over-privileged keys, and tampered dependencies. Clear a level and it shows you why the defense missed (and what it would have needed to catch you).

You submit each attempt from your own phone or laptop through a simple web form, so a 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.

AI applications are quickly becoming foundational to modern software systems, driving everything from personalization and automation to critical decision-making. But as these systems grow in complexity, so do the risks associated with their failure or exploitation. Traditional security assessments often struggles to account for the unpredictable nature of AI. Security Chaos Engineering offers a way to tackle this challenge.

In this talk, we’ll explore how to apply chaos engineering principles to AI systems with a focus on identifying and addressing security vulnerabilities before they become real threats. Attendees will learn how to design experiments that simulate realistic failure modes and adversarial conditions, such as poisoned training data, corrupted pipelines, prompt injection, or degraded model behavior. We'll look at practical techniques for injecting controlled security chaos into AI workflows.

OWASP Nettacker project (a portmanteau of "Network Attacker") is a relatively new yet an awesome and powerful 'swiss-army-knife' automated penetration testing framework fully written in Python. Nettacker recently gained a lot of interest from the European and Asian penetration testing communities and was even included in the specialist Linux distribution for penetration testers and security researchers. Nettacker is able to run various scans using a variety of methods and generate scan reports for applications and networks, including services, bugs, vulnerabilities, misconfigurations, default credentials and many other cool features - for example an ability to chain different scan methods. This talk will feature a live demo and several practical usage examples of how organisations can benefit from this OWASP project for automated security testing

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!!

Avi Douglen, Kim Wuyts and Francesco Cipollone will be at the Phoenix Security booth S4 to sign and give away a pack of the cyber card game: Context & Cringe Application Privacy Game.Packs are limited. Only 25 packs are available. However, we have 5 more packs to give away in the Phoenix raffle. 
Avi and Kim, who create the Cyber security games, will be happy to sign a copy of their most popular CyberSec Game Challenge. It is a fast-paced card game about application privacy, awkwardness, and real human impact that helps teams understand why privacy decisions matter.

Stay tuned

Purchase a book and receive a complimentary e-book version!

**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.

Get Ready To Fight Secrets Sprawl!
Plaintext credentials, aka secrets, are lurking throughout your environment. Your mission is to manually find any secrets throughout the cards containing code commits, Jira messages, logs, and Slack cards that would grant access to another system or decrypt data. But you need to balance speed with accuracy; each false positive or false negative has consequences!

And what do you do once you find a secret? Let's explore that together with the second part of the exercise to help you paint a roadmap towards a more secure and scalable future!

You want a mocktail. A fancy non-alcoholic drink. But you don't have time to browse through all your options. You ask the agent: "Order me a unique mocktail. Surprise me."

The agent checks the menu. Decides none of the options are "surprising" enough. Places orders for champagne, high-end vodka, and white truffle syrup. No prompt injection. No exploit. Just a strong desire to offer you a memorable drink.

In this round-table activity, we use printed cards describing agentic AI failures mapped to the OWASP Top 10 for Agentic Applications. Trace the identity chain. Find where the permissions failed. Create corrections. Three levels of difficulty. Come thirsty to learn more. Investigate what happened, and how to prevent the agent from going rogue again.

Booth S4.

Francesco Cipollone will sign the book "Securing the AI-Native SDLC," written in collaboration with the Cloud Security Alliance. Visitors can get this book at the Phoenix Security booth.
Izar Taranbach and Matthew Coles will sign the book "Threat Modelling". A practical guide for development teams". This book can be bought at OWASP bookstore and signed at Phoenix Security booth.

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.

The OWASP Certified Secure-Software Developer (OCSD) project is developing a certification program to help developers build the knowledge and skills needed to create secure software.
This presentation will explore the project’s journey, progress to date, and the relevance of secure development expertise in an era when tools such as Claude can generate applications in hours. As AI accelerates development, developers still need to understand security risks, evaluate generated code, and make informed decisions about the software they deliver.
The project has developed curriculum content supported by references from the OWASP body of knowledge. We invite contributors to help strengthen these resources by reviewing the curriculum, validating references, and recommending supplementary reading materials.

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!

Everyone agrees that threat modelling is valuable. Almost nobody does it for every feature. It needs scarce experts, it produces findings too broad to act on, and it's the first thing cut from the sprint.

Rapid Developer-driven Threat Modelling (RaD-TM) is an OWASP project that fixes this. Developers threat model a single feature, without a security expert in the room, using expert-curated Threat Templates. Six stages take a feature from requirements to a filed backlog in one short session.

In fifteen minutes we'll show the one idea that makes this work, the Threat Template. We'll then show why its tight structure makes RaD-TM unusually well suited to AI: a quick demo takes a real feature from user story to backlog tickets. We'll also name the two things AI must never be allowed to do. You'll leave knowing whether RaD-TM fits your team, and where to go to try it properly.

Outline

1. The problem (4 min). Three reasons threat modelling fails at scale: the expert bottleneck, the scope mismatch, and the workflow disconnect. That is why most teams model once, on one system, too late.
2. The fix (8 min). RaD-TM in one slide: six stages, scoped to one feature. The Threat Template is the core idea. It's a list of up to 20 threats with pre-approved controls and default severities, written by experts and used by developers.
3. AI demo (10 min). A "Transfer Funds" feature goes from user story to a threat list, control mapping and backlog tickets using the RaD-TM AI skills. The template grounds the AI's output, so it isn't inventing threats.
4. What stays human (4 min). Template authorship and accepting a risk. We explain why automating either one undermines everything else.
5. Next steps (4 min). Pilot with one team, one template and one sprint. Join the hands-on workshop to run it yourself, and find the OWASP project resources and skills on GitHub.

Key takeaways

1. Why feature-scoped, template-driven threat modelling succeeds where whole-application modelling stalls.
2. A clear picture of where AI helps with threat modelling and where it must not decide.
3. A path to trying it next sprint.

In December 2025 someone tried to break into a multi-tenant scanning platform. The submitted repository contained a symlink pointing at /proc/self/environ, a script designed to phone home, and a dependency pointing at an attacker-controlled server. What happens when the code you ingest runs?Analyzing a repository isn't always read-only. A config file can load executable checks, a package install can run lifecycle scripts, and a gemspec gets evaluated as Ruby code. Unsafe symlink handling can also expose files outside the submitted repository.
We tested 20 selected hosted platforms. Five exposed sensitive worker data or credentials: four through code execution and one through a file read. We used callbacks to identify which payloads triggered outbound requests, then follow-up tests to confirm execution or file access and the sensitive data exposed.
I'll use those findings to walk through an example architecture for a hosted scanning service built around third-party tools. We'll start with what the service needs to do, then separate analysis from the credentials used to fetch inputs and publish findings. We'll cover limits on file access, network access, and resource use, including what an attacker can still do within those limits.
I'll show how to test that required scans work while forbidden access fails, using evidence collected outside the scan worker. I'll also show how to use Build Canaries, an open-source, MIT-licensed tool, to generate test repositories for your own service.

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.

*THIS EVENT IS FOR THE APPSEC COMMUNITY*

Arnica and Prime Security invite you to an evening of cocktails, conversation, and bites to wind down after OWASP San Francisco Day 1.
Join us at Bar Sprezzatura, just a 2-minute drive or 9-minute walk from the OWASP venue, where we’ll take over their heated outdoor patio for a relaxed evening with the AppSec community.
With design, development, testing, and runtime experts all in the room, your entire AI-native AppSec toolchain will be covered in a single evening.
🏀 Plus, we’re ending the night with a slam dunk: one lucky guest will win an Ultra Club ticket to see the Golden State Warriors take on the Orlando Magic at Chase Center on November 7th!
Come for the conversation, stay for the cocktails, and you might just leave with a Warriors ticket. 🏁🏀

What are ✨Ultra Club✨ seats?:
The Ultra Club at Chase Center offers a premium two-story experience for guests in Sections 113–118, featuring a 100-foot bar, incredible court views, craft cocktails, and elevated dining. It’s the perfect social hub for fans looking to enjoy the game in a lively, upscale setting.

Good food. Strong opinions. Security people. It just doesn't get better.
Join Amplify Security and Root Evidence for dinner and drinks at Blackwood Thai, with Jeremiah Grossman, CEO of Root Evidence and SF OWASP 2026 keynote speaker, and Ali Mesdaq, CEO of Amplify Security.
It's an evening of Thai food, cocktails, and candid conversation with fellow security practitioners. Bring the problem you’re wrestling with, the opinion you can’t put on LinkedIn, or simply an appetite.
Pull up a chair. Reserve your spot today. Space is limited & we can't wait to see you!

Wrap up day one of OWASP Global AppSec with Maze at the Hyatt Regency, where the hallway conversations keep going over good drinks and passed bites.
Whether you want to catch up with people you only see at conferences, compare notes on the day’s talks, or meet more of the AppSec community in town for the week, come hang out! No talks, no slides.
Spots are limited and registration is required. RSVP today to save your spot.

Right in the conference hotel, no walk needed!

https://mazehq.com/event/owasp-global-appsec-reception-hyatt-regency

The talks are done. Time to talk shop. Join the Jscrambler team and fellow AppSec folks at Perry’s Embarcadero for drinks, good food and conversations you won’t hear on the main stage.

Thursday, November 5 · 7:00–9:00 PM Perry’s Embarcadero, 155 Steuart St, San Francisco, CA 94105 (Map)

On the menu:Rogue AI agents, LLM vulns and AI-generated codeHot takes on what’s overhyped (and what isn’t)War stories from the fieldDrinks, bites and zero awkward icebreakers
No slides. No pitches. No name-tag bingo. Just AppSec people and real talk.Come find Pedro, Sean and Jeffrey. We’ll save you a seat.

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.

Five Hours. Three Rounds. Three Chances to Win.
Team ArmorCode invites security leaders and engineers to a hands-on Capture the Flag (CTF) competition to put their exposure management skills to the test.

Join us on November 6, from 10 AM–3 PM PST. Drop in anytime during the competition window, tackle challenges at your own pace, and race up the leaderboard for a chance to take home one of three prizes:

Competition round: 
10:00–11:40 AM PST.  Prize: WiFi Pineapple Mark VII Basic
11:40 AM–1:20 PM PST. Prize: Screen Crab
1:20–3:00 PM PST. Prize: WiFi Pineapple Pager

New challenges drop at the start of each round, and the leaderboard resets—giving you a fresh chance to win. The player with the most correct solves when the round closes wins its prize. If players tie, whoever reached that solve count first wins. One prize per person; previous winners can keep playing for bragging rights.
Refreshments will be available in the room throughout the event.

Bring your curiosity. Find the flags. Race the clock.

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.

Get Ready To Fight Secrets Sprawl!
Plaintext credentials, aka secrets, are lurking throughout your environment. Your mission is to manually find any secrets throughout the cards containing code commits, Jira messages, logs, and Slack cards that would grant access to another system or decrypt data. But you need to balance speed with accuracy; each false positive or false negative has consequences!

And what do you do once you find a secret? Let's explore that together with the second part of the exercise to help you paint a roadmap towards a more secure and scalable future!

You want a mocktail. A fancy non-alcoholic drink. But you don't have time to browse through all your options. You ask the agent: "Order me a unique mocktail. Surprise me."

The agent checks the menu. Decides none of the options are "surprising" enough. Places orders for champagne, high-end vodka, and white truffle syrup. No prompt injection. No exploit. Just a strong desire to offer you a memorable drink.

In this round-table activity, we use printed cards describing agentic AI failures mapped to the OWASP Top 10 for Agentic Applications. Trace the identity chain. Find where the permissions failed. Create corrections. Three levels of difficulty. Come thirsty to learn more. Investigate what happened, and how to prevent the agent from going rogue again.

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.

For eight years, CycloneDX has answered one question well: what is in it? Regulators, customers, and security teams now ask harder ones. What does it do? What could go wrong? Which controls are in place, and how do you know?
CycloneDX 2.0 answers them. It evolves from a bill of materials into a Transparency Exchange Language: a modular fabric that weaves components, threats, risks, controls, behaviors, and evidence into one linked graph, exchanged as a portable file or through an API.

This session traces the industry's shift from assertions to claims to evidence, and shows how 2.0 encodes each step so assurance becomes verifiable rather than promised. We will tour hardware and material inventory with provenance down to where materials were mined and smelted; threat modeling with threat scenarios, attack trees, and attack paths across STRIDE, LINDDUN, MAESTRO, and MITRE ATT&CK weaknesses as the source of risk; and a risk model that carries FAIR, OWASP Risk Rating, FMEA, NIST SP 800-30, or your own method without forcing a translation.

We will show how controls become first-class objects, so GRC engineering can prescribe controls as data and organizations can publish verified control inventories. Threat modelers, GRC, vulnerability management, and threat intelligence teams finally share one machine-readable language instead of spreadsheets and meetings.

Finally, we will explore blueprints and behaviors: what systems actually do, declared versus observed. That distinction exposes shadow AI and agentic activity no inventory can see, and turns a cryptographic inventory into practical post-quantum readiness by revealing how keys are used and whether algorithms can change.
Attendees will leave knowing what 2.0 delivers, what is still in development, and how to put it to work.

Key takeaways

• How 2.0 moves supply chain transparency from assertions to evidence-backed assurance
• How to represent threats, weaknesses, risk, and controls in one standard, regardless of the frameworks your organization uses
• How declared and observed behaviors reveal shadow AI and drive post-quantum cryptography migration

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.

How do you actually verify that an AI system is secure? In this workshop, the AISVS project leads walk through practical assessment scenarios using the OWASP AI Security Verification Standard. We'll work through real requirements from chapters on prompt injection defense, agentic action security, RAG/vector database hardening, and output safety controls, showing what "verify that" looks like in practice against running systems. Participants will leave with a working understanding of how to scope an AI security assessment, select appropriate verification levels, and apply AISVS requirements to LLM-based applications, autonomous agents, and MCP-connected tool ecosystems. Bring a laptop if you want to follow along.

Threat modelling fails at scale for predictable reasons: it depends on scarce experts, it produces artifacts too broad to act on, and it sits outside the developer workflow. Rapid Developer-driven Threat Modelling (RaD-TM), an OWASP project, solves this with a lightweight six-stage method. Its expert-curated Threat Templates let developers model a single feature in one short session.
This workshop is almost entirely hands-on. In small groups, you'll threat model a realistic financial feature by hand through all six stages. Then you'll switch to the security expert's role and write your own Threat Template. Finally, you'll run the same process with the RaD-TM AI skills against a sample codebase, compare the AI's output with your own, and practise the judgment calls that must stay with humans.
You'll leave with a completed threat model, a starter template you wrote yourself, working AI skills, and a one-page plan to pilot RaD-TM with your team next sprint.
What participants need

1. A laptop with a browser and Git.
2. Access to an AI assistant that can load skills or custom instructions. We demo with Claude, and alternatives are documented in the repo.
3. No security expertise. Familiarity with the SDLC is helpful. 
   

What we provideA GitHub repo containing the sample payments app (spec, user stories, API definition, IaC and a sample PR), the worksheets, two complete example templates (STRIDE and PCI DSS), a blank template scaffold, both AI skills, and the pilot-plan template. Everything is openly licensed through the OWASP project.

Key takeaways

• Hands-on experience running all six RaD-TM stages on a real feature.
• A Threat Template you wrote yourself, plus a repeatable way to build a starter library from OWASP and compliance resources.
• Working AI skills and first-hand evidence of where AI speeds up threat modelling and where it goes wrong without good templates and human review.
• A concrete pilot plan for your own team.

Agenda
1. Why threat modelling breaks, and the RaD-TM fix (0:00–0:20)
A short framing talk. We cover the three failure modes and the six stages, and explain why the Threat Template is the key idea. Groups form (3–4 people) and pick roles: developer, security champion and reviewer.

2. Run RaD-TM by hand (0:20–1:20)
Groups work through the "Transfer Funds" feature in a sample payments app using printed or digital worksheets. Each stage is timeboxed with a short facilitator debrief:

• Stage 1–2: Draw the data-flow diagram and mark the trust boundaries (15 min).
• Stage 3: Apply the PCI DSS and Secure Code Implementation templates, and merge them into one threat list (15 min).
• Stage 4: Map the controls as implemented, partial or not implemented, with a rationale for each (10 min).
• Stage 5: Rate severity and set a status. Groups must defend one "Accepted" decision (10 min).
• Stage 6: Write backlog tickets using the RaD-TM ticket template (10 min). 

Break (1:20–1:30)
3. Author a Threat Template (1:30–2:10)
Groups switch to the security expert's role. Starting from an OWASP resource (ASVS, the Top 10:2025, or the LLM Top 10 for an AI-feature template), each group writes a template of up to 20 threats. They choose threats, map controls, set default severities and add version metadata. Groups then swap templates and review each other's for gaps and ambiguity. We also cover governance: version control next to code, choosing among several templates, and feeding template updates back into existing models.
4. RaD-TM with AI (2:10–2:50)
Participants load the two RaD-TM AI skills: the developer-facing six-stage skill and the template-authoring skill.

• Run the six-stage skill on the same feature, using the spec, pull request and infrastructure-as-code from the sample repo. Compare the AI's output with your manual model: what it caught, what it missed, and what it got confidently wrong.
• Run it again using the template your group wrote in Part 3. See how template quality directly changes the AI's output.
• Human judgment exercise: the AI proposes risk acceptances, and groups must overrule or approve each one with a reason.

5. Take it home (2:50–3:00)
Each participant fills in a one-page pilot plan: which team, which template, which sprint, and who writes the first template. We finish with pointers to the OWASP project, the skills repo and how to contribute templates back.

SecretSifter is an open-source passive scanner that detects live credentials in production web application traffic as it flows through a browser session. It needs no source code access, no active probing, and no credential configuration. The scanner watches what the application serves and flags what should not be there.

The demo runs three scenarios against a purpose-built intentionally vulnerable web application running entirely offline.

Scenario 1 covers an Azure AD credential chain. SecretSifter passively collects an Azure AD AppID, AppKey, Resource URI, and APIM SubscriptionKey from JavaScript bundles loaded during normal browsing. The demo then shows how those four values combine to mint a Bearer token against the Azure AD token endpoint and reach protected API endpoints.

Scenario 2 covers a CryptoJS encrypted configuration. SecretSifter identifies a CryptoJS-AES encrypted blob and its co-located decryption key in the same JavaScript file. Manual decryption recovers the underlying credential set.

Scenario 3 puts the tool in context. A brief walkthrough of GT-194, a benchmark of 194 confirmed production secrets across 113 enterprise applications, shows where SecretSifter adds coverage that static tools miss: 77.8% recall versus 36.6% for the best static scanner, with a remaining 13.9% structural blind spot that no pattern-based tool closes.

SecretSifter runs as a Burp Suite extension, a Chrome and Firefox browser extension, and a standalone desktop application. All three interfaces are shown during the demo.

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.

Application security guidance has a discovery problem. The field's best work — OWASP's cheat sheets, testing guides, verification standards, and code — is scattered across hundreds of repositories, wikis, and PDFs. It's voluminous, inconsistent, occasionally contradictory, and riddled with stale cross-references. OWASP holds some of the best-kept secrets in security, and most practitioners never find them. Generative models have made this worse, not better: drafts, summaries, and "best practices" now land every week, and no team can manually track what changed, what conflicts, or what actually applies to their stack.

That's why we built the OWASP Agent.
Powered by Project OIE (the OpenCRE Information Engine), the OWASP Agent is an autonomous pipeline over OWASP's living body of knowledge. It continuously harvests OWASP sources, filters noise, maps relevant passages to Common Requirement Enumeration (CRE) nodes, and routes uncertain links to human reviewers. Instead of chasing documents by hand, practitioners get one queryable view across cheat sheets, testing guides, repo updates, and formal standards — grounded in the CRE graph and available through OpenCRE and its API.

But this is more than an OWASP search box. It's a blueprint for unlocking any corpus of policy, standards, and guidelines: map the content to a shared taxonomy at the semantic level, then layer a grounded RAG system on top to answer questions, expose MCP services to agents, and generate bespoke standards for a specific use case and technology stack at the press of a button.

This talk marks the public launch. We'll cover the problem we set out to solve, how the four-module architecture works, what shipped over the past year and during GSoC 2026, and where the OWASP Agent goes next: web pages, RSS feeds, and security corpora well beyond GitHub markdown.

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.

Privacy risks are rarely obvious when looking at data, features, or apps in isolation. They emerge through changing context and are impacted by user perception.

In this POD, participants play Context & Cringe, a discussion-driven card game where players build fictional app scenarios using real-world data and features, then judge how those designs feel from a user’s perspective.

Rather than focusing on compliance or checklists, this session helps participants develop intuition for privacy impact by actively creating, debating, and experiencing cringey design choices. The result is a hands-on, low-barrier way to surface privacy risks that are often missed in a traditional security analysis - and a non-adversarial way to introduce uncomfortable topics into team discussions.

**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 executable code, dependencies and other things we are familiar with, 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 defense stack. Each level adds a layer (a pattern detector, an action authorization guard, then the scanner's own LLM judge), and your job is to find the gap. You'll start simple, then work through the evasion classes that beat real-world tooling - encoding wrappers, lookalike characters, runtime command reassembly, and injections aimed at the LLM judge - alongside the ways a trusted skill is turned against its host: stale approvals, symlink config overwrites, over-privileged keys, and tampered dependencies. Clear a level and it shows you why the defense missed (and what it would have needed to catch you).

You submit each attempt from your own phone or laptop through a simple web form, so a 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.

As autonomous agents evolve from stateless chatbots to persistent systems with long-term memory, they inherit a massive new attack surface. "Agent Memory Guard" explores the critical security vulnerabilities introduced when agents can read, write, and act upon persistent context across sessions. This talk dissects real-world failure modes—such as memory poisoning, cross-tenant data leakage, and persistent prompt injection—and introduces a robust architectural framework for securing agent memory. Attendees will learn how to implement cryptographic memory signing, context-aware access controls, and adversarial memory sanitization to build agents that remember safely.

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.

This panel brings together security practitioners from large/high profile organizations to talk about how they have adapted their AppSec programmes to the craziness of the last few years and also how they are using AI to help achieve this.

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!

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.

The OWASP Amass Project has become a foundational toolset for security researchers, bug bounty hunters, red teamers, and defenders who rely on automated reconnaissance and external asset discovery to map attack surfaces. With the release of Amass v5.0, the project has undergone a major architectural transformation centered around the Open Asset Model (OAM)—a structured property graph that defines how Internet-facing assets and their relationships are stored, analyzed, and queried.

This two-hour hands-on workshop, led by Jeff Foley, the project’s founder and long-time maintainer, offers attendees a first look at Amass v5.0’s new intelligence collection engine, which seamlessly populates the Open Asset Model database during enumeration operations. The session will walk through how Amass collects and organizes OSINT from various sources—including DNS records, WHOIS/RDAP data, TLS certificates, and more—and models the results as a dynamic graph of properties and relationships between discovered assets.

Participants will learn to use core Amass tools such as:

amass enum – for deep, recursive asset discovery using passive and active techniques

amass subs – for quick subdomain discovery from the Open Asset Model database

amass viz – to render interactive visualizations of asset relationships in the Open Asset Model

In addition to these staples, the workshop will introduce the new assoc tool, a powerful query interface designed to unlock the true potential of the Open Asset Model database. Built around a custom Triples query language, the assoc tool enables users to describe paths—called association walks—through the asset graph, surfacing linked insights across related properties (e.g., domains associated with a network, IPs linked to DNS records, etc.). The language is inspired by RDF-style triples but optimized for simplicity and clarity in cybersecurity investigations.

Amass v5.0 also ships with completely refactored documentation, providing diagrams to help users understand the data types, their fields, and their associations within the OAM. This new documentation dramatically lowers the learning curve for users new to the Amass Project, making it easier to build mental models of how different types of Internet assets are discovered and interrelated.

This workshop will include a live walkthrough of setting up and running Amass v5.0, from enumeration to advanced queries. Participants will leave with hands-on experience using the full Amass suite, understanding how the Open Asset Model works under the hood, and writing association walk queries using Tr

Most threat modeling tools stop at the diagram. You draw data flows, brainstorm threats, and produce a document that rarely gets revisited. The gaps are familiar: generic threat suggestions with no depth, no connection to compliance requirements, no way to track whether countermeasures actually got implemented, and no validation against real-world findings. 

OWASP Precogly is an open-source threat modeling platform built to close those gaps. In this demo, you will see how to:

- Start modeling in seconds with a guest mode that requires no signup, so your team (and this audience) can try it with zero friction
- Build multi-level data flow diagrams with nested component decomposition, trust zones, and trust boundaries, all in one model instead of separate flat diagrams
- Import curated library packs for AWS, Azure, GCP, and more, so teams reuse proven threat knowledge instead of starting from scratch every time
- Map threats across taxonomies simultaneously: STRIDE, MITRE ATT&CK, CAPEC, CWE, and LINDDUN in a single unified view
- Track countermeasures as real work items with lifecycle statuses, effectiveness scores, evidence URLs, and verification types, not just free-text notes. 
- Trace countermeasures to compliance requirements across OWASP ASVS, NIST CSF, DORA, PCI-DSS, and more, replacing the
spreadsheets teams maintain alongside their threat models
- Score risk using the methodology your organization requires: 5x5 matrix, FAIR, OWASP Risk Rating, or Mozilla Rapid Risk Assessment
- Reconcile pentest findings against the threat model to see what you predicted, what you missed, and where to improve
- Generate stakeholder-ready reports (Executive, Technical, Compliance) with configurable depth and DOCX export
- Export everything as open-format TM-BOM JSON with no vendor lock-in
- Accelerate threat modeling with an AI layer (either via the built-in MCP server or the "Precogly Skills") without sacrificing the journey of understanding which is so essential to effective threat modeling.

Precogly is an OWASP project. All source code is open and community-driven. Documentation is available at https://precogly.github.io/precogly/.

**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.

Get Ready To Fight Secrets Sprawl!
Plaintext credentials, aka secrets, are lurking throughout your environment. Your mission is to manually find any secrets throughout the cards containing code commits, Jira messages, logs, and Slack cards that would grant access to another system or decrypt data. But you need to balance speed with accuracy; each false positive or false negative has consequences!

And what do you do once you find a secret? Let's explore that together with the second part of the exercise to help you paint a roadmap towards a more secure and scalable future!

You want a mocktail. A fancy non-alcoholic drink. But you don't have time to browse through all your options. You ask the agent: "Order me a unique mocktail. Surprise me."

The agent checks the menu. Decides none of the options are "surprising" enough. Places orders for champagne, high-end vodka, and white truffle syrup. No prompt injection. No exploit. Just a strong desire to offer you a memorable drink.

In this round-table activity, we use printed cards describing agentic AI failures mapped to the OWASP Top 10 for Agentic Applications. Trace the identity chain. Find where the permissions failed. Create corrections. Three levels of difficulty. Come thirsty to learn more. Investigate what happened, and how to prevent the agent from going rogue again.

AI is writing and re-writing mountains code, your supply chain is an attack surface, and your development pipeline is too much for traditional AppSec to handle. A faster 2020 AppSec program with more people, is still a 2020 program. We need an entirely new model. Come examine how to vibe with developers and give your security program a greater impact. This talk features The Securable Framework: OWASP FIASSE and the rest of the OWASP ecosystem.

OWASP FIASSE is the first development-first OWASP project/standard/framework. It recently reached its first public release milestone. It is specifically designed to complement other assurance and requirements focused OWASP projects. We will introduce the driving ideas behind the project and take a deep dive into the principles that drive securable software. I will also connect and differentiate it from other projects like ASVS, SAMM and Top 10 lists. What is new is a repositioning of find-and-fix, SLAs, an agentic refinement on shift-left powered by FIASSE and ASVS.

# Outline
Intro
Traditional AppSec issues
A Layered Structure
- Requirements
- IDE/Agent
- Merge Review
- Find-n-Fix
- SBOM + Attestation
- Behavioral monitoring
The Feedback Loop
Securability

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.

Privacy tooling for developers and security teams is still catching up to where AppSec was a decade ago. This talk gives an update on the work closing that gap, from the standpoint of treating privacy the way we already treat security: with testable requirements, structured severity, and tooling built for engineers, not just auditors.

Our current efforts are centered around the Application Privacy Verification Standard (APVS), a technical, atomic verification standard for privacy: the closest thing to an ASVS equivalent that privacy has had. As APVS continues to mature, we'll walk through the decisions that shaped its structure: how it's leveled, how it stays testable and implementable rather than becoming another audit checklist. Expect concrete detail on categories and requirements, how to actually put it to use as a dev team baseline, reviewer checklist, or vendor-assessment tool, plus a few behind-the-scenes stories from the build.

APVS isn't the whole picture, though. We'll also introduce Privacy Weakness Scoring, an effort to give privacy issues the kind of structured, comparable severity scoring that security has long had with CWSS.

Beyond these two, there are other resources in active development that will have taken further shape by the time of this talk. We'll give a state-of-play view of what's coming, and where the community can plug in and contribute while things are still being built.

We'll give you a grounded look at what privacy engineering tooling looks like when it's built with the same rigor as AppSec's.

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 executable code, dependencies and other things we are familiar with, 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 defense stack. Each level adds a layer (a pattern detector, an action authorization guard, then the scanner's own LLM judge), and your job is to find the gap. You'll start simple, then work through the evasion classes that beat real-world tooling - encoding wrappers, lookalike characters, runtime command reassembly, and injections aimed at the LLM judge - alongside the ways a trusted skill is turned against its host: stale approvals, symlink config overwrites, over-privileged keys, and tampered dependencies. Clear a level and it shows you why the defense missed (and what it would have needed to catch you).

You submit each attempt from your own phone or laptop through a simple web form, so a 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.

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.

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.

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.